Open KamranAsif opened 7 years ago
Congrats on publishing evil-diff! Does it make sense to do a v1 which just applies evil-diff at the end of the reducer steps on the state? That seems easy to put together and would give many of the performance benefits.
Then once we release we can pull state out into models one at a time. I can probably put together a POC using reselect which would make things nice and clean.
This would still be interesting, but may be a use case for Immer. @somavara @mycrobe could you keep this issue in mind if anyone wants to play around w/ and learn about Immer.
Sure @wcjordan
Our current redux store contains both derived and source data. This has led to some messy code (see stateHelper files)
I propose a new strategy, thanks to my evil-diff library.
The redux store contains only source data, acting as the single source of truth. This means it will store the props, and some basic scroll and column logic.
The redux store will not be connected to any react component. Instead, it'll be consumed by a series of models (read: pure functions) that will transform the data as needed.
For example, there will be a model that takes in data like rowHeights, scroll offset, etc. and outputs visible rows. A model can depend on another model downstream, so the visible rows will be consumed by a model that will calculate rowOffsets and another that will calculate rowHeights.
To make this performant, evil-diff will apply psudo-immutability so we can avoid re-running models that haven't changed.
All these models will feed the FixedDataTableContainer component that will map it correctly and pass it into the FixedDataTable view.