Reduce re-derivation of body rows and columns #4
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.
The original strategy had plugins expose a row transformation function in a
Readable
, to whichuseTable
then subscribed to transformoriginalRows
into the final set of rows to display.However, this meant that any updates to plugin state would cause the entire derivation to recompute from
originalRows
torows
.We can improve plugin performance – especially if plugin state being updated is at the end of the transformations – by creating a chain of derived stores.
The goal is to only recompute rows from the point of a plugin that updated and onwards.
To do so, each plugin receives a
Readable<BodyRow[]>
store which it uses to derive a transformedReadable<BodyRow[]>
store. Plugins can then be chained together by passing the result of one plugin to the next. By creating this chain, the only dependencies of a plugin's derived rows are its own plugin state and the previous plugin's derived rows, minimizing the re-computation required.