Building Advanced Vue.js Applications

One problem with the Vue Options API is that it is hard to share stateful logic that relies on reactive variables. The Composition API offers us an excellent solution to this problem. In this article, we look at a possible workflow for efficiently building components and applications with Vue 3 and the Composition API...

When I first studied the new Composition API, I was confused that there are two watch hooks: `watch()` and `watchEffect()`. From the documentation alone, it was not immediately apparent to me what's the difference...

I am currently working on porting vue-lazy-hydration to Vue 3. With that comes the potential to make some significant improvements since Vue 3 has an API that allows controlling the hydration of VNodes. Working with the new APIs got me thinking about the general concept of hydration...

I'm kind of obsessed with Dependency Injection. But for a good reason. I believe that an essential factor when it comes to building maintainable, large-scale applications is to get Dependency Injection right...

Some time ago, I read a very informative article by Pete Hodgson about feature toggles. I'm thinking a lot about the Context Provider Pattern and the types of problems it can help solve, and it appeared to me as if feature toggles are one of the use cases where this pattern can provide a lot of o value...

In the React world, React Hooks are basically what in the Vue world is the Composition API. Although React Hooks and the Vue Composition API try to solve similar problems (mainly, reusability of stateful logic), how those two frameworks deal with reactivity under the hood is quite different...

With the new Composition API and Vue 3, there is a lot of talk about whether or not we still need Vuex or if it is possible to replace Vuex completely by making reactive objects globally available. In this article, I argue that thanks to the Composition API's new tools, Vuex is rarely necessary anymore...

I recently played around with the idea of using renderless provider components not only for data but for styles too. This pattern seems especially promising when it comes to building base components with style modifier props...

We use Dependency Injection to achieve loose coupling. But loose coupling and Dependency Injection can make it harder to understand how our code works. It can make it more challenging to determine where a particular dependency is coming from...

Recently I saw an interesting Tweet by Mark Dalgleish, about the idea of contextual defaults for React components. I was especially interested in this because I had to solve a similar problem only a few days before...