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.
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
useMutableSource #147
useMutableSource #147
Changes from 1 commit
e394803
536c00d
e3ecb1b
4048476
fd8b988
b5cec6a
99721c1
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's almost like Redux was designed for this RFC. lol
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
or vice versa :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note this example shows direct usage of
useMutableSource
, although this would likely be abstracted within a Redux-supplied custom hook (rather than used directly).Redux would likely not expose the underlying source object returned by
createMutableSource
, but would instead perhaps expose some selector API (and perhaps a way to setup a scoped subscription).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like, say, uh....
useSelector()
? :)https://react-redux.js.org/api/hooks#useselector
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How would you manage a scoped subscription for
useSelector
? Would it be possible? (I'm not familiar with Redux really.)There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Depends on what we mean by "scoped".
Since Redux is a global store, any component can choose to extract any original or derived data from the store at any time.
As a typical example, a
<UsersList>
component might do:While a
<UserDetails>
component might do:Any component can have many
useSelector
calls at the same time.So, it's "scoped" in that a given
useSelector
call only cares about certain pieces of data, but not scoped in that anyuseSelector
can access any part of the state tree.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Managing a scoped subscription for
useSelector
should be possible. Redux can store the thescheduleUpdate
callback along with the selector as a pair and iterate over them when the store updates. It will have to re-run the selectors to see if the derived values have changed but react-redux is already doing that.I think there could be a problem with the selector not deriving its returned value from the snapshotted store but I think that can be solved by storing the last result from the
getSnapshot
function in redux land.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Fair enough. The idea was that stores like Relay and (maybe) Redux may be able to further optimize with
useMutableSource
to only schedule updates for components whose snapshot values change.Given your example above, both
<UsersList>
and<UserDetails>
read fromstate.users
and so, conceptually, they wouldn't need to re-render whenstate.somethingElse
changes.I think this is the key detail. If there's a way to constraint the scope/access a selector has, then the subscription could take advantage of this and avoid scheduling unnecessary no-op updates.
I think @JeremyRH is suggesting that Redux could automatically re-evaluate selectors when the store changes, and dispatch a scoped "change" event only if their value changes. Not sure how expensive this would be, since it would require all selectors to be eagerly evaluated.
It also seems that such a comparison might fail for derived cases like @markerikson shows above with
<UserDetails>
.