State Management

[KLBa]

State Management

• Status: proposed
• Date: 2020-11-10

Context and Problem Statement

The ADR-Manager has a state that needs to be stored. Currently there is no global store, but this should be changed. Data that make sense storing globally:

• Edited ADRs until they're committed (maybe even all ADRs from all added repositories)
• Added Repositories
• The current mode (basic, advanced, professional)

How should the state be stored?

Decision Drivers

• ADR-Manager should be lightweight and easy to implement.
• ADR-Manager should be easy to maintain.

Considered Options

• Don't use any global store.
• Implement a state manager from scratch.
• Use the Vue-State-Manager Vuex.

Pros and Cons of the Options

Don't use any global store.

Just "cascade" updates between Vue-Components via Events and Props. E.g. each editor tab has a prop (v-model) for the displayed ADR. Whenever the ADR is changed the Sup-Component (currently TheEditor.vue) updates the ADR in each tab. When a new ADR is created via a toolbar menu, the event needs to cascade down to each related Editor-Component.

• Good, because it's easy to implement. It is currently done that way and requires no further actions.
• Bad, because it's a debugging nightmare.
• Bad, because GUI and functionality is more directly connected. Changes to the GUI often require updating functionality and vice versa.

Implement a state manager from scratch.

Implement a state manager from scratch as described at https://vuejs.org/v2/guide/state-management.html#Simple-State-Management-from-Scratch.

• Good, because GUI and functionality are split better. Debugging is easier.
• Good, because it's a compromise between using Vuex and using no global state.

Use the Vue-State-Manager Vuex.

Docs can be found at https://vuex.vuejs.org/.

• Good, because best long-term maintainability.
• Good, because prepares for extensions like 'Undo-Redo'.
• Good, because the development team can gather experience with Vuex.
• Bad, because of more concepts and boilerplate.
• Bad, because does not fit in our project. We assume that ADR-Manager is a small-to-medium project and not a medium-to-large project

[koppor]

The Vue-State-Manager Vuex reads like a redux implementation. I would assume that this state is not persistent of hard reload.

Proposal:

Bad, because does not fit in our project. We assume that ADR-Manager is a small-to-medium project and not a medium-to-large project

(Inspired by the quote of the vuex page)

But if you are building a medium-to-large-scale SPA, chances are you have run into situations that make you think about how to better handle state outside of your Vue components, and Vuex will be the natural next step for you.

Edited ADRs until they're committed (maybe even all ADRs from all added repositories)

I think, this is the main requirement for the decision - the other things need to behandled differently (see below).

For that, I would also go for the "Implement a state manager from scratch."

Added Repositories

This needs to be persistent across browser sessions.

I think, this can be implemented using GitHubs authorization concept: As user, I allow an application access to certain repositories. This information is "the same" as the added repositories (should be kept in sync). - If not, "local storage" should be used (see below)

The current mode (basic, advanced, professional)

I would assume that something should be stored in the "Local Storage" to have it persinstent across browser restarts

Maybe a cookie could be enough though?

Nitpick comment

A heading should not end with a .. :innocent:

[KLBa]

Good points! I didn't consider cookies and persistent storage yet.

Also added the con argument for Vuex.

[xJREB]

I also support the notion that a flux architecture (e.g. Redux, Vuex, etc.) is usually only worth the effort and additional complexity if you have a reaaaally complex app with tons of views and client-side states. If you don't have that, a small config object in localStorage usually is more than enough to allow some nice usability-related storing of values.