rilldata
[WIP] Prototype to leverage immer to create isolated derived stores
Checklist
- [ ] Manual verification
- [ ] Unit test coverage
- [ ] E2E test coverage
- [ ] Needs manual QA?
Summary
Issue addressed:
Details:
TODO (these cannot be done without complete adoption of state-managers):
- [ ] Create new store for each dashboard instead of the global
metricsExplorerStore. - [ ] Move the init and sync functions to state managers.
- [ ] Create an instance of
ImmerLayerfor each dashboard. - [ ] Get rid of manually adding
rootkey. - [ ] Add safeguards to make sure all fields used in selectors are actually derived.
Steps to Verify
I havent queued this to see if it solves the problem at hand, if it does then I think it would be fine to put in as a stopgap solution.
Architecturally, my concern would be that going this direction will add a profusion of new types that have to be added by hand. One of the things that we were attempting to do with the old approach was to use type inference operating on simple functions to make things like manually specifying DashboardDataSources<T> for all the possible variants of T unnecessary.
I was looking around the code more, and I think the way that I would probably approach this if I was able to take a run at it again would be to remove all of the selectors that return a function in a readable in favor of only using flat selectors that return values, and then caching the values and only set-ing the readables when the cached output changes. That would allow the overall architecture including the type inference and the simple selector pure function definition approach to work as it does now, but memoizing output values of the selectors would prevent cascading changes (and rerenders) when actual values are unchanged.
But I think the broader architectural issues it don't really matter at this point, I think the practical thing to do would be to go ahead and merge this approach if it fixes the rerun door problems in the short term.
