Using in production?

[devalberg]

Hello!

I've been checking your library the past few days and played around a little by integrating it into an existing project I'm a part of.
I must give massive kudos to the documentation and implementation as it was simple and straight forward, fits right into the project with only slight tweaks, love it!

However, I'm concerned about investing into using this library as it's not yet in 1.0 release, but that's not a deal breaker! My main concern is the discussion and efforts around #55 - Is that the vision going forward and would that mean a drastic towards API going forward? As would the existing patterns be ditched in favor of something completely new?

Do you recommend going ahead and use it as is, or should we rather wait to see the progress?

This might be obvious but as I see it, the strongest point of the current implementation is that it allows developers to maintain React components as NodeViews or Plugins rather than pure PM way of doing things (which in my experience is where most efforts go into when adding new features), but at the same time give access to PM's powerful core when required without necessarily over complicating things and steering too far away from the conventional PM way. This results in greatly reduced learning curve to other/new project maintainers that aren't at all familiar to PM (not just in my project but any consumer of this library)!

It's not really my place to say or ask this and hope I don't come off as condescending 😅, but is all the effort in the aforementioned discussion/PR much more beneficial than "just" to maintain and improve the current implementation? Is the payoff worth it? I'm relatively new to this space and I am just trying to understand better! (I've read through the #47 pull request and my head was spinning 😵)

Thank you in advance! Love and highly appreciate what you guys are doing here! 😃

[smoores-dev]

Hi @devalberg! Thanks for your kudos, and I'm really glad to hear that you had an easy time setting up the library!!

This library is definitely pre-v1, and that does mean that we expect to introduce some breaking changes before it stabilizes. The changes proposed in #55 / #47 are actually pretty minor from an API standpoint, but they have significant implications for the stability and usability of the library overall. There are some challenging bugs (#42, #41) that we don't have a great way to resolve with the current architecture, and there are some subtle gotchas with using custom node views that we hope to get rid of with the new architecture proposed in #47.

It's possible that the new architecture from #47 won't end up working out (though I think we're on a good path!) and we'll have to take another approach, but either way it's a goal of this library to provide a stable, usable integration between React and ProseMirror that continues to meet the needs you've expressed of using React to implement complex node views, without sacrificing access to the underlying ProseMirror implementation.

... is all the effort in the aforementioned discussion/PR much more beneficial than "just" to maintain and improve the current implementation?

sigh I wish it wasn't, truly! Haha. I think it is, though; the need to wrap React node views in extra DOM elements provides a lot of surface area for browser-specific contenteditable bugs, unfortunately. At the end of all of this, the goal is to have a more robust integration between React and ProseMirror that "just works" at the same level that ProseMirror "just works", which is to say, basically everywhere in basically all contexts (which is a big missive!)

[devalberg]

Thanks for the reply and clarifications! And I do apologise for the naivety, it's obvious you guys have done lots of research + work and know what you're up to! 😅 - I will definitely be keeping up with your progresses 🙇 🙏