Open MichaelTamaki opened 3 years ago
We do want modifications to grapherSvgPanZoom to go through the VueX mutator system so that when it changes those values are published and it causes a refresh of the draw to occur. So it doesn't need to belong in CalChartState, but it does need to be part of the mutations.
I would propose we have two different types of state. CalChartApp state and CalChartDoc state. The rule of thumb would be that values and properties that would pertain to state that we want shared between two different users collaborating on a show would be in the CalChartDoc state, otherwise the value would be in the CalChartApp state. (those two different users could be the same user at some point in the future, so like when you save a show and restore a show in the future)
For instance, the addition of a stunt sheet by one user would want to be seen by a different user, but if user A is editing stunt sheet 4 and the user B adds a stunt sheet at 8, we wouldn't want user A to suddenly have the sheet the are editing become stunt sheet 4. So the currently viewing Stuntsheet should be a CalChartApp state variable, but the stunt sheets would be a CalChartDoc state variable.
There's also probably something about how the CalChartApp state isn't saved to the file, but instead resides in some sort of local cache. If you refresh CalChart, we wouldn't want the currently editing stunt sheet to go back to stunt sheet 1, we'd want it preserved along with the CalChartDoc state. So it's should participate with the CalChartDoc state in terms of saving and restoring, but shouldn't be exported to other users when it is used for collaboration.
We do want modifications to grapherSvgPanZoom to go through the VueX mutator system so that when it changes those values are published and it causes a refresh of the draw to occur. So it doesn't need to belong in CalChartState, but it does need to be part of the mutations.
There's no UI component listening on changes to grapherSvgPanZoom
, so I don't think a refresh of the draw would occur... E.g. there's no UI component that uses grapherSvgPanZoom
in the <template>
or the computed
properties. Tools use grapherSvgPanZoom
to enable/disable zoom controls though.
To your second point, these are good ideas! Two separate states might be overly complex for an MVP though... Maybe later when we're looking into collaborative editing or if STUNT brings up a use case where this is needed! Maybe an alternative to your idea is that we selectively pick which parts of the state are saved to a .shw file, and what is saved to the browser's local storage. For example, a .shw file has state variables that would be in CalChartApp
, whereas state variables in CalChartApp
and CalChartDoc
is in local storage. This way CalChartDoc
only affects the current user and we don't need to maintain two different states!
Application state? Document state? E.g. opening a menu is part of application state. Moving a dot is part of document state.
What should be saved to the show file? Vs. what is saved to local storage/cache? Thinking about google docs.
Consider undo/redo system. It needs to exist as a property separate from show
.
What do we store in a .shw
file?
{
"show": ...,
"undoRedoStack": ...,
}
What do we store in local storage/cache?
Everything else! beat
, selectedSS
, etc.
Also consider the future where real-time editing is a feature. If Michael updates stuntsheet 2, Richard should see those changes when he flips to stuntsheet 2.
Code organization for choosing what gets saved in .shw
file? e.g. How to define the fields that are saved? Consider using VueX modules https://vuex.vuejs.org/guide/modules.html#modules. Or, define classes or property sets, etc?
.shw
= CalChart1-3
.shw4
or .json
or .shoooow
or .jshw
= CalChart4 (JSON format)
We don't need to store every global variable in CalChartState. This is particularly for fields that have no effect on the UI. An example is
grapherSvgPanZoom
andinvertedCTMMatrix
. No Vue component needs to listen on changes to either of these.This gives us the benefit of not sending a bunch of unneeded mutations to the Vuex store... Hopefully this makes it easier on the undo system.
These could be stored as global variables... Or whatever gets the job done! Roughly: