Chart rendering and localstorage logic cleanup #40
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.
Summary
This PR fixes some inefficiencies in the code related to rendering charts and writing to
localStorage
.Chart rendering
renderChart()
calls in places where the chart is also rendered automatically due to thestore.subscribe
callback (should bring a minor increase in chart performance)topster
package already assumes the same set of defaults when the checked attributes are missing (cuts down on memory usage when a chart is loaded as we were cloning the entire chart to run the migration)localStorage
from the code that reads fromlocalStorage
LocalStorageWatcher
renderless component at the top of the DOM intended be the only component that writes/reads directly to/fromlocalStorage
localStorage
and the Vuex state - this should make the data flow more coherent:LocalStorageWatcher
watches the Vuex state and updateslocalStorage
when it changeslocalStorage
, data flows only one way:Vuex -> localStorage
. An update tolocalStorage
should never trigger a re-render.TopBar
andSwitcher
still communicate withlocalStorage
because they interact with thecurrentlyActive
localStorage
item. It might be worth creating a new state item to track this value so we can give it the same one-way treatment as above.Interaction Layer
Additionally, this PR splits the
ChartCanvas
component into two as suggested by #13:ChartCanvas
contains the canonical rendered chart (plus empty item placeholders) and only re-renders when the chart state changes.InteractionCanvas
handles the drag-and-drop interactivity. This canvas is set to the same size as theChartCanvas
and sits on top of it, but the only thing it ever renders is when the user is dragging an item around on the chart.This system nearly eliminates the jankiness that could occur when moving around items on a large chart on a slower device, as we're not re-rendering everything on the chart for every frame of movement.
Notes
It's possible that the
localStorage
refactor will unblock #36.