Book Image

Vue.js 2 Design Patterns and Best Practices

By : Paul Halliday
Book Image

Vue.js 2 Design Patterns and Best Practices

By: Paul Halliday

Overview of this book

Vue.js 2 Design Patterns and Best Practices starts by comparing Vue.js with other frameworks and setting up the development environment for your application, and gradually moves on to writing and styling clean, maintainable, and reusable Vue.js components that can be used across your application. Further on, you'll look at common UI patterns, Vue form submission, and various modifiers such as lazy binding, number typecasting, and string trimming to create better UIs. You will also explore best practices for integrating HTTP into Vue.js applications to create an application with dynamic data. Routing is a vitally important part of any SPA, so you will focus on the vue-router and explore routing a user between multiple pages. Next, you'll also explore state management with Vuex, write testable code for your application, and create performant, server-side rendered applications with Nuxt. Toward the end, we'll look at common antipatterns to avoid, saving you from a lot of trial and error and development headaches. By the end of this book, you'll be on your way to becoming an expert Vue developer who can leverage design patterns to efficiently architect the design of your application and write clean and maintainable code.
Table of Contents (19 chapters)
Title Page
Copyright and Credits
Packt Upsell
Contributors
Preface
Free Chapter
1
Vue.js Principles and Comparisons
12
Server-Side Rendering with Nuxt
Index

Components


There are many ways for components to communicate within Vue, such as the use of props, events, and store-based scenarios. Vue also gives us access to $parent and $children objects, which allow us to interact with parent/child components. Let's take a look at this and see why it shouldn't be used.

Communication – Anti-pattern

Imagine that we had our familiar TodoList example, and within the TodoItem component, we want the ability to complete a particular Todo. If we wanted to keep our todos within the TodoList and thus call the completed method from TodoItem, we could do it like this:

export default {
  props: ['todo'],
  methods: {
    completeTodo(todo) {
      this.$parent.$options.methods.completeTodo(todo);
    }
  }
}

This is a bad idea for numerous reasons, mostly because we're tightly coupling these two components together and assuming that there will always be a completeTodo method on the parent component.

What can we change about this to make it better?

I'm not saying that...