Note: This is part 3 of a 3-part series on "Instance Aware Vuex Modules". In Part 1 we covered a basic introduction to Vuex and the use of namespaced modules. In Part 2 we covered the usage of dynamic route-based Vuex modules, the issues with
map*helpers, and how we can work around them with our own
mapInstance*helpers methods. In this post, we'll explore other opportunities where instance-aware Vuex modules can help us.
Note: This is part 2 of a 3-part series on "Instance Aware Vuex Modules". In Part 1 we covered a basic introduction to Vuex and the use of namespaced modules. In this post, we'll explore using dynamically-namespaced Vuex modules alongside dynamic routes in vue-router, and some interesting challenges presented.
Vuex is a great state-management tool provided by the Vue core team. It's especially useful in server-side rendered (SSR) applications as a mechanism to send the server-side state up to the client for the app hydration process. In this post, we'll look at some of the basics of Vuex and how we can use namespaced modules to isolate our logic into small, targeted modules.
As web apps grow more complex, we end up sending larger JS/CSS bundles to the client. If you're not careful, before long you can find yourself with a site that no longer snappy on slower connections due to the sheer amount of time it takes to send the bundles across the wire. This post aims to document handful of patterns we've found handy at URBN to keep bundles small and our load times fast.
A layman's interpretation of Occam's Razor can be boiled down to "the simplest explanation is usually the correct one." This was exactly what came to mind the moment I learned how Vue.js implements it's change detection under the hood. It's simple, elegant, and beautiful.