Kdux

# Getting Started

At the center of every Kdux application is the store. A "store" is basically a container that holds your application state. There are two things that make a Kdux store different from a plain global object:

  1. Kdux stores are reactive. When Kdu components retrieve state from it, they will reactively and efficiently update if the store's state changes.

  2. You cannot directly mutate the store's state. The only way to change a store's state is by explicitly committing mutations. This ensures every state change leaves a track-able record, and enables tooling that helps us better understand our applications.

# The Simplest Store

NOTE

We will be using ES2015 syntax for code examples for the rest of the docs. If you haven't picked it up, you should (opens new window)!

After installing Kdux, let's create a store. It is pretty straightforward - just provide an initial state object, and some mutations:

import Kdu from 'kdu'
import Kdux from 'kdux'

Kdu.use(Kdux)

const store = new Kdux.Store({
  state: {
    count: 0
  },
  mutations: {
    increment (state) {
      state.count++
    }
  }
})

Now, you can access the state object as store.state, and trigger a state change with the store.commit method:

store.commit('increment')

console.log(store.state.count) // -> 1

In order to have an access to this.$store property in your Kdu components, you need to provide the created store to Kdu instance. Kdux has a mechanism to "inject" the store into all child components from the root component with the store option:

new Kdu({
  el: '#app',
  store: store,
})

TIP

If you're using ES6, you can also go for ES6 object property shorthand notation (it's used when object key has the same name as the variable passed-in as a property):

new Kdu({
  el: '#app',
  store
})

Now we can commit a mutation from component's method:

methods: {
  increment() {
    this.$store.commit('increment')
    console.log(this.$store.state.count)
  }
}

Again, the reason we are committing a mutation instead of changing store.state.count directly, is because we want to explicitly track it. This simple convention makes your intention more explicit, so that you can reason about state changes in your app better when reading the code. In addition, this gives us the opportunity to implement tools that can log every mutation, take state snapshots, or even perform time travel debugging.

Using store state in a component simply involves returning the state within a computed property, because the store state is reactive. Triggering changes simply means committing mutations in component methods.

Next, we will discuss each core concept in much finer details, starting with State.

← State →