In this article, we extend the functionality of our very simple demo application from the previous article to display multiple paginated lists for the same content type. The paginated list feature module does not fetch any data itself but instead connects to the data model module. Doing so makes it possible to cache requests with the same query across feature modules to reduce the number of requests to your API and make your app feel snappy...
The data model approach builds on the idea that you have a separate Vuex module for every data model of your application (e.g., users, posts, comments). Following this pattern makes it very straightforward to structure your Vuex store. But there are also some problems with a pure data model paradigm...
Often it seems like we build the same applications again and again. And at least sometimes it feels like that because indeed we do. Again and again, we build the same CRUD applications with their generic list views, edit forms, and previews. Throughout this article, we examine how to create a generic and reusable structure for a traditional CRUD application. Our primary goal is to keep our codebase DRY...
One of the main concerns I have when building Vuex-based applications is the tight coupling of components with the Vuex store that seems inevitable when using Vuex. Ideally, I want to be able to switch the data layer of my application at any time without having to touch all my components that rely on data from an external resource...
Today we look at how we can design a system for quickly creating generic Vuex modules for typical CRUD content types. Often when creating applications rather sooner than later we catch ourselves repeating the same boilerplate code over and over again because most of our content types are very similar at their core...
Listening to one of Full Stack Radio's latest episodes, I was very impressed by the expertise of Matt Biilmann, CEO of Netlify. Adam Wathan and Matt talked a lot about how global state is handled in the Netlify web application. Although the Netlify app is built with React and Redux when he spoke of his philosophy for structuring the global state of the app, it motivated me to think a little more about this topic in the context of Vue.js and Vuex...
When first starting with Vuex, most people wonder what data should be stored in Vuex in the first place? In the journey of answering this question, for many people (including me) comes what I call the “Let's Store Everything in Vuex” phase. But very quickly, after having encountered the first obstacles, comes the realization that this cannot be the be-all and end-all solution to managing state in Vue.js applications...
I'm currently in the process of refreshing my knowledge about Laravel. I do so by reading the official documentation. Although, I almost exclusively work on the front side of things with Vue.js nowadays, there is a lot to be learned by getting to know techniques outside of your comfort zone...
In this article, we take a look at a possible way of how to structure a Vuex store for a large scale application. When I was researching possible approaches for handling the state of big, Vue powered applications with Vuex, it was pretty hard to find any good examples...
In one of my previous articles about form field handling in combination with Vuex, I introduced the vuex-map-fields package, which allows to conveniently map a list of fields to Vuex conform getter and setter functions. In today's article we take it a step further and we'll explore how we can use the latest release of vuex-map-fields to build a Vuex powered multi-row form...