News for hackers. Stuff that matters.
Re:Svelte 3: Rethinking Reactivity by evangow on Monday April 22, 2019 @12:28PM (#19720240)
One area where the virtual DOM seems to be important is for rich text editors, where the VDOM can basically take the input, diff it using an immutable structure, then render it to properly structured HTML.

An example use case where this would be valuable: a user hightlights text, bolds it, then highlights it again plus some more text, and bolds it. A naive approach would have: <b><b>This text is bolded</b> plus I bolded this</b> when what you want would simply be: <b>This text is bolded plus I bolded this</b>

Libraries like DraftJS and SlateJS use immutable data structures to parse the input/formatting in the VDOM and reconcile them into "blocks" (basically javascript objects containing the formatting) that deduplicate formatting.

The talk below on DraftJS is pretty good.

https://www.youtube.com/watch?v=feUYwoLhE_4

What's the recommended way to handle a rich text application in Svelte? Is there anything like the above for Svelte?

Re:Svelte 3: Rethinking Reactivity by rich_harris on Monday April 22, 2019 @12:33PM (#19720279)
Rich text editing is possibly a special case, though the right person to ask about that would be Jacob Wright (https://github.com/jacwright). He's the creator of https://www.dabblewriter.com (which uses Svelte) and a Svelte contributor, so he probably knows more about this topic than just about anyone else!
Re:Svelte 3: Rethinking Reactivity by evangow on Monday April 22, 2019 @12:43PM (#19720382)
Thanks for sharing! Looks like Jacob has open-sourced a svelte-based rich text editor based on Quill. Link below for anyone who is curious.

https://github.com/typewriter-editor/typewriter

Re:Svelte 3: Rethinking Reactivity by writepub on Monday April 22, 2019 @02:39PM (#19721544)
I'd argue that a rich text editor tied to a framework is inflexible, and possibly inefficient. You want a rich text editor to be good at one thing, editing, and not be concerned with how it's invoked.

A good editor would be standalone, with wrappers to make it callable from a framework of your choosing.

Most good rich editors implement their own internal Dom to achieve uniformity across browsers. DraftJs, Quill, Trix... use this strategy. There's nothing unique to react-Dom that benefits rich text editing

Re:Svelte 3: Rethinking Reactivity by quickthrower2 on Monday April 22, 2019 @07:15PM (#19724036)
An important feature of a good framework is to be able to break out when needed to do normal JS, so I imagine you’d do that and grab a regular editor component.
Re:Svelte 3: Rethinking Reactivity by dgreensp on Monday April 22, 2019 @01:34PM (#19720833)
If you need a rich text editor, I would just plug in a framework-agnostic rich text editor (e.g. ProseMirror).