Today we're kicking off TechTalk, a new series of blog publications dedicated to the technologies implemented in Webitel’s platform, interesting product features, and recommendations on using our services to ensure great contact center performance. In our first issue, Daniil Lohvinov, Front-end Team Lead at Webitel, discusses the motivation and results of migrating the platform to Vue 3. Have a nice read!
Our product has been greatly improved, leading to a completely new platform version 5 years ago. Since then, we have created an expressive front end with ten diverse client applications, from the typical CRUD registers to the visual diagram designer and our own component library.
Our front end is built on the Vue ecosystem. We started with Vue 2, Webpack v4 Bundler, and Jest test runner, and moved on to Vue 3, Vite, and Vitest. Why did we decide to migrate? Let’s discuss the most interesting moments of the upgrade.
All about Vue 3 and its benefits
Composition API Composition API is a new style of writing the Vue components, in fact, the most interesting and important feature of the new version. It has numerous advantages:
Code reuse Code, written with the Composition API, is simple and easy to reuse. This is its main advantage over the Options API. Code reuse is made through so-called Composable functions, something similar to React custom hooks, but with important differences for Vue (unlike React custom hooks, Composable functions are called only once).
Solving issues related to mixins Mixins are used to reuse code between components in Options API, but they have drawbacks. Some issues that may be insignificant in small projects become very inconvenient in large ones. When using mixins in a component, we add properties that we can’t see in this component because this is implicit. Due to this, we need to dig deep into the mixin hierarchy if the task is to find the problem causing the issue. Besides, the properties declared in multiple mixins are simply overwritten by the last one used. This may be ok for a small application with one mixin for each component. But as soon as there are several mixins, and, even worse, they start using each other, too many problems begin. We had an experience with the old project with five levels of mixin hierarchy. Understanding this code is both difficult and even scary.
As we speak about Composable functions, they are quite different because every use is transparent. We choose what we want to 'take' from what the function returns to us, and how we like to call it.
Flexible code organization The Composition API doesn’t have a strict object structure like the Options API, so writing components looks like a standard script: we can arbitrarily set the order of initializations, calls, etc. However, this has its pros and cons. On the one hand, Composition API allows you to group the code by its functionality rather than what it is (‘data’, ‘computed’, etc.), which makes sense. On the other hand, it does not require a strict component structure (as in the Options API) and allows developers to structure their code as they like. However, as you know, where there is more freedom, there are also more risks aka ‘Is everything structured and clearly prescribed?’.
A deeper understanding of working with Vue As for me, Composition API seems to be closer to JavaScript and has fewer Vue 'wrappers' between what we write and what ends up in the bundle. For example, we can import ‘ref’ for declaring a variable reactive instead of ‘to make the variable reactive you need to write it into data’. I think this will help you understand your work better, and reduce the gap between ‘I know Vue’ and ‘I know JavaScript’.
A breath of fresh air After four years of working with the Options API, the opportunity to write code on the Composition API is like a breath of fresh air that motivates explore and try new things.
TypeScript We use JavaScript, so here let me refer to the Vue documentation, which states that Composition API is much better with typifications than Options API.
However, the Composition API also has its cons:
Difficulty In my opinion, the Composition API component is more difficult to write. You have to get used to some peculiarities of this style and even fail a few times before you will learn how to write complex components.
Combining Options and Composition API Mixins are quite difficult to combine with composables in one component. Thus, sometimes you need to import the same thing twice because of ‘this’ component's unavailability (Options API) in the setup function (Composition API) or find other ways. Sometimes we decided not to refactor some components (because they were using mixins), or for a simple action to map, for example, a router and a store separately.
New features of Vue 3
In addition to the Composition API, there are a lot of new Vue 3 features that may catch your eye, particularly:
Fragments Finally, you don’t need to wrap the component markup which has several root elements in an extra div;
Emit declaration Now it is possible to declare component emits, similar to the declaring of props;
Provide/inject Instead of custom global Vue variables, you can do it in a specific scope, and explicitly;
Better TypeScript support as Vue 3 is completely written on TypeScript.
Striving to implement up-to-date technologies
The obsolescence of the framework itself isn’t such a problem. Real problems begin when you try to find supported libraries working with an old framework version. Of course, there are ‘eternal’ libraries, but if you want to search for something special, such as a calendar or carousel within Vue 2, this will take a lot of your time and resources.
Actual technology stack support is essential for product health and the developer’s professional level, especially when your project is actively developing. Our platform is a product that lives, changes, and evolves: our team prepares up to six system releases a year. Implementing new technologies into the product is important for its constant development. Therefore, our decision to migrate to Vue 3 is a logical path for the company’s product growth strategy.
Our experience
Since I was responsible for the migration, I can share our detailed experience. The basic migration of nine applications took about a month with a compatibility build. This also includes moving to Vue Test Utils v2, and unit test fixes. However, over the next year, we were tracking and fixing bugs caused by migration. Nevertheless, it was a rewarding experience.
Conclusion
Moving to Vue 3 took approximately a month for general migration and a year for minor bug fixes. However, it was worth it. Our platform now uses an upgraded framework with improved functionality, access to library updates, and a great opportunity for creating new awesome product features.
Comments