monokle
monokle copied to clipboard
refactor: add virtualization to section/item blueprint/instance
The main goal of this PR was to virtualize the list of elements rendered by sections/items while also keeping the functionality that we had before.
Changes
- virtualized the rendering of sections and items using
react-virtual
- introduced new NavigatorRow and RowBuilder models which represent the virtualized rows for section/item instances
- added optional
rowBuilder
property to section/item blueprints to allow customizing dimensions of rows - removed
groups
logic from sections because it only complicated the code and subsections should be sufficient - removed lots of styling properties that are not used anymore
- split the
sectionBlueprintMiddleware
logic into multiple files to improve readability + simplified some of the logic - moved most of the logic from the old SectionRenderer to the sectionBlueprintMiddleware
- fixed the "full scope cache" logic
Left to do in following PRs:
- properly unregister blueprints when changing projects
- figure out if we can keep custom rendering for the actual rows (affecting
nameDisplay
), because we have to specify a fixed height for virtualization - reintroduce Kustomize Patches section, but have them as subsections to each kustomization (should look similar to the Helm pane sections)
- reintroduce Unknown Resources section, but make it a subsection to the K8s Resources section
- check if the Walkthrough on the K8s Section still works (probably not, needs to be reintroduced)
- determine if we still need "registeredSectionIds" in the redux store
- later on, determine how RTK liteners could be used instead of the middleware (probably by having a listener for each blueprint? but at the moment there are operations that have to happen after all instances are built)
- maybe we should define a list of actions that can change the instances but my concern is that it will become harder to maintain the logic
Checklist
- [x] tested locally
- [x] added new dependencies
- [ ] updated the docs
- [ ] added a test
I’ve looked at how much time the processSectionBlueprints
function takes to complete on both old and new implementation and the timings seem to be really close. So with the refactor so far, the only performance gain would be on the virtualization of the elements. At the moment I’m trying to run some of the processing in workers to see if that speeds it up. Additionally, I think each blueprint might have to define which redux actions can affect their scope to avoid doing unnecessary processing.
We can close, code has been moved to monokle-core/packages/tree-navigator.