This repository was archived by the owner on Jul 30, 2018. It is now read-only.
Support deferred properties #736
Merged
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.
Type: feature
The following has been addressed in the PR:
Description:
v()now supports a function as the second parameter (rather than justVirtualDomProperties). If a callback is passed, the callback will be called on render as per usual, and then again on the nextrequestAnimationFrame. This allows you to for example measure and apply changes to a property without having to trigger a full re-render, or change a style property to trigger a css transition.Example usage:
There are a few caveats which will likely be resolved in future:
in lieu of a bonafide scheduler, there is nothing fancy here - it will simply queue a deferred property callback to the next
rAFeven if a main render is scheduled for the nextrAF. In the future it will be more desirable to remove deferred property callbacks from the queue if they are going to be updated as part of a main render anyway.there will currently be an issue with using
this.metain a deferred property callback on render due to us scheduling nodes to be added to the node handler (which meta uses for dom node existing) on arICrather than arAF. the node handler also clears out nodes after each__render__, which is problematic for anything deferred after it, so we will need a better way of handling dom nodes generally in the node handler.I will raise a PR with a readme update separately as their is an outstanding PR open.
Resolves #714