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 keeps the component from being injected with virtual-DOM logic. It can simply be its own Ruby object. The wrapper acts as an adapter between the two.
There are two main benefits of this:
@type
instance variable. Previously, if you defined one in your component, it would prevent the virtual-DOM engine from caching it.key
method on your component to optimize diffing/patching when child nodes are moved around or deleted. Previously, you either had to wrap the component in a container node with akey
property (slower because it would have to be diffed without hints) or set an@key
instance variable (completely unintuitive in Ruby).The downside of this is that it allocates an additional object for each cached component on every render, but I haven't seen this cause any negative effect on realistic performance. Even in my contrived app that renders (among other things) 1000 cached list items, performance improved (from 9ms to 4.5ms per render) with no noticeable difference in memory usage.
Posting a PR in case there's something I may be missing. Render caching is pretty important for Clearwater so I don't want to screw it up. :-)