Performance #248
Replies: 3 comments
-
One of the biggest performance bottleneck was resolved with this issue: SlateJS itself uses currently path as an unique identifier for buffer nodes. I replaced generated ID's by using path as string (XX.YY.ZZ) as an identifier for DnD and other such actions. There are still some strange performance issues. SlateJS performance does not work as simply as you might think it works. But more about this later. |
Beta Was this translation helpful? Give feedback.
-
Many of the performance bottlenecks have been removed. When actually using the editor, you tend to keep large parts of your story folded, because you really don't want to keep all the text mass at the screen at the same time. That's why you use structured editors, right? There are few things we might consider to improve the use cases where you have all the text visible at the same time. There are few new issues to study for this: These are not that urgent, but at some point we might consider improving these parts. |
Beta Was this translation helpful? Give feedback.
-
I also opened a project for performance related issues: |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Some words about performance.
There is practically one critical place, where performance is needed: editor view. Every keystroke causes React to rerender the view, which includes:
Re-render should happen as quick as possible, as you feel even small delays as lagging when writing and editing. The editor feels lazy and sluggy. So, if you are looking code that is related to editor view components and rendering, you will see somewhat complex solutions.
Some principles for these components:
There is a project to collect performance issues:
MaweJS: Performance
Beta Was this translation helpful? Give feedback.
All reactions