Nicklas Israelsson
Dec 4, 2018
(10 votes)

Using Vuex in the MusicFestival template site

We’re rewriting the music festival template site to use vuex to handle the state of the app. Previously, we’ve been using instance specific properties and mixins to handle and share state in different ways. In my opinion, moving all state handling into a centralized store is a good idea regardless of framework. It makes the code easier to understand and reason about. It’s also worth noting that the available libraries for the different frameworks using flux-like stores are similar enough to make it easy to transition between frameworks.

Another positive aspect is that the available tools for using a state management system make debugging very convenient.

Vuex debugging

What are the differences?

On the surface, the site should function exactly the same, so the difference only lies in the architecture of the site. We’ve moved the different states we previously had into separate vuex modules. Modules makes it easier to separate the concerns of the different states but still use a centralized store to get the data that is needed.

Updating the model

In my previous blog, I mentioned a lot about who should own the model. This approach does not fundamentally change that concept since we will still pass the model from a parent component to child components. The difference will be that instead of using the EpiDataModelMixin, the loading and updating of the model will be done in the epiDataModel vuex store module. The parent components will read the model from the store and pass it to child components. Updating the model is initiated from the router. When a route has changed, the router will dispatch an action in the store telling it to update the model.

Keeping track of editing context

The $epi property was used to hide and show the editing overlay in edit mode. The same functionality is now stored in the epiContext module. We’ve changed the old file that defined the $epi instance to something we call epiMessages. The sole responsibility of epiMessages is to register the event handlers for beta/contentSaved and beta/epiStart that will update the new epiContext store module.

Keeping track of application context

The $app property was mainly used on the start page to show/hide a modal window and demonstrate how turning editing on and off in on page edit could be handled in that scenario. This has also been moved into its own vuex module called appContext.

Github repo

This rewrite was merged through a PR on github recently, so if you’re interested in looking into how a transition to using a state management system could look like you can view all commits in the PR here: Use vuex

Related links

Blog series about the template site and SPA sites in OPE:

Documentation on client side rendering in Episerver:

Dec 04, 2018


valdis Dec 9, 2018 05:40 PM

this is nice!

SReddim Sep 13, 2019 08:25 AM

Hi, Can we use this with Vue and Nuxt Js? Can you provide any insight how we can do that with a sample routing configuration.

Please login to comment.
Latest blogs
Zombie Properties want to Eat Your Brains

It’s a story as old as time. You work hard to build a great site. You have all the right properties – with descriptive names – that the content...

Joe Mayberry | Mar 29, 2023 | Syndicated blog

Optimizely finally releases new and improved list properties!

For years, the Generic PropertyList has been widely used, despite it being unsupported. Today a better option is released!

Tomas Hensrud Gulla | Mar 28, 2023 | Syndicated blog

Official List property support

Introduction Until now users were able to store list properties in three ways: Store simple types (int, string, DateTime, double) as native...

Bartosz Sekula | Mar 28, 2023

New dashboard implemented in CMS UI 12.18.0

As part of the CMS UI 12.18.0 release , a new dashboard has been added as a ‘one stop shop’ to enable editors to access all of their content items,...

Matthew Slim | Mar 28, 2023