-
Notifications
You must be signed in to change notification settings - Fork 24.2k
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
IncrementalPreview #4953
IncrementalPreview #4953
Conversation
Preview of new experimental Incremental concept for feedback. I have D2506522 internally that is the source of truth. Video: https://youtu.be/4UNf4-8orQ4
🚀 🎸 |
Oooooh! 😍 |
My thoughts (as @sahrens and I discussed elsewhere) -- it would be neat to find a way to integrate requestIdleCallback (perhaps optionally) in order to further de-prioritize incremental rendering, so incremental chunks only start when there is some 'idle' time. This could be optional. |
does this solve js navigator transitions issue ..? |
@chandu0101 - it could help if your views in the new scene are all inside of incremental presenters. there is other work being done to specifically address that right now though -- offloading animations to main thread. |
cool ok , thanks for info :) |
🚀 🎸 Does the experimental WindowedListView solves the memory hungry issue for a long list? |
Yes, WindowedListView is focused on the memory usage of infinite lists, but there are tradeoffs, especially because it is designed for variable height rows.
|
Oh, sounds amazing! 😻 |
@sahrens updated the pull request. |
Hey @sahrens, I'm working on updating an internal tab bar component, which I'm have transition speed issues with complex views on iPad (in particular unmount component speed of views containing multiple list views). Is Incremental a good fit for improving this kind of perf? WindowedListView sounds like it may help with multiple listviews as well. |
Doubt it would help with unmount - any idea why that's slow? This might help with transition smoothness, but doesn't help with total speed. It's goal is to improve responsiveness, so if you touch the screen during a big render, the app can respond immediately rather than waiting for that render to complete - would that help what you're seeing?
|
@sahrens updated the pull request. |
1 similar comment
@sahrens updated the pull request. |
Preview of new experimental
Incremental
concept for feedback. I have D2506522 internally that is the source of truth and necessaryInteractionManager
changes that are in the process of landing.The problem addressed here is expensive components that can tie up the JS thread during render, making the app unresponsive to taps, the canonical example being scroll loading of expensive rows. The approach is to slice up the rendering into separate chunks of work separated by setTimeout calls.
Everything wrapped in
<Incremental>
is rendered sequentially viaInteractionManager
.The
onDone
callback is called when all descendent incremental components havefinished rendering, used by
<IncrementalPresenter>
to make the story visible all at onceinstead of the parts popping in randomly.
This includes an example that demonstrates streaming rendering and the use of
<IncrementalPresenter>
. Pressing down pauses rendering and you can see theTouchableOpacity
animation runs smoothly. Video:https://youtu.be/4UNf4-8orQ4
Plan is to use this in
WindowedListView
and get that out as an Experimental component in open source soon as well.Note that the new setDeadline method must be called on InteractionManager, otherwise everything will just get batches up in setImmediate. We should consider changing that default.
Ideally this will be baked into React Core at some point, but according to @jwalke that's
going to require a major refactoring and take a long time, so going with this for now.