12 ms·

Rich Text Editor for React

110 points by ozanyurtsever 4y ago

Apofis 4y ago
Am I the only dev on the planet that thinks not having CSS editing and a code view makes most of these entirely useless except for simple sites like blogs or comment sections?
ozanyurtsever 4y ago
Hello Guys, Until this year, draft.js was one of the mainly used libraries out there for building web based text editors, and there are lots of component libraries for React based on draft.js. However, the development team(which is facebook) has announced that the project is not under development anymore, since they have started a brand new project, which is Lexical. Lexical is a framework to build text editors and is under early development currently. By using Lexical, I have built a new component library that comes with a ready to use rich text editor. It is under very early development as well, as I am trying to make it more modular and flexible with each improvement. I hope this project can help some startups that needs to implement a highly functional text editor to their projects. All of the support(like stars) and contribution to the project is very much welcomed. Thanks.
- urban_alien 4y ago
  How has been your experience working with Lexical so far?
  - ozanyurtsever 4y ago
    Hello, as it is in very early phase, most of the time you cannot find a sufficient amount of information or no information from the docs about a provided API. However, I have used lexical playground to bootstrap this project, so it was easier to convert it to a separate react component package.
- Tade0 4y ago
  Thanks for the writeup. For a minute there I thought you were creating a WYSIWYG editor from scratch, in which case, as someone involved in a high-profile project of this sort in the past, I would have to urge you to refrain from doing it - it's not worth it. ---- I know you're reading this, Wiktor. Say hi to the team for me.
  - panzerboiler 4y ago
    > it's not worth it. It depends. If the editor is a central part of what your software is doing and you need/want total control, it's well worth it. General purpose libraries are mostly made of bloat when your project just need 20% of all the things they (have to) do. Focusing on that 20% could be a good time investment and yield a better software.
    - Tade0 4y ago
      The Selection API alone is such a minefield of divergent browser implementations that it's a massive PITA. And that's just the start. Check what happens in different browsers when you hit backspace in a contenteditable containing a single space character. Overall there are a lot of such changing, undocumented behaviours.
      - panzerboiler 4y ago
        I know. The APIs offered by browsers for editing text are less than ideal, and require a lot of work to make something robust. That being said, my point stands. If something is not easy it doesn't necessarily mean that is not worth doing. I have my opinions about how text editing should work in my software, and it is my job to design and develop a solution that fullfills my vision. I will take working around the browser APIs every day instead of fighting a library developed to fullfill a different vision, that adds layers of indirection on top of the same problematic browser APIs.
        Tade0 4y ago
        There's a name for what you're displaying here and it's "Not Invented Here Syndrome". I strongly advise against this.
LinguaBrowse 4y ago
What does this do that the Lexical playground as-is doesn’t? On the surface, it just seems to be that demo redistributed as a library.
- elvin_d 4y ago
  Indeed, it seems that copy-pasted playground with custom UI. They didn't bother themselves even to create at least some new plugin for it. Playground plugin: https://github.com/facebook/lexical/blob/main/packages/lexical-playground/src/plugins/CommentPlugin.tsx https://github.com/facebook/lexical/blob/main/packages/lexic... Copy paste: https://github.com/ozanyurtsever/verbum/blob/bfac38815eb0057e4d3e71314f6b97e18f7d5d05/src/plugins/CommentPlugin.tsx https://github.com/ozanyurtsever/verbum/blob/bfac38815eb0057... Made a PR at least to credit the authors https://github.com/ozanyurtsever/verbum/pull/3/files https://github.com/ozanyurtsever/verbum/pull/3/files
mapcars 4y ago
This looks quite interesting and useful for us, thanks for great work! I'll check with teammates if we have resources to contribute
hahamrfunnyguy 4y ago
I am currently using ProseMirror in my project. It's the best rich text editor I've used up to this point. It's a headless text editor that's pretty flexible and extensible. It's not a drop in component like other text editors, but it's certainly been the least painful to integrate. I am using a wrapper for Vue called tip-tap, that project has also made a React wrapper with similar architecture. What does Verbum do differently than ProseMirror?
- samwillis 4y ago
  TipTap is awesome, as is the team behind it, love what they are also doing with the Y Collective and collaborative editing. Back at the beginning of last year I was using TipTap v2 for a project (when it was in closed beta), one of the best open source communities I have had the pleasure of working with. I helped to contribute the Vue3 port of TipTap, required going quite deep into how both Vue3 and ProseMirror work. Was great fun, sadly not working with anything rich text related at the moment.
  - brodo 4y ago
    I got into CRDTs a little a couple of months ago and stumbled upon TipTap. It sounds really cool. I think they want to release a backend for it soon. (You need one for peer discovery and to get around NAT problems.) In combination with Tauri one could do really interesting offline first collaborative editors.
  - blorenz 4y ago
    This is the first I have heard of TipTap, went to the demo and am very enthused about it now! What I don't immediately see is things around serialization. What does your persistence layer look for this? What is your presentation of this serialized data? I'm on the React end of things so I currently serialize to markdown and utilize `react-markdown` to display the contents.
    - hahamrfunnyguy 4y ago
      You have the option of using HTML or JSON to store the document. I am storing it as JSON in a database column. The advantage of JSON is that it's already in the native form for ProseMirror, it is relatively straight-forward to merge documents together and can be easily queried from my database (SQL Server).
davidhariri 4y ago
I just started to use SlateJS for my project. Why should I have chosen this instead?
- blorenz 4y ago
  If you are using Slate then I recommend adding Plate https://plate.udecode.io/ https://plate.udecode.io/ on top of it. It makes it so much easier to use and to get rich functionality.
- jitl 4y ago
  Check how well your Slate version supports CJK input and input generally on Android. The last time I tested Slate, it had glaring issues on Android.
- jack_hanford 4y ago
  Depending on how far along you are, I'd recommend checking out: https://lexical.dev/ https://lexical.dev/ I'm in the process of migrating my companies RTE from Slate to Lexical. I've been able to remove thousands of lines of custom code and increase the performance and reliability
egeozcan 4y ago
I'm quite disappointed that even in the year 2022 the best solution HTML offers for rich text editing is the infamous contenteditable attribute. I can never expect a WYSIWYG editor from a library to work 100% without friction on every platform. I know it's already near-impossible to implement a web-browser and adding more to the pile of standards/components to implement sounds counter-intuitive. On the other hand, a basic browser that can render just basic HTML and basic CSS is comparatively easy and I would rather have them be able to render a rich-text-field on a low-capability device than being able to do all sorts of JS/CSS magic. I'm not even against React and all the amazing ecosystem surrounding it - given that your use-case justifies it. I just think auto-completers and rich-text editing and other stuff that nearly every website on this planet re-implements should be standard.
- qsort 4y ago
  That's because there's no standard for rich text at all, everything is either MS Word, some other bespoke proprietary format, or a kludge on a kludge on a kludge. In part that's due to the shortcomings of HTML itself. And no, markdown a.k.a. whatever the interpreter accepts is decent enough at what it does but it's not what we are looking for here.
  - lopatin 4y ago
    So many rich text formats? Ridiculous! We need to develop one universal standard that covers everyone's use cases. [j] https://xkcd.com/927/ https://xkcd.com/927/
    - egeozcan 4y ago
      I never said anything about text formats though. Go crazy as the input, give me HTML as the output. I can sanitize it any way I want on the server-side anyway.
      - ta1636467 4y ago
        Sanitize when rendering the HTML, all other paths lead to hell. I agree with granddaddy, the web just didnt cater for this with all the XSS, XSRF etc shennigans. We're left with everyone implementing hacks, or in some cases, getting it right. Mud pie. Slap on an extra dollop.
kklisura 4y ago
I wish people build _native_ JS library first and then framework library wrapper over that, so at least their library can be used in non-framework environments. There are lot of great react libraries which I would like to use in non-react applications and it would be great to have that same library in some X framework by just building a wrapper over it.
- benbristow 4y ago
  You could just render a single component using ReactDOM if you wanted to use React libraries within a non-framework environment. You don't have to go full-SPA with React, you can use it piecemeal.
- Aeolun 4y ago
  Building a native JS library for something that I only want in React sounds like it’d bring me no benefit for a lot of extra effort.
  - jbverschoor 4y ago
    If someone else has done this, you’d only have to create the react layer. That’s one of the benefits
  - kklisura 4y ago
    Yes - if you're building just for yourself, but if you're building an OSS library your _audience_ is now larger than just React one and you have potential benefit of writing a thin wrapper around it in some new framework (if React stops being _mainstream_). Writing a wrapper around it sounds better than rewriting a whole library.
- jacobr 4y ago
  This is built on the Lexical framework, which is exactly what you suggest - vanilla JS with optional React bindings. OP's project is an additional React-specific layer on top of Lexical, and since it's concerned with rendering the editor UI it makes sense that it's UI rendering library specific.
jherskovic 4y ago
We use QuillJS https://quilljs.com/ https://quilljs.com/ for our projects, as a drop-in component to allow our users to edit rich-text fields. Works great for our CRUD apps; I am not a front-end person, but it's simple, does what we need, and seems to work in multiple browsers without issues. Am I missing something?
- lewisjoe 4y ago
  You don't need to migrate. QuillJS is enough for almost 98% of rich-text editing usecases out there. These options just improve over the document model and relevant document manipulation APIs - which won't be a requirement until your product's core is an editor.
  - jherskovic 4y ago
    Awesome, clear answer. Thanks!
- misterS 4y ago
  We use Quill, too, we only need rudimentary features, though. Its maintenance status is... questionable, although my information is out of date (see last paragraph). * Github: https://github.com/quilljs/quill/ https://github.com/quilljs/quill/ * It's latest release was 2019-09-09 – which is _ages_ in term of a JS library. * There's tons of open issues, the maintainer was (or still is) rather quiet. * It's pretty much a one-man-show. Although now that I look at it, the last few months a second contributor appeared. * Apparently there is a v2 in the works, but nobody know when it is due nor what its status is. * There were issue that asked whether the project was abandoned. The issues went unanswered, and then were deleted. To be fair: development seems to have picked up again. There were sporadic commits at the end of 2021, and I now see that there are a few this year, too.
catchclose8919 4y ago
The solution to the problem people have is almost never "rich text editing", it's "structured content editing & management. Eg. smth more like https://wagtail.org/ https://wagtail.org/
manigandham 4y ago
Added to the latest list of rich-text/HTML editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487

110 points by ozanyurtsever 4y ago

Am I the only dev on the planet that thinks not having CSS editing and a code view makes most of these entirely useless except for simple sites like blogs or comment sections?

ozanyurtsever 4y ago

Hello Guys, Until this year, draft.js was one of the mainly used libraries out there for building web based text editors, and there are lots of component libraries for React based on draft.js. However, the development team(which is facebook) has announced that the project is not under development anymore, since they have started a brand new project, which is Lexical. Lexical is a framework to build text editors and is under early development currently. By using Lexical, I have built a new component library that comes with a ready to use rich text editor. It is under very early development as well, as I am trying to make it more modular and flexible with each improvement. I hope this project can help some startups that needs to implement a highly functional text editor to their projects. All of the support(like stars) and contribution to the project is very much welcomed. Thanks.

urban_alien 4y ago
How has been your experience working with Lexical so far?
- ozanyurtsever 4y ago
  Hello, as it is in very early phase, most of the time you cannot find a sufficient amount of information or no information from the docs about a provided API. However, I have used lexical playground to bootstrap this project, so it was easier to convert it to a separate react component package.
Tade0 4y ago
Thanks for the writeup. For a minute there I thought you were creating a WYSIWYG editor from scratch, in which case, as someone involved in a high-profile project of this sort in the past, I would have to urge you to refrain from doing it - it's not worth it. ---- I know you're reading this, Wiktor. Say hi to the team for me.
- panzerboiler 4y ago
  > it's not worth it. It depends. If the editor is a central part of what your software is doing and you need/want total control, it's well worth it. General purpose libraries are mostly made of bloat when your project just need 20% of all the things they (have to) do. Focusing on that 20% could be a good time investment and yield a better software.
  - Tade0 4y ago
    The Selection API alone is such a minefield of divergent browser implementations that it's a massive PITA. And that's just the start. Check what happens in different browsers when you hit backspace in a contenteditable containing a single space character. Overall there are a lot of such changing, undocumented behaviours.
    - panzerboiler 4y ago
      I know. The APIs offered by browsers for editing text are less than ideal, and require a lot of work to make something robust. That being said, my point stands. If something is not easy it doesn't necessarily mean that is not worth doing. I have my opinions about how text editing should work in my software, and it is my job to design and develop a solution that fullfills my vision. I will take working around the browser APIs every day instead of fighting a library developed to fullfill a different vision, that adds layers of indirection on top of the same problematic browser APIs.
      - Tade0 4y ago
        There's a name for what you're displaying here and it's "Not Invented Here Syndrome". I strongly advise against this.

LinguaBrowse 4y ago

What does this do that the Lexical playground as-is doesn’t? On the surface, it just seems to be that demo redistributed as a library.

elvin_d 4y ago
Indeed, it seems that copy-pasted playground with custom UI. They didn't bother themselves even to create at least some new plugin for it. Playground plugin: https://github.com/facebook/lexical/blob/main/packages/lexical-playground/src/plugins/CommentPlugin.tsx https://github.com/facebook/lexical/blob/main/packages/lexic... Copy paste: https://github.com/ozanyurtsever/verbum/blob/bfac38815eb0057e4d3e71314f6b97e18f7d5d05/src/plugins/CommentPlugin.tsx https://github.com/ozanyurtsever/verbum/blob/bfac38815eb0057... Made a PR at least to credit the authors https://github.com/ozanyurtsever/verbum/pull/3/files https://github.com/ozanyurtsever/verbum/pull/3/files

mapcars 4y ago

This looks quite interesting and useful for us, thanks for great work! I'll check with teammates if we have resources to contribute

hahamrfunnyguy 4y ago

I am currently using ProseMirror in my project. It's the best rich text editor I've used up to this point. It's a headless text editor that's pretty flexible and extensible. It's not a drop in component like other text editors, but it's certainly been the least painful to integrate. I am using a wrapper for Vue called tip-tap, that project has also made a React wrapper with similar architecture. What does Verbum do differently than ProseMirror?

samwillis 4y ago
TipTap is awesome, as is the team behind it, love what they are also doing with the Y Collective and collaborative editing. Back at the beginning of last year I was using TipTap v2 for a project (when it was in closed beta), one of the best open source communities I have had the pleasure of working with. I helped to contribute the Vue3 port of TipTap, required going quite deep into how both Vue3 and ProseMirror work. Was great fun, sadly not working with anything rich text related at the moment.
- brodo 4y ago
  I got into CRDTs a little a couple of months ago and stumbled upon TipTap. It sounds really cool. I think they want to release a backend for it soon. (You need one for peer discovery and to get around NAT problems.) In combination with Tauri one could do really interesting offline first collaborative editors.
- blorenz 4y ago
  This is the first I have heard of TipTap, went to the demo and am very enthused about it now! What I don't immediately see is things around serialization. What does your persistence layer look for this? What is your presentation of this serialized data? I'm on the React end of things so I currently serialize to markdown and utilize `react-markdown` to display the contents.
  - hahamrfunnyguy 4y ago
    You have the option of using HTML or JSON to store the document. I am storing it as JSON in a database column. The advantage of JSON is that it's already in the native form for ProseMirror, it is relatively straight-forward to merge documents together and can be easily queried from my database (SQL Server).

davidhariri 4y ago

I just started to use SlateJS for my project. Why should I have chosen this instead?

blorenz 4y ago
If you are using Slate then I recommend adding Plate https://plate.udecode.io/ https://plate.udecode.io/ on top of it. It makes it so much easier to use and to get rich functionality.
jitl 4y ago
Check how well your Slate version supports CJK input and input generally on Android. The last time I tested Slate, it had glaring issues on Android.
jack_hanford 4y ago
Depending on how far along you are, I'd recommend checking out: https://lexical.dev/ https://lexical.dev/ I'm in the process of migrating my companies RTE from Slate to Lexical. I've been able to remove thousands of lines of custom code and increase the performance and reliability

egeozcan 4y ago

I'm quite disappointed that even in the year 2022 the best solution HTML offers for rich text editing is the infamous contenteditable attribute. I can never expect a WYSIWYG editor from a library to work 100% without friction on every platform. I know it's already near-impossible to implement a web-browser and adding more to the pile of standards/components to implement sounds counter-intuitive. On the other hand, a basic browser that can render just basic HTML and basic CSS is comparatively easy and I would rather have them be able to render a rich-text-field on a low-capability device than being able to do all sorts of JS/CSS magic. I'm not even against React and all the amazing ecosystem surrounding it - given that your use-case justifies it. I just think auto-completers and rich-text editing and other stuff that nearly every website on this planet re-implements should be standard.

qsort 4y ago
That's because there's no standard for rich text at all, everything is either MS Word, some other bespoke proprietary format, or a kludge on a kludge on a kludge. In part that's due to the shortcomings of HTML itself. And no, markdown a.k.a. whatever the interpreter accepts is decent enough at what it does but it's not what we are looking for here.
- lopatin 4y ago
  So many rich text formats? Ridiculous! We need to develop one universal standard that covers everyone's use cases. [j] https://xkcd.com/927/ https://xkcd.com/927/
  - egeozcan 4y ago
    I never said anything about text formats though. Go crazy as the input, give me HTML as the output. I can sanitize it any way I want on the server-side anyway.
    - ta1636467 4y ago
      Sanitize when rendering the HTML, all other paths lead to hell. I agree with granddaddy, the web just didnt cater for this with all the XSS, XSRF etc shennigans. We're left with everyone implementing hacks, or in some cases, getting it right. Mud pie. Slap on an extra dollop.

kklisura 4y ago

I wish people build _native_ JS library first and then framework library wrapper over that, so at least their library can be used in non-framework environments. There are lot of great react libraries which I would like to use in non-react applications and it would be great to have that same library in some X framework by just building a wrapper over it.

benbristow 4y ago
You could just render a single component using ReactDOM if you wanted to use React libraries within a non-framework environment. You don't have to go full-SPA with React, you can use it piecemeal.
Aeolun 4y ago
Building a native JS library for something that I only want in React sounds like it’d bring me no benefit for a lot of extra effort.
- jbverschoor 4y ago
  If someone else has done this, you’d only have to create the react layer. That’s one of the benefits
- kklisura 4y ago
  Yes - if you're building just for yourself, but if you're building an OSS library your _audience_ is now larger than just React one and you have potential benefit of writing a thin wrapper around it in some new framework (if React stops being _mainstream_). Writing a wrapper around it sounds better than rewriting a whole library.
jacobr 4y ago
This is built on the Lexical framework, which is exactly what you suggest - vanilla JS with optional React bindings. OP's project is an additional React-specific layer on top of Lexical, and since it's concerned with rendering the editor UI it makes sense that it's UI rendering library specific.

jherskovic 4y ago

We use QuillJS https://quilljs.com/ https://quilljs.com/ for our projects, as a drop-in component to allow our users to edit rich-text fields. Works great for our CRUD apps; I am not a front-end person, but it's simple, does what we need, and seems to work in multiple browsers without issues. Am I missing something?

lewisjoe 4y ago
You don't need to migrate. QuillJS is enough for almost 98% of rich-text editing usecases out there. These options just improve over the document model and relevant document manipulation APIs - which won't be a requirement until your product's core is an editor.
- jherskovic 4y ago
  Awesome, clear answer. Thanks!
misterS 4y ago
We use Quill, too, we only need rudimentary features, though. Its maintenance status is... questionable, although my information is out of date (see last paragraph). * Github: https://github.com/quilljs/quill/ https://github.com/quilljs/quill/ * It's latest release was 2019-09-09 – which is _ages_ in term of a JS library. * There's tons of open issues, the maintainer was (or still is) rather quiet. * It's pretty much a one-man-show. Although now that I look at it, the last few months a second contributor appeared. * Apparently there is a v2 in the works, but nobody know when it is due nor what its status is. * There were issue that asked whether the project was abandoned. The issues went unanswered, and then were deleted. To be fair: development seems to have picked up again. There were sporadic commits at the end of 2021, and I now see that there are a few this year, too.

catchclose8919 4y ago

The solution to the problem people have is almost never "rich text editing", it's "structured content editing & management. Eg. smth more like https://wagtail.org/ https://wagtail.org/

manigandham 4y ago

Added to the latest list of rich-text/HTML editors: https://gist.github.com/manigandham/65543a0bc2bf7006a487 https://gist.github.com/manigandham/65543a0bc2bf7006a487