We're trying to choose between Lexical and Slate at work. Do you have any code examples that would be similar to this?
Example: https://www.slatejs.org/examples/richtext
Code: https://github.com/ianstormtaylor/slate/blob/main/site/examp...
Example: https://www.slatejs.org/examples/richtext
Code: https://github.com/ianstormtaylor/slate/blob/main/site/examp...
Btw I'd love to see any public posts about the architecture of the Notion editor!
I co-wrote a post about our editor internals after finishing up the recent re-work but we decided not to publish it to conserve our Competitive Advantage.
Guess I'll just have to get a job at Notion some day and dig it up...
2. Building an editor is so complicated that most organizations want to do it only once. They build a web editor, and wrap it in a native app. The shell like file browser, sharing screens, etc are “native” but the editor surface is a webview. This is how Quip, Dropbox Paper, Google Docs, Notion, etc work. Even iOS worked this way initially for all editable styled text (per https://twitter.com/kocienda/status/1400484473540513792?s=21...)
3. If you are going to bet the core competency of your business on a framework, it’s important to understand the motivations and limitations of said framework.
The major issue for both Android and CJK input is dealing with “composition” of characters by an “input method editor”. https://en.m.wikipedia.org/wiki/Input_method
In English, usually it’s okay to assume one key press event = one letter input. The opposite is true on Android generally, and for CJK languages on all platforms. These use input systems (like handwriting) where keypresses never occur, or many keypresses compose to produce one character. There are also new rules for IME composition input like “you can’t touch the DOM or change the selection during composition or the input will cancel and your user will be mad”. It turns the problem from “Hard” difficulty to “Nightmare” difficulty.
The baffling thing on Android is that each keyboard (Gboard, Samsung Keyboard, Swiftkey, Simeji, Sogou, Naver) have different composition behaviors with different event patterns… and GBoard’s ENGLISH input is probably the most strange! It composes whole English words like they were Chinese characters, and it wants to compose SO badly it will move text selection from wherever the user tapped to the nearest English word. And as an added bonus on Android only, the browsers selection APIs report the wrong selection during different phases of the event flow. Hah. Like when you tap a key, Android will send a selectionChange event before the first input-related event, and that selectionChange will probably report some weird lie about the selection position.
also, opting to use a big old plaintext textbox and something markdown-ish avoids these problems, right? (I'm trying to figure out why typing becomes slow on discord/slack in Firefox routinely. though I guess those are not real textboxes, but also contenteditable things :/)