-
Notifications
You must be signed in to change notification settings - Fork 11
Global Store
Before we had a global data store, we had one entry point at the component parent and passed down state continuously to individual components. Sometimes, we would pass data through children components so it would get to their children components. With a global store, data is centralized in a single place and can be immediately accessed by components. Using Vuex as a state management system is better than using global variables because changing state causes Vue to re-render components.
For example, say we change the subject color, so all courses of that subject should also change colors. This change should be reflected in the the schedule view, the bottom bar, and the requirements bar. We can easily get this synced value from the global store without passing around the data to multiple (sometimes irrelevant) components.
To read data, import store and access store.state.variableName
. The types for
the data are in
store.ts
in VuexStoreState
.
Vuex doesn't let you write data arbitrarily; instead, it is indirectly performed
by mutations (which have to be defined in ordered to be used). This looks
something like store.commit('mutationName', payload)
where payload
is the
data you pass in. Note that writing a to the global store doesn't immediately
write it to the database as well.
To keep the global store consistent with the database, we write to Firestore, Firestore writes to Vuex (in real time using snapshot listeners), and components subscribe to Vuex.
We avoid just updating the data store, so we are able to maintain that mutations are inside listeners.
When writing to the database and then updating the global store via listeners, it's usually fast enough but there are inevitably network latencies. This makes the pattern not sufficient for drag and drop; otherwise, the user sees a delayed result. So, we don't use Firestore listeners for dragging first. Instead, we write to Vuex first and then to the database.