DEV Community: Marina Mosti

Loading and using a fixture from an API endpoint for Cypress e2e tests

Marina Mosti — Wed, 19 Feb 2020 10:01:05 +0000

I love Cypress, it’s one of those tools that for me has just made e2e testing actually fun and engaging. In this article, we’re going to explore a common scenario that you may encounter when doing e2e testing on your apps: fetching a data fixture from an API endpoint before your tests and using it to write your tests.

What is a Cypress fixture?

In case you haven’t heard of fixtures before, you can think of them as a predefined piece of data that you use in your tests to perform certain actions.

Consider the following fixture example.

    {
      "username": "yoda",
      "password": "secureiam",
      "id": 123
    }

If we have an endpoint in our application that for example holds the user’s settings page, we may need to construct the following URL:

    http://www.holocrons.com/123/settings

In this demo URL, the first segment is the id of the user, so based on our dummy fixture it would be 123.

In Cypress, to navigate to a URL you use the visit command, so you may want to construct your action as follows:

    cy.visit('/123/settings')

The problem here however is that we are hardcoding a user id into our tests. In most cases this will become a problem, because unless our backend and database are set up to work with a specific id, if that user ceases to exist for some reason then all of our e2e tests will break.

The first solution is to create a local fixture, so you would go into your cypress folder structure, and create a user.json file inside the appointed fixtures folder. Inside, we would paste the content of our demo fixture.

    # user.json
    {
      "username": "yoda",
      "password": "secureiam",
      "id": 123
    }

Now, in order to use this fixture inside our test, we could set up a beforeEach hook inside our spec file, and load it as follows.

    describe('my tests', () => {
      beforeEach(function() {
        cy.fixture('path/to/user.json').as('userData').then(() => {
          // Do some things like setting up routes. 
        });
      })
    })

The Cypress fixture method takes a string param that points to where the fixture file is located. This path is based off where your root cypress.json file is located.

Once the file is loaded into the fixture, you can use then block to trigger some extra actions like setting up your cy.server() and some routes.
Notice that in this example we’re setting up an alias with .as('userData'). This is important if you’re going to be using the loaded fixture data later on in your tests, outside of the then block.

Let’s now take our new fixture userData and actually use it to set up some routes. Because we are inside the then block you have two choices, you can receive as the param to the method the newly loaded fixture, or you can use this to access it as a property.

In these examples we’re going to use the this approach, but be warned - in order for this to keep the correct context, we have to use regular function () syntax, not arrow functions on our it calls! If you don’t do this, you will get undefined errors due to how arrow functions this context works.

Let’s create a router alias for our settings page.

    describe('my tests', () => {
      beforeEach(function() {
        cy.fixture('path/to/user.json').as('userData').then(() => {
          // Do some things like setting up routes. 
          cy.server()
          cy.route(`${this.userData.id}/settings`).as('userSettings')
        });
      })
    })

Notice how in this case we are using this.userData.id to explicitly declare that our route needs to point to user id 123, the one that was declared in the fixture. Now we can access any data inside our user.json file through the this.userData property.

Here’s another example inside an it block.

    it('shows the users username in the header', function() {
      cy.visit(`${this.userData.id}/settings`)
      cy.contains('h1', this.userData.username)
    })

Our tests are now hard-code free. But what happens when our tests are driven by some sort of function or endpoint that populates our database with dummy data? We are now going to look at the same problem/solution, but by loading the fixture from an API endpoint.

Loading API based fixtures

In order to get our fixture from an API, we are going to create some Cypress custom commands to make the code easier to use in our tests.

Head over to your commands.js file, and let’s get started.

    Cypress.Commands.add('loadFixture', (savePath) => {
      cy.request({
        method: 'post',
        url: `api/path/to/fixture/endpoint`,
        timeout: 50000
      }).then(res => {
        cy.log('Fixture loaded from API');

        cy.writeFile(savePath, res.body);
        cy.log('Fixture written to disk');
      });
    });

Let’s take a closer look at the code. First we create a new Cypress command and call it loadFixuture, it will receive a single param called savePath. This will be a string, and the path to where our fixture will be saved in the disk.

Inside our command, we first call cy.request to make a network request to our fixture endpoint in the API. This endpoint should give us a JSON response, so make sure to adjust the url paramter to match your app’s needs - you can also of course pass paramters in the body or query string as needed. Check out the documentation for cy.request for more options.

After the request completes, we chain a then callback that gives us the result from our request - this res holds the response from the API.

We make a couple of cy.log statements so that we can track from our Cypress log what is happening, and finally call a cy.writeFile command with the savePath that we passed to our command, and the body from the network response. This will write the JSON to a file.

You may be wondering at this point why we are writing the network result to a file, we need this information to be in a file so that we can later on read it using the cy.fixture command.

With our new command, we can now update our tests to use the new loading.

    describe('my tests', () => {
      before(function() {
        cy.loadFixture('path/to/user.json')
      })

      beforeEach(function() {
        cy.fixture('path/to/user.json').as('userData').then(() => {
          // Do some things like setting up routes. 
        });
      })
    })

Notice that we are now downloading the fixture on the before hook, that way we can guarantee that it is only downloaded once since this type of request can usually be heavy on the server and database.

Now, whenever we call the beforeEach as we did before we will actually be targeting a file that has been downloaded and written before our tests begin, this also guarantees that if necessary you will be working with new generated data.

As always, thanks for reading and share with me your comments on twitter at: @marinamosti
PS. All hail the magical avocado 🥑
PSS. ❤️🔥🐶☠️

Accessible form error auto-focus with Vuelidate in Vue

Marina Mosti — Tue, 10 Dec 2019 19:47:23 +0000

Vuelidate makes it very simple for developers to handle even the most complex cases of form validation, but what about accessibility UX? Let's take a look at some very simple practices that you can implement on your Vuelidate powered forms that will make them behave a lot more nicely for accessibility tools like screen reade

The form

Let's first create a standard form, and apply some validation rules to our data.

    <template>
      <div>
        <form @submit.prevent="submit">
          <div>
            <label for="firstName">First Name</label>
            <input
              type="text"
              id="firstName"
              name="firstName"
            >
          </div>

          <div>
            <label for="lastName">Last Name</label>
            <input
              type="text"
              id="lastName"
              name="lastName"
            >
          </div>

          <div>
            <label for="email">Email</label>
            <input
              type="email"
              id="email"
              name="email"
            >
          </div>

          <button type="submit">Submit</button>
        </form>
      </div>
    </template>

Our form has three inputs - the first two are of type text and the last one of type email. Finally, we have a submit type button to trigger the submit event on our form element.

The form element itself has a @submit handler with a prevent modifier so that we can stop default browser behavior and process the form submit ourselves.

To learn more about event modifiers, you can check the official docs

Let's now add the code that will handle the validation rules and the submit method.

    <script>
    import { required, email } from "vuelidate/lib/validators";
    export default {
      name: "App",
      data() {
        return {
          firstName: "",
          lastName: "",
          email: ""
        };
      },
      validations: {
        firstName: { required },
        lastName: { required },
        email: { required, email }
      },
      methods: {
        submit() {
          // Submit the form here!
        }
      }
    };
    </script>

First, we import a couple of Vuelidate's built in validators: required and email.

We create a local state with data and set up a property for each of our inputs, and proceed to create a validations object. This object in turn defines rules for each one of our inputs.

Finally, we need to head back into the <template> and connect our inputs to Vuelidate through v-model.

    <div>
      <label for="firstName">First Name</label>
      <input
        type="text"
            id="firstName"
        name="firstName"
        v-model="$v.firstName.$model"
      >
    </div>

    <div>
      <label for="lastName">Last Name</label>
      <input
        type="text"
        id="lastName"
        name="lastName"
        v-model="$v.lastName.$model"
      >
    </div>

    <div>
      <label for="email">Email</label>
      <input
        type="email"
        id="email"
        name="email"
        v-model="email"
        @change="$v.email.$touch"
      >
    </div>

Notice that for firstName and lastName we are v-modeling directly into Vuelidate's internal $model for each property, this allows us to not have to worry about triggering the $dirty state of each input on change/input events.

For the email input, however, I have opted to v-model directly to the data() local state and trigger the $touch event manually. That way the validation won't trigger right away until after the input blur's, and the user won't be faced with an immediate error message when the email condition is not met because they're starting to type it out.

Adding error messages

Let's start by adding descriptive error messages when an input's validation fails. We are going to first add a <p> element directly after the input and output the error for the user.

    <div>
      <label for="firstName">First Name</label>
      <input
        type="text"
        id="firstName"
        name="firstName"
        v-model="$v.firstName.$model"
      >
      <p
        v-if="$v.firstName.$error"
      >This field is required</p>
    </div>

    <div>
      <label for="lastName">Last Name</label>
      <input
        type="text"
        id="lastName"
        name="lastName"
        v-model="$v.lastName.$model"
      >
      <p v-if="$v.lastName.$error">This field is required</p>
    </div>

    <div>
      <label for="email">Email</label>
      <input
        type="email"
        id="email"
        name="email"
        v-model="email"
        @change="$v.email.$touch"
      >
      <p v-if="$v.email.$error">{{ email }} doesn't seem to be a valid email</p>
    </div>

Notice that each p tag is getting conditionally rendered by a v-if statement. This statement is checking inside the Vuelidate object $v, then accessing the state for each input (based on how we defined your validations and state in the previous section), and finally we access the $error state of this element.

Vuelidate has different states it tracks for each element, $error is a boolean property that will check for two conditions - it will check that the input's $dirty state is true, and that ANY of the validation rules is failing.

The $dirty state is a boolean with the value of false by default, when an input is changed by the user and a v-model state to the $v.element.$model is set, it will automatically change to true, indicating that the contents have been modified and the validation is now ready to display errors (otherwise the form would be in default error state when loaded).

In the case of our email input, since we binding the v-model to our local state, we have to trigger the $touch method on the change event - this $touch will set the $dirty state to true.

Now that we have a clear error message for our users when the validation fails, let's go ahead and make it accessible. As it is right now, screen readers will not pick up the change and notify the user of the problem whenever the input is re-focused, which would be super confusing.

Thankfully, we have a handy tool to attach this message to our input - the aria-describedby attribute. This attribute allows to attach one or more element through their id that describe the element. So let's modify our form to reflect this.

    <form @submit.prevent="submit">
        <div>
          <label for="firstName">First Name</label>
          <input
            aria-describedby="firstNameError"
            type="text"
            id="firstName"
            name="firstName"
            v-model="$v.firstName.$model"
          >
          <p
            v-if="$v.firstName.$error"
            id="firstNameError"
          >This field is required</p>
        </div>

        <div>
          <label for="lastName">Last Name</label>
          <input
            aria-describedby="lastNameError"
            type="text"
            id="lastName"
            name="lastName"
            v-model="$v.lastName.$model"
          >
          <p v-if="$v.lastName.$error" id="lastNameError">This field is required</p>
        </div>

        <div>
          <label for="email">Email</label>
          <input
            aria-describedby="emailError"
            type="email"
            id="email"
            name="email"
            v-model="email"
            @change="$v.email.$touch"
          >
          <p v-if="$v.email.$error" id="emailError">{{ email }} doesn't seem to be a valid email</p>
        </div>

        <button type="submit">Submit</button>
    </form>

Great! If you now test out the form with a screen reader such as ChromeVox, you can trigger a validation error and focus the element - the screen reader will now read the error as part of the input's information when focused, making it clearer to the user as to what is going on.

Triggering validations on @submit

Let's take the form one step further, right now when you click the submit button nothing will happen. Let's trigger the validation check for all of the element's on our form when the user tries to submit the form.

Modify the submit method like this.

    methods: {
      submit() {
        this.$v.$touch();
        if (this.$v.$invalid) {
          // Something went wrong 
        } else {
          // Submit the form here
        }
      }
    }

Two things are happening here, first we trigger the validations on every input on our form by calling $v.$touch(). Vuelidate will go over every input that has a validator and trigger the validation functions, so that if there are any errors the states will be updated to show it.

Vuelidate also managed a "global" state for the form which includes its own $invalid state, which we will use to verify if the form is in a valid state to be submitted - if it's not, we are going to help our users out by auto-focusing the first element that has an error state.

Auto-focusing the element with an error

As it is right now, when our users click the submit button and trigger the submit() method, Vuelidate will verify all the inputs. If some of these inputs have errors, the v-if conditions for each of these inputs will be met and the error messages will be displayed.

However, screen readers will not auto-read these error messages unless we tell them to. In order to make our users' experience better, let's auto focus the input that has the problem.

First, we are going to have to go back into our form and add a ref attribute to each of our inputs so that we can reference and target it inside our submit() method.

    <form @submit.prevent="submit">
      <div>
        <label for="firstName">First Name</label>
        <input
          aria-describedby="firstNameError"
          type="text"
          id="firstName"
          name="firstName"
          ref="firstName"
          v-model="$v.firstName.$model"
        >
        <p
          v-if="$v.firstName.$error"
          id="firstNameError"
        >This field is required</p>
      </div>

      <div>
        <label for="lastName">Last Name</label>
        <input
          aria-describedby="lastNameError"
          type="text"
          id="lastName"
          name="lastName"
          ref="lastName"
          v-model="$v.lastName.$model"
        >
        <p v-if="$v.lastName.$error" id="lastNameError">This field is required</p>
      </div>

      <div>
        <label for="email">Email</label>
        <input
          aria-describedby="emailError"
          type="email"
          id="email"
          name="email"
          ref="email"
          v-model="email"
          @change="$v.email.$touch"
        >
        <p v-if="$v.email.$error" id="emailError">{{ email }} doesn't seem to be a valid email</p>
      </div>

      <button type="submit">Submit</button>
    </form>

Notice that I have named all the ref attributes the same as their respective models. This will make the looping easier in the next step.

Now that we can target the inputs, let's modify the submit() method so we can loop through the different inputs and figure out which one has the error.

    submit() {
      this.$v.$touch();
      if (this.$v.$invalid) {
        // 1. Loop the keys
        for (let key in Object.keys(this.$v)) {
          // 2. Extract the input
          const input = Object.keys(this.$v)[key];
          // 3. Remove special properties
          if (input.includes("$")) return false;

          // 4. Check for errors
          if (this.$v[input].$error) {
            // 5. Focus the input with the error
            this.$refs[input].focus();

            // 6. Break out of the loop
            break;
          }
        }
      } else {
        // Submit the form here
      }
    }

Lots of code! But fear not, we're going to break this down into easy steps.

First we create a for loop to go through each of the properties in the $v object. The $v object contains several properties, between them you will find each of the inputs that are being validated - and also some special state properties like $error and $invalid for the whole form.
We extract the input/property name into a variable for easy access
We check if the input contains the $ character, if it does we skip this one because its a special data property and we don't care for it right now.
We check the $error state, if the $error state is true, it means this particular input has a problem and one of the validations is failing.
Finally, we use the name of the input as a way to access it through the instance $refs, and trigger the element's focus. This is input → ref name relationship is why earlier we went with the same naming for the ref and the v-model state.
We only want to focus the first element, so we call break to stop the loop from continuing to execute.

Try this out, now when the user triggers the form's submit and there is an error the form will automatically focus the first input with an error.

One more slight issue, the screen reader will still not read our custom error message. We need to tell it that this <p> tag describing the input is going to be a "live" area that will display information and that may change.

In this case, we are going to add aria-live="assertive" to our error messages. This way when they appear and our focus goes to the element, the screen reader will notify the users. It will also notify them if this message changes into something else, like from a required validation error to a minLength error.

    <form @submit.prevent="submit">
      <div>
        <label for="firstName">First Name</label>
        <input
          aria-describedby="firstNameError"
          type="text"
          id="firstName"
          name="firstName"
          ref="firstName"
          v-model="$v.firstName.$model"
        >
        <p
          v-if="$v.firstName.$error"
          aria-live="assertive"
          id="firstNameError"
        >This field is required</p>
      </div>

      <div>
        <label for="lastName">Last Name</label>
        <input
          aria-describedby="lastNameError"
          type="text"
          id="lastName"
          name="lastName"
          ref="lastName"
          v-model="$v.lastName.$model"
        >
        <p v-if="$v.lastName.$error" aria-live="assertive" id="lastNameError">This field is required</p>
      </div>

      <div>
        <label for="email">Email</label>
        <input
          aria-describedby="emailError"
          type="email"
          id="email"
          name="email"
          ref="email"
          v-model="email"
          @change="$v.email.$touch"
        >
        <p
          v-if="$v.email.$error"
          aria-live="assertive"
          id="emailError"
        >{{ email }} doesn't seem to be a valid email</p>
      </div>

      <button type="submit">Submit</button>
    </form>

Wrapping up

Auto focusing elements for the user when attempting to submit an invalid form is a very nice form of accessible UX that doesn't take a lot of effort and work on our side as developers.

With the use of attributes like aria-describedby and aria-live we have already enhanced our form into an accessible state that most form out there in the wild wild web don't implement. This can also be enhanced futher of course, but this is a great starting point!

If you want to see this example in action, I have set up a codesandbox here.

As always, thanks for reading and share with me your accessible form experiences on twitter at: @marinamosti

PS. All hail the magical avocado 🥑

PPS. ❤️🔥🐶☠️

How to target the DOM in Vue

Marina Mosti — Thu, 21 Nov 2019 18:17:23 +0000

This article as originally published at https://www.telerik.com/blogs/how-to-target-the-dom-in-vue

A very common practice in web development is to be target an element in your DOM (Document Object Model) (aka all your HTML elements and the logical structure they represent) and to manipulate it in some way.

In this article we are going to check out the power of ref and some of its edge cases. Get your toast ready, and let's peel this 🥑.

Knights of the Old Vuepublic

For those of us that come from the old ways, aka jQuery, we were very used to targeting a DOM element in our page to modify it or use it in any certain way. In fact this was almost unavoidable in cases where you wanted to use any type of plugin that would make use of an element in your page.

In jQuery, you would select an element by targeting it with the $()function, and that would open up a wide variety of methods for manipulating this object. Take the example of a div, where you would like to set or toggle the visibility by switching around the display css property.

Let's consider the following markup for our example.

<body>
  <div id="datOneDiv" class="myCoolClass" style="display: none;">I is hidden</div>
  <div>I is shown</div>
  <div>I is 🐶</div>
</body>

In jQuery, this would look like the following.

$('#datOneDiv').css('display', 'block');

A couple of interesting things to mention here. First of all, notice that we're targeting a very specific div in our document, the one with the id of datOneDiv as seen by the selector #datOneDiv (the # here work just the same as a CSS selector, it denotes an id).

The second thing to note is that as fantastically easy as this was, it prevents a lot of people from actually learning how to JavaScript, which as time go by became a problem.

Do you even JS, breh? 😎💪

In actual vanilla JavaScript, the same result can be achieved by using querySelector and some property manipulation.

document.querySelector('#datOneDiv').style.display = 'block';

The key thing to notice about this example is that once again, we are making use of an id to target a very specific div inside of our document. Granted, we could have also targeted the div with its class by doing .myCoolClass, but that as you will learn will present the same problem.

The Vue awakens

We are going to do some Sith killing today, don't worry no actual horned cool looking dudes were harmed in the making of this article.

Consider the following Vue component Sith.vue.

    <template>
      <div>
        <p class="sithLord">I is Sith</p>
        <button @click="keelItWithFire">Kill the Sith DED!</button>
      </div>
    </template>

    <script>
    export default {
      methods: {
        keelItWithFire() {
          document.querySelector(".sithLord").style.display = "none";
        }
      }
    };
    </script>

I KNOW, I KNOW. Amaga, I should be using dynamic classes, your example is so bad, the avocado is mad and you are no longer my bff. It's alright, I didn't like you anyway. However, for purposes of example let's pretend that we didn't know about all that Vue goodness and that we actually were trying to target the DOM this way to make some changes to it. (Jokes aside, if there is a way you can apply classes or styles dynamically, you should ALWAYS opt for doing it with dynamic properties! We are just doing this as an easy to follow example.)

If we instantiate this component in our App.vue or our main app entry point, and we click the button you will notice that it actually works. So why exactly have we been told time after time that it is SO BAD to target the DOM directly in Vue like we are doing here?

Try modifying your main template (or wherever you're testing these components) to actually hold two or more Sith lords, like so.

    <template>
      <div id="app">
        <Sith/>
        <hr>
        <Sith/>
        <hr>
      </div>
    </template>

Now go ahead and click on the second one to kill it ded. HUH. The force is weak with this one. Do you know what happened?

When the component method keelItWithFire triggers on the second component, the querySelector method is going through the DOM and trying to find the first instance of an element with the class sithLord, and sure enough it finds it!

The big issue with targeting the DOM directly in Vue is first of all that components are meant to be reusable and dynamic, so we can not guarantee that the class here is going to be unique.

Well, we can use an id you see! And you are partially correct, assigning an id attribute to a template in Vue will sort of guarantee its uniqueness, proven that you don't instantiate more than a single one of those components in your whole application (else you're basically going to run into the same problem as above).

The second caveat is that you will also have to guarantee that no other thing in your app, no other developer, and no other library is going to create an element that can potentially hold the same id.

The way of the Vuedi

Vue or do not, there is no try.

In Vue we have plenty of tools to modify the template dynamically through computed properties, local state, dynamic bindings and more. But there will come a time where you will be faced with the need to actually target the DOM. A couple of common reasons are to implement an external party plugin that is not vue specific, or to target a field in a form and focus it, for example.

When such a case arises, we have a pretty cool attribute we can slap to elements called ref, you can check out the official documentation for it here https://vuejs.org/v2/api/#ref.

We are going to make a new component, this time a Jedi.vue and this time we are going to do things as we are meant to in Vue.

    <template>
      <div>
        <p ref="jedi">I is Jedi</p>
        <button @click="keelItWithFire">Kill the Jedi DED!</button>
      </div>
    </template>

    <script>
    export default {
      methods: {
        keelItWithFire() {
          this.$refs.jedi.style.display = "none";
        }
      }
    };
    </script>

What, you thought because they were Jedi we weren't going to 🔥? Ain't no one mess with tiny hippo, ain't NO ONE 😠.

Now, the important thing here is to understand what is going on when we add a ref attribute to one of the elements on our <template>. In simple terms, each component instance will now hold a private reference pointing to their own <p> tag, which we can target as seen on the keelItWithFirefunction via the $refs property of the instance.

Other than the problems that arise with class and id targeting, it is of utmost importance to know that the biggest issue of all is that modifying DOM directly can lead to those changes being overwritten by Vue when there is a re-render cycle of the DOM either on that component or its parent.

Since when we target the DOM directly Vue doesn't know about it, it won't update the virtual "copy" that it has stored - and when it has to rebuild, all those changes will be completely lost.

If you don't want a certain piece of your DOM to constantly become re-rendered by Vue, you can apply the v-once attribute to it, that way it will not try to re-render that specific part.

So far this example doesn't seem super exciting but before we jump to a real case scenario, I want to touch up on some caveats.

Caveat 1

If you use ref on top of a Vue component, such as <Jedi ref="jedi">, then what you get out of this.$refs.jedi will be the component instance, not the element as we are here with the <p> tag. This means that you have access to all the cool Vue properties and methods, but also that you will have to access to the root element of that component through $el if you need to make direct DOM changes.

Caveat 2

The $refs are registered after the renderfunction of a component is executed. What this means is that you will NOT be able to use $refson hooks that happen before render is called, for example on created(), you will however have it available on mounted().

There is a way to wait for created() to have the elements available, and it is by leveraging the this.$nextTick function.

What this.$nextTick will do is that it will hold out on executing the function you pass to it until the next DOM update by Vue.

Consider the following example.

    <template>
      <div>
        <p ref="myRef">No</p>
      </div>
    </template>

    <script>
    export default {
      created() {
        if (!this.$refs.myRef) {
          console.log("This doesn't exist yet!");
        }

        this.$nextTick(() => {
          if (this.$refs.myRef) {
            console.log("Now it does!");
          }
        });
      },
      mounted() {
        this.$refs.myRef.innerHTML = "🥑";
        console.log("Now its mounted");
      }
    };
    </script>

We have a <p> tag with a ref of myRef, nothing fancy there. On the created() hook though theres a couple of things going on.

First, we make a check to see if this.$refs.myRef is available to us, and as expect it will not be because the DOM has not yet being rendered at this point - so the console.log will be executed.

After, we are setting an anonymous function to be called on $nextTick, which will be executed after the DOM has had its next update cycle. Whenever this happens, we will log to the console "Now it does!".

On the mounted() hook, we actually use this ref to change the inner text of the <p> tag to something more worthwhile of our savior the magical avocado, and then we console log some more.

Keep in mind that you will actually get the console logs in this order:

This doesn't exist yet!
Now its mounted
Now it does!

mounted() actually will fire before nextTick because nextTickhappens at the end of the render cycle.

The dark side

Well, now that you have all the awesome theory, what we can we actually do with this knowledge? Let's take a look at a common example, bringing in a third party library - flatpickr, into one of our components. You can read more about flatpickrhere, https://flatpickr.js.org/.

Consider the following component.

    <template>
      <input
        ref="datepicker"
      />
    </template>

    <script>
    import flatpickr from 'flatpickr';
    import 'flatpickr/dist/themes/airbnb.css';

    export default {
      mounted () {
        const self = this;
        flatpickr(this.$refs.datepicker, {
          mode: 'single',
          dateFormat: 'YYYY-MM-DD HH:mm'
        });
      }
    };
    </script>

First, we import the library and some required styles, but then the package requires that we target a specific element in our DOM to attach itself to, we are using ref here to point the library towards the correct element with this.$refs.datepicker.

This technique will work even for jQuery plugins.

But beware of the dark side. Angerlar, jFear, Reactgression; the dark side of the Force are they. (Disclaimer, this is a joke. I don't actually dislike the other frameworks. Except maybe jQuery, jQuery is evil.)

Wrapping up

Hope you had some fun learning about ref today, it's a misunderstood and underused tool that will get you out of trouble when used in the right moment!

The sandbox with the code examples used in this article can be found on the following link: https://codesandbox.io/s/target-dom-in-vue-r9imj

As always, thanks for reading and share with me your ref experiences on twitter at: @marinamosti

PS. All hail the magical avocado 🥑

PSS. ❤️🔥🐶☠️

Demystifying the v-model Directive in Vue

Marina Mosti — Sat, 26 Oct 2019 16:16:33 +0000

This post was originally published at https://www.telerik.com/blogs/demystifying-the-v-model-directive-in-vue

More often than not I get comments and messages asking me to go into detail about v-model by people that have read an article or attended a workshop and the magic of v-model is touched on but not thoroughly explained.

Today, we will go into detail on what exactly this directive does for us in Vue, and a top-level glance at how it works behind the scenes.

This article is intended for novice and intermediate users who want to further their understanding of the directive, and I am assuming a general basic knowledge of Vue as a whole.

Two-way binding and the basics

Often times we find ourselves describing the v-model directive as a magical entity that allows creating a two way biding to an input element. But what exactly does the two way binding mean? And why should you care?

Vue and other frameworks like it have a bunch of magical methods and ways of doing things, v-model is a great example of this type of thing.

The entry-level knowledge required to use it is minimal because frankly, you don't really NEED to understand how it works in order to use it - but when you fully grasp the concept behind it the way you use it or think about it changes.

Listen to user input

Let's start with a simple input element. It will be of type email.

<input type="email" />

The problem is simple, we need to be able to know what the user types in here. We need to maybe send it to the back end for them to log the user in, or to capture it for a registration form.

How would you approach this using jQuery or vanilla JS?

In jQuery maybe you would add an id attribute to the element, and target it directly to extract the value.

<input type="email" id="email" />

$('#email').val();

The problem with this approach is that you are stuck having to then add an event listener if you want to react to keystrokes because so far you are getting a static value at the moment the code is executed. It is NOT reactive.

Let's try this again with an event listener and vanilla JS.

const el = document.querySelector('#email');
el.addEventListener('input', function(event) {
    // when the user types this will fire
    const inputValue = event.target.value;
    doSomethingWith(inputValue);
});

Alright, we're getting somewhere! So far we are able to call the function doSomethingWith with the event's value (what the user typed). This seems like a lot of code though, and what happens if we have a form with 30 different inputs?

Let's do it the Vue way. We are going to add an event listener to the input and call our fake doSomethingWith function every time it fires.

<input type="email" @input="doSomethingWith" />

I don't know about you, but this seems like magical avocado mischief to me. How does Vue accomplish the same thing behind the scenes?

First of all, notice that we don't need an id anymore. In fact, I would argue that using id in Vue is a terrible idea!

If you use ids in Vue, and you use the component in several places then you are going to have several instances of an element with the same id - which spells out CHAOS.

Your developer avocado has gone bad, frand. GG. 🥑☠️

Let's go back to our example though when we add @input to our element, Vue is smart enough to attach the necessary event listener to this particular element via reference. It will also handle removing this event listener for us!

Finally, it will call the function that we passed inside the " " whenever the event is fired, and it will pass it the event object. Neat!

Changing the input programmatically

Let's move on to problem #2.

You managed to listen to the events of the user making inputs on your field, good work! (Hopefully using Vue and not jQuery, come on. I am disappoint. ☹️)

Now, part two of "two-way binding". What if we want to dynamically do something with the user's email and have the input reflect the change?

Maybe we have some sort of form autocomplete, or validation, or we have another input element that will prepopulate their name from the database. There's a lot of possible scenarios.

Let's approach this problem with jQuery first. 🤢

// This is the value we are storing somewhere
// So that later we can send it to the backend
const userEmail = 'somevalue@theuserentered.com';

$('#email').on('input', function() {
    userEmail = $('#email').val();
});

// Now what if we want to change the email on the input programmatically?
function changeEmail(newEmail) {
    $('#email').val(newEmail);
    userEmail = newEmail;
}

changeEmail('your-email@is-wrong.com');

You can see from this last example how quickly this can start to get really messy. Monolithic files of jQuery for event handling and input validation are a thing of the past!

You can also appreciate how it's going to be a problem keeping a state. We have a high-level variable userEmail that is keeping the value, and we have to be careful that we are orderly about our code. Now do this 40 times for a big form, please.

One thing that you may have also not considered at this point is that we are trying to be really careful about setting the .val of our input when we change it on the changeEmail function. But what if another dev, or even ourselves make another function that modifies the userEmail variable somewhere else?

We have to keep in mind that every time this variable changes the input has to be updated, or we have to get into some rather advanced javascript that will set up getters and setters for us to fix that reactivity problem.

Let's approach this second problem in Vue. We are going to create first a local state in our make-believe component.

data() {
    return {
        email: ''
    }
}

Now that we have our local state, we have to tell the input to use it and bind it to the value.

<input 
  type="email" 
  :value="email" 
  @input="doSomethingWith"  
/>

methods: {
    doSomethingWith(event) {
        this.email = event.target.value;
        // Do other stuff, eat avocados, play zelda and admire a raccoon
    }
}

That's it! Every time the email state changes, the input will be updated accordingly. We now have two ways of binding to the input.

First, when our local state changes. Second, when the user types on the field, the input listener will update the state with the value. When the state updates, it will update the input.

Do you see the cycle? DO YA?

Enter v-model

The kind folks at the Vue realized that this pattern of adding two one-way bindings, one that feeds into the input, and one that feeds out of the input was very common when dealing with forms and user data.

Thus, the magical avocado and the v-model directive were born. Both were cared for and nurtured, and the magical avocado went bad throughout the night and we had to toss it out. But such is life.

What happens then when you have to two-way bind your inputs, do you have to go through this double process where you bind the :input to some sort of state, and then listen to an event and re-write all the state?

The answer is no! v-model your friendly neighborhood avocado to the rescue.

We currently have this for our form input.

<input 
  type="email" 
  :value="email" 
  @input="doSomethingWith"  
/>

data() {
    return {
        email: ''
    }
},
methods: {
    doSomethingWith(event) {
        this.email = event.target.value;
        // Do other stuff, eat avocados, play zelda and admire a raccoon
    }
}

And with the power invested in me by Vue, and the blessing of captain planet (yes, I'm old), we can make it all nice and simple.

<input type="email" v-model="email" />

data() {
    return {
        email: ''
    }
}

That's it! v-model will make sure that the correct event is being listened to (in the case of native elements like inputs, selects, etc.) and then bind our local email data property to it! Ah-two, ah-way, ah-binding. 👌

Conclusion

Keep in mind, v-model has some caveats regarding which property it has to bind to and which event it has to listen to.

Vue is super smart regarding this behind the scenes when being used on inputs, selects, checkboxes and radio buttons - but when you are working with custom components you are going to have to do this heavy lifting yourself.

This, however, is out of the scope of this beginner article. But you can check out this reference on v-model on custom components on the official documentation, or the last part of my Vue for Beginners Series where I touch up on a little about v-model.

As always, thanks for reading and share with me your experiences with v-model on twitter at: @marinamosti

PS. All hail the magical avocado 🥑

PSS. ❤️🔥🐶☠️

In Vue, when do I actually need the :key attribute and why?

Marina Mosti — Mon, 14 Oct 2019 07:13:08 +0000

This article was originally published at https://www.telerik.com/blogs/in-vue-when-do-i-actually-need-the-key-attribute-and-why

The problem

So you find yourself writing a Vue app. Maybe you are using the amazing Vue CLI 3, and got yourself a nice set up that gives you some eslint errors and hints.

All of a sudden you are minding your own business, eating your avocado toast and morning latte and the squiggly lines catch your attention. That last v-for loop seems to be wrong?

Maybe you decide to ignore it and to carry on with your avocado induced nirvana but then it strikes you one more time. Console errors 🚧. You panic a little, Vue is demanding it. :key has not been set.

You give in to your instincts and add a :key based on the array's loop, you know it has to be unique. Sweet relief, the errors are gone and you can move on seeking the betterment of humanity through javascript.

Except, what exactly does this all even mean? And why should you care?

Understanding the basics of `:key` 🔑

As suggested by the official docs the key special attribute is used by Vue as a hint for it to understand what exactly it is you're trying to accomplish.

But what exactly does it mean to say that it is only a hint? Vue is smart. If you don't add the :key attribute to your v-for loop the app will not come crashing down on itself in fiery wrath. It is not actually even required that you add it.

When :key is missing, Vue will use internal functions or algorithms to try to figure out the best way to avoid moving DOM elements around. Less movement means less re-rendering and better performance.

This process, however, has the faults of being generic and automated, and even though it is GOOD at its job - you, the programmer 💻, will probably know better on how the performance and DOM manipulation should happen. This implies that you understand the attribute in order to actually get the desired outcome.

So why do we get eslint warnings and console warnings? ⚠️

There are particular cases where the use of key is vital, either to provide data consistency and not lose values (for example in forms) or to attain object constancy in animations. More on these later.

My personal suggestion, in this case, is that you continue to use it in every case, but, with a better understanding of what it will accomplish and why you need to add it.

Let's talk specifics.

Preserving state

When working with HTML elements that have a state in our v-for loops we have to be careful that that state does not get destroyed when the DOM is re-rendered.

Elements like <input>, <select> and <textarea> all hold an internal state that captures the value of that element. When Vue's virtual DOM is modified because our reactive data changed, we can have cases where the DOM that holds our looped elements can be completely or partially destroyed if the key is not properly set.

<!-- Wrong -->
<input v-for="input in myForm" />

<!-- Right -->
<input v-for="input in myForm" :key="unique-condition" />

This problem will lead to a situation VERY hard to debug if you don't know exactly what you are looking for, because it may simply "look" like there's a problem with how the data you are gathering from the form is being magically deleted.

This same case applies to looping through elements that make use of the v-html directive. The key property will assist Vue in making a better job of recognizing each element on the list, and not destroying elements potentially that could hold elements with a state within them.

<!-- Wrong -->
<span v-html="<input />" v-for="item in items" />

<!-- Right -->
<span v-html="<input />" v-for="item in items" :key="unique-condition" />

This of course also applies to looping custom made components that hold state, the same rule of thumb applies. If the key is not defined, you are at risk of data and state being destroyed due to a re-render of the DOM.

Finally, keep an eye out for v-for loops that cycle on an element that contains a stateful element WITHIN it. The same problem can obviously occur.

<!-- Wrong -->
<div v-for="item in items">
    <input>
</div>

<!-- Right -->
<div v-for="item in items" :key="unique-condition">
    <input>
</div>

Object Constancy

Animations are not just a pretty way to move data around 🎬, they convey important information to our users of what is happening to the information they are looking at. When an object moves around the screen, slides, or fades, we expect that object to be consistent and easy to track as it conveys the information it’s trying to show us.

Wait, what?

Imagine a mobile menu sliding in from the left 📲 after you’ve touched on a hamburger 🍔 icon (🤔 We have hamburger and kebab menus, let's make 🥑 menu happen team!).

It transitions smoothly into halfway through the screen and clearly displays the options that you, the user, has for navigating the webpage. However, when you touch on one of the menu items, the menu magically snaps to the right side of the screen and disappears to the right hand of the phone.

Confused, you tap the hamburger icon and the menu reappears from the left side of the screen once again. 🤷‍

This is a great example of a lack of object constancy. We expect the virtual object of the menu to be “hidden” on the same side of our phone, and that it “slides in” to the viewport when we press the button. When this animation is not consistent or clear, it creates a bad user experience and also causes problems tracking the information.

This is a VERY simple example, but what happens when we take it a step further and have a list of items that are trying to convey for example some charted data, or a todo list. When one of those items slides to the left or fades out, we expect THAT item to disappear. If for some unknown reason to the user, the object magically disappeared, and then another one slid to the left it would create confusion and the animation - rather than serving a strong visual cue, it would create discomfort and confusion.

A real-world example

Talk is cheap. Show me the code. - Linus Torvalds

I’ve created a simplified example of the last user interaction that I described so that you can see it in action.

https://codesandbox.io/s/jjlwv87w1v

Open up the Sandbox, and look at the App.vue file.

We have two lists of items been fed by the same pool of data, a property called list.

On the top list, we create a v-for loop that is using the unique id property of each item as a way to track the uniqueness of each of the list items - as usually suggested by the compiler, and to increase DOM performance.

On the bottom list, we are using a common “hack“, to use the array’s index as a way to loop our items and satisfy the :key warning.

I’m not going to touch deeply on the DOM implications of using the index as a key, for it can sometimes be the correct answer if you know exactly what you are doing regarding index management. But instead, let’s focus on the implications it has for UX.

Both lists are wrapped inside a <group-transition> component that will allow us to visually identify what is happening. Go ahead and play around with the top list, click around a few objects, and then hit the reset button. Smooth, right? The object you click is the one that is sliding away. Mission accomplished.

Go ahead and click around the second list now. I don’t know about you, but to me, this seems bugged.

Chris Fritz has an amazing example of how fluid animations can give you an intuitive user experience. Be sure to check it out in this fiddle. Also, try playing around with the :key, if you break the system then the numbers will simply stop animating.

Keep in mind for this last example that <group-transition> actually throws a warning if you remove key, and also the rendering will completely break.

Try adding an index to the v-for loop and setting it as the value for the :key, as some people do to "satisfy" the condition and remove the warning.

Breaking things apart

What exactly is happening here that breaks our object constancy in the second example? 🔎

When we click on one of the items to trigger the removeFromList method, Vue does a couple of things on the background. First of all, the method updates the array that holds our list by calling the splice method on the item's index.

Once the list 📝 has been updated however, Vue has to re-render the DOM in order to react to the changes in the state, this is the core of Vue's reactivity.

Usually, Vue would know that for a v-for loop, it needs to figure out which element it needs to update via the key, this is what you already know. However, because of the <transition-group> Vue keeps a partial state copy to perform the animations while the elements get removed from the screen, even though this element doesn't exist any longer on the actual component's state.
When we use :key with the object's id on the first example, Vue has an exact reference to what we are trying to accomplish, because this particular item has a unique way to identify itself. So when Vue needs to remove it, both from the state, and from the animation it can tell exactly which one it needs to work with.

When we use :key with the index however, we run into a problem. Remember the step by step we just went through? Let's try that again but let's take a closer look at what the index is doing.

We click on an item - let's use id 2 as an example.
The removeFromList method finds that the index of this item is actually 1 and promptly removes this item from the array.
Vue knows it has to do some DOM re-rendering because the list got updated, and tries its best to figure out which items it has to redraw on the screen. So it starts with index 1 (cycling the array), looks like that didn't change. It goes on to index 1 and notices the content is different (what was in index 2 now is in index 1, because splice moved it all one space down). Then goes on to index 2 and the same problem occurs, and so on. Vue effectively re-render the who list.
On the other hand, <transition-group> is trying its best to catch up with the DOM changing and the state getting modified, and in its best attempt it "copies" the deleted item into the end of the list and animates it leaving the screen. It has no way to know how to re-order its internal state to accommodate for the index changes in the state.

Wrapping up

The key attribute has a lot more under the hood than it appears. Now that you understand exactly what it is trying to accomplish, and the reasons behind the "magic", you can make better calls when developing your loops - and obtain more granular control over your application and how it performs. 💪

As always, thanks for reading and share with me your thoughts on Twitter at @marinamosti

PS. All hail the magical avocado 🥑

PSS. ❤️🔥🐶☠️

So what actually is Vue.set?

Marina Mosti — Wed, 09 Oct 2019 04:58:45 +0000

This article was originally published at https://www.telerik.com/blogs/so-what-actually-is-vue-set

Talking about Vue.set is talking about reactivity, so prepare yourself for some theory on this one. However, as always, it doesn't need to be something hard or boring. Find your avocados and chips, make some guacamole, and let's dip right in.

Data and Reactivity

Whenever you create a data() property function inside a Vue component, and return the object back, Vue does a lot of things behind the scenes to hook everything up inside your component and to make it reactive.

export default {
  data() {
   return {
     red: 'hot',
     chili: 'peppers'
   }
  }
}

The first thing that Vue will do here with our awesome awesome awesome RHCP data, is walk through each of the properties of the return { } object, and create a unique getter and setter for each one. The nitty gritty of how this actually happens is beyond the scope of this article, but Vue Mastery has a very nice video explaining this in detail.

The purpose of creating these is so that when you access these properties inside your code, by doing this.red for example, or when setting them with this.red = "hotter" you are actually calling these getters and setters that Vue created for you.

Inside this magical land of SETGET, Vue hooks up your computer properties, watchers, props, data, etc. to become reactive, in super simple terms, a function is called that updates the whole shebang every time the setter is changed.

The pitfall

Awesome! This is what we love about Vue right, its amazing reactivity and under-the-hood power. But there is a dark side here that needs to explored.

Let's change our data a little bit and see what happens when we start trying to work with dynamic data.

data() {
  return {
    members: {}
  }
}

Alright, nothing fancy so far, we have a members property of our data into which we want to add band member information. Now for the sake of example, let's add a method that will pretend to pull some information from a remote http call, that will give us back a JSON object with the band info.

data() {
  return {
    members: {}
  }
},
methods: {
  getMembers() {
   const newMember = {
     name: 'Flea',
     instrument: 'Bass',
     baeLevel: 'A++'
   }; // Some magical method that gives us data got us this sweet info

   // ...
  }
}

Hm. Ok, so looking at this example let's stop and think. There are many ways to resolve this current dilema, how do we add this newMember object into our current members property?

Maybe you're thinking let's turn members into an array and push it, sure, but that's cheating because it breaks my CAREFULLY constructed example that I didn't just make up as I was typing this.

In this scenario, we NEED to have members as an object. Ok, simple - you'd say, let's just add a new property to the members property, it's an object after all. In fact, let's go ahead and make the member's name the name of the property.

getMembers() {
   const newMember = {
     name: 'Flea',
     instrument: 'Bass',
     baeLevel: 'A++' // Totally important property that we will never use
   }; // Some magical method that gives us data got us this sweet info

   this.members[newMember.name] = newMember;
  }

Lok'tar Ogar!

Except, no, because A. this is not Orgrimmar and B. we now have a problem.

If you were to run this code on your browser and test it right now, you will see that you are actually pushing this new data into the members data, but this change to the component state will not actually make any of your application re-render.

In a scenario where you are just using this data for some computation, or for some type of internal storage then doing things this way won't impact your application - however, and this is a huge HOWEVER, if you are using this data reactively on your app to display some information on your page, or for conditional rendering with v-if or v-else then things are going to get funky.

Actually using Vue.set

So now that we understand where the problem is actually coming from, we can learn what is the proper solution. Allow me to introduce you to Vue.set.

Vue.set is a tool that allows us to add a new property to an already reactive object, and makes sure that this new property is ALSO reactive. This completely takes care of the problem that we were experiencing on the other example, because when our new property on members gets set, it will automatically be hooked into Vue's reactivity system, with all the cool getters/setters and Vue-magic behind the scenes.

A small note is however required to understand how this affects arrays. So far we have only really played around with objects, which are super easy to understand. New prop? Add it with Vue.set if you want it to be reactive. Simple.

Following up with our example, let's switch things up to use Vue.set instead.

getMembers() {
   const newMember = {
     name: 'Flea',
     instrument: 'Bass',
     baeLevel: 'A++'
   }; // Some magical method that gives us data got us this sweet info

   //this.members[newMember.name] = newMember;
     this.$set(this.members, newMember.name, newMember);
  }

This bit is new this.$set(this.members, newMember.name, newMember);

There's two things I want to mention for this piece of code. I've been telling you so far that Vue.set is how we are going to be doing things, but now im using this.$set, but fear not - this is only an alias, so it will do and behave in the exact same way. The cool thing, is that you don't have to import Vue inside your components to use it.

The second thing I want to make note of is the syntax of this function. It takes three paramters, the object or array which we are going to modify (in this case this.members).

A second paramter which points to the property or key of the first object/array that we passed (so newMember.name because we want it to be dynamic).

And finally a third paramter which is the value we want to set into it. (In our case, newMember).

         this.members [newMember.name] = newMember;
//            V               V              V
this.$set(this.members, newMember.name,   newMember);

(PS. My ASCII skills are not for sale ^)

But what's up with array reactivity?

When we create an array inside the initial state, Vue sets it up to be reactive for us, however Vue is unable to currently detect when you directly assign a value using an index. For example, if we were doing this:

this.membersArray[3] = myNewValue;

Then Vue won't be able to detect this change, and thus it would not be reactive. Please keep in mind that if you modify arrays with operations like pop, splice, push then those operations WILL trigger reactivity on the arrays, so you can safely use those.

In the off case that you need to set an index value directly, we have Vue.set to help us out. Let's see how that would look on our previous example.

this.$set(this.membersArray, 3, myNewValue)

If you want to read more about all the reactivity caveats check out this link to the official documentation

Vue 3.0

This is all still subject to change at the time of this writing, but the word on the street is that these caveats will no longer be an issue. In other words, in Vue 3.0 you will be safe to forget about these edge cases completely, with the exception of those poor souls that still have to target some old browsers that will not fully support the new reactivity system.

A first look at the Vue CLI

Marina Mosti — Mon, 23 Sep 2019 15:24:41 +0000

This article was originally published at https://www.telerik.com/blogs/a-first-look-at-the-vue-cli

Hello again! 😃

I've recently completed a beginners tutorial series for Vue.JS (shameless self promotion, sorry 😅), in which we went over all the basics of how Vue works.

However, we only looked at Vue from the perspective of adding a <script> tag to a static HTML file and setting it up directly on the page's JS.

It's time to graduate to the big girl tools, and to look at one of the most pleasurable aspects of working with Vue - the CLI (Command Line Interface).

Fear not, it's super easy!

Sadly, for this tutorial i'm going to have to assume that you have a little knowledge of how to navigate inside the terminal with basic cd commands, because this is way out of scope of what Vue CLI is or does. The cd command is super basic though, and you can easily google for a video or quick tutorial if you need a refresher

Getting set up

There's a couple of things that we need to get set up in your computer before we begin. Feel free to skip over some of these if you already have them, but be super careful that you're not skipping over something vital.

NodeJS

In order to get the CLI working on our system, we're going to need to install Node first, particularly at the time in writing this we need to have at least version 8.9 but 8.11+ is recommended.

If you've installed Node before, but are unsure of which version you're using, open up your terminal and run the following command node -v. You should get an output like v11.9.0, if you get an error then you probably don't have Node installed on your machine.

Head over to the official page for node https://nodejs.org/en/ and on the very homepage you'll see two green buttons for downloading. Go ahead and click on the version that says LTS (Long term support) unless you know what you're doing and wanting the latest version.

You will get a download for your current operating system, double click it and go through the installation wizard. Once you're done, fire up the terminal once again and try running node -v once more to check that everything is working.

One more thing, when installing Node you also get NPM (Node package manager) installed on your computer for free! We're going to be using this later, so just keep that in mind in case you wonder where this came from.

Yarn (Optional)

Some people prefer to use yarn over npm as their choice of package manager, personally I don't have a preference and will use both depending on the project and the team's requirements - but if you want to take it for a go just head over to https://yarnpkg.com/en/ and click on the Install Yarn button.

Once again, download the file and follow the install wizard. Once it's done, you can check that yarn was correctly added to your machine by running yarn -v on your terminal.

Installing the CLI

Sweet! Now that we have all that we need, we can actually go ahead and install the Vue CLI on our computer.

Open up your terminal, and run the following command. (Note, that i'm going to be showing both NPM and YARN commands, you don't have to run both - pick the one that you want to use and that you have installed from the previous section).

npm install -g @vue/cli

yarn global add @vue/cli

When you run this command in your terminal, it's going to execute a handful of scripts and you're going to get some very cryptic output. Don't worry about this, go get yourself some coffee and wait until it's done installing everything.

Note the -g and global flags on both of these commands, what this means is that you're installing this package globally on your computer. In short, this means that you will be able to use the commands from anywhere inside your filesystem, without having to navigate to a specific folder.

Once more, let's check that everything was installed properly by running vue --version on the terminal, you should get output back with the version number of the CLI.

Creating our first project

It's time to get our hands dirty and actually use this thing. Fire up your terminal if you haven't already and navigate to the folder in which you want to create your project.

The command you want to run now is vue create <name>, where <name> is the name of your project - and also the folder that will be created.

Let's create our first project then by running:

vue create avocados

Fitting, right?

You're going to get hit with a bunch of questions that will help you configure your project, but don't panic, they're all very self explanatory.

The first screen will allow you to either select a default configuration (which is ok for beginner use), or to hand pick your options through the manual configuration option.

Don't worry if you didn't select an option such as say, Vuex, on your project set up - there's always a chance to reinstall all of these at any point in time later on on top of your project.

If you picked a manual setup, you're going to go through a wizard of options that will configure the options for your project. You can navigate this with your arrow keys, select and unselect options with the spacebar, and skip to the next screen with the enter key.

In here you can make choices like adding TypeScript support, Router base configuration or even Vuex for global state management.

Once you're done the CLI will do its thing, and after a few seconds your shiny new project will be ready. Go ahead and cd into it - and let's check out the folder structure together.

The Folder Structure

Alright! I'm going to open this new project inside VS Code, and i'm using the Material Icon Theme to make the icons pretty, in case you were wondering.

Quick run down!

node_modules: Holds your dependencies code, the ones that you can install or remove using npm and yarn
public: This folder will hold the index.html that your webserver will load up when you navigate to the app's url. All the files that it will need will be auto injected by Vue, so you don't really need to worry much about what happens here.
src: This is where you will put all your code, components, assets, etc.
root files: On your project root you will see a bunch of configuration files like .eslintrc.js for your ES Lint configuration, .gitignore for GIT, your package.json and package-lock.json or yarn.lock files for package management, and others depending on your previous choices.

So ok yeah, now what?

A good rule of thumb is that when you have a new project and you want to see your available scripts you should check out the package.json file. Go ahead and open it and you'll see an entry in the JSON that is called scripts.

  "scripts": {
    "serve": "vue-cli-service serve",
    "build": "vue-cli-service build",
    "lint": "vue-cli-service lint"
  },

On the left side you'll get the name of the script, and on the right side of the key:value pair you'll get what that script actually does for you.

How do I use them? Well, it's actually very simple.

If you're using NPM, you would type into your terminal npm run <scriptname>, for example npm run serve. If you're using YARN, then you would type yarn serve.

Serve and Build

There's two main scripts that you will be working with when using the Vue CLI, one is serve and the one other one is build.

Go ahead and run npm run serve or yarn serve on your terminal (you need to be on the project directory before), and give it a few seconds to perform its magic. It will compile and bundle all your current assets, and finally spit out this legend.

A couple of things are now happening.

This command fired up a server for you, which won't "quit" until you hit control + c on your terminal window.
The server will be on the lookout for changes you do on your code and when you save them, it will rebundle your assets immediately (and yell at you if you have errors).
It gives you this localhost url that you can copy and paste or command/control click into your browser and will allow you to serve and view your project.
It has a hot reload function that will dynamically reload parts of your app from within your browser when something changes, so for example if you change a bit of CSS, the browser will auto-magically get updated after the CLI finishes recompiling.

So, bottom line, if you're working on your project you want this running in the background all the time.

On the other hand, you have the build command.

Go ahead and run npm run build or yarn build and give it a few seconds to compile your assets.

You will get a new folder in your root called dist which will have inside a copy of your index.html, but this time its minified and it will have the embedded scripts and styles that it needs to load.

Inside this folder you will also get css and js folders that hold your compiled project.

In short, this is the folder that you would eventually want to put into your web server to deploy your application.

Bonus

Vue CLI actually has a GUI. 🤯

Head over to your project root in the terminal and run the command vue ui and prepare to be amazed. You will get a full web-app GUI that will allow you to view/remove/install plugins, check out your dependencies, play around with your project's configuration and even execute the scripts you learned earlier!

Conclusion

Knowing and using the Vue CLI is a -must- for any developer that wants to use Vue to make SPAs. I know the terminal can be a dark and scary new world for first timers, but I promise once you go through these steps a couple of times it'll become less and less daunting to use. (And if everything else fails, you have the web UI to back you up!)

Hands-on Vue.js for Beginners (Part 7)

Marina Mosti — Tue, 05 Mar 2019 14:30:12 +0000

We are nearing the end of journey, and you are almost ready to graduate from Vue Padawan level. But first watchers, you must learn.

We're going to tackle two very important concepts today, watchers, as mentioned, and form input bindings.

Let's get started and we'll build a super simple form to showcase both these fantastic features.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">
    <label>What's your favorite game ever?</label>
    <input type="text" >

    <hr>

    <p>{{ response }}</p>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    const app = new Vue({
      el: '#app',
      data() {
        return {
          favoriteGame: null,
          response: ''
        }
      }
    });
  </script>
</body>

</html>

Let's take a look at what we're doing here.

Inside our <div id="app"> we've created a label and the most basic form of an <input> tag. After, we're outputting the result of a response property.

Inside our Vue instance, we're declaring a local state that includes two properties, favoriteGame and response. Also note, that we're using the data() as a function with the return syntax this time, if we don't v-model won't work.

The idea here, is that we want to first be able to store whatever the user inputs on the <input> field into a variable, that way we can use it later on as we see fit.

In vanilla JS or even jQuery you may be tempted to try to capture the input element with a $('input') or document.querySelector, but in Vue we have a much simpler way to achieve this mundane task.

Introducing v-model.

v-model

As you've learned before, everything that starts with a v- is a Vue directive. What v-model in particular translates to, in very simple terms, is:

Vue, I want you to grab this input that i'm putting this `v-model` directive on, and make a two way relation with it. I'm going to give you a `property`, and whenever I change this property anywhere in my code - I want you to change it on the input, and likewise, whenever this input changes - I want you to reflect those changes in my prop.

Let's try to put this in action, go to the <input> declaration, and add the v-model directive to it.

<input type="text" v-model="favoriteGame">

Now go and run this in your browser and type something into your magical input box of goodness. Taaaaa...da?

Ok, even though nothing seems to be happening. Go ahead and open your Vue devtools and inspect the <Root> element's data. YEAH. Progress!

Now go into the dev tools and change the value of favoriteGame into something else (don't forget the quotes wrapping it, we need a string here). EZ-BINDS-R-US 💪

Vue is VERY smart about how to bind with every type of native HTML form inputs, so really you only need to drop in the v-model bomb and profit, but the power of v-model really shows when you start building your own wrapper components and using it a-la-carte.

Behind the scenes v-model is actually setting up a v-bind:value and a v-on:input even binding, but going in depth on this is a bit out of scope so i'm just going to drop you a link if you're interested in looking further and look the other way. v-model on Components

Watchers

Now that we have our sweet sweet two-way binding v-model awesomeness in place, let's actually do something with it.

You've already learned that with a state data prop you can put it in your template with {{ favoriteGame }}, so no need to go over that again. You've learned how to use it inside a method and computed prop with this.favoriteGame - so no need to redo that. But what happens when you want to "listen" or "react" to this property actually getting modified?

Computed properties are fantastic at recalculating stuff and returning a value, but what if we want to modify another piece of state on our app when this value changes, or maybe even fire an async request of some sort? In these niche cases watchers come and save the day.

Let's go an add the boilerplate for creating a watched prop.

<script>
  const app = new Vue({
    el: '#app',
    data() {
      return {
        favoriteGame: null,
        response: ''
      }
    },

    // Watchers here
    watch: {
      favoriteGame(newValue, oldValue) {
        console.log('Favorite game was ' + oldValue + ' and now is ' + newValue)
      }
    }
  });
</script>

Watchers are defined inside a watch property in our instance or component, and we pass it an object that will include a property for each one of the props we want to watch.

In simple terms, every data prop or props prop you want to watch/react to needs to go inside this watch: {} with its name. So if your prop is named favoriteGame that's the name of your function.

Each one of these functions gets two params passed to it, the first one will be the newValue that this prop is getting, and the second one is the oldValue that it used to have before the change.

Check out the console.log statement and refresh your browser window. Try typing something into the <input> and check out your console output. Every time our favoriteGame prop changes in ANY way, this watcher will be fired.

Now let's actually do something cool with it. Remember our response prop? Let's put something into it depending on what the user answers, and have some fun with it.

watch: {
  favoriteGame(newValue, oldValue) {
    if (!newValue) return // If its an empty string, pass

    // If the new value contains the keyword metroid
    if (newValue.toLowerCase().indexOf('metroid') !== -1) {
      this.response = 'Ceres station is under attack!'
      return
    }

    // If the new value contains the word zelda
    if (newValue.toLowerCase().indexOf('zelda') !== -1) {
      this.response = 'Its dangerous to go alone, take this 🗡️'
      return
    }

    // If the OLD value was metroid, and user changed it something else
    if (
      oldValue.toLowerCase().indexOf('metroid') !== -1 &&
      newValue.toLowerCase().indexOf('metroid') === -1
    ) {
      this.response = 'GET TO DA CHOPPA NAO'
      return
    }

    // Default response
    this.response = 'Sure, why not?'
  }
}

In case you don't know, indexOf checks the string and returns -1 in case there was no match, and else it returns the position of the string we're searching for in the string being searched.

Go ahead and have some fun with this, make some new examples and play with it in your browser.

I hope you can see now the power of watched properties, the way I have found it useful is to think, if my property changes and I need to REACT programmatically to it (with an ajax call, an external function, updating a secondary value, etc), then watchers are usually a good call. For anything else, go with computed properties.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">
    <label>What's your favorite game ever?</label>
    <input type="text" v-model="favoriteGame">

    <hr>

    <p>{{ response }}</p>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    const app = new Vue({
      el: '#app',
      data() {
        return {
          favoriteGame: null,
          response: ''
        }
      },
      watch: {
        favoriteGame(newValue, oldValue) {
          if (!newValue) return

          if (newValue.toLowerCase().indexOf('metroid') !== -1) {
            this.response = 'Ceres station is under attack!'
            return
          }

          if (newValue.toLowerCase().indexOf('zelda') !== -1) {
            this.response = 'Its dangerous to go alone, take this 🗡️'
            return
          }

          if (
            oldValue.toLowerCase().indexOf('metroid') !== -1 &&
            newValue.toLowerCase().indexOf('metroid') === -1
          ) {
            this.response = 'Nothing is true , everything is permitted'
            return
          }

          this.response = 'Sure, why not?'
        }
      }
    });
  </script>
</body>

</html>

Conclusion

Congratulations on making it this far!

You now have the basic tools to actually build a really cool and functional application in Vue, I guarantee it. However, there is still a lot to learn and a lot to explore in order for you to squeeze every inch of juice out of this framework.

But don't worry, I've said it before and I stand by it today, one of the key aspects I enjoy most about Vue.js is the documentation.

I remember back when I was starting out with programming I was really afraid of having to dive docs because they were usually really poorly explained, and assumed a high level of understanding of the language and the framework/lib that I was trying to use.

Thankfully, the Vue docs team has done a wonderful job of making a complete guide full with examples for everything that we have covered in this guide plus everything else you need to excel at this framework.

This concludes the Beginner series for Vue!

If you want to keep up with my articles, keep an eye on my Twitter account at @marinamosti and check out my other articles at Progress' blog!

Beware the power of the magical avocado, and thanks for reading! ♥

Hands-on Vue.js for Beginners (Part 6)

Marina Mosti — Fri, 01 Mar 2019 14:23:46 +0000

Let's talk about computed properties.

So far you've learned how Vue handles its own local state, the one we put inside data, and how a component can handle its prop properties - the ones that get handed down by the parent.

However, there is a type of properties in Vue which are called Computed Properties. Let's take a look at these today.

We're going to use a clean slate today, so that we can build a clear example. Here's the code.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">
    <age-calculator></age-calculator>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    Vue.component('age-calculator', {
      template: `
        <p>
          NAME has been kicking butt for X days!
        </p>
      `
    });

    const app = new Vue({
      el: '#app'
    });
  </script>
</body>

</html>

I've gone ahead and added the scaffolding for an age-calculator component, right now it only outputs a <p> tag with an X where we're going to perform some sort of calculation. I've also added the corresponding tags <age-calculator> to the div#app.

If you need a refresher on basic components, take a look at Part V of this series, or better yet, nosedive the official docs!

When a simple prop isn't enough

Before we write any code, let's talk about what we're trying to accomplish.

I want to have a component where I pass it someone's age, and it will tell us how many days they've been around to enjoy avocados. If you don't like avocados then this is where our relationship ends, have a nice life.

Let's tackle the easy tasks that we already know how to accomplish, first we need an array of people with ages so that we can loop through it and output a bunch of components. Let's add the corresponding data.

const app = new Vue({
  el: '#app',
  data: {
    people: [
      { name: 'Mario', age: 38 },
      { name: 'Luigi', age: 38 },
      { name: 'Samus', age: 31 },
      { name: 'Link', age: 20 },
      { name: 'Marina', age: 32 },
      //Add yourself here :)
    ]
  }
});

Now, let's set up our v-loop to output an age-calculator per each one.

<div id="app">
  <age-calculator v-for="person in people" :key="person.name"></age-calculator>
</div>

Awesome, now let's allow the age-calculator component to receive a person, remember we do this with a prop. So first, let's add this new prop to the component.

Vue.component('age-calculator', {
  props: {
    person: {
      type: Object,
      required: true
    }
  },
  template: `
    <p>
      {{ person.name }} has been kicking butt for X days!
    </p>
  `
});

Bonus! Before you learned that to declare the props that a component can receive, you set up an array of strings props: ['person'] and this is fine in most cases. But what happens if we want a bit more control?

You can also, like in this case, set props to be equal to an object. Inside this object, we can create a property per each property we want to declare.

Inside the property declaration, in this case person, we can set some configuration values.

type to declare which (duh) type of data we're passing, so Object, Array, String, Number for example.

required is a boolean that allows us to mark this property as required for the component to work.

You can also set a default value, but we're not going to use that here.

Next, look at the template. We are now outputting the person's name {{ person.name }} onto the <p> tag.

One more thing before we can actually run this in our browser though. Can you tell what we're missing?

We still need to pass the actual person to the age-calculator component!

Go into the render loop and pass in our variable.

<age-calculator 
  v-for="person in people" 
  :person="person"
  :key="person.name"></age-calculator>

Go ahead and run this in your browser to check that everything is working. Baby-steps!

Note Before we move on, if you're curious what setting a prop to required will do for you, try removing this last bit we did when we pass the person to the component and look at your dev tools in the console section.

Handy, ain't it? 👌

The actual Computed Property

Alright, enough setting up and review.

We still have one more feature to tackle inside our component, we want to calculate the number of days each person has been alive.

Granted, it's not a very hard calculation, we just have to multiply 365 times the number of years (we're not going to go hardcore with JS Dates here). And in fact, we could go ugly and direct and put this straight into our template.

template: `
        <p>
          {{ person.name }} has been kicking butt for {{ person.age * 365 }} days!
        </p>
      `

This works, sort of. But what happens when you require more logic? A harder computation, some ifs/ands/ors/whens/beers? Then you're in a real problem because you can't really put that much logic inside the template, or it's going to get unmanageable real quick.

Here's where computed properties shine. Computed properties are in the end functions, that will execute a bit of code, and return a value. This value is now treated like a property, which means we can straight up use it in our template.

Let's take a look at how to set it up. First, let's add the computed wrapper to our component.

Vue.component('age-calculator', {
  props: {
    person: {
      type: Object,
      required: true
    }
  },
  template: `
    <p>
      {{ person.name }} has been kicking butt for {{ person.age * 365 }} days!
    </p>
  `,
  computed: {
    // Computed props go here
  }
});

So far so good, in fact this structure is the exact same one we have been using for methods, remember? (If you're thinking a method could also solve our problem, you're on the right track - we'll talk about this in a minute.)

Let's create a new computed property called daysAlive, it needs to be a function, and it needs to return something.

computed: {
  daysAlive() { //Remember, computed props are functions in the end
    return this.person.age * 365
  }
}

Take note that just like in methods we need to access the person prop though this, only inside the template we can use it directly! Other than that, nothing too fancy going on.

Now let's use this new daysAlive prop in our template.

template: `
  <p>
    {{ person.name }} has been kicking butt for {{ daysAlive }} days!
  </p>
`,

Note that we're outputting the value of the daysAlive --property--, (aha moment here). Vue treats computed props as, well, props - so we can use this here as you would a props prop, or a data prop.

In fact, Vue makes it so that if you would need to use this prop inside a method for example, you would have to access it through this.daysAlive. Neat right? It ACTUALLY becomes a prop. 🤯

YAY, run it in the browser and bask in your awesomeness.

Methods vs Computed Properties

You may have noticed a lot of similarities between methods and computed props, I mean, they're basically identical at code level. However there is a CORE difference that you need to understand in order to harness them fully.

Computed properties get cached.

What this means is, in the simplest possible way to explain it, that behind the scenes Vue will "read" your code and look for reactive dependencies - so data props and props props. It will watch these properties, and whenever they change, Vue will recalculate the value of your computed property. If they don't change, it'll just use a cached/stored value.

Methods, on the other hand, are ran EVERY time - there is no caching, no code reading, no magic. They're just plain old functions.

Why does this matter? When are these functions called?

Every time your component/app re-renders (so every time a component's data change, or every time it's parent's data changes), Vue will figure out if that data is tied to a computed property, if it's not - it won't call this function again. For regular methods however, they will be re-run every time!

For this example, where we're doing a very simple calculation for these few objects it doesn't really matter, frankly. But when you start doing some serious code weightlifting on top of a thousand components, then you're going to want to leverage this caching or your app is going to take a hit on each render cycle.

If you want to read more, here's a link to the official docs regarding computed properties.

Here's the complete code for today.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">
    <age-calculator 
      v-for="person in people" 
      :person="person"
      :key="person.name"></age-calculator>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    Vue.component('age-calculator', {
      props: {
        person: {
          type: Object,
          required: true
        }
      },
      template: `
        <p>
          {{ person.name }} has been kicking butt for {{ daysAlive }} days!
        </p>
      `,
      computed: {
        daysAlive() {
          return this.person.age * 365
        }
      }
    });

    const app = new Vue({
      el: '#app',
      data: {
        people: [
          { name: 'Mario', age: 38 },
          { name: 'Luigi', age: 38 },
          { name: 'Samus', age: 31 },
          { name: 'Link', age: 20 }
        ]
      }
    });
  </script>
</body>

</html>

That's it for today! Thanks for reading, and we'll keep on going next week with watchers! 🕵️‍♀️ 👀

Understanding the Spread Operator in JavaScript

Marina Mosti — Tue, 26 Feb 2019 17:27:46 +0000

{...object}

The first time I looked at this I was really confused about what it was supposed to mean, or even do, but harnessing the power of the spread operator in JavaScript has definitely payed off.

In my latest entry to Hands-on Vue for Beginners series, I used a spread operator in the tutorial and promised I would make a post explaining what it is, and how it works, for anyone that is not yet familiar with it.

Disclaimer. The spread operator is an ES6 feature, and thus is not supported in every browser (IE strikes again). However you can rest assured that it will work on all major and modern browsers. Browser Compatibility

Diving in

MDN explains it like this:

Spread syntax allows an iterable such as an array expression or string to be expanded in places where zero or more arguments (for function calls) or elements (for array literals) are expected, or an object expression to be expanded in places where zero or more key-value pairs (for object literals) are expected.

And I don't know about you, but for me when I was trying to learn all this it was super daunting and confusing. So let's break it down to digestible pieces.

Imagine you have a function, where you want to add three values:

function add(a, b ,c) {
  return a + b + c;
}

Now imagine, you have an array of values:

const values = [1, 2, 3];

Now, if we ask ourselves, how would we go about putting those values into the function add them. A practical approach would be to maybe do something like this:

const sum = add(values[0], values[1], values[3]);

I mean, it sort-of works. Right? But take it up a nudge, what happens when you have a function that will accept a dynamic number of arguments? Or even simpler yet, what if we have a scenario where this function wants 20 values and I give you an array with 20 numbers.

This is when things start to get really ridiculous, are you going to access all the values directly via index? (There's ways to do this with array functions like reduce, I know, but bare with me for the sake of example.)

Consider the following example:

function sum(a,b,c,d,e,f,g,h,i,j,k,omgwhy) {
 return a+b+c+d+e+f+g+h+i+j+k+omgwhy;
}

const values = [1,2,3,4,5,6,7,8,9,11,12];

Here's where the spread operator shines! Imagine that this values array is a box, it contains all these numbers in it in a VERY neat and orderly fashion, each one has an index - and that contains it perfectly.

When we access an array's index value like this values[1] we are very neatly taking out that single value, which is what we did on the first example. But to continue with the metaphor, what if we wanted to take out ALL the values in the exact order in which they are in the box?

Maybe it could be cool to be able to do something like this values[0-11], but instead we type it like this ...values.

Now in this case in particular with the function, you would say:

const result = sum(...values);

Tada! Now, watch carefully because when take the values out of the array they're not just getting thrown around into the wind, they're all going into their respective parameters in the function. a will get 1, b will get 2 and so on.

Merging

Alright, so spreading arrays into functions is nice. But i've honestly not used it a lot. However merging two arrays together or two objects becomes a breeze!

Let's cook up an example:

const favoriteGames = ['Zelda', 'Metroid'];
const favoriteBands = ['Queen', 'RHCP'];

const lifeFavorites = [...favoriteGames, ...favoriteBands];

So first we're just defining a couple of arrays for examples, favoriteGames and favoriteBands. But let's take a look closely at the third line.

const lifeFavorites = we're going to store the result of the merge here, nothing too fancy and we're setting it to be equal to a NEW array.

Notice = [somestuffshere];

This is super important to understand, when you spread an array or an object those spread values needs to be used somehow, you need to clean up after yourself. So in this case we're saying:

Ok, JS, grab the contents of these two array boxes, dump all the crap they have in them into this new box and call it lifeFavorites. Thankfully the actual crap-dumping is done in a very orderly fashion and order of the values will be respected.

So the result will actually be:

['Zelda', 'Metroid', 'Queen', 'RHCP']

Making copies

Another great way to use the spread operator is to make a copy of an array or an object. In JavaScript when you assign an object or array to a variable you're actually storing something called the "pointer", which sort of works like the address of where that object is being stored.

So if you do:

const obj = {name: 'Marina'};
const anotherObj = obj;

The big problem here will be that both obj and anotherObj are actually pointing to the same object. So if you change one or the other, they will both change because the pesky pointer is addressed to the same object.

In frameworks like Vue this becomes a real problem and a real pain to debug, because in some cases like when making copies of props you never want to modify the original object. In React this is also used when changing the state, you're not supposed to directly modify the value.

So how do we make a copy with the spread operator?

const baseObject = {name: 'Marina'};
const myCopy = {...baseObject};

const baseArray = [1, 2, 3];
const arrayCopy = [...baseArray];

Something important to note is that when making a copy of any object/array using a the spread operator the copy will be shallow. This means that if your object has a child object, that child will still have a pointer to the original object. (Thanks to everyone that pointed this in the comments)

const original = { name: 'Parent', child: { name: 'Child' } };
const copy = {...original};

// The thing to note here is that the COPY will have a child property, but this
// child property is actually pointing to the same exact object as ORIGINAL

// So:
// original.child === copy.child

That's it! Once again, we're pouring out our boxes into another box that contains it, and that will ensure that the resulting object/array are actually a copy of the original - and you can safely modify them without fear of messing with the first.

Hands-on Vue.js for Beginners (Part 5)

Marina Mosti — Fri, 22 Feb 2019 17:59:01 +0000

This time around we're going to look (finally) at components! So get some ☕️ and let's get started.

Here's the clean slate for today's article 😁

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">

  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    const app = new Vue({
      el: '#app',
      data: {

      }
    });
  </script>
</body>

</html>

Component Basics

We're going to nosedive right into component creation because this is where really fun stuff starts. But rest assured that this is only barely brushing the power of components. Also, we still have yet to learn computed properties and watchers, which will also be a huge aid. But we'll cover that next time on top of what we learn today.

Components are a core part of the Vue.js framework, they are your Lego blocks for building reactive, rich applications - and luckily for us, they are super simple to learn and use!

Think of a component as any element in your webpage/app that you want to use one or several times. It can be as smol as a button, or input, or as a big as your whole menu bar or even the whole page's view.

The advantage of creating a component is that you write the logic for how its displayed (HTML/CSS), and how it interacts with the user (JS) once - and then you just use it all over your app.

As usual, we're going to start with the simplest possible example, a button.
Let's define first the blueprint or template for this component, we'll call it awesome-button and it shall be so!

Let's define a new awesome-button component. Copy this code above your new Vue declaration.

Vue.component('awesome-button', {
  template: `<button @click="clickHandler">Click me for some awesomeness</button>`,
  methods: {
    clickHandler() {
      alert('YAAAS 😎');
    }
  }
});

The Vue object that is made available to us through the Vue.js script tag that we added on day 1 has this component method that we are calling here. It allows us to create a new component, as expected. The first parameter we are setting is a String, which will be the name of our component.

The second parameter is a JavaScript object, which - surprise - is actually the same type of configuration object that we have been using for our main Vue instance! What does this mean for you? That you already know how to assign properties and methods for this new component.

In the example above, you will notice just one difference - the template property. In here we're declaring a String (note that we're also using the back-tick character to wrap it so that we can declare multiple lines later on if we need without having to concatenate multiple strings), this String will hold our actual HTML code for this component. In the case of this particular example, just a simple <button> tag will suffice.

If you reload your page right now, nothing will happen. Remember earlier I told you this was only the blueprint/template? It's time to actually render it on our page.

Head over to the <div id="app"> where we have been placing all our markup, and create a new <awesome-button> element.

Your HTML should now look something like this:

<div id="app">
  <awesome-button></awesome-button>
</div>

Load the page, and now you will actually see the button is rendered on the page. Place a couple, or ten more (reader's choice), awesome-button tag on the page. Now you start to see the power of components, although at this point I think we can take it up a nudge.

Bonus: If you're the curious type, take a look at your page source and compare it to the inspect feature with your browser's developer tools. When the page load, Vue.js is using the <awesome-button> tag as a placeholder to where it should put the parsed content of our template.

Level 2 - Something a little more useful

Let's revisit our example from last week, and play some more with our games data.

First, let's re-add this array of games into our data() in the main Vue instance.

const app = new Vue({
  el: '#app',
  data: {
    games: [
      { name: 'Super Mario 64', console: 'Nintendo 64', rating: 4 },
      { name: 'The Legend of Zelda Ocarina of Time', console: 'Nintendo 64', rating: 5 },
      { name: 'Secret of Mana', console: 'Super Nintendo', rating: 4 },
      { name: 'Fallout 76', console: 'Multiple', rating: 1 },
      { name: 'Super Metroid', console: 'Super Nintendo', rating: 6 }
    ]
  }
});

Just as before, feel free to update these with your favorite titles.

This time, however, we are going to create a game-card component, that will make a bit more sense to display our data in.

Ready for this?

Vue.component('game-card', {
  props: ['gameData'],
  template: `
    <div style="border-radius: .25rem; border: 1px solid #ECECEC; width: 400px; margin: 1rem; padding: 1rem;">
      <h2>{{ gameData.name }} - <small>{{ gameData.console }}</small></h2>

      <span v-for="heart in gameData.rating">❤️</span>

      <button @click="increaseRating">Increase Rating</button>
    </div>
  `,
  methods: {
    increaseRating() {
      // this.game.rating++ ?
    }
  }
});

Don't get overwhelmed, you already know all/most-all of this 😃!

We're creating a new Vue.component and naming it game-card. Let's skip props for a second, and look at the template.

Nothing new here, except you may have noticed we're accessing the properties of a gameData property that is not defined inside data, but inside the props property.

Afterward, we declare our methods object, with the increaseRating method inside it. I've purposely commented out this.game.rating++ which would be how you may want to address this particular function, but it won't work! Now it's time to talk about props.

Component Props

One of the reserved properties we can have on our custom components is called props. In its simplest form, it will take an array of Strings that will define variables. In our previous example, we are telling the component blueprint/template that we want it to be aware of a property called game.

Props will allow us to pass information into our components from outside! Let's view this in action, it'll be easier to grasp.

First, let's add a bunch of <game-card> items to our app. We will be using a v-for loop just like we did before, but we're going to loop on top of our custom components this time!

<div id="app">
  <awesome-button></awesome-button>
  <hr>
  <game-card v-for="game in games" :game-data="game" :key="game.name"></game-card>
</div>

That is quite a bit of game being tossed around, so let's look at it in detail.

First step, we are creating our <game-card> component, like we discussed earlier.

After, we add the v-for="game in games" loop like we saw last week. This creates a game variable that will hold the current game in the loop, and we can use it right away!

Finally, we assign to the template's prop, gameData, a value, in this case our game variable from the loop. Notice that instead of camel case, we're using a hyphen game-data because HTML is case insensitive. If you are having a hard time grasping this, try thinking it in object terms. We are doing something similar to game-card.props.gameData = game

Don't forget about the :key!

There is a huge gotcha to mention here, we are passing game to our game-data prop, but there is a : behind it. Did you notice?

When we assign a property to a component instance, there's two ways to go about it. Following our example, we could either do it with the : before it (this is a shorthand for v-bind:!). This will make sure the data that we are passing after the ="<here>" is used by JavaScript as a variable, or an actual piece of code.

If you were to type instead gameData="game", then Vue will take this as assigning the gameData prop the String "game". So something like: game-card.props.gameData = "game"!

Go ahead and take a break from theory and actually go and run this in your browser. You will see as expected, that our whole <game-card> component's template is being rendered for each one of our game's.

The greatest part about this is that if we were to make a change to our HTML, it will be updated everywhere in our app.

Also, and most importantly, components allow you to contain the logic for that particular component. Let's revisit that game-card's increaseRating() method.

Component Data vs. Props

Props for components actually can be a very lengthy subject, but there is a very important rule of thumb that you must always keep in mind. A property should NEVER be modified from inside a component.

In fact, if you try to do this, Vue will throw all sorts of warnings and yell at you in the console - because this WILL lead to unexpected behavior. Here's the documentation, in case you want to read about it: Mutating props in Vue2 is an anti-pattern.

How then, will we modify the value of rating inside of our component's storage? The key is in the question itself! We need to make a copy of this prop into our data so that we can actually modify it.

Let's first add our data to our game-card component, and assign it a new non-conflicting name (props and data props will conflict if named the same), and then pre-fill it with the prop's value.

data() {
  return {
    game: {...this.gameData}
  }
},

Couple of things to note here, but before that, if you don't know yet what {...gameData} is doing, it's a spread operator. I won't go into full detail here and will try to post a brief article about it soon, but basically were making a copy of the gameData prop, because we don't ever want to modify that from the child.

The data property's return:

When we learned about the data property, I told you that it needed to hold an object with all the properties we needed, and this is how we've been doing it for our main Vue instance. However for components we actually need to make it a function, by adding (), and second return the actual object.

But WHY?! 😫

Simply put, there can be one or many instances of your component, right?

Each instance will need a unique data object! You don't want to share a single data object between all of those, or they would all share the same title for example - and the point of this whole app would be lost.

So the whole reason behind making it a function and returning an object, is that Vue can ☎️ call this function every time it creates one of our game-cards. That way each one will get a unique object of data to play with!

Accessing our props:

When we create the game's data property, we are assigning it this.gameData, so a couple of things to learn here. props can also be accessed within your component scripts via this just as your local state props from data. So here, we are setting game to be equal to the gameData property.

This means now we have to update our HTML, so inside the component switch the gameData reference for game like so:

<div style="border-radius: .25rem; border: 1px solid #ECECEC;">
  <h2>{{ game.name }} - <small>{{ game.console }}</small></h2>

  <span v-for="heart in game.rating">❤️</span>

  <button @click="increaseRating">Increase Rating</button>
</div>

Run this once again in your browser, and you should get the same results.

Finally, we are at the point where we can make our increaseRating method work! Head to the method and replace the comment with the following:

methods: {
  increaseRating() {
    this.game.rating++
  }
}

With every click, we're going to increment the component's internal data property which holds the game's rating, -not- the prop.

There is a lot of theory to be learned about components, i've just began to scratch the surface, but hopefully you are starting to have a clearer picture of why frameworks like Vue are so popular, and so much fun to use.

From this point forward we're going to start looking at what I consider intermediate topics, like computed properties, watchers, events, etc. So hopefully you are excited to get to know the meaty part of Vue soon enough.

In case you need it, here's the complete code for today, and thanks for reading! 🤗😋

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">
    <awesome-button></awesome-button>
    <game-card v-for="game in games" :game-data="game" :key="game.name"></game-card>
  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    Vue.component('awesome-button', {
      template: `<button @click="clickHandler">Click me for some awesomeness</button>`,
      methods: {
        clickHandler() {
          alert('YAS. 😎');
        }
      }
    });

    Vue.component('game-card', {
        props: ['gameData'],
        data() {
          return {
            game: {...this.gameData}
          }
        },
        template: `<div style="border-radius: .25rem; border: 1px solid #ECECEC; width: 400px; margin: 1rem; padding: 1rem;">
          <h2>{{ game.name }} - <small>{{ game.console }}</small></h2>

          <span v-for="heart in game.rating">❤️</span>

          <button @click="increaseRating">Increase Rating</button>
        </div>`,
        methods: {
          increaseRating() {
            this.game.rating++
          }
        }
      });

    const app = new Vue({
      el: '#app',
      data: {
        games: [
          { name: 'Super Mario 64', console: 'Nintendo 64', rating: 4 },
          { name: 'The Legend of Zelda Ocarina of Time', console: 'Nintendo 64', rating: 5 },
          { name: 'Secret of Mana', console: 'Super Nintendo', rating: 4 },
          { name: 'Fallout 76', console: 'Multiple', rating: 1 },
          { name: 'Super Metroid', console: 'Super Nintendo', rating: 6 }
        ]
      }
    });
  </script>
</body>

</html>

Hands-on Vue.js for Beginners (Part 4)

Marina Mosti — Thu, 14 Feb 2019 18:32:38 +0000

Welcome back! 🤩

Last time we took at conditional rendering with v-if and v-show. This time we will learn how to loop through arrays and objects and create an element for each one of the items in them. We will also apply some of the concepts we have learned before.

v-for

v-for is one of the fundamental directives of Vue.js, and once you understand how it works the extension of what you can build inside your apps will grow exponentially.

v-for is, simply put, a for loop. If you don't yet know what this means, a for loop is a piece of code that gets executed one time per each element in a group - which in turn is usually an Array or an Object.

We're going to start with an empty slate today so that everything we do has a clear purpose. Here's a copy of our base index.html file for you to copy and paste into your editor.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
  <div id="app">

  </div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    const app = new Vue({
      el: '#app',
      data: {

      },
      methods: {

      }
    });
  </script>
</body>

</html>

Let's start by creating a simple list, an array, that we can loop to output its content. We will create a property inside our data object, called games. Feel free to change the titles to your own personal favorites 🙃🎮

data: {
  games: [
    'Super Mario 64',
    'The Legend of Zelda Ocarina of Time',
    'Secret of Mana',
    'Super Metroid'
  ]
},

Awesome! Now that we have our array set up, let's create a sad and simple <ul> element where will display it. For the sake of example, let's keep it simple for now.

<div id="app">
  <ul>
    <li>Game title here</li>
  </ul>
</div>

Ok, looking good! Now we have to tell Vue that we want to output as many <li> elements inside the <ul> as needed to loop through our whole array.

In other languages, and even in vanilla JavaScript, you may be used to doing something that looks similar to this:

<?php foreach ($game in $games): ?>
  <li><?php echo $game; ?></li>
<?php endforeach; ?>

Where the loop encloses the element(s) it's going to output or print out.

In Vue we declare our v-for directive on TOP of the element we want to loop. Make these changes to your <li> and we'll dissect them after.

<ul>
  <li v-for="game in games">{{ game }}</li>
</ul>

Let's take a look.

v-for was added directly to the <li>, not the <ul> as we saw earlier. This reads: "For each game in my games array, please make a new <li> inside these <ul> tags.
Note that games is the property that we added earlier with the array inside our data, so we have to use this variable name.
The variable game (singular) is defined by us, we could use item, game, title or whatever we feel like. But be sure to understand that this *game* in games is what you will be using as a variable inside your loop.
Finally, inside our <li> tag we're outputting the contents of our game variable, so while the loop is running for each of our games, this will output the string into the <li>.

Run your app inside the browser, and you should see your list of items being outputted to the screen.

Taking it up a notch

So far, so good? v-for is actually a very simple concept, and this example is super boring. So how about we make things a bit more complicated, by making our array include some objects, and also applying some v-ifs inside our list?

First things first, let's update our games property with some more interesting data.

data: {
  games: [
    { name: 'Super Mario 64', console: 'Nintendo 64', rating: 4 },
    { name: 'The Legend of Zelda Ocarina of Time', console: 'Nintendo 64', rating: 5 },
    { name: 'Secret of Mana', console: 'Super Nintendo', rating: 4 },
    { name: 'Fallout 76', console: 'Multiple', rating: 1 },
    { name: 'Super Metroid', console: 'Super Nintendo', rating: 6 }
  ]
},

As always feel free to use your own favorite titles. PS. Super Metroid's rating of 6 is not a typo, it's just THAT good - and I'm biased. 😬 Also, Bethesda, you should be ashamed. cough Anyways.

If you run your app this point it will not particularly break, but it will just output the objects in a string format, which is not pretty. In fact, we're going to scratch our <ul> approach completely, and use a <div> to output our information. (Don't worry, it'll still be ugly).

Update your whole <div id="app">:

<div id="app">
  <div v-for="game in games">
    <h1>{{ game.name }} - <small>{{ game.console }}</small></h1>

    <span v-for="star in game.rating">❤️</span>

    <div v-if="game.rating > 5">Wow, this game must be <b>REALLY</b> good</div>
  </div>
</div>

WOAH. Ok, maybe not, but don't worry, you already know everything you need to understand what's happening here.

div v-for="game in games" Same old, we're going to loop our games array prop and store each game in the game variable.
h1. Ok, so game is an object, which in turn holds its own properties, name, console and rating. Inside the <h1> we're going to output the game's *name: game.name. And the console: game.console. As you can see now, v-for is not limited to outputting just a single element as we saw before with the li, but you can actually output as much HTML as you need.
The nested v-for. So inside the span element we actually have a nested v-for loop (which is TOTALLY ok to do), except it's a little different, we're not looping an array or an object. I didn't LIE to you, maybe just withheld some information - like for example, you can actually loop a numeric value (in this case game.rating and the loop will count up from 1 till it reaches the value of the rating. Simple?
Finally, v-if. We are going to output a <div> tag inside our loop IF the condition is met, so if and only if the current game's rating is greater than 5. Take a guess which?

Go ahead and run this again in your browser and behold the awesomeness of not bothering with CSS.

What if I don't need a wrapping DIV?

If at any point you find yourself making a bunch of <div> elements simply to wrap up your v-for loops, there's a special HTML tag you can use to help your case. <template></template>

If you, for example, remove the wrapping <div> and change it for <template> take a look at your developer console and you'll see that the <h1> and <span> elements are not wrapped by anything.

<template> is special, because Vue will treat it as a wrapper element but it won't be rendered into the HTML when we execute it, so you can safely use it to wrap a bunch of other elements logically for the loop without affecting your markup.

The :key attribute

One final thing that I purposely left for the end. The :key attribute.

When you are looping through elements with v-for Vue.js has NO clue how to track your elements for reactivity, because it can't "tell apart" one object from the other. What this means for you is that since Vue can't do this, it will re-render the WHOLE section of the page that is being created by this loop. In our case it's a very small section and the performance hit would probably be minimal, but it's something that you should keep in mind - and just do it for best practice.

Now, how do we use it?

:key expects some string it'll use to "name" or "track" the element, so we need to give it a unique identifier. In the case of our games it's simple, we can do:

<div v-for="game in games" :key="game.name">

I'm pretty certain that we're not going to have the same game twice in this list, so this is pretty safe. An id if you have data coming from a database is also ideal to use here.

If you are curious about the intricacies of :key you can always take a look at the documentation. Key's docs

In fact, now that you have gotten this far I can't stress enough the importance of getting acquainted with the documentation. Vue.js 's docs are impressively good, and very very clear with code examples, the documentation team does a fantastic job to keep them updated and clear - big shout out to all of them.

Final code

Here's the final code, just in case.

<html>

<head>
  <title>Vue 101</title>
</head>

<body>
<div id="app">
  <div v-for="game in games" :key="game.name">
    <h1>{{ game.name }} - <small>{{ game.console }}</small></h1>

    <span v-for="star in game.rating">❤️</span>

    <div v-if="game.rating > 5">Wow, this game must be <b>REALLY</b> good</div>
  </div>
</div>

  <script src="https://cdn.jsdelivr.net/npm/vue/dist/vue.js"></script>

  <script>
    const app = new Vue({
      el: '#app',
        data: {
          games: [
            { name: 'Super Mario 64', console: 'Nintendo 64', rating: 4 },
            { name: 'The Legend of Zelda Ocarina of Time', console: 'Nintendo 64', rating: 5 },
            { name: 'Secret of Mana', console: 'Super Nintendo', rating: 4 },
            { name: 'Fallout 76', console: 'Multiple', rating: 1 },
            { name: 'Super Metroid', console: 'Super Nintendo', rating: 6 }
          ]
        }
    });
  </script>
</body>

</html>

Challenge

This time you get a challenge if you wish to accept it. Add a @click listener to the <span> which outputs the game's rating, and increase the ranking by 1 with each click for that UNIQUE game. You already know everything you need to achieve this 😉.

Tip: You'll need to pass the game you're looping to the click function, and inspect it.

Good luck!

DEV Community: Marina Mosti

Loading and using a fixture from an API endpoint for Cypress e2e tests

What is a Cypress fixture?

Loading API based fixtures

Accessible form error auto-focus with Vuelidate in Vue

The form

Adding error messages

Triggering validations on @submit

Auto-focusing the element with an error

Wrapping up

How to target the DOM in Vue

Knights of the Old Vuepublic

The Vue awakens

The way of the Vuedi

Caveat 1

Caveat 2

The dark side

Wrapping up

Demystifying the v-model Directive in Vue

Two-way binding and the basics

Listen to user input

Changing the input programmatically

Enter v-model

Conclusion

In Vue, when do I actually need the :key attribute and why?

The problem

Understanding the basics of :key 🔑

Preserving state

Object Constancy

Wait, what?

A real-world example

Breaking things apart

Wrapping up

So what actually is Vue.set?

Data and Reactivity

The pitfall

Actually using Vue.set

Vue 3.0

A first look at the Vue CLI

Getting set up

NodeJS

Yarn (Optional)

Installing the CLI

Creating our first project

The Folder Structure

Serve and Build

Bonus

Conclusion

Hands-on Vue.js for Beginners (Part 7)

v-model

Watchers

Conclusion

Hands-on Vue.js for Beginners (Part 6)

When a simple prop isn't enough

The actual Computed Property

Methods vs Computed Properties

Understanding the Spread Operator in JavaScript

Diving in

Merging

Making copies

Hands-on Vue.js for Beginners (Part 5)

Component Basics

Level 2 - Something a little more useful

Component Props

Component Data vs. Props

Hands-on Vue.js for Beginners (Part 4)

v-for

Taking it up a notch

What if I don't need a wrapping DIV?

The :key attribute

Final code

Challenge

Understanding the basics of `:key` 🔑