4 ms·

I was planning to write a little toy WYSIWYG editor for basic html formatting in the near future (mostly for fun). Any general advice before jumping into it?

jitl 5y ago
I'm not sure how to best optimize for fun in this scenario. Since I've sweated this stuff so much building for produciton, I would never do this kind of thing for fun myself. Do you want to build from scratch? The classic advice is to keep your data model totally separate from the DOM. Treat the DOM as a drawing and input device, not as the source of truth for your document. Probably the easiest way to accept input for a weekend project is to use the beforeInput event and preventDefault() pretty much every event you see, apply the update to your data model, and then render the new data into the DOM yourself. This way you avoid unexpected shenanigans or mutations. The downside is that this approach doesn't work well on Android or for IME languages. If you want to use a library, check out Prosemirror (low-level) or layers over Prosemirror like Remirror or Tiptap, although I haven't used those abstractions myself. I would stay away from Slate.js -- it has a very nice design, but doesn't support Android well. I think if you're going to invest time with a library, it should be one that can support you into production, be well-proven and bullet-proof. Quill also seems production-ready, but might not support more complex layouts, but it's been a while since I played with it. For a fun/scrappy WYSIWYG kinda toy, any of these libraries are probably overkill.
- asddubs 5y ago
  Thanks for taking the time to respond! Yes, I was going to do it from scratch (no libraries), it's supposed to be a very basic WYSIWYG markdown dialect editor, which also supports rich text pasting. It will probably never see the light of day in any practical use, I just want to see firsthand how feasible it is to do something like this, and hopefully learn a thing or two in the process. Because the desired end result is markdown, and it's supposed to only support very basic formatting, I was planning to have a separate data model anyway, I figured I could use a MutationObserver, parse the editable dom into tokens, then just toss out everything that doesn't fit into the model, and generate new HTML based on the resulting model. I guess this ultimately does still treat the dom as the source of truth in a roundabout way, though.

jitl 5y ago

I'm not sure how to best optimize for fun in this scenario. Since I've sweated this stuff so much building for produciton, I would never do this kind of thing for fun myself. Do you want to build from scratch? The classic advice is to keep your data model totally separate from the DOM. Treat the DOM as a drawing and input device, not as the source of truth for your document. Probably the easiest way to accept input for a weekend project is to use the beforeInput event and preventDefault() pretty much every event you see, apply the update to your data model, and then render the new data into the DOM yourself. This way you avoid unexpected shenanigans or mutations. The downside is that this approach doesn't work well on Android or for IME languages. If you want to use a library, check out Prosemirror (low-level) or layers over Prosemirror like Remirror or Tiptap, although I haven't used those abstractions myself. I would stay away from Slate.js -- it has a very nice design, but doesn't support Android well. I think if you're going to invest time with a library, it should be one that can support you into production, be well-proven and bullet-proof. Quill also seems production-ready, but might not support more complex layouts, but it's been a while since I played with it. For a fun/scrappy WYSIWYG kinda toy, any of these libraries are probably overkill.

asddubs 5y ago
Thanks for taking the time to respond! Yes, I was going to do it from scratch (no libraries), it's supposed to be a very basic WYSIWYG markdown dialect editor, which also supports rich text pasting. It will probably never see the light of day in any practical use, I just want to see firsthand how feasible it is to do something like this, and hopefully learn a thing or two in the process. Because the desired end result is markdown, and it's supposed to only support very basic formatting, I was planning to have a separate data model anyway, I figured I could use a MutationObserver, parse the editable dom into tokens, then just toss out everything that doesn't fit into the model, and generate new HTML based on the resulting model. I guess this ultimately does still treat the dom as the source of truth in a roundabout way, though.