reactive props#1912
Merged
Merged
Conversation
be7f635 to
16e2f2d
Compare
Reading a prop inside an effect/computed did not react to the same changes the template reacted to. Props participated only in the forced-render channel (parent re-render -> arePropsDifferent -> node.props replacement + fiber.render), while props() getters performed plain reads that were invisible to the reactive system. Expose props through signal-backed getters so reading this.props.x subscribes the current computation, and refresh those signals after node.props is updated on parent re-render. This keeps onWillUpdateProps observing the previous this.props value while effects/computed rerun with the applied value on the next microtask. For declared props, the key set is fixed and only the existing signals are refreshed. Bare props() still tracks runtime key additions/removals because t-props can change the prop object shape across renders. prop() remains static and reference-stable.
16e2f2d to
0c4372f
Compare
This file contains hidden or 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
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.
Reading a prop inside an effect/computed did not react to the same changes the template reacted to. Props participated only in the forced-render channel (parent re-render -> arePropsDifferent -> wholesale node.props replacement + fiber.render), not in the reactive channel: props() getters did a plain node.props[key] read, so the prop slot was not an atom and swapping a prop value was invisible to effects/computed.
Back each declared prop key with a signal used purely as a notification atom: the getter subscribes the current computation but returns the live node.props value. Notifications fire from a new node.propsUpdated list, invoked right after node.props is applied (sync and async branches) so that reads inside onWillUpdateProps still see the old value and async hooks observe the applied value. The synchronous forced render resets the render computation to EXECUTED before the batched microtask, so no extra render is introduced.
prop() (static, reference-stable) stays non-reactive.