DEV Community: Joe Erickson

What are services in Vue?

Joe Erickson — Tue, 23 Mar 2021 23:50:57 +0000

You might have heard the term "service" in relation to a Vue application. But looking through the Vue documentation, you might find that there isn't any mention of what a service is at all.

So when someone says "Just put that in a service", what is that supposed to mean and what are you supposed to do about it?

What is a service?

When someone mentions adding a service to an application, that just means that you are going to create a JavaScript file that will export something for you to use in your application. This could be something that calls an API or formats dates or does some other focused piece of functionality for your application. And that's all it does, focus is the key here.

Where to put services

Where do we put our services? I like to put them in a directory right next to the component directory and call it services.

📂 src/
 ⤷ components/
 ⤷ services/

Service examples

What goes into a service is usually based on what you need that service to do. If it's a simple function, you can create a file that exports the function:

export function formatErrors(errors) {
  const formattedErrors = {};

  errors.forEach(error => {
    if(! formattedErrors[error.field.name]) {
      formattedErrors[error.field.name] = [];
    }

    formattedErrors[error.field.name].push({
      message: error.message,
      link: error.moreInfoUrl
    });
  });

  return formattedErrors;
}

Then import it into your component or other Vue script, with this:

<script>
  import { formatErrors } from '../services/formatErrors.js';

  export default {
    ...
    computed: {
      formattedErrors() {
        return formatErrors(this.errors);
      }
    }
    ...
  }

Now you can write unit tests for that method easily and use it in all the components that might need it.

What about an API? Many APIs have multiple ways of interacting with it, so one function won't be enough. But you can group your API calls into an object that you can use for all of the functions:

import axios from 'axios';

axios.defaults.withCredentials = true;

export default {
  getCluster(id) {
    return axios.get('/api/cluster/' + id).then((response) => {
      return response.data;
    });
  },
  addCluster(name) {
    return axios.put('/api/cluster', { name: name }).then((response) => {
      return response.data;
    });
  }
};

Now you can use this export in your code:

import ClusterApi from '../services/ClusterApi.js';

export default {
  ...
  mounted() {  ClusterApi.getCluster(window.location.href.split('/').pop()).then(
      (cluster) => {
        this.points = cluster.places.map((place) => {
          return {
            lng: place.location.coordinates[0],
            lat: place.location.coordinates[1],
          };
        });
      }
    );
  },
  ...
};

So that's what services are, focused pieces of reusable and testable code that you can use across your application. There's nothing above that's specifically a Vue concept, but thinking of any logic in your application as a collection of services can help you structure everything in a more maintainable way.

Why does changing my copy change the original! A JavaScript Dilemma

Joe Erickson — Mon, 08 Mar 2021 13:41:31 +0000

Have you ever been working on your JavaScript code and changing the value of an object you were sure that you made a safe copy of only to have the original object change too?

And then you looked up why the heck that was happening, you read a blog post saying "Use Object.assign() instead". But you do that and it still freaken happens?

Then someone says that you have to download lodash and use the cloneDeep() method? And still no one has explained just what the hell is going on?

Yeah, I hate that.

Anyway, here's why it's happening.

Want a YouTube version of this article? Watch it here:

The values of variables

This is probably some fairly common code that you've seen before if you've done any kind of JavaScript coding:

let counter = 2;
let peopleArray = ['John'];
let languages = {
    en: 'English',
    fr: 'French',
    zh: 'Chinese'
};

These are all common ways of declaring a variable and defining what its value should be. You have a counter set to the number 2, a peopleArray set to an array with one string in it, 'John', and languages set to an object with keys of en, fr, and zh with the values 'English', 'French', and 'Chinese', respectively.

I also think that I can safely assume that you know that if you call this code:

peopleArray.push('Marty');
console.log(peopleArray);

You will see the following output in the console:

[ 'John', 'Marty' ]

And a call to:

counter++;
console.log(counter);

Will give you:

All of that is what we would expect. Nice, normal, not crazy making behavior from our good friend JS.

Where we run into problems is with this:

let supportedLanguages = languages;
supportedLanguages.de = 'German';

console.log(languages);

Which gives us this clearly wrong answer:

{ en: 'English', fr: 'French', zh: 'Chinese', de: 'German' }

But I didn't add German to the languages object! I added it to the new supportedLanguages object! Ah!

Why did this happen? How can we anticipate it and prevent it and, just as important, talk to other developers about it in the future?

Well, let me tell you.

What exactly is in a JavaScript variable?

When we think about JavaScript variables, what lives in those variables? How you think about this can help us understand the issue that we're seeing.

Most of the time, we probably don't think about this. Or we think that what's on the right side of the = is what lives in it. But that's only sort of true.

Here's how I want you to think about JavaScript variables from now on.

JavaScript variables only hold one thing.

That makes sense on the surface. Of course they only hold one thing.

But arrays and objects hold more than one thing, of course. Surely, I don't mean those?

Oh, but I do! Allow me to explain.

Many of the data types in JavaScript represent one thing. Like numbers and booleans. Another type can be treated in this same category---because of the way that it's programmed in JavaScript---strings. So you can consider that when you put one of these pieces of data in a variable, that's what the variable has in it.

let counter = 1;
let shouldContinue = true;
let name = 'Marty';

Here, the variable counter contains the value of 1. If we set a new value, we are replacing that value:

counter = 1;

If we are copying the value to another variable, it is indeed copying it and not doing something we don't expect:

let extraCounter = counter; // Copies the number 1 from counter to extraCounter
let oldShouldContinue = shouldContinue; // Copies true from shouldContinue to oldShouldContinue
let originalName = name; // Also puts 'Marty' from name to originalName

If you keep this mental model¹ for numbers, booleans, and strings, you'll be just fine. It's probably the one you're expecting anyway.

Object and Array variables are different

While the above works when thinking about numbers, booleans, and strings, it doesn't work when thinking about object and array variables. That's because objects and arrays hold more than one thing.

And since they contain more than one thing, they can't fit into a variable. So...what's in those variable?

Leave your number at the tone

Imagine, if you will, your phone's address book. You've got a lot of entries in there and if you scroll through, you'll see all the names of the people that you know in there. If you click on one of those names, does that person spring out of your phone?

Of course not! Phones don't hold people! But they can hold numbers. And that number acts as a link between you and that person. If you call that number, you can then talk to the actual person.

Well, that's how objects and arrays work in JavaScript too! What's stored in the variable? An address to the object or array!

let person = { name: 'Anna', occupation: 'Developer' };

So what does person contain? You can think of it as the address to the object on the right side, which is also called the reference in programming circles.

let person = { name: 'Anna', occupation: 'Developer' };
// person contains something like an address that points to the object,
// but doesn't actually contain the object.

It's like a phone number for data! When the variable is used, it is calling the object and asking the object to do something:

console.log(person.name);
//                ^--- ring, ring, can I have your name?

The . is often called the dereference operator for this very reason. It dereferences, or calls, the object.

This address business is something that JavaScript hides behind the scenes and you will never see it, except in a case like this:

let person = { name: 'Anna', occupation: 'Developer' };
let aNewPerson = person; // We copied the address, not the object!

In the above example, person contains an address and when aNewPerson "copies" person, it's actually copying the address, not the object! It's like having two people in your contacts that have the same phone number. When you call them, you'll connect with the same person on the other end, no matter what you change the names to.

So this is why, if we change the object aNewPerson points to, it'll also change the object person is pointing to!

let person = { name: 'Anna', occupation: 'Developer' };
let aNewPerson = person; // We copied the address, not the object!

aNewPerson.name = 'Marie';
console.log(person);

Can you guess what this prints?

{ name: 'Marie', occupation: 'Developer' }

And the same is true of arrays:

let names = [ 'John' ];
let copyOfNames = names;
// That only copied the address to the array, it did not copy the array!

copyOfNames.push('Marty');
console.log(names);

Will show:

[ 'John', 'Marty' ]

It was the same array all along!

Solutions to copy

`Object.assign()`

So, now that we know objects and arrays copy references and not values, how do we avoid the worst of the mistakes when working with them?

The first is to just keep in mind that = will copy the address and then any changes will happen to the object that they both point to. Usually, that's not what you want.

So the first thing to look at for objects only is the Object.assign() function. This does what is called a shallow copy, meaning any direct member is copied. So if you have a simple, flat object, this should work fine:

let myPhone = {
    manufacturer: 'Motorola',
    speed: 'LTE'
};
let yourPhone = Object.assign({}, myPhone);

yourPhone.manufacturer = 'Apple';
console.log(myPhone);
console.log(yourPhone);

This will create a new object---the {} above as the first argument to Object.assign()---and then copies the values of the second argument---myPhone in this case---to that new object. We got this output:

{ manufacturer: 'Motorola', speed: 'LTE' } // myPhone
{ manufacturer: 'Apple', speed: 'LTE' } // yourPhone

If you have simple data like this, this will work great. But it doesn't do a deep copy. A deep copy is where all the values, no matter how deep in the structure, are copied to the new object. In the case above with Object.assign(), it only copies the first level and that means that any objects at that level will have their references copied instead!

let goodBook = {
    author: {
        first_name: 'Brené',
        last_name: 'Brown'
    },
    title: 'Daring Greatly'
};

let scaryBook = Object.assign({}, goodBook);
scaryBook.title = 'The Shining';
scaryBook.author.first_name = 'Steven';
scaryBook.author.last_name = 'King';

console.log(goodBook);

What does that print? Shock of shocks!

{
  author: { first_name: 'Steven', last_name: 'King' },
  title: 'Daring Greatly'
}

Does it make sense yet why that would happen?

If Object.assign() is only copying the first level, that means that it copied goodBook.title and put the value in the new object. But when it copied goodBook.author it took the reference to the author object and copied it. So both books are stuck with the same author and changing it in one changes it in the other! This is why you can't always use Object.assign().

So the rule of thumb is:

If the object you are copying does not contain an object or array, use Object.assign().

`slice()`

slice() is often recommended to copy arrays. Suffice it to say, it has the same problems with Object.assign().

let books = [
    'The Alchemist',
    'A Tale of Two Cities',
    {
        title: 'Fight Club'
    }
];

let happyBooks = books.slice();
happyBooks[1] = 'The Mystery of the Ghostly Face'; // This won't change books
happyBooks[2].title = 'The Cat in the Hat'; // But this will because of the object

console.log(books);

So, again like Object.assign():

If the array you are copying doesn't contain an object or array , use slice().

`_.cloneDeep()`

How do you make sure you actually get a copy? Sadly, the answer lies outside of JavaScript and in other libraries that you will need to import. There is no native function in JavaScript that can do this. You could write your own function to make deep copies, but there are functions already written---and tested---that we can use if we import them into our project.

One of the most popular is cloneDeep() from the lodash library.

If your object or array is any kind of complex, use cloneDeep() or something similar from a library your are already using in your project.

A mental model is a way of thinking about a programming concept, not necessarily the way that it's actually programmed. It helps you picture in your head how things are working so that you can reason about and problem solve with them. ↩

How to load Vue Components on Non-SPA sites

Joe Erickson — Sun, 28 Feb 2021 21:48:41 +0000

There are times when you want to use Vue components, but the application you're working on is still in the age of jQuery. Is there a way to start using Vue without switching everything to Vue and making a single page application? Can we get all of that beautiful, juicy component action without breaking everything else that's currently on the site? Also, can we add Vue components without having to rewrite the entire website to use Vue?

Luckily, yes. But there are some things that we'll have to do to get there. Those things are:

Create Single File Components in Vue
Create a loader script that will add your component to a page when you want it
Compile the components in a build step as part of your development

Create Single File Components in Vue

Now, we can create regular ol' Vue SFCs, or single file components. By creating the whole component in one file, we get the flexibility of thinking of our components as one functional unit made up of HTML, JavaScript, and CSS. We can also write components in TypeScript or SASS if we want to. We can also get syntax highlighting since SFCs end up being fundamentally HTML documents. And with VSCode plugins like Vetur, development in SFCs has a lot of benefits going for it.

My recommendation would be to create a new folder at the root of your project called vue. This file won't be included in your deployment. Think of this as the source code that will be compiled into actual JavaScript before being deployed.

In that folder, create another called components. This is where your Vue component files will go. If you want to test this out, create a file called Hello.vue in the components folder and add this content:

<template>
  <div>Hello, {{ name }}.</div>
</template>

<script>
export default {
  data() {
    return {
      name: "World",
    };
  },
};
</script>

<style></style>

Create a loader script

The loader script should then be created that will add the component to the webpage. In this, you define that you want the component to be loaded on a certain element. Loader files can be created in a folder called vue/loaders. Name this one helloLoader.js and have it look like this:

import Vue from "vue";
import Hello from "../components/Hello.vue";

// The following creates a new instance of the component and puts it anywhere
// a element has a data-vue-component="hello" attribute.
document
  .querySelectorAll("[data-vue-component=hello]")
  .forEach((element) => {
    new Vue(Hello).$mount(element);
  });

Compile the components and loaders

This is the biggest step and one that may be very specific to your current project set up. I'm approaching the following with the idea that your project is just an HTML, CSS, and JavaScript project. If you already have a package.json or are using NPM for something else, your mileage may vary.

For the following, you will need to have the latest Node LTS installed, at least 14.16 I would say.

We need to add a compilation step to the project. If you already have Webpack for something else, this will be able to fit into that. If you're not using Webpack, I show below how to do that. Otherwise, I found the information on the Vue loader site.

First, install the vue, vue-loader, and vue-template-compiler libraries:

npm install -D vue vue-loader vue-template-compiler

We'll also install webpack, if you don't have it in your project yet:

npm install -D webpack webpack-cli

And then there's, well, other stuff to include. Webpack needs a lot of other tools to build our code, so let's install those:

npm install -D @babel/core babel-loader css-loader vue-style-loader

And then we need to create a configuration file for webpack at webpack.config.js:

// webpack.config.js
const { dirname } = require("path");
const VueLoaderPlugin = require("vue-loader/lib/plugin");

module.exports = {
  entry: {
    "favorite-cat": "./vue/loaders/favoriteCatLoader.js",
  },
  output: {
    filename: "bundle.js",
    path: __dirname,
  },
  module: {
    rules: [
      {
        test: /\.vue$/,
        loader: "vue-loader",
      },
      // this will apply to both plain `.js` files
      // AND `<script>` blocks in `.vue` files
      {
        test: /\.js$/,
        loader: "babel-loader",
      },
      // this will apply to both plain `.css` files
      // AND `<style>` blocks in `.vue` files
      {
        test: /\.css$/,
        use: ["vue-style-loader", "css-loader"],
      },
    ],
  },
  plugins: [
    // make sure to include the plugin for the magic
    new VueLoaderPlugin(),
  ],
};

Whenever you add a new component—and a new loader—add the loader script to the entry section above.

And then add a section to your package.json to compile these scripts into a bundle.js file:

    "scripts": {
        "build": "webpack --config webpack.config.js --mode development"
    },

Run that script with npm run build and you should see a new bundle.js file in your project. You can include that in your HTML head as <script src="bundle.js" defer></script>.

Use the component

Now you just need to add the following HTML tag to see the component in action:

<div data-vue-component="hello"></div>

Is that it?

Yes, at its basics. But a lot depends on your general set up for your project. For instance, Laravel already has a lot of this builder stuff built into Mix, so that will be set up differently. Other frameworks will help or not help with this as they see fit. If you already have Webpack in your project, you may need to modify the config rather than directly replacing it.

But this is the basic set up if you have a straight HTML, JS, and CSS project you'd like to add it to. This is a great way to progressively enhance your existing JavaScript, especially if you're getting into component based JavaScript development and moving away from something like jQuery and massive JavaScript files.

Since it's not a one size fits all, email me at joe (at) jerickson.net if you run into any issues or have a different configuration and want to know how to get this to work.

Learning Programming is About Learning Concepts

Joe Erickson — Sun, 10 Jan 2021 20:03:53 +0000

One of the main pieces of advice that people give in learning programming is that you should pick a language and learn it. Just pick the language that you think you'll most want to do, get a couple of classes or tutorials on it, and learn programming!

I think that that's pretty bad advice. Someone who knows nothing about programming, picking up a language, and trying to learn that language is an extremely inefficient and slow way of learning how to program. It's like telling someone to choose their favorite saw, saw some things, and they'll eventually learn carpentry. Although they will learn a facet of it, it will be very hard for them to know how it all fits together.

This advice reminds me of The Karate Kid. Mr. Miagi has Daniel-san sand his deck and paint his fence and then, lo and behold, Daniel-san knows karate! It's a nice fantasy for the movies, but it's not very realistic.

Now, it's absolutely true that you need some sort of raw material to get into topics around programming and to practice it. But focusing on the language or that you have to pick the right language, is extremely counterproductive.

In language learning theory, a lot of ink is spilled on what is the most effective way to learn. And there are many studies that talk about how learning facts is very counterproductive for learning, when in fact, what you should be learning are ideas, or what I like to think of as concepts. This doesn't just apply to programming, it applies to many different areas. If you want to learn chess, you sort of have to know the rules of chess, but that doesn't teach you how to play chess. Experts also have to weigh bigger ideas around what those rules mean. They evaluate pawn structures and board control and lines of pressure. Some of this is experience for sure. You won't get better at chess by only reading about it, but you can advance pretty quickly by also learning about the concepts once you have the basic rules down.

Understanding concepts is what is most important and then after that, learning how to apply the tools to achieve those concepts. So if you want to become a programmer, you need to learn the concepts behind programming. I have built systems in about ten different languages over my career and the thing that has let me do that is that the concepts are applicable no matter what language I am working in. The rest is just the details of figuring out how to express those concepts in a new language, which is much easier to look up.

Now, what does it mean to focus on the concepts? What are the actual practical things that you can do?

When you're presented with a new concept, what you should be doing is sitting down and trying to build some sort of mental model of how it works, to think through and build in your head a way of thinking through these specific types of problems.

So for example, if you're just starting out learning programming, you might run into arrays. Sit down and think about a representation that you can reason about. What would an array look like if it was a physical thing? Would it look like pigeon holes that you see at hotels with different room numbers on them, or they may be P.O. boxes at the post office? When teaching this concept, I will show the students one of those seven day pill holders and put 0 through 6 on them to try and build some sort of mental representation of what is essentially an abstract concept that doesn't actually exist. But having a mental model of how it works in your head will allow you to problem solve how to program with arrays.

What about when you get into object orientation? If you're looking at a number of objects that are working together, if you don't have a way of representing this in your mind, you're going to get very quickly lost. Everyone has had the experience of jumping between files and not having any clear idea of what's going on. And you can't remember what object called what method? Next time, try and sit down and think about it this way: if these objects were on this table in front of me, what would it look like? Which objects are inside other objects? Which objects are talking to each other? Are some of these objects in an array?

Learn how to visually lay this out and draw it on a piece of paper. Draw boxes for each object in the system. Draw lines between them that are method calls. Draw little boxes inside of them that represent instance variables and those are objects that are inside objects or variables that are inside objects. Where does everything live? And where is it at?

Why do this? Because the files themselves will never represent how the system works. They are blueprints, not a house, and you need a model of the house to understand what's going on.

Once you have something like that written out, it is much more possible to know what file to go look at for a certain part of the code. Because you're saying that this object is calling this method on this object? You know the type of that object and can now go to that class and look up what that method is.

What about the services on a server that are all working together? You have your web server, you have your database server, how are these working together? Again, draw it out on a piece of paper. In your head, imagine that they are actual computers in a room. How are they laid out? What wires are connecting from one computer to another? You can start to reason about these things, once you have some sort of representation that you can work with in your head. Just knowing the facts about them isn't good enough, it doesn't take you far enough, you need to have something that you can work with that makes sense to you.

Now, I don't know if this works for everybody. This physical representation idea. But it is vital to my understanding of programming. I am a very visual, physical type of learner. I grew up with Legos and Lincoln Logs. I am someone that can see a visual representation of things in my head, as I'm working through them. A lot of that came through experience. But the only way that started was by doing this exercise and trying to build a mental representation of programming concepts. Once I understand the concept, I can start to understand other concepts by putting these together like Legos.

Once I have my Lego house, I can start to put chimneys on it, I can put windows in. This is how I understand these concepts working, by having a visual representation of them in my head. If I run into something that doesn't fit my mental representation of it, that's good. I don't have to throw everything out, it means that I'm modifying what's already there and I see that now as the process of learning. If I have a concept of an array, and then I find out about queues and stacks, and somehow those don't fit with my representation of an array, that means I need to fix my representation.

So the next time you run into some sort of concept that you don't understand in programming, sit down and try and build a representation of it. If you're just copying and pasting facts, you're never going to get to a point where you're programming confidently and where you're building something new based on concepts that you've learned before. Understanding the concepts enough to try new things with them is what being a programmer is all about.

A Common Roadblock Going from Junior to Mid-level

Joe Erickson — Thu, 19 Nov 2020 01:48:24 +0000

Have you ever worked on a coding problem and have to constantly stop to look up syntax? You're almost at the solution to a problem and you know exactly what you need to do, you just don't know exactly how to do it?

It's a super common and frustrating issue and is a really good sign that you're progressing faster in your ability to think about problems than you are in your ability to memorize less used syntax or tools. This, in my mind, is the start of a transition from a junior developer to a mid-level developer. A switch to the mode of "conscious incompetence" and while that doesn't sound like a good thing, it's the first step towards getting really good at programming.

But something that everyone gets tripped up on is, "How do I get through this?" It's not fun to be conscious of your incompetence.

I think there are a couple of things that you can do. The first is to evaluate what you're struggling with the most. I've noticed a few common areas that people get stuck on. Which of these are you constantly looking up?

Syntax of the language you're working in
Command line syntax
Editor shortcuts that you see more advanced programmers using
Slow typing due to not knowing how to touch type
Vocabulary and names for patterns and programming concepts
Vocabulary for server applications and what other systems do
Administrative tasks for your application (adding new libraries or building the project)
Processes that happen behind the scenes (ie. How is the DOM built, how does the browser download files, etc)

I don't know that these are exastive, but I remember running into these myself. Some of these do with programming, but others are much more about the environment around programming. You need to be comfortable enough with your tools that you can use them at the speed of thought. Stopping and looking things up constantly will just slow you down and prevent you from doing your best. It's frustrating, too. I didn't know how to touch type when I started programming, which was fine at first because my brain wasn't moving very fast. But once I was good enough to work faster, I had to learn touch typing to keep up and not get annoyed with myself over struggling over it.

All of these are fixable, but one thing you'll notice is that a lot of them will require practice, either practice doing them like the typing or the shortcuts. The best way to learn those...is to practice! It really is that easy.

As I said earlier, I didn't know how to touch type when I started programming. So I trained myself using a typing tutor (which are all over the web now for free) and spent time each day practicing. It probably took about a month of that to end what had been a long bout of frustration. Since then, I've switched my keyboard layout to Colemak—due to shooting pain in my wrists—and picked that up the same way.

The other items require some sort of memorization. If you look up the same thing more than three times, memorizing it will be worth it in the future. A good way to do that is with spaced repetition. Have to look something up? Write it down on a flash card and then go through the flash cards every day. Eventually, you'll have it down pat and won't have to run to Google every time you want to create a new class or set up a controller. You'll also know what the other developers mean by "Pub-Sub" when it comes up in a meeting.

Even if you feel like you're being held back by your abilities, you can improve at this and move into a higher understanding of programming paired with a better ability to get things done.

Should you use created() or mounted() in Vue?

Joe Erickson — Sun, 12 Apr 2020 22:18:50 +0000

All in all, the Vue lifecycle methods are fairly straight forward. There's even a helpful Vue lifecycle chart that describes when the various methods are called. All of that is super helpful.

Until you want to use them. If I want to load in data from an API, which method should I use? Why does my component crash sometimes when I try to update DOM elements in created()? Which method should I use for what?

First of all, let's remember when the methods are called as the page is loaded and our components are added.

The created() method will be called on your component after the component object is created but before it is put on the page. All of the component's data, props, computed and methods will be available. The only thing that won't be available is the template or any of the component's DOM. There really is no view yet to speak of.

mounted() is called after the component's DOM created in memory and is added to the page. mounted() is basically Vue saying, "I'm finished with this one."

So, which one do I use?

So, with created() there is no view yet. And because there is no view, this is the perfect time to fetch data from an API or manipulate data passed in via props. Fetching data now means that there will be less of a delay from when the component is show to when the data shows up on the screen because the call will start before the component is rendered.¹ When the view is shown, the data you've loaded will be shown as well.

So what is mounted() good for? It's good for loading anything that manipulates the component's DOM. Maybe it's working with a plugin like Google Maps or a slide show library, mounted() is where you will have access to the this.$el variable--representing the component's root element--and can load in those other libraries.

So most of the time, expect to use created() unless you run into a scenario where you need to have access to the DOM first.

This cuts down on user perceived speed, but doesn't actually speed up the API call. Thanks to @papa_john for pointing out that this wasn't clear. ↩

What's the purpose of Vuex?

Joe Erickson — Sat, 14 Dec 2019 17:23:23 +0000

There are a lot of things to worry about when it comes to Vue applications. You've got SPAs and routing and web workers and Jest and Cypress and everything else. It gets overwhelming pretty quickly. The hard part is not learning these technologies, it's knowing what their place is in the application.

So, Vuex. What the heck is it for and why might you want to use it?

To start with, let me tell you what its function is. Vuex is a Vue addon that acts as a central data store to all the parts of your front-end application. A Vue application is composed of a lot of separate but coordinated components that, when put together, create a functioning front-end application. You might have a screen to edit users, a screen to show users, a screen to show a specific user and they all need to work together and communicate with each other to be in a useful way. Vuex can help do that by keeping all that data in one place and allowing all of these separate components to access and change it.

And that's what Vuex can do. So what is Vuex?

Vuex is a front-end datastore

Vuex is a datastore that is used by all the components in an application to share data. When a component creates data, it can put it into Vuex so that other components can use it. If a component displays or uses data from Vuex, it will be updated immediately if that data ever gets updated. In other words, its data is reactive.

Vuex acts as a central place for data to live. This doesn't mean that all data goes there. If there really is data that's only used by a single component, that component can still have data properties all its own. But if the same data needs to be synced across multiple components, that's where Vuex comes in.

Vuex is a single source of truth

You'll see this often in the documentation. What does single source of truth mean?

I mentioned "synced across multiple components" before and that's exactly what you don't want to do. You don't want copies of data in each component that you have to keep in sync between components. Imagine having each component having their own data properties that, when one changes, you had to somehow let all the others know that it changed and then copying that data between all the components. (Please don't ever do that.)

Vuex acts as the single source to go for data. If every component knows to keep and get data in Vuex instead of individually and treat it as the source of data, that greatly simplifies your application.

Vuex is not a database

Nothing in Vuex is meant to be permanent. Vuex is not your database and you should not load your entire database into Vuex! Vuex is simply there to hold data that the user needs right now. Front-ends should be fast and light, so only keep in the Vuex store what the user is currently interested in seeing. If they need new information, clear the current stuff and load in the information from a separate permanent storage. And if something changes and needs to be saved to the permanent store, do that right away. Don't wait because Vuex won't stick around if someone leaves the page or the app crashes.

You might be wondering about offline abilities. Shouldn't you load things into Vuex so the user can work offline?

No. That's what Window.localStorage or IndexedDB API is for. You can tie your Vuex store to these more permanent datastores, but Vuex does not replace them. Vuex is always temporary data that your components are using right now.

So what's the purpose of Vuex? To simplify your Vue application's data handling. It's there to keep all your runtime data in one place and accessible to all the components in your application. If you can learn to use this powerful tool, you're going to make your work a whole lot easier to code and maintain.

The basics of mapState (it's not as hard as it looks)

Joe Erickson — Wed, 20 Nov 2019 15:22:23 +0000

If there is one thing that I see developers looking into Vuex getting hung up on the most, it's these weird map functions that are in Vuex. The syntax is just so damn weird. What the hell are these ... things doing? Why do I need them sometimes and not others?

The Vuex docs seem to assume a lot here, mainly that you're already a JavaScript guru and secondly that you've heard of a spread operator which is an operator so rarely used in JavaScript that you may have never seen it before.¹

To explain all of these concepts, I'm going to pull up a simple example.

Imagine, if you will, that we have a Vue component that shows a user's name in the UI:

<template>
    <h1>{{ honorific }} {{ firstName }} {{ lastName }}</h1>
</template>

<script>
    export default {
        name: 'show-name',
        computed: {
            honorific() {
                return this.$store.state.honorific;
            },
            firstName() {
                return this.$store.state.firstName;
            },
            lastName() {
                return this.$store.state.lastName;
            }
        }
    }
</script>

And a Vuex store with the following state:

state: {
    honorific: 'Mr.',
    firstName: 'Johnny',
    lastName: 'Bravo'
}

When the Vuex store is passed into the Vue component, the component will use the value from the firstName from the Vuex store as a computed property called firstName. So when the UI references firstName, it will get the value from the store. Same, of course, for lastName and honorific.

This is such a common thing to do that Vuex decided that they would make a helper method to make this easier. If all of your values come from the Vuex store for your component, you can replace all the boiler plate above with this:

<script>
    import {mapState} from 'vuex';
    export default {
        name: 'show-name',
        computed: mapState(['honorific', 'firstName', 'lastName'])
    }
</script>

That's a lot less typing! But what is it doing?

What's happening is that mapState() is returning an object that has all of that previous code already filled out. All the functions get set up for us, so all we need to do is pass them straight to computed.

In other words, this:

mapState(['honorific', 'firstName', 'lastName'])

Returns this:

{
    honorific() {
        return this.$store.state.honorific;
    },
    firstName() {
        return this.$store.state.firstName;
    },
    lastName() {
        return this.$store.state.lastName;
    }
}

computed is already expecting an object full of functions, so it takes those and uses them. This is Vuex trying to be helpful! Thanks, Vuex!

But what happens when we have other computed properties? If mapState() is returning an entire object, we aren't able to do this:

<script>
    import {mapState} from 'vuex';
    export default {
        name: 'show-name',
        computed: {
            fullName() {
                return this.firstName + ' ' + this.lastName;
            },
            mapState(['honorific', 'firstName', 'lastName'])
        }
    }
</script>

mapState() is returning an entire object, so the above code is equivalent to:

<script>
    import {mapState} from 'vuex';
    export default {
        name: 'show-name',
        computed: {
            fullName() {
                return this.firstName + ' ' + this.lastName;
            },
            {
                honorific() {
                    return this.$store.state.honorific;
                },
                firstName() {
                    return this.$store.state.firstName;
                },
                lastName() {
                    return this.$store.state.lastName;
                }
            }
        }
    }
</script>

And, yuk, that's not right at all. In fact, it won't even run and you should get a big, ugly error message on the screen. This is because computed is expecting an object with functions, not an object embedded in another object that has functions. That's just bad syntax.

What we want to do it take those functions out of the object and put them in the computed object.

Well, you can. Modern versions of JavaScript have an operator called the spread operator and it's that strange ... you see in some of the documentation. Putting ... before the mapState() method says to take each thing in the object returned and put it right here. Rip it out of that object and put it in this one right here. In our example, it turns this:

<script>
    import {mapState} from 'vuex';
    export default {
        name: 'show-name',
        computed: {
            fullName() {
                return this.firstName + ' ' + this.lastName;
            },
            ...mapState(['honorific', 'firstName', 'lastName'])
        }
    }
</script>

Into this:

<script>
    import {mapState} from 'vuex';
    export default {
        name: 'show-name',
        computed: {
            fullName() {
                return this.firstName + ' ' + this.lastName;
            },
            honorific() {
                return this.$store.state.honorific;
            },
            firstName() {
                return this.$store.state.firstName;
            },
            lastName() {
                return this.$store.state.lastName;
            }
        }
    }
</script>

And now we have a valid object of functions.

TL;DR

To recap:

If you have no other computed properties, use this:

computed: mapState()

Otherwise, use this:

computed: {
    otherProperty() {
        return 'value';
    },
    ...mapState()
}

That's it. It is here to make your life easier, not more confusing. Hopefully now, it can do that for you.

It's also really new. Edge doesn't even really support it yet. This is why it's important to use something like Babel that can help these poor, lowly browsers play better with newer syntax. ↩

How to query your API using Vuex in your Vue application

Joe Erickson — Tue, 12 Nov 2019 13:36:39 +0000

Once you start using Vuex to manage the shared data of your Vue application, it becomes less clear on where or how to call your back-end API. I think everyone starts out making API calls in the created function of your component. But that doesn't scale past a handful of components. Then, they end up loading in the same data over and over again and each component has it's own copy, which is impossible to keep in sync. You lose the efficiency of having one part of the system in control of the data when you do that and on a larger application, this very quickly falls apart.

You could try to share the data pool using a Vuex store with every component calling APIs and shoving the data into Vuex, but then every component is sharing API logic and unit testing becomes pretty impossible to do. Components shouldn't really be messing with outside resources that much and should instead focus on their one area of responsibility. Otherwise, you get maintenance hell.

There seem to be a million ways to do this, but a simple one I'm going to show now is one that I have liked and have seen in other projects, too.

The responsibility of the data for the application rests squarely on Vuex and so I will show how Vuex can handle all back-end data interactions as well. This will keep our data responsibilities all in one place.

I have a bare bones sample project on CodeSandbox here, if you want to check it out: https://codesandbox.io/s/example-api-call-from-vuex-t7zxw

Making the API call

Vuex has two sections where logic can be kept; actions and mutations. I've talked before in Understanding data flow in Vuex about what the difference is between these two sections but we're going to use them together to perform our API call.

First, create a new state field for the user information, which will be coming in as an array of objects, but that we can just set to an empty array to start with:

state: {
  users: []
},

Then we want to set up a simple mutation (all mutations should be simple) that will take a new set of users and set them to the state:

mutations: {
  SAVE_USERS(state, users) {
    state.users = users;
  }
}

We're now ready for the actual API call. I'm going to use Axios and Vue-Axios for this call, which is a library that makes API calls super simple and sane.

First, I'll set the default base URL to the API¹:

Vue.axios.defaults.baseURL = "https://jsonplaceholder.typicode.com/";

Then we can set up an action to actually make the API call. Why an action? Because this is a call that will do some logic and will take time (network calls always take an unknown amount of time). Actions are meant to be asynchronous while mutations should happen as near to instantly as possible.

So we make an action that makes the API call and then calls the mutation with to set the data once it's done.

actions: {
  loadUsers({commit}) {
    Vue.axios.get('users').then(result => {
      commit('SAVE_USERS', result.data);
    }).catch(error => {
      throw new Error(`API ${error}`);
    });
  }
},

This Vuex store not only handles the local data store like it should, it also has all the logic needed to refresh the data store from the back-end.

Using the Vuex store in a component

How should this back-end aware Vuex store be used in a component? Most everything will be the same as usual. We'll create computed properties that will link to the Vuex's state information:

computed: {
  users() {
    return this.$store.state.users;
  }
},

or, using mapState()

computed: mapState(['users']),

The trick is that the action in the Vuex store to load in the users, loadUsers(), will not magically call itself. So a component will do that itself when it is created:

created() {
  this.$store.dispatch('loadUsers');
}

This doesn't do anything to the component except let the Vuex store know that it wants some user data. Once the user data loads into the Vuex store, the computed mapping to that state is triggered and the component will show the new data.

If there were multiple back-end endpoints, as there would be in any application that wasn't super simple, then a component would just trigger a load for data that it needed. There is no need to load in everything from the back-end all at once if it's not needed by any of the components that are on the page.

If you want to see this in action, feel free to look at the CodeSandbox I set up called Example API call from Vuex.

This is one way to handle API calls in a Vue application and one that is shown in the Real World Vue project on Github. I like this approach in that it keeps all the data handling within the sphere of Vuex and let's the components be both focused on their front-end presentation duties and unit testable since they aren't connecting to any system outside of themselves except the easily mockable Vuex store.

This would usually go in an environment variable. Hard coding it here merely as an example. Here, we're using data from a faked API over at JSON Placeholder. ↩

Loading dynamic images in a Vue Component

Joe Erickson — Tue, 05 Nov 2019 14:09:29 +0000

When I first started using Vue, one thing I got continually wrong was how to load an image into a Vue component dynamically. At first, I found that using an absolute URL worked, but that was only useful if I was storing the images on a CDN or other external site. If I included the images in my project, as either lightweight icons or static images, then using an absolute URL, with hostname and all, didn't really work. What about when I wanted to test some new images locally or on a dev server? Linking directly to the images in production just wasn't going to cut it.

When researching this, the Vue CLI documentation for static assets was, frankly, a little less than helpful. They didn't give a good example for what I was trying to do.

What I was building was a little form control to take credit card numbers. It consisted of a single file Vue component and looked something like this:

<template>
    <div class="form-group">
    <label>Credit Card Number</label>
    <input type="text" name="creditCardNumber" v-model="creditCardNumber"
           placeholder="1111111111111111">
    <img class="creditLogo" v-bind:src="creditCardLogoSrc">
  </div>
</template>

<script>
export default {
  name: 'credit-card-field',
  computed: {
    creditCardLogoSrc(vm) {
      if(vm.creditCardNumber.startsWith('4')) {
        // Return the Visa image
      } else if (vm.creditCardNumber.startsWith('5')) {
        // Return the Mastercard image
      } else if (vm.creditCardNumber.startsWith('6')) {
        // Return the Discover image
      } else {
        // Return the generic image
      }
    }
  },
  data() {
    return {
      creditCardNumber: ''
    }
  }
}
</script>

What I wanted to happen was, as the user is typing in their credit card number, I will look at it and swap out the img tag's source to show the credit card type that they were entering. I had a Visa image, a Mastercard image and a Discover image as well as the image of a generic credit card if it didn't match any of those. Since all Visas start with 4, all Mastercards start with 5, and all Discover cards start with 6, this would be a pretty easy check to do.

The logic ended up being the easy part. The hard part was loading the images. I had the images in the Vue CLI provided assets folder, but how do I load them in?

Looking at the documentation, there are a lot of "in templates, do this" and "only in templates!" kinds of things. But I wasn't in a template. I was in the code part of my component.

After much research, I found the answer was to require() the images from the asset folder. Intuitive! 😒

So, when I need to use an image that is in the assets folder, I can require() the relative path to that image in my computed method:

creditCardLogoSrc(vm) {
  if(vm.creditCardNumber.startsWith('4')) {
    return require('../assets/visa.png');
  } else if (vm.creditCardNumber.startsWith('5')) {
    return require('../assets/mastercard.png');
  } else if (vm.creditCardNumber.startsWith('6')) {
    return require('../assets/discover.png');
  } else {
    return require('../assets/credit.png');
  }
}

One nice plus to doing it this way is, if the image is small enough, require() will return a dataurl instead of a URL path, which will save an extra call to the server and make the component a little more self contained.

So if you need to load images from inside a Vue CLI project's assets folder from outside the template of your component, now you know how.

Who was that masked variable?

Joe Erickson — Thu, 31 Oct 2019 18:10:37 +0000

Who is that masked variable?

We were running through some of our curriculum at Tech Elevator and ran across a piece of code that said that you couldn't define the same variable name in two different scopes in JavaScript.

This struck me as a little strange. JavaScript will let you do anything it just might not be what you wanted. Surely, it wouldn't throw an error if you define the same variable again in a child scope? So I wrote this code in my browser's console to test it out:

{
    let i = 3;
    {
        let i = 29;  // <-- This is a new variable and masks the original
        console.log(i);  // <-- Will print 29
    }
    console.log(i); // <-- Back to the original variable, will print 3
}

So the second variable just masks the first one until it falls out of scope. Interesting!

At first I thought that this might be useful, but then I couldn't think of a single useful thing to use this with.

So, my question to you, can you think of a useful way of using this feature in an algorithm in JavaScript?

Four ways to keep backend data synced with your frontend

Joe Erickson — Mon, 19 Aug 2019 14:15:16 +0000

One big question people have when building frontend applications is, what's the best way to keep backend data synced with my frontend data? You seem to always get different answers from different people and the dreaded "It depends". Well, what does it depend on?

Here are the four main ways that developers keep their data in sync and the reasons why you might choose one over the other.

1. Refresh data on every action

You could refresh the data on every action that the user takes. User opens the app? Pull the information from the backend. User views the list of pictures they saved? Repull the information from the backend. User saves a new picture? Save it, then repull the information from the backend. This is very useful when

This is typically a perfectly reasonable way to start out and is the technique that most developers come to when first starting out. If your data is not too heavy, this is probably the main way to go. I'm a fan of avoiding premature optimization and so would recommend this to any dev just starting out.

This is especially true if your application has data that only this user will be editing. If there's no real fear of the data changing on the backend when the application is running, then there's no need to change the data unless this user changes it themselves.

Users would expect this kind of behavior in any application that is essentially single user, like a nutrition tracker or bookmark manager.

2. Add a refresh button

You could refresh the data only when a user clicks on a refresh button on the page. This puts the responsibility for getting new information from the backend on the user, but can cut down on the number of network calls that your application needs to make. This could either be an explicit button or, in the case of mobile apps, a swipe down on the screen to trigger a refresh.

There are many applications that follow this approach. If real time data is not vital to the application, a nice refresh button on the screen can allow a user to update the data when they want it to update.

There are many times when updating data when the user doesn't expect it could lead to confusion on the user's part. YouTube's Trending channel follows this convention on mobile and Twitch will not real-time update the channel list either. If they did, as new information came into the system, the user would be constantly trying to hit a moving target. Better to show them the current recommendations right now and let them tell you when they want a new set of data.

3. Periodic refresh

You could refresh the data every five minutes or half an hour. By setting a timer and refreshing data when the timer is up, you can keep the screen refreshed with the latest information without overwhelming the user or your server. This used to be how many of the browser-based email clients worked (and some probably still do) but I will say that most of them have moved on to using the next method that I'll talk about.

If your application is kept in a tab and left to run often and alerts don't need to be delivered the minute they happen, this can still be a useful technique to follow.

4. Push Notifications

The last technique is called Push Notifications on mobile and implemented with either Web Sockets or Web Push. (It used to be called Comet, but the technique that describes is long past its prime.)

This is when the backend pushed data to the client instead of the client asking for data from the backend. When the frontend starts, it registers with the backend that it wants real time data updates and then, when something comes into the backend that the frontend needs, the backend will push that information to the frontend right away.

Think any chat application, from Facebook Messenger to Google Hangouts. They are using some form of Push Notification, but so is Slack in your browser window. Use this when users want information right away and a delay wouldn't be acceptable.

All together now

While these are all very distinct methods for updating data, they are best used together, depending on the circumstances outlined above. If I'm looking at my Twitter feed on mobile, Twitter will use periodic checks to see if I have any updates (option 3). If I have an update, it will enable a "See X new tweets" refresh button that I can click to pull the new data (option 2). And if I'm on my user profile page, it won't attempt to load in new data at all until I click out of it and back in (option 1). Every app is going to pick a different technique to use depending on what user experience they want the user to have.

So look into these different techniques for your frameworks and think about it this way, What does the user expect to happen? That's the best way to choose how to sync your data.