In the previous article of the "How to Structure a Large Scale Vue Application" series, we took a look at some standards that you can employ in your Vue.js application to keep your codebase predictable, easy to navigate, and understandable. Another step you can take to improve the developer experience when building a large scale application, especially with a team, is to setup some automated process for code linting and formatting.
What is the best way to structure a Vue.js application so that it scales and remains maintainable and extendable the more it grows? This is a question that I've heard on numerous occasions and I think one answer to that question lies in the principle of predictability. When it comes to creating a scalable project you want everything about it to be as predictable as possible.
Ever wonder how to build one of those fancy tag input components like you see in blog admin panels or in notion docs? Well, wonder no more! In this article we'll use Vue 3's composition API to make a reusable tag input component of our very own. Along the way we'll cover some important concepts you should know to be effective with the Vue 3 composition API.
Throughout this series we've explored various store solutions both official and DIY. We'll end the series by taking a look at a home rolled solution with Vue 3's composition API.
Now that we've seen some library options for implementing a Vue.js store (Vuex and Pinia), I want to spend a little time talking about some home rolled solutions. While home rolled solutions can be more fragile (if done hastily), less tested, and less standardized, they also provide an opportunity for useful customizations and the opportunity to learn more about stores and push the limits on what's possible.
First, let's talk about
Vue.observable for all of you still using Vue 2 and once we've seen the concepts employed here it will only be a short leap to using the Vue 3 Composition API as a store in the next article.
So where do we start rolling our own store in Vue 2? Vue 2.6 exposed a wonderful little method called
Vue.observable() made it possible to create reactive data outside of a Vue component, thus also making it possible to have a single source of truth (or state) that can be shared directly between multiple components.
An alternative option for creating a store for your Vue.js application is Pinia. Pinia is the new kid on the block when it comes to stores for Vue. It was started by Vue core team member Eduardo San Martin Morote with the first commit to the repo being made on Nov 18, 2019. Pinia boasts an intuitive API and many of the features you've come to expect from a Vue.js store.
One of the most powerful features of modern single-page web applications (SPA) is routing. Modern single-page apps such as a Vue application can transition from page to page on the client-side (without requesting the server). Vue Router is the official library for page navigation in Vue applications. Vue Router is simple to use, yet powerful. In this article, we will deep dive into Vue Router 4 (used with Vue 3). We will go over everything you need to know to use Vue Router comfortably.
In the previous article in this series we discussed what a store is, why it's useful, and when it's a good time to implement one. With those principles in mind, we can now look into how to implement a store with Vuex.
Perhaps you've heard of Vuex and you're wondering what it is. What does it do? Why does it exist? How do I use it? If these questions are on your mind you've come to the right place! In this series of articles, we'll take a look at Vuex, the official Vue.js store solution, as well as some alternatives that can serve the same purpose but with different approaches. By the end of the series you should have a good grasp on Vuex and other Vue.js store solutions and be well prepared to implement the store solution best suited for your project and coding style.
<router-link> tag is a great tool for navigating between different pages of your Vue application but it is not the tool to use when navigating to an external link, for that you’d want to use a regular
<a> tag. Maybe it's just me, but often times, I can't be bothered with keeping up with the difference. Other times the links might be dynamic, that is, coming from a database or some user provided data source. In such cases you simply won’t know if the link is external or internal and what a pain it would be to do a v-if manually in every place that link might be used.