We definitely have plans to improve Tables drastically over time, but I'm not sure when we'll get to those particular issues. If you care to make an Issue for this on GitHub, that would be much appreciated :)
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…
>Sure, but indicate that it's an alpha product Do you mean something like the banner on the README? https://github.com/facebook/lexical >They don't even have the decency to label it is such Do you mean something like…
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…
We definitely have plans to improve Tables drastically over time, but I'm not sure when we'll get to those particular issues. If you care to make an Issue for this on GitHub, that would be much appreciated :)
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…
>Sure, but indicate that it's an alpha product Do you mean something like the banner on the README? https://github.com/facebook/lexical >They don't even have the decency to label it is such Do you mean something like…
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…