calband / calchart-redesign

Calchart 4 for the web! 🌐
https://calband.github.io/calchart-redesign/
4 stars 0 forks source link

Clean out unneeded properties from CalChartState #123

Open MichaelTamaki opened 3 years ago

MichaelTamaki commented 3 years ago

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 and invertedCTMMatrix. 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.

image

These could be stored as global variables... Or whatever gets the job done! Roughly:

export const GLOBAL_GRAPHER_VARS = {
  grapherSvgPanZoom: ...,
  ...
}
rmpowell77 commented 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.

rmpowell77 commented 3 years ago

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.

MichaelTamaki commented 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.

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.

image

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!

MichaelTamaki commented 3 years ago

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?

MichaelTamaki commented 3 years ago

.shw = CalChart1-3 .shw4 or .json or .shoooow or .jshw = CalChart4 (JSON format)