Sure - DraftJS, for instance, delegates DOM reconciliation to React. Lexical does not. The core library is framework-agnostic, with it's own diffing and reconciliation processes.
It's under consideration, but as of now we need native support for iOS and Android first. React Native doesn't currently support contentEditable.
Yes, we have something like this in @lexical/selection: https://github.com/facebook/lexical/blob/af099ffd9f464b523d6...
You mean typing latency, right? The most important thing we do there is handling reconciliation ourselves rather than delegating to a framework (e.g., React). If you have full control over the reconciliation process,…
I work at Meta on the Lexical team - yes, Lexical supports markdown and rendering from markdown syntax. Lexical isn't a drop-in replacement for Draft, but we're migrating all of our surfaces internally and it isn't…
FWIW, we updated the README to reflect the status of DraftJS today. https://github.com/facebook/draft-js Point taken about updating the site, though.
It would be awesome if you'd be willing to report them on GitHub :) https://github.com/facebook/lexical/issues/new?assignees=&la...
> So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM? I do now see your general point about the conflation there - the reality is Lexical also provides separate…
> 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…
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…
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…
Sure - DraftJS, for instance, delegates DOM reconciliation to React. Lexical does not. The core library is framework-agnostic, with it's own diffing and reconciliation processes.
It's under consideration, but as of now we need native support for iOS and Android first. React Native doesn't currently support contentEditable.
Yes, we have something like this in @lexical/selection: https://github.com/facebook/lexical/blob/af099ffd9f464b523d6...
You mean typing latency, right? The most important thing we do there is handling reconciliation ourselves rather than delegating to a framework (e.g., React). If you have full control over the reconciliation process,…
I work at Meta on the Lexical team - yes, Lexical supports markdown and rendering from markdown syntax. Lexical isn't a drop-in replacement for Draft, but we're migrating all of our surfaces internally and it isn't…
FWIW, we updated the README to reflect the status of DraftJS today. https://github.com/facebook/draft-js Point taken about updating the site, though.
It would be awesome if you'd be willing to report them on GitHub :) https://github.com/facebook/lexical/issues/new?assignees=&la...
> So Lexical doesn't care about how the DOM is rendered? Or is speech-to-text derived independent of the DOM? I do now see your general point about the conflation there - the reality is Lexical also provides separate…
> 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…
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…
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…