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
Investigate hypothetical autotracking-based perf optimization #2033
Comments
Just saw this issue now :) Please take a look at #2043 where I describe a potential way to use SolidJS's stores to avoid rerunning irrelevant selectors. |
There's some strongly-related work from the Causal team here, where they've built their own store subscriptions and are trying to narrow down how many selectors run based on ordering: |
Closed
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://github.com/simonihmig/tracked-redux uses autotracking to selectively update UI components that depend on specific changed pieces of state.
I already ported that logic to Reselect, in reduxjs/reselect#605 .
I wonder if there'd be some way to use this within React-Redux.
Like, what if we had an alternate
Subscription
implementation that wrappedstore.getState()
with this autotracking proxy and passed that around, then tracked which callbacks accessed the state and got smarter about when to re-run those?I'm sure there's a ton of caveats here, such as nested subscriptions and
connect
, bundle size, perf overhead, etc.related, yet another "Redux perf is hard at scale" talk: https://twitter.com/zeigenvector/status/1668713918049525760
The text was updated successfully, but these errors were encountered: