Shane Friedman

@saranrapjs > it doesn't look like any of the implementation here required changes to any of the existing React wrappers for ProseMirror view components, yes? is there a model where...

@saranrapjs Gotcha. Yeah I suspect that when it comes down to it, it's going to be a tradeoff between the risks you've outlined here, and the risks of the approach...

@tilgovi @saranrapjs (and anyone else interesting): So... what do you think? Should we actually try to do this? I don't see any reason that we _literally could not_ continue implementing...

> And didn't you do some experiments with that from which you concluded even that had problems? Indeed; secondary renderers can't share context with primary renderers, so context has to...

Alright, thanks @saranrapjs! If you think he'd be open to it, could be neat to have Marijn join the conversation here, too!

> we should only do this we can avoid breaking compatibility for library consumers that still want to use the mainline prosemirror-view.EditorView. I don't totally understand what this would mean,...

Nothing about the original API (the `` component and the `useNodViews` hook) is _broken_ by the new `` component, but it is _replaced_ by it. That is, aside from the...

Ah, I think I see where I was misunderstanding you. I had been interpreting your previous messages as a suggestion that we should _indefinitely_ maintain both interfaces. > If you...

It sounds like there's enough interest in this approach to continue forward; I'm going to do my best to continue working on this direction, porting over code from prosemirror-view as...

@tilgovi (et al) the latest here is in sort of a nice place, I think, or at least heading there. I've directly copied over all of prosemirror-view's domcoords.ts, dom.ts, and...