State management & application data flow

From local state management using data, to application state management using Vuex store.

Summary

• Reactive data (again)
• State management
  • Local state
  • The store pattern
  • Vuex store
• Application data flow

Reactive data

• (reactivity) => [docs]
• (1-way data flow) => [docs]

State management

• What is state?
• What is state management?
• What is state management pattern?

State

The behavior of the app at a given moment in time.
Super declarive!

State management

How to define, drive, check and debug that behaviour?
Me

State management pattern

It is a self-contained app with the following parts:

• The state, the source of truth that drives our app
• The view, a declarative mapping of the state
• The actions, the possible ways the state could change in reaction to user inputs from the view

Vuex

Local state

It is often overlooked that the source of truth in Vue applications is the raw data object [... For this reason, you may have a] piece of state that [is] shared by multiple [components]. Now whenever [the data] is mutated, [your components] update their views automatically.
Vue State Management docs

However...

[...] the simplicity quickly breaks down when [...]:

• multiple views may depend on the same piece of state
• actions from different views may need to mutate the same piece of state

Vuex

And...

[Although we] have a single source of truth now, [...] debugging would be a nightmare. Any piece of data could be changed by any part of our app at any time, without leaving a trace.
Vue State Management docs

Code time

Pro tip: take notes here...

The store pattern

• (vue state management) => [docs]
• (flux architecture) => [docs]
• (redux architecture) => [docs]

So...

[...] why don't we extract the shared state out of the components, and manage it in a global singleton? With this, our component tree becomes a big "view", and any component can access the state or trigger actions, no matter where they are in the tree!
By defining and separating the concepts involved in state management and enforcing rules that maintain independence between views and states, we give our code more structure and maintainability.
Vuex

In a nutshell:

• extract the shared state out of the components
• manage the state in a global singleton
• separation of concerns

• store
  • holds the application data
  • manages the application state
  • defines and "receives" actions
• state
  • defined by data
  • represents the application behaviour at any specific moment in time
  • mutates by responding to an action
• action
  • triggers a mutation in the state
  • defines the application internal API

Also...

The most important concept is that data flows in one direction.
Flux concepts docs

It’s important to note that you should never replace the original state object in your actions - the components and the store need to share reference to the same object in order for mutations to be observed.
Vue State Management docs

Code time

Pro tip: take notes here...

Vuex store

• (vuex) => [docs]

Why?

• deeper connection with vue
  • ie. uses reactive data for the state
  • ie. has getters ("computed props" for the store)
• it scales better for mid to large SPA

Flux libraries are like glasses: you’ll know when you need them.
Dan Abramov

Key concepts

• state
• getters
• mutations
• actions
• modules

State

Vuex uses a single state tree - that is, this single object contains all your application level state and serves as the "single source of truth." [... Usually you will] have only one store for each application. A single state tree makes it straightforward to locate a specific piece of state, and allows us to easily take snapshots of the current app state for debugging purposes.
Vuex state docs

• state is reactive, like Vue components data
  • be aware of reactivity when mutating the state (read more here)

Getters

You can think of them as computed properties for stores. Like computed properties, a getter's result is cached based on its dependencies, and will only re-evaluate when some of its dependencies have changed.
Vuex getters docs

Mutations

The only way to actually change state in a Vuex store is by committing a mutation.
Vuex mutations docs

• use them to mutate the state
  • "the only way to actually change state" ↑
  • be aware of reactivity when mutating the state (read more here)
• you cannot directly call a mutation: you need to commit it
• mutations are only synchronous

Actions

Actions are similar to mutations, the differences being that:

• instead of mutating the state, actions commit mutations
• actions can contain arbitrary asynchronous operations

Vuex actions docs

• can be dispatched or called directly
• can be sync or async

Modules

Due to using a single state tree, all state of our application is contained inside one big object. [...] To help with that, Vuex allows us to divide our store into modules. Each module can contain its own state, mutations, actions, getters, and even nested modules.
Vuex modules docs

• by default modules are registered under the global namespace
• if you want your modules to be more self-contained, you can mark them as namespaced

Code time

Pro tip: take notes here...

Application data flow

A brief introduction to layered applications

Layers

1. data access (aka persistent)
   • data is stored (CRUD)
2. business
   • data is restructured, manipulated, computed and/or aggregated
3. connection (aka service or application)
   • data becomes application state
4. presentation
   • UI

Code time

Pro tip: take notes here...

Q&A

Pro tip: ask stuff...