How to use react component as embed?

[Hideman85]

Sorry for not using your beautiful issue template but this is more a question.

I want to be able to use a react component as embed or as first child of the embed. It can be easily done by using ReactDOM.render(component, node) but it is a bit more complex than this.

I want to use a react component to be able to access to react context that I shared in a upper component (upper than react-quill).

The issue is ReactDOM.render() don't forward context to the new subtree.

I try to investigate how to do and found two potentials solutions but I weren't able to solve my issue.

I'm using the latest version of react and so there is the promising solutions:

• ReactDOM.createPortal() (https://reactjs.org/docs/portals.html)
• ReactDOM.unstable_renderSubtreeIntoContainer() (unstable_renderSubtreeIntoContainer does not transfer context facebook/react#16721)

Have you already face to this challenge and have you found some solution?

[Hideman85]

Any news on this aspect?

[bogoroh]

Anyone?

[jwhiting]

This may be of value but I'm unable to grok what's really going on here or if it's a viable approach: https://medium.com/@rakeshar3796/render-react-component-inside-quill-without-losing-context-151eac4eda08

[Hideman85]

In the end I came to use slatejs & plate that are much more powerful than quill and a perfect alternative to a dead project.

[rimzzlabs]

wow, im kinda nervous as my work place here using quill and I couldn't find what Im looking for, and turns out there is no solution for this :(

[jwhiting]

Do you really need react in the editor? You can't just use an embed element with the necessary state stored as attributes on it, and then render it with regular dom rendering in a custom embed element? That's how I do it. This issue is IMO probably too small to warrant a total pivot of editor tool unless you have some very unusual editor requirements.

IME all wysiwyg editors have serious problems and frustrating limitations that only appear deep after your initial commitment to building your use cases in them. Unless your use cases are strictly supported by the stuff out of the box, prepare for war, headache, and disappointment, generally speaking. This applies to all of them. Some people get lucky and find their needs met out of the box, but people with more custom requirements are in a serious technical challenge. The hope is to find the one that covers the most use cases out of the box, and provides the shortest battle to closing the gap via plugins and/or custom code to meeting the rest of the requirements.

I could not get slatejs to work for my requirements ultimately, some of which were fairly simple expectations for natural cursor and newline behaviors and nested list behaviors. Quill did a much better job for me. But it does not, out of the box, it not being a react-first library, support react components inside the editor and to be fair, it's amazing that anything would, given how complex an editor really is, having a full-fledged react component in one is incredibly complex, conceptually.

In any case, Quill itself is not a dead project, but this react-quill adapter may be. The react-quill adapter itself is just a bit of glue, a very small percentage of code/logic involved in the total solution, and abandoning an entire editor option because the react adapter is disappointing is, IMO, a deep lack of perspective on how much work is involved in making these things work for custom use cases.