Use consistent module layout and naming

[tilgovi]

Move every module in the contexts directory to the components directory. Name each one with a consistent suffix "Context" suffix. From each one, export the context and the context value interface.

For every context module, ensure there is a corresponding module with a component that wraps the provider. These modules do not have any suffix.

Move the useLayoutGroupEffect hook into the hooks directory. Fix all of the remaining references to the old "deferred layout effects" naming.

Export only a single EditorProps type that is the type of the props for the ProseMirror and Editor components. Hooks do not export their types.

Make all of the exports in the barrel module consistent.

Rename PortalRegistry to NodeViews.

[tilgovi]

I based this loosely on what react-redux does, where Context and Provider are both in a components directory. It makes sense. Even though we're exporting a context, a context object is an object with Provider and Consumer attributes that are components. So, these are also components. Keeping it all together in the components directory seems simpler.

To get a feel for this change, mostly just look at the changes to src/index.js.

[tilgovi]

I don't think changing the naming of the portal registry should affect anyone. We don't have that documented as public interface. Mostly, folks should just be calling renderNodeViews. But now useNodeViews is consistent with NodeViews and NodeViewsContext and it's clearer that they all work together.

[tilgovi]

I actually have a little more to clean up here. Hmm. I am just getting hung up on the React EditorProps vs the ProseMirror EditorProps.

[tilgovi]

Okay, this should be ready to go now.

[eelzon]

I'm a fan of the export naming changes especially -- makes it a lot easier to read the index.js file when getting oriented in what features are available to import!

[smoores-dev]

I don't think this should be a blocking sentiment, just a slight modification to consider:

It feels a little weird to me that the contexts are in their own files in the components directory. I think I could get behind putting all of the Contexts, split out as they are now, in a contexts directory, and even maybe putting all of the context definitions inside their corresponding component definition files. But contexts are more than just components, and are also used by hooks, which is why it feels a little weird to have them live alongside components.

Anyway, the other comment is more important I think, this one is just something I wanted to throw out there.

[tilgovi]

It feels a little weird to me that the contexts are in their own files in the components directory.

I was a bit on the fence, myself, but I've grown to like it. They aren't components, but their .Provider and .Context are. We do call useContext, of course, but even so, contexts are kinda "in" the component tree.

[tilgovi]

This was necessary because React doesn't want to let us make an interface type that's indexable by a unique symbol. With this change, our interface can be this:

export interface NodeViewsContextValue {
  [key: NodeKey]: NodeViewRegistration[];
}

[tilgovi]

If you're unconvinced by the Context argument, I really don't mind moving them back to a contexts.

[smoores-dev]

If you're unconvinced by the Context argument, I really don't mind moving them back to a contexts.

Hahaha ok, I appreciate that; I am indeed unconvinced.

[tilgovi]

Okay. Contexts are back where you want them!

[smoores-dev]

I think the readme formatting needs to be adjusted

[tilgovi]

I think the readme formatting needs to be adjusted

Where are you seeing an issue? I just glanced at the rendered markdown and don't see it.

[tilgovi]

Oh. Prettier!

[tilgovi]

Okay. We're all green.

[tilgovi]

@smoores-dev let me know if you find anything else!