Implement default folding behaviour of ShapeViewer and ability to unfold #301
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.
This PR implements default folding of the interaction when first rendered in the ShapeViewer.
Rather processing the entire interaction body all at once, we're only rendering rows that will actually be visible. To reduce the amount of visible rows for first render, we only have the first element of every array unfolded, with the rest hidden. When clicking on a folded line, the view model can be updated by only rendering the bit of missing shape and inserting it in the right place, rather than having to recalculate the entire thing.
The exact behaviour of what and what not to fold is arbitrary, but what we have now is a good default until we start considering diffs (out side the scope of this PR). In case of the example I'm testing with, instead of processing and rendering
781
rows straight from the beginning, we collapsed19
trails and only render96
rows initially.Since we start with a small amount of initial rows and can then incrementally process additional subsets, that also gives us the partitioning we need to decide what to perform additional transformations on, like annotating each row with the expected type.
Another thing that's worth mentioning is that the view model expressed using the reducer pattern. This makes all the state transformations into stateless functions, which doesn't only help us get the logic right in this first implementation, but is also a first great step to it being extracted to it's own module later (for use of Typescript, easier testing, re-use of logic, etc). Any additional enhancements are easily expressed as actions as well.
Final note: this is still behind a disabled-by-default feature flag + opt-in URL.