Planning: What's the path to merging react-editor-view?

[smoores-dev]

Hey all! I've been spending some time getting the full prosemirror-view test suite passing, addressing feedback, fixing bugs, etc, and the react-editor-view branch is feeling pretty robust to me, at this point. I wanted to chat with you all about what it would look like to make this the mainline branch.

I exclusively recommend that folks use the react-editor-view branch, at this point, and I know of at least a few folks that are using it in production for complex rich text editors. It's easier to reason about and has fewer edge cases to worry about as a developer.

I know that getting the Times onto the react-editor-view branch is a pretty big endeavor, and not something to be rushed. I have been wondering if we should try to keep the current mainline branch alive for the Times until you're able to move onto the new implementation, so that mainlining react-editor-view doesn't have to be blocked by the Times internal usage.

Tagging some folks that I suspect will be interested in this conversation: @coolov @saranrapjs @tilgovi @gabrielainsf. Please invite anyone else who may be interested that I've missed!

[saranrapjs]

I'd be up for seeing what getting the react-editor-view published versions looks like in some of our non-Oak code. It's less likely to exhaustively test/exercise all of the changes, but it's also potentially less risky right now to try something like this out.

[smoores-dev]

That would be awesome! Definitely let me know how I can help with this!

[tilgovi]

I would like to find time to comb through it, ask questions, and assess the state of the code. Unlike the main branch, this branch hasn't had 2+ sets of eyes on it all along.

Beyond that, I'd love to have answers to some questions we've kicked around, like whether we should really support non-React node views or not, and I maybe won't have opinions on that until I can grok the scope of the complexity impact of those decisions.

Are there other questions you can think of that we might like to resolve?

[smoores-dev]

I'm still pretty strongly in favor of leaving the non-React node view support in there. Partly because it's in there now and people are using it, and partly because it makes the migration story much more digestible. Down to discuss more though.

The other big thing that I've been poking at today is support for React StrictMode and seeing if we can memoize node view components. I actually just got something working that I'd love to get your eyes on, maybe I'll push it up as a PR. The StrictMode stuff feels fairly important, given to direction React is going; the memoization stuff feels like a nice to have but kind of falls out of the strict mode stuff. I think it could be a pretty big performance win though for bigger/more complex apps.

That's the only thing I can think of though; the API feels pretty settled and the current feature set seems to be working for folks.

[tilgovi]

Do the production deployments you know about have any non-React node views?

[smoores-dev]

Yeah; specifically, prosemirror-tables. I think that library in particular is going to be a pretty significant thing for folks, because reimplementing it yourself is a pretty huge project

[tilgovi]

Oh, I think we're talking about something different, maybe. I mean toDOM() that returns DOM nodes, rather than specs. We can render specs in React. It's only node views that return instances of Node that we have to manage as children of a React wrapper node that I would love to not support.

[smoores-dev]

Oh uhhh hm ok. Yeah so we don't currently support toDOM methods that return DOM nodes, and I'm not sure about those but I think I would be ok with not supporting them. They don't seem very widely used.

I had thought that we were talking about custom mode views that use plain DOM nodes, which we do support, are used by prosemirror-tables, and I think we ought to continue supporting.