Facebook open sources Lexical, an extensible text editor library

This feels half baked and confusing.

More than half docs page are blank:

- https://lexical.dev/docs/concepts/commands

- https://lexical.dev/docs/getting-started/quick-start

- https://lexical.dev/docs/concepts/extending-nodes

- https://lexical.dev/docs/concepts/editor-state

- https://lexical.dev/docs/api/lexical

- https://lexical.dev/docs/api/lexical-selection

- https://lexical.dev/docs/api/lexical-text

- https://lexical.dev/docs/api/lexical-offset

> An extensible text editor library

> Lexical is an extensible JavaScript web text-editor framework

The terminology is also confusing. In some places its called a library. In other places it's called a framework. Then other commenters mentioned that the demo gives the impression that it is a full package editor, but is just pegging onto CodeMirror. That's clarified here?

> It doesn't directly concern itself with UI components

> core of Lexical is ... a DOM reconciler that takes a set of editor states, diffs the changes, and updates the DOM according to their state.

> Lexical is designed for everyone. It follows best practices established in WCAG

These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?

I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC? Normally I'd benchmark myself, but in this case I don't see other compelling reasons too. The author mentioned the 22kB bundle size is less than Draft.js by Facebook, but Slate.js is 10kB and much more mature.

Some features that could make Lexical have "powerful features" as claimed: UNDO/REDO manager (without storing the entire state on the stack, which is just not scalable on memory), possibly implementing the Command pattern, then make easy consumption of collaborative editing such as with Operational Transform.

Is this meant to be a good drop-in rich-text/WYSIWYG editor?

What is the format that it creates that you could then persist in a database? Does it just save its state in HTML or some JSON format or what?

The core Lexical library is really a framework for building such editors. However, we also provide many common rich-text features out-of-the-box via separate packages, such as @lexical/rich-text. We also expose bindings for React (and hope to have them for other frameworks soon). Check out the lexical-playground package on GitHub for an example of how you can create a rich-text editor by adding plugins to the LexicalComposer component in @lexical/react.

Thank for the feedback - we're definitely still working on the docs.

> These are weird and conflated set of buzzwords. Why should something that isn't concerned with UI components be concerned with accessibility best practices?

Are they? Support for speech-to-text technologies and IME/composition input, for example, are independent of UI components.

> but Slate.js is 10kB and much more mature.

Is it?

https://bundlephobia.com/package/slate@0.77.0

> I'm building my own text editor and I thought VSCode was impressive enough. See this well written article about their text buffer reimplementation: https://code.visualstudio.com/blogs/2018/03/23/text-buffer-r.... Then I realized Ace.js has some even crazy magic implementation that can handle millions of LoC files without lag. Can Lexical handle 100k+ LoC?

Also, to clear up any confusion, Lexical isn't a code editor - it could be used to build one, for sure, but some sort of virtualization would probably be required in order to support millions of lines of code.