In this article, we will start by looking at how the app initialization code works in Vue 2 apps. Then we’ll see what drawbacks it has and how those are eliminated with the new initialization syntax used in the 3rd version of the Vue framework.
In the previous parts of the series we discussed the concept of a domain and how it could correlate to building independent and easily maintainable modules in your application. Most of the introduced concepts concentrated on separating parts of your app and avoiding tight coupling between them. Even if you make your modules independent there are still things that will lead to significant and time-consuming rewrites once you have to replace them - third parties.
In this article you will learn how to make your app independent from them as well!
In this article, we will dive into one of the cool new features that were introduced with Vue 3 - Teleport.
Since the announcement of Vue 3 there are two questions I am frequently asked by newcomers and senior Vue developers.
- Should I use or learn Vue 2 in 2020?
- When is the Vue 3 Masterclass coming?
In the previous article I introduced the concept of Domain-Driven-Design and showed how it can be utilized within Nuxt with their modules. In this part I want to share with you how we applied the same concept in Vue Storefront 1 which is a regular, Vue 2 application.
I’ve been experimenting with Domain-Driven approach in Vue apps for quite some time already in Vue Storefront and Vue Storefront Next. Utilizing this approach can lead to significant improvement in areas related to the maintenance and complexity of your codebase. In this mini-series I want to share some of the patterns that worked for us in Vue Storefront and can be easily applied in any Vue application.
I will show how to apply these patterns both in Nuxt and “vanilla” Vue projects. In this article we will focus on theory and Nuxt implementation.
In today's part of Vue Performance series we will focus on the most exciting framework in Vue.js ecosystem - Nuxt! Specifically we will focus on how it’s Server-Side Rendering (SSR) mechanism impacts performance and what we can do to optimize it. Of course all previous tips from this series are still viable in Nuxt!
In the last couple of months Composition API took Vue community by storm. Thanks to a plugin that brings it’s capabilities to Vue 2 the new API is already supported in many of the most impactful projects from Vue ecosystem like
vue-apollo. Unfortunately, despite a very quick adoption Composition API was lacking a proper way of supporting applications that are utilizing Server-Side Rendering. The majority of such applications is written in NuxtJS. The Nuxt core team was very aware of that issue and few months after Composition API plugin for Vue 2 was released they did what they’re doing best - made an awesome module to help their community. In this article I want to introduce
@nuxtjs/composition-api module that brings first-class Composition API support to Nuxt.
Until now, the Vue.js Performance series has focused on the bundle size. While it’s certainly one of the most important aspects of app performance it’s not the only one. To build fast web applications, it's not only crucial to serve the smallest possible assets. It's also important to reuse them whenever possible so users won't wait for something that he/she has already downloaded. If you have read the previous parts of this series you most likely know enough about the bundle size to be confident on that field. This is why in this article I will focus on another technique that could significantly improve your loading times - caching.
We are used to certain ways of reusing code. Usually it happens through libraries and components with strictly defined APIs but sometimes thats not enough. Sometimes we want to reuse our whole codebase in a way that lets us adjust it to a special event like Black Friday or just make a slightly different version of our website for a specific country. In cases like that, we usually have very different needs, and being limited by previously defined extension points could make such tasks painful or even impossible.
Being able to automatically inherit all “standard”, unchanged files from a single source of truth and only adding what we want to change when making a new version of our website could drastically reduce the amount of maintained code. In this article, I will show you how to make all of that possible in Nuxt.js in a relatively simple way.