-
Notifications
You must be signed in to change notification settings - Fork 377
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix: improved lg editor performance #2632
Conversation
Hi @a-b-r-o-w-n ,I believe the blocking comes from the sync method imported by @lei9444 to resolve a bug "form won't update when shell data update".
lgField here maintains a real-time synced data from shell, it caused a editor re-render. Compares to this, all up view maintains a local state at initial load, never meet the performance issue. I prefer also keep a local state value here. |
That was our thought as well but the editor doesn’t use the shell data to render after the initial render (it’s an uncontrolled component). But there is enough blocking IO to back up the event loop and prevents the browser from repainting. I do think there could be some work to further decouple the persistent layer from the store, but our initial investigation didn’t point to any smoking guns. |
@zhixzhan re-reading your comment after coffee I see what you are saying now. I'll look at that sync method to see if that is the issue. |
* throttle lg apis in shell * use throttle in file operations instead of debounce * remove dead code
Description
I'm not entirely sure why the update lg template code path is slow, or why it is blocking, but it is causing the editor and flow to have a delay when typing quickly. Adding a throttle to all lg api methods solves this by circumventing the IO for intermediate keystrokes.
Task Item
fixes #2627