Optimize rendering & dispose(s) #19
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
hamsbrar
force-pushed
the
dev-optimizations
branch
from
8fb6943
to
d295813
Compare
hamsbrar
force-pushed
the
dev-optimizations
branch
from
d295813
to
1322ba6
Compare
hamsbrar
force-pushed
the
dev-optimizations
branch
3 times, most recently
from
cc9bada
to
0021bda
Compare
JS is unlikely to have jump tables so we should try to bail out early for update types that happens more often(such as update, dispose)
Short-circuit dispose on parts of tree that doesn't contain any un-mount event listeners
hamsbrar
force-pushed
the
dev-optimizations
branch
from
0021bda
to
a205856
Compare
|
Alright it's ready now. I can see long term benefits in going with RenderEvents, and we can optimize a lot more using them if needed but that's already more than enough for now. I'm bit tired and probably going to merge this in 1-2 days. In case anyone wanna suggest/review changes, feel free to do so! |
Prepositions like after/before are not a good choice. They were choosen because: - StatefulWidget: We can add didRenderWidget in State but didUpdateWidget is already there and it's semantically different from afterUpdate. didUpdateWidget happens before render while afterUpdate happens after DOM updates are flushed. So I choosed afterRender & afterUpdate, completely different. - Choosing after/before in WatchfulRenderElement was my mistake. It should be didRender, didUpdate, willUnMount and didUnMount.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pull request contains:
Render events
RenderEvents are the events that framework will emit when it interacts with a RenderElement. Just like we can add event listeners for user interactions on DOM elements, we can now add event listeners for framework interactions on RenderElements. Similar to DOM events, we've different types of RenderEvents for different types of interactions which are listed below:
didRenderis a event that's emitted after framework finishes rendering the output of render to the DOM.didUpdateis a event that's emitted after framework finishes rendering the output of update to the DOM.willUnMountis a event that's emitted when framework is about to remove the widget from the DOM.didUnMountis a event that's emitted after framework finishes removing the widget from the DOM.RenderElements can decide to listen to a particular or all render events by adding event listeners.
Comparing RenderEvents with DOM events, there are few differences & restrictions:
These restrictions are temporary and we'll lift them when needed.
RenderEvents are meant to solve the problem of limited control over lifecycle in RenderElements. Previously we were providing a sub-class
WatchfulRenderElementwith hardcoded lifecycle. Now, using the new RenderEvents API, users can add as much or as little lifecycle as they want, to any RenderElement(widget). This new API effectively makesWatchfulRenderElementobsolete(but we'll keep it for backward compatibility).Benchmark results