Live data from Hacker News

Facebook open sources Lexical, an extensible text editor library

lexical.dev

101–110 of 141 posts

Re: Facebook open sources Lexical, an extensible text editor library

#101
post #14

How does this fit in with Draft.js? Is it a successor? Seems like it has to connect in some way...

Internally, we've been replacing Draft.js with Lexical. To be clear though, they're different projects with little API compatibility. We hope to add some docs explaining how we've approached our upgrade path in the future. To expand on this further, I'll pull this from another HN thread: Draft.js was built a long time ago when many of the concerns around making contentEditable work stemmed from patching browser-suppo…

Great news to hear Lexical replacing Draft. Also great that you're handling `beforeinput` (like Slate). I work on a text expander browser extension and supporting Draft is a pain[1].

Are there any plans to make inserting text from the "outside" easier on Lexical? Maybe exposing the Lexical instance on the dom node (like CKEditor does)? Right now we're using `execCommand` to support Lexical.

[1] https://github.com/Briskine/briskine/blob/master/src/content...

Re: Facebook open sources Lexical, an extensible text editor library

#102
post #28

Earlier quoted context omitted.

I completely understand. I can't guarantee anything, no on can in software. However, we do have a dedicated full-time team working on Lexical. DraftJS never had that, it only had a few part-time maintainers at Facebook.

> I can't guarantee anything, no on can in software. What does this mean?

(1) People aren't often good at communicating their intent with language. It requires using public meanings (words) assembled in some order to reflect a private meaning which is non-linguistic.

(2) I think something like "At the moment it's funded, but I can't legally bind my org to that commitment. And in general, as software comes-and-goes, it's future utility and support is always hard to pin-down".

I mention (1) because I think (2) can be inferred from the comment, and I think we have some responsibility as readers/listeners to do that; rather than expect all communication will be clear to us.

Re: Facebook open sources Lexical, an extensible text editor library

#103
post #59
post #27

Earlier quoted context omitted.

It is in production at Facebook. We're slowly rolling out to more surfaces, replacing our existing DraftJS implementations as we go. We've noticed a big improvement internally from doing so, both in terms of less bugs but also performance and accessibility.

If I remember correctly you’re the Dominic who wrote inferno.js right? Love how performance obsessed you are. Facebook is lucky to have you.

Yep, I’m the same person still :p

Re: Facebook open sources Lexical, an extensible text editor library

#104
post #41
post #28

Earlier quoted context omitted.

I completely understand. I can't guarantee anything, no on can in software. However, we do have a dedicated full-time team working on Lexical. DraftJS never had that, it only had a few part-time maintainers at Facebook.

Hey Dominic, good to see you :) I take you moved from the React team to this dedicated Lexical team?

Good to see you too! I moved from the React core team about 2 years ago, and since then, I was fortunate to be able to build a team around Lexical!

Re: Facebook open sources Lexical, an extensible text editor library

#105

Earlier quoted context omitted.

> a company that intentionally broke text editing Of course inclined to believe you, but do you have a source to back this up?

Perhaps not intentionally broken but I still have issues with double texting on the Messenger mac/web app. iMessages also has this issues as well... Telegram, Discord, WeChat, MSN Messenger, etc. all seem to have figured out how to prevent double texts from occurring.

Excuse my ignorance, but what is a "double text"?

Re: Facebook open sources Lexical, an extensible text editor library

#107
post #68

Earlier quoted context omitted.

For 1. 2. see @trueadm's answer here - https://news.ycombinator.com/item?id=31022152 3. Lexical is not strictly tied to collaboration but its plugin system was built to be extensible enough to cater all developers needs. Collaboration is just another plugin (@lexical/yjs) and does listen and perform the conversion every time there's changes in the EditorState. This model of independent plugins that can be plugged-and…

Thanks for the pointer. His comparison of Draft vs Lexical makes a lot of sense. I'm keener to understand the different between Prosemirror vs Lexical. He mentions that he pulled the best ideas from libs like Prosemirror. I'm curious how Lexical is an improvement over Prosemirror's approach. As to my current knowledge, 1. Prosemirror considers state as the source of truth and syncs to subsequent states using deltas.…

I don't think ProseMirror has taken a bad approach. I think we've just taken a different approach when it comes to the design of things. In Lexical, you rarely concern yourself with the DOM – and typically you deal with Lexical's node API directly and that's really all you touch.

Lexical also treat its own EditorState as the source of truth. We use DOM MutationObservers to ensure the DOM matches the EditorState at all times. We do allow external mutations from things like spellcheckers update Lexical – otherwise people wouldn't be able to use Grammarly and other tools with Lexical. However, that's really constrained so that they don't overreach.

Lexical also has the notion of double-buffering. When you update Lexical, or use a node transform, you're actually mutating the "work in progress" EditorState. Once Lexical feels that the EditorState is ready, it will commit it to the DOM, and that EditorState will become immutable and will reflect what you see on the page.

Re: Facebook open sources Lexical, an extensible text editor library

#108
post #81

Earlier quoted context omitted.

My view is that the bottleneck is documentation or technical writing. As far as I can tell, so far nearly all of practical computing is conceptually easy. Digging into the work on the question of P versus NP does get tricky quickly, but so far that question is not very practical , e.g., with the question and the work so far, in practice can't do much with them. For progress on documentation, as I hinted in my post, a…

I'm sure good documentation, i.e. one that starts at a basic level assuming almost no prior knowledge and then gradually building on that, would lower the barrier of entry for many autodidacts. Maybe that will be the norm one day. But until then, we all find ourselves in the position where we need to quickly scan a text in order to assess if the level expertise required to understand it is within our potential grasp…

Yup.

Re: Facebook open sources Lexical, an extensible text editor library

#109
post #27
post #26

Is this in production on Facebook? I have not had the greatest experiences with their rich text editor, from not being able to remove styling on subsequent lines, to getting a nice little note saying that you can't edit rich text posts on mobile. Hoping lexical brings some improvements here.

It is in production at Facebook. We're slowly rolling out to more surfaces, replacing our existing DraftJS implementations as we go. We've noticed a big improvement internally from doing so, both in terms of less bugs but also performance and accessibility.

Hey Adam, is Meta using / planning on using Lexical for React Native as well?

Re: Facebook open sources Lexical, an extensible text editor library

#110

Earlier quoted context omitted.

Thanks for the pointer. His comparison of Draft vs Lexical makes a lot of sense. I'm keener to understand the different between Prosemirror vs Lexical. He mentions that he pulled the best ideas from libs like Prosemirror. I'm curious how Lexical is an improvement over Prosemirror's approach. As to my current knowledge, 1. Prosemirror considers state as the source of truth and syncs to subsequent states using deltas.…

I don't think ProseMirror has taken a bad approach. I think we've just taken a different approach when it comes to the design of things. In Lexical, you rarely concern yourself with the DOM – and typically you deal with Lexical's node API directly and that's really all you touch. Lexical also treat its own EditorState as the source of truth. We use DOM MutationObservers to ensure the DOM matches the EditorState at al…

quick question: I assume it ships(or supports a plugin) with a serializer to convert an editor state JSON to HTML. Does it depend on browser APIs to do so? Can it be somehow liberated out of native DOM APIs and language bindings for JSON-2-HTML in common languages like Java & Rust.

This could be a huge win for simple multi-platform rendering.

Post reply on HN