Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Do not slice `classNames` and `classNameBindings` speculatively. #14389
The vast majority of the time these arrays are completely static on the prototype, there are relatively few instances where we actually need to slice them but we were speculatively doing this "just in case" you wanted it.
This change does not remove the ability to have custom
This avoids many extraneous array allocations, and one more layer of wasted work during initial render.
Do we think we can get away with this? I suspect it would probably be considered a breaking change since the slice was added a while ago in response to this use case. If we think it's okay to make this change I would be happy to see this go though.
However, if we can't, I have an alternative that I am working on. My plan is that we make these a getter and try to detect access them during construction (with some POST_INIT trick), and if they are accessed, we assume they are being mutated and returned a sliced version (only during init).
I plan to apply this to a few things such as per-instance tagName, etc to emit optimized component templates. If we detect that any of these features are used, we can set a flag on the class indicating the component is unoptimizable and fallback to the generic template we have today.
If that works out, we might be able to get the same performance improvements without the breaking change.
@chancancode - Thank you for reviewing! Yes, I agree that this is a tad bit tricky, but I still think this is something that we can do. No capabilities are removed by this PR (the only use cases I have seen of this are already
We have done this sort of thing before, so there is precedent. For example, we made helpers params / hash frozen objects during the 2.9 cycle for similar optimizations.