DEV Community: Rasmus Langvad

An Introduction To NextJS

Rasmus Langvad — Sun, 06 Feb 2022 07:45:42 +0000

What is NextJS?

NextJS is a “meta framework” for React. It provides tools and conventions that makes it easier for you as a developer. Looking at their website they write:

The React Framework for Production

Lots of concepts goes in to this statement. It’s one thing to develop your application on your computer where the conditions are optimal. When taking your application live to a production environment there are many things to consider. That NextJS will help you with.

When using a classic create-react-app you get all the things needed from React to build a full scale application. But when putting this to production you will encounter other issues that you need to handle. Rendering is one of them. A regular React application is always rendered on the client, referred to as Client Side Rendering (CSR).

NextJS provides extra rendering options such as Server Side Rendering (SSR), Static Site Generation (SSG) and Incremental Site Regeneration (ISR). I will not go into detail about each in this article but those are the main reasons to use NextJS, I would say. Makes it easier to manage pages and components based on the rendering strategy. And you can choose which one to use depending on your specific project needs.

NextJS also provides other features such as bundling, optimised assets for production, code splitting, API routes, TypeScript support and more. All there for you as a developer to make your life easier.

Getting started

Open a terminal and run either this npm or yarn script.

npx create-next-app@latest

yarn create next-app

If you want your project to be in TypeScript you can add the --typescript flag after the initial command and you will have all the support and configuration files included in the boilerplate.

This will give you an application with a simple project structure.

If you open the newly created folder and run npm run dev or yarn dev you will get an app running on localhost.

Basic concepts

NextJS provides many features out of the box. These things will make your life easier as a developer and you will create better applications.

Pages

The most important feature is the /pages folder. This magic folder lets you create files that will turn into pages in your application. For example adding the file /pages/info will generate the path /info. Try to create this page and add the following:

export default function Info() {
  return <div>Information content</div>;
}

Then run your application with npm run dev or yarn dev. The new page is then accessible at localhost:3000/info. You can create pages by filename, but you can also create a subfolder that will map to subpaths. Another approach to the page above is to create a folder called /info and have a index.js file exporting the same code. This also opens up the option to create other files in the /info folder. If we were to add a new file called contact.js to the /info folder it would map to the path /info/contact.

This works great with static content. What if we want to fetch some data from an api and render it?

Fetching data

NextJS provides different ways of fetching data depending on what type of application or specific page you have. The pages could be exported as static HTML pages, i.e. created at build time, or created on every request. Both ways will serve pre-rendered content and complete HTML files. Along with minimal JavaScript that is only needed to make the page interactive. You might have heard about the term hydration. This is the process of making a static HTML page interactive by applying the JavaScript code served alongside. This is the recommended approach to use, it has advantages on both performance and SEO. Although not being applicable in all situations.

NextJS provides 3 functions that you need to understand to be working with dynamic data.

getServerSideProps
getStaticProps
getStaticPaths

When working with these features I always prefer to work with a real API. There are lots of free API:s to use as a developer. One of my favourites is the Star Wars API (https://swapi.dev/).

Lets create a page that will show a list of Planets from the Star Wars universe. The data for this could be fetched from the API with https://swapi.dev/api/planets. This will return a list of planets with lots of information about each.

Lets create a new folder called /planets inside our pages folder. Inside that folder we create an index.js file.

Lets add the following HTML:

function PlanetsPage({ planets }) {
  return (
    <main>
      <h1>Planets</h1>
      {planets.map((planet) => (
        <div key={planet.name}>
          <h2>{planet.name}</h2>
          <p>Population: {planet.population}</p>
          <p>Terrain: {planet.terrain}</p>
        </div>
      ))}
    </main>
  );
}

This expect props to have an array of planets with name, population and terrain information. Lets get this data from the Star Wars API. For this we use the getServerSideProps function. To get this to work you only have to export a function called getServerSideProps from the page file. Put this above or below the PlanetsPage function.

export async function getServerSideProps() {
  const res = await fetch('https://swapi.dev/api/planets');
  const data = await res.json();

  return { props: { planets: data.results } };
}

Here two things are happening:

Data is being fetched from the example API
An object with a props property is returned from the function

What we return as props will be available as props in the PlanetsPage function. This is magically handled by NextJS.

Now when navigating to localhost:3000/planets you should see a list of planets.

When using getServerSideProps the HTML document will be created on every request. The example data we are working with is very static and is perfect to be statically generated. For this we can use the getStaticProps function. It works the same as getServerSideProps and the only thing we need to do is to replace the function name.

export async function getStaticProps() {
  const res = await fetch('https://swapi.dev/api/planets');
  const data = await res.json();

  return { props: { planets: data.results } };
}

This should work exactly the same as before. The difference is this will create the HTML pages at build time. You can try this out and see for yourself. If you run npm run build with getStaticProps you can see the generated HTML page at .next/server/pages/planets.html. Changing the method to getServerSideProps, deleting the .next folder and run npm run build again. The same HTML file will not be created. Being able to decide what methods to use means you can use statically generated pages on some pages and server side rendered on others. This is a really powerful feature.

Dynamic data

It’s often common to have dynamic paths depending on the content being fetched. A blog post might have a specific slug for example. In this example we want to add a page for a specific planet. We can fetch a planet by adding an id to the path (https://swapi.dev/api/planets/1). In our application we then want to add a path for /planets/1. To achieve this we will create a new page under the planets folder and use the function getStaticPaths. This needs to be in combination with getStaticProps to work.

Create a file called /planets/[id].js. The square bracket notion means a dynamic path.

First add the HTML part that only requires the data for one planet this time.

function PlanetPage({ planet }) {
  return (
    <main>
      <h1>{planet.name}</h1>
      <p>Population: {planet.population}</p>
      <p>Terrain: {planet.terrain}</p>
    </main>
  );
}

Then we add the getStaticProps to get the data for one specific planet. Getting the id from the url. getStaticProps receives a context object from which we can get the params for the current path.

export async function getStaticProps(context) {
  const res = await fetch(`https://swapi.dev/api/planets/${context.params.id}`);
  const data = await res.json();

  return { props: { planet: data } };
}

Then add the getStaticPaths function to generate the pages based on the content:

export async function getStaticPaths() {
  const res = await fetch('https://swapi.dev/api/planets');
  const data = await res.json();

  const paths = data.results.map((planet, i) => ({
    params: {
      id: i.toString(),
    },
  }));

  return {
    paths,
    fallback: true,
  };
}

Here we are fetching all the planets and create an paths list.

getStaticPaths must return an object with a paths array. The array should contain objects that must have a property mapping to the name of the dynamic page. In this case id. The value of id must be a string. For a blog post this could be named slug and the filename be [slug].js etc.

Note: in this case the Star Wars API does not return the id for each entry. Normally you would want to create your pages based on some value for each entry. As the specific planet is fetched by an increasing id we can in this case use the index within the map function. This is not recommended in a real application.

If you run npm run build or yarn build you will get an output with all the pages created. For me it looks something like this:

├ ● /planets (429 ms)
└ ● /planets/[id] (3171 ms)
    ├ /planets/8 (444 ms)
    ├ /planets/5 (436 ms)
    ├ /planets/4 (412 ms)
    ├ /planets/6 (366 ms)
    ├ /planets/1 (327 ms)
    ├ /planets/2 (323 ms)
    ├ /planets/3 (319 ms)
    └ [+3 more paths]

If you start up your application again you can now navigate to /planets/1 and you should see the content for only that planet.

The complete file for the PlanetsPage then looks like this. You can place the exported functions either before or after the page function. I prefer to have them before.

export async function getStaticProps(context) {
  const res = await fetch(`https://swapi.dev/api/planets/${context.params.id}`);
  const data = await res.json();

  return { props: { planet: data } };
}

export async function getStaticPaths() {
  const res = await fetch('https://swapi.dev/api/planets');
  const data = await res.json();

  const paths = data.results.map((planet, i) => ({
    params: {
      id: i.toString(),
    },
  }));

  return {
    paths,
    fallback: false,
  };
}

function PlanetPage({ planet }) {
  return (
    <main>
      <h1>{planet.name}</h1>
      <p>Population: {planet.population}</p>
      <p>Terrain: {planet.terrain}</p>
    </main>
  );
}

export default PlanetPage;

Going forward

This was just a quick introduction to NextJS. We have learned about the concepts of pages and filename routing. How we could fetch data depending on specific situations. I will continue to add more posts about all the other specific features in the future.

To continue working on your application and explore all the other features of NextJS I recommend to start reading their documentation https://nextjs.org/docs/getting-started.

Finding the Right Mindset as a Junior Developer

Rasmus Langvad — Mon, 31 Jan 2022 07:52:24 +0000

As a new developer it can be confusing navigating all the available programming languages, frameworks, do's and don'ts, buzzwords etc. In addition to this you have as many opinions as there are developers. Depending on who you follow, what blogs you read or what teacher you had - your path as a developer is determined by the opinions of those people.

I firmly believe that the most important skills as an aspiring developer is to have an open mind, be willing to try new things and keep learning. Don't get stuck on opinions of others. The phrase "you should start with vanilla JavaScript before even trying out a framework" mindset is dangerous. It's fine to start with a framework. One huge motivation factor is to have fun while making progress. If you find yourself enjoying working in a React application. Don't get thrown off that path because some people say that you are starting in the wrong end. As long as you are building, you are learning.

Solve problems

When learning programming you should not narrow down your thinking to a specific language. Instead think of it as you are solving problems. Programming languages are there for you, to help you solve problems. So what problems are we talking about? In this context you have some kind of goal with what you are building. Say you want to build a website to learn concepts about web development. To achieve that goal you need to solve problems along the way. When setting up your first website you need to start somewhere. It might be confusing by all the available alternatives out there. The important thing here is to start. Wether it's by building a simple indexl.html file or a Vue application for example. Whatever makes you interested in the process and that makes you accomplish something.

Another example of something you might need to solve is triggering an action when a user clicks a button. How will you do that? If you are building the website with Vue for example, you would search for how to add a click event to a button in Vue. Get your answer from Stack Overflow or the Vue documentation and add it to your application. At this point you don't need to understand what the actual click event in Vue are doing. You managed to get something to happen when you clicked the button - problem solved.

When you are comfortable with handling events in Vue you could look them up in detail. But only when you find that interesting enough to investigate. Then you could try and implement the same event without a framework. Both ways of going at this are completely fine. Find your way of solving problems. Have fun along the way.

Going forward. Instead of thinking that you are learning Vue in this case, think of it as you are learning to build a website with the help of the framework Vue. You could also be building the same website with any other framework. Or plain HTML, CSS and JavaScript. Your mission is to build that website. Of course you need to learn Vue to build a website with Vue. But you should think of your learning in a broader perspective.

When reading blog posts or scrolling through Twitter I see that lots of people are recommending to completely learn HTML, CSS and JavaScript before even touching a framework. I do not think this is necessary. Although, at some point in your career you will have to learn the basic concepts, but for a developer starting out you will gain more from continuing with the framework you started with and solve problems. The more you build the more you will learn and in the end will make you grow as a developer.

Must I choose one specific framework?

No, you don't. It could be dangerous to identify yourself as a React developer or a Vue developer. You should identify yourself as a web developer that solve problems.

Although you have to start somewhere. In that sense I think it's preferable to learn one framework to a decent level before learning the next. It's better to be great at React than have basic knowledge of many frameworks. You still need to understand the differences between the frameworks and what problems they are solving. When seeing the languages and frameworks as tools to help you solve problems you can choose the best tool for the problem you are facing.

Learn by doing

You can read multiple books or watch hours of tutorials but the absolute best way to learn is by doing. I can't say this enough. Get started and build something. The more you build the more situations and problems you will encounter. It's by solving those problems that will make you grow as a developer.

When building projects you will also build a portfolio. A platform to both show off your skills and to try new out new things. You will gain a lot from having your own website as a base for this. You will start to have an online presence and have something to show in upcoming interviews. Although I do not think that having an online presence is required at all. If reading Twitter there are many people talking about the importance of online presence. I don’t think that is for everyone. You will probably get some opportunities and meet people that you otherwise wouldn’t. But it can also be very stressful. Focus on building and learning first. And if you are comfortable and willing it could be fun to show other what you are learning.

Another underrated aspect is to take inspiration from others. GitHub is a huge opportunity to learn from the industry. There are so many projects that are open sourced that you can watch and learn from. Find a project that uses the same stack or framework that you're interested in and clone that repo.

Summary

I would like to summarise my rambling above in to 5 bullet points:

Learn by doing
Find your path
Build, build, build
Don't get stuck in other peoples opinions
Have fun

How To Work with Meta Data in Nuxt

Rasmus Langvad — Mon, 29 Mar 2021 10:12:03 +0000

What is meta data?

First let us talk about what meta data is. You can provide information about a html document inside <meta> tags. Meta tags belongs inside the <head> element of a html document. Meta tags could hold information about the following:

Information for the browser on how to render the HTML document
Instructions for search engines on how to interpret and display information
Describe for social media platforms how to display your information when a link is shared

Meta data is not visible on the page. It gets parsed by the browser and search engine crawlers. You can inspect a webpage and look in the <head> tag for all the <meta> tags available on that page. The data inside the meta tags are not hidden in that sense.

Example of meta tags

<head>
    <title>Current title</title>
    <meta charset="UTF-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0" />
    <meta name="description" content="This is my description that could be visible in search engine result pages" />
    <meta name="author" content="Rasmus Langvad" />
</head>

Technically the <title> tag is not a meta tag. It is commonly referred to as meta data and it have an impact on SEO and user experience. So I recommend to treat it that way.

For a complete list of available meta tags I like this list: Complete List of HTML Meta Tags.

What is Open Graph?

Open Graph is a protocol created by Facebook. With the purpose of structure information on links shared on social media platforms. The tags give the author the opportunity to decide what content is shown in the preview when sharing a link. The Open Graph meta tags adds a prefix to the property value with og:. Twitter also have their own tags for setting meta data. Instead of og: they use twitter:. Twitter also uses og tags as a fallback.

An example with og tags

<head>
    <meta property="og:title" content="Current title" />
    <meta property="og:description" content="Custom description. Might be the same as meta description" />
    <meta property="og:image" content="https://langvad.dev/image.jpg" />
    <meta property="og:url" content="https://langvad.dev" />
</head>

An example with Twitter tags

<head>
    <meta name="twitter:card" content="summary" />
    <meta name="twitter:creator" content="@rlangvad" />
    <meta name="twitter:description" content="Custom description. Might be the same as meta description" />
</head>

If you want to know more about the Open Graph and Twitter specific tags and which ones are required and recommended to use, I suggest reading The Essential Meta Tags for Social Media on CSS-Tricks.

How to set meta data in Nuxt

So, now we know what meta tags are and how they are being used to show information about your website. But how do we set the meta data values dynamically for each page? Lets say we have a blog. Like this one. Where we want to show a different title and description based on the current blog post.

In Nuxt you have access to a special property called head. The head property is next to all the other properties in a component. On the same level as data, fetch, methods etc. It can be either an object or a function. I will soon explain the difference. With the head property you can set title and meta data for each page in your application. You can also use head to set everything related to the <head> tag. Meaning you can add stylesheets, script tags, link tags and more. In this article I will focus on the meta data part but it's useful to know the other parts as well.

Using the head property

You can set the data in head from any Vue component. The most common use case is to use head inside your pages components. It's not that common to set the data from a smaller component that are being used on multiple pages. But it is possible. So we have some pages and want to set some meta data. All we need to do is to add the head property and set the data we want. Lets add a title and description.

export default {
    head: {
        title: 'My title',
        meta: [
            {
                hid: 'description',
                name: 'description',
                content: 'My description',
            },
        ],
    },
}

As I mentioned before the title tag is not really a meta tag. Therefor it is being set outside the meta array property. If we take a look at the description property you might wonder what the property hid is. This is something specific for Nuxt and is being used as a unique identifier so the correct property can be overwritten by child components. So if the want to set the description from within a child component we need to use the same hid value.

When setting the meta data as above the values of title and description are not very dynamic. If we want to use static information we can use the object version of the head property. But it we want to set som dynamic data, for example title and description of this blog post, we need to use head as a method. Let me show you how I use head for this blog post.

head() {
    return {
        title: this.article.title,
        meta: [
            {
                hid: 'description',
                name: 'description',
                content: this.article.description,
            },
            {
                hid: 'og:title',
                name: 'og:title',
                content: this.article.title,
            },
            {
                hid: 'og:image',
                property: 'og:image',
                content: `/${this.article.image}`,
            },
            {
                hid: 'og:description',
                property: 'og:description',
                content: this.article.description,
            },
            {
                hid: 'og:url',
                property: 'og:url',
                content: `https://langvad.dev/blog/${this.article.slug}`,
            },
        ],
    }
},

Here I'm using the head as a function that returns an object. I'm setting all the meta data based on information on the current article. Making it more dynamic and unique for each page.

Setting meta data in nuxt.config

You also have access to the head property inside your nuxt.config.js file. Here you can set default values used on every page. Useful if you don't want to duplicate some basic meta data for all pages in your application. You can also use a template for you title. If you want every title on your site to end with for example your site name. You can set this up from here with the titleTemplate property.

head: {
    title: 'My title',
    titleTemplate: '%s - langvad.dev',
    meta: [
        ...
    ]
}

Now every title will end with - langvad.dev. The %s symbol is a placeholder for whatever value is being set as title.

Using the new useMeta helper

Even though Nuxt 3 is not released yet you can use the upcoming new features related to Vue 3. For example the useMeta helper. Check out Nuxt Composion API Module for more information. The useMeta helper can be used within the setup() method. This makes it easier to set dynamic data and more clear on what data is being used. To enable the functionality of useMeta you need to import the helper and set the head property to an empty object. A basic example could look something like this.

import { defineComponent, useMeta } from '@nuxtjs/composition-api'

export default defineComponent({
    head: {},
    setup() {
        useMeta({
            title: 'My title',
            meta: [
                {
                    hid: 'description',
                    name: 'description',
                    content: 'My description',
                },
            ],
        })
    },
})

This is a neat way of setting our meta data. But it doesn't look any different than using it in the head property directly. Which still of course is possible. useMeta is only a helper. If you want to have a more dynamic way of setting the data you could get the variables returned by useMeta.

import { defineComponent, useMeta } from '@nuxtjs/composition-api'

export default defineComponent({
    head: {},
    setup() {
        const { title } = useMeta()
        title.value = 'My title'
    },
})

In this case you can change the value of title within the setup method. Maybe the value is different based on some logic or data being fetched. Instead of initialising useMeta every time we want to change the data we can change the value of the variable title. We could also get the variable meta and apply changes to description and all the meta properties available in the meta array.

What if I want to make changes to the title (or any other meta data) from outside setup? Maybe the title should change based on some user interaction on the page. Our last example makes the title editable within the setup method. But it will not be accessible from our component. To achieve this we need to make a reactive variable and pass it in with a function to useMeta. By returning the reactive variable we can access it from our template and other parts of the component.

<template>
    <div>
        <button @click="title = 'New title'">Change title</button>
        <button @click="title = 'Another new title'">Change title again</button>
    </div>
</template>

<script lang="ts">
import { defineComponent, useMeta, ref } from '@nuxtjs/composition-api'

export default defineComponent({
    head: {},
    setup() {
        const title = ref('')
        useMeta(() => ({ title: title.value }))

        return {
            title,
        }
    },
})
</script>

Summary

Meta data is essential for how your site will look like in the eyes of search engine crawlers, social media platforms and your users. It is important to understand these concepts and how you can work with dynamic data. I hope this article made some concept clear and that you got some inspiration on how to work with meta data within your application. As your application grows there are many ways you can handle meta data in a a more structured way. It is very common to have some kind of meta data helper function. Since the meta data is only a plain object you can have a function that returns the meta object based on some input. This makes it even more dynamic and easier to work with on multiple pages.

Working With Nuxt and Vuex

Rasmus Langvad — Fri, 22 Jan 2021 13:58:31 +0000

In this article I will show you how to get started with Vuex in a Nuxt application. How to set up your first Vuex module and how you can use the store in your components and pages. I will not be going in to details about how Vuex works. I will focus on how to use Vuex within a Nuxt application and how easy it is to get started with.

What is Vuex

The most simple explanation is that Vuex is a state management tool for Vue. It holds a global state that can be accessed and modified within your application. It enables you to work with state in a controlled way and to use conventions like actions and mutations to handle changes to the state.

It is a separate module within the Vue ecosystem maintained by Vue core members and the community.

You do not have to use Vuex in a Vue application but as soon as you need some global state or a centralised place to hold data, it is recommended to use Vuex. If you want to know more about Vuex in detail I recommend you to head over to the Vuex documentation for further reading.

How do I set up Vuex in a Nuxt application

Vuex comes along with Nuxt by default. When scaffolding a new project you might have noticed an empty folder called store. This is where we work with Vuex. It is disabled by default but will be activated as soon as a .js file is created in this folder. Each file in this folder will be converted to a Vuex module. The index.js file will be the root module.

The four building blocks of a Vuex module:

// store/index.js

export const state = () => {}

export const mutations = {}

export const actions = {}

export const getters = {}

Lets say we want a specific Vuex module to handle fruits in our application. Yes lets work with fruits. Why not. It's a great metaphor.

Create a new .js file in the store folder called store/fruits.js and add some methods.

// store/fruits.js

export const state = () => ({
    fruits: [],
})

export const mutations = {
    addFruit(state, fruit) {
        state.fruits.push(fruit)
    },
    removeFruit(state, fruitId) {
        state.fruits = state.fruits.filter((fruit) => fruit.id === fruitId)
    },
}

export const actions = {
    addFruit(context, fruit) {
        const slicedFruit = sliceFruit(fruit)
        context.commit(slicedFruit)
    },
}

export const getters = {
    getApples: (state) => {
        return state.fruits.filter((fruit) => fruit.type === 'Apple')
    },
}

Here we are using both a mutation and an action to handle adding a new fruit. Actions can be used when you want to change the incoming data or make an asynchronous action before committing the data to the store. In this example we are calling a method that will slice the fruit before adding it. In my opinion when having an action that only forwards the data to the mutation, that action can be omitted and you should use the mutation.

We have also created a getter that will filter the list of fruits in the state to only return a list of apples. This is useful since the getter will be reactive. So when the fruit list updates the getter will reflect these changes.

So how are we using this new fresh fruits module in our application?

Working with the Vuex state from pages and components

Using Nuxt context store helper

Accessing the state

Nuxt adds a store property to the context that can be accessed with this.$store in every Vue component. So if we want to display our list of fruits we could do something like this:

<template>
    <ul>
        <li v-for="fruit in fruits" :key="fruit.id">
            {{ fruit.name }} - {{ fruit.type }}
        </li>
    </ul>
</template>

<script>
export default {
    computed: {
        fruits() {
            return this.$store.fruits.state.fruits
        },
    },
}
</script>

Notice that we need to access the state from the module name on the $store property. If we would have added our state to the index file we could have accessed it directly on $store.state.fruits. We're using a computed property to make it reactive.

Using actions and mutations

So how do we use the actions and mutations to add a new fruit? I've hard coded the fruit to be added just for demo purposes.

<script>
export default {
    methods: {
        addFruitFromComponent() {
            const newFruit = {
                name: 'Pink Lady',
                type: 'Apple',
                id: 2,
            }

            // Use dispatch to call an action
            this.$store.dispatch('fruits/addFruit', newFruit)

            // Use commit to call a mutation
            this.$store.commit('fruits/addFruit', newFruit)
        },
    },
}
</script>

The actions and mutations are available directly on the $store property. There are two differents methods to use: dispatch and commit. Dispatch triggers an action and commit is used for mutations. In the example above both will add a new fruit to the fruits list but the action will first call the sliceFruit(...) method. If you need to manipulate, change or validate the data being added, this should be done in the action rather than the mutation method. Or maybe even before being sent to the store at all, but that's another discussion. The important thing to remember is that actions can handle asynchronous calls. While mutations are synchronous and should only be used to update the state.

Using getters

The getter methods works very similar to a computed property. With the difference being accessible globally. Using our getApples getter would look something like this:

<template>
    <ul>
        <li v-for="apple in apples" :key="apple.id">
            {{ apple.name }}
        </li>
    </ul>
</template>

<script>
export default {
    computed: {
        apples() {
            return this.$store.fruits.getters.getApples()
        },
    },
}
</script>

Using Vuex mappers

Vuex also provides mappers that you can use instead of this.$store. For a more detailed explanation on how to use them I once again refer to the Vuex documentation and especially the section for binding helpers.

Taking the same example as above but with binding helpers would look like this:

<template>
    <ul>
        <li v-for="fruit in fruits" :key="fruit.id">
            {{ fruit.name }} - {{ fruit.type }}
        </li>
    </ul>
</template>

<script>
import { mapState } from "vuex";

export default {
  computed: {
        ...mapState('fruits', ['fruits']
  }
}
</script>

Using actions and mutations:

<script>
import { mapActions, mapMutations } from 'vuex'

export default {
    methods: {
        ...mapMutations('fruits', ['removeFruit']),
        ...mapActions('fruits', ['addFruit']),
        handleFruits() {
            const newFruit = {
                name: 'Pink Lady',
                type: 'Apple',
                id: 2,
            }

            // Call action to add fruit
            this.addFruit(newFruit)

            // Call mutation to remove fruit
            this.removeFruit(newFruit.id)
        },
    },
}
</script>

One benefit of using the binding helpers is that you can call the methods with less code. This is extra useful when calling an action or mutation directly in the template.

<!-- With binding helpers -->
<template>
    <button @click="addFruit(fruit)" />
</template>

<!-- With $store helper -->
<template>
    <button @click="$store.addFruit(fruit)" />
</template>

One downside is that it might loose the visual connection to the store. It's not obvious if this.addFruit or addFruit is referring to the store action or a method on the component. Try them out and decide what works best for you. In larger projects you will most likely encounter both ways of doing this. This could be dangerous and I would recommend that you always strive for consistency. Find out how you or your team prefers to do things and apply that in all places.

Using the nuxtServerInit method

Nuxt exposes a specific store action that lets you set a predefined state from the server that synchronizes with the client. This requires that Nuxt runs in universal mode and that the nuxtServerInit action is present in the index.js file.

Example taken directly from the nuxtServerInit documentation.

// store/index.js

export const actions = {
    nuxtServerInit({ commit }, { req }) {
        if (req.session.user) {
            commit('user', req.session.user)
        }
    },
}

Upcoming updates

With the recent release of Vue 3 both Nuxt and Vuex have new major versions around the corner. Although they are not released yet and any breaking changes are not final. But keep in mind that this article focuses on Nuxt 2 in combination with Vuex 3. I will write a new article later on with Nuxt 3 and Vuex 4 in focus. Since great things are coming! But many applications will use these versions for a long time and it's important to understand these concepts as well.

Conclusion

Working with Vuex in a Nuxt application is simple and easy to get started with. It provides module creation based on folder and file structure under the store folder. The context helper property $store is useful when accessing the store from a component. Other than that there is no Nuxt specific ways of working with Vuex compared to a plain Vue application. Nuxt let you quickly get up and running so you can focus on implementation rather than configuration.

Thanks for reading! Please reach out to me if you have any questions or thoughts on this article.

Happy coding!

What Is a Component Library

Rasmus Langvad — Mon, 16 Nov 2020 15:28:35 +0000

In this article I will share my thoughts on what a component library is and the benefits of using a component library. I will not go in to details about creating your own library. But first let's have a look at what we mean when talking about a component. When I'm referring to a component I'm talking about an entity on a web page. The term component is also commonly used when talking about systems and development in general. But here I'm focusing on element that a user can see or interact with in some way.

What is a component

A component is a single element or a group of elements that together creates an entity. A component could be built with html elements or it could be made up of other components. In general a component is not dependent on any framework. But usually you have some sort of logic or properties in a component that can change its style and behaviour. By having components based on a framework, like React or Vue, it makes these interactions easier. If you are working in a Vue application it makes sens to use Vue components. The output of a component created within a framework is always HTML, CSS and JavaScript in the end.

As I mentioned components can also consist of other components. Larger components like these make it more cumbersome to maintain. As one component is dependent on several others, it quickly becomes more complicated. A common approach to structuring components is Atomic Design. The term Atomic Design is coined by Brad Frost, who has a lot of great content written about this. I really recommend you to read about it if you are not familiar with the concept. I've used this structure in many projects. Once you understand the concept it makes it easier to create and manage different hierarchies of components.

What is a component library

When talking about component libraries, you might think of a large project with many developers and designers. Where the mission is to set design standards and principles for a project or company. But, the concept of a component library and its benefits are not based on the size of the application or project. I would say that a small project has as much to gain from a component library as a larger project. A component library is a set of re-usable components. It could be a folder inside your project with common components used throughout the application. It could be a distributed package on npm. It could also be a part of a bigger design system. A component library can be small and it can be large. There are no official rules for what a component library means. It depends on your project and your needs. It can be either components that you created your self or a public library from a big company. There are dozens of public component libraries that you could use and take inspiration from. I list a handful of them in the end.

When to use a component library

If you are using a similar component in two or more different places, I recommend you to create a general component and place it inside a library folder. Then use that component in both places instead. If they need to differ in some way you can set this up with properties or other logic to determine its output.

The most classic example is a regular button. If you have a button on many places in your application it is good practice to use the same component for that button. You get a consistent look and feel to your application and you only have to make updates in one place. This is commonly referred to as the single source of truth.

Another reason to use a component library is if you are not interested in design and just want a component that looks good and does what it should. Then you can use one of the public libraries where you get a design and a battle tested component out of the box.

Benefits of using a Component Library

Single source of truth

One huge benefit of using a component library is that you have a single source of truth for your components. There are no variations implemented in different places. All the html, styling and logic can be found in one place. This makes it easier to share. You can very quickly get up and running with a new project and have access to the components straight away. Changes to a component will be reflected on all of your projects.

Design

When having a single source of truth for the components it's a lot easier to talk to designers and have a common understanding of how things look and feel. You can for example add Storybook to have a common place to display your components. Where you can sit together with designers and stakeholders to discuss changes and new features. It makes it easier to work with design in a more iterative way. It is possible to deliver new versions at a faster pace and easier to try out new things.

Maintenance

By having all your components in one place it makes it easier to maintain. Updating components or adding new features is done once and will be reflected on every implementation of that component. Pushing updates is a lot faster and more consistent. It's also easier for new employees to get a overview of the architecture and what bricks you have to play with.

Working with tests

It is easier to create a well thought out test suite for the components in the library when they are grouped and implemented in one place. The tests become more relevant and important to have. When adding new features it's also easy to use Test Driven Development by created the new tests before implementing the feature. I find it easier to work with Test Driven Development when having this kind of setup. Rather than having the components spread out in the application. It makes your projects more robust.

Common public component libraries

It's easy to create a small set of components. But when starting to work with multiple browsers, accessibility, design for different devices it can start to feel overwhelming. Luckily there are dozens of public component libraries for all frameworks out there. Some follow certain design principles like Material Design. Others are created by individual developers with their own preferences.

I would recommend you to check out and get to know some of the more common design frameworks for components on the web. Most of them have component library implementations for each web framework. This is a good introduction to working with components and component libraries.

List of design frameworks and component libraries that I recommend

5 success factors as a junior developer

Rasmus Langvad — Sun, 08 Nov 2020 21:04:20 +0000

During the last couple of years I've been working with different developers and many of them on a quite junior level. I’ve found some factors and behaviours that all junior developers would benefit from practicing.

Focus on one thing at a time. From time to time you might want to learn everything you hear about at once. This could be quite dangerous to pursue. I’d say you benefit more from focusing on learning one thing at a time - and learn it well. It gets easier if you tie it to your current project or task. Solve the issue in front of you in the best possible way and focus your learning efforts on that.
Ask questions. All the time. Don’t be afraid to ask any kind of question. Always make sure you understand. Do not say that you understand something when you don’t. It will only come back and bite you. Your colleagues and manager are probably more open to helping you than you think in that case. Be curious and ask people in your surroundings for advice and that they explain their solutions.
Learn to handle imposter syndrome. Every developer will sometime during their career have some degree of imposter syndrome. Especially if you are new. When you start to learn new things and new concepts you will realise something that might feel overwhelming. Something that is also my favourite quote related to learning: "the more you know, the more you realize you don’t know”. Try to accept that you will never know everything and that every other developer have been in your shoes. We all have to start somewhere.
Be proud of your work. Celebrate milestones, personal achievements, team efforts, releases etc. Celebrate often and together. Celebrate small and large things. Try to show other colleagues, teams, stakeholders or family members of your work. It will make you feel good and it is always fun to show others what you have been working on.
Take it easy. Don’t rush things. Sometimes you might feel stressed over an important release or that you don’t know how to solve a specific issue. Take it easy and think about what is the worst thing that could happen? It usually isn't that bad. Ask for help and make sure you are solving the issue in a good way that you understand and can explain to others.

Don't forget to Have fun! Really important. You have the best job in the world and your possibilities are endless! Enjoy the ride and watch yourself grow for each year.

How to configure axios in a Nuxt application

Rasmus Langvad — Tue, 27 Oct 2020 20:02:43 +0000

You have probably heard of or used axios in your web applications. Axios is a http client for the browser and node. It makes api requests a lot easier to handle. If you’re working with Nuxt there is an official module that simplifies it even more: @nuxtjs/axios. This is what I will focus on in this article. It assumes you are familiar with Nuxt and have a project setup. I will not go in to details on how to use axios. Here you will learn how to configure axios for your needs in a Nuxt application.

How to install the axios module

In your current Nuxt project run yarn add @nuxtjs/axios or npm install @nuxtjs/axios depending on your setup.

Add @nuxtjs/axios to your modules list in nuxt.config.js.

Axios is now ready to use!

Basic usage

You can now use axios in your components and in any part that have access to the Nuxt context. The module adds axios to the context and is accessible with $axios. You can for example use this.$axios.get(url) or this.$axios.post(url, data) in any .vue file.

Configure with a plugin

One way to configure axios is to create a plugin where you set all the default values. This is the same as creating any other plugin for Nuxt. The code will run before instantiating the root Vue application.

Create a plugin

Create a file in the plugins folder. Name it anything you like but for example axios.js is a common naming convention..
List the file in the plugins list in nuxt.config.js
Done!

Setting up the plugin

Then what should the plugin look like?

export default function ({ $axios, store }, inject) {

    // Add configuration

})

In this article we will only use $axios and store from the context. But here you can extract more configuration objects and application specific setup options. For more information see the Nuxt context guide: https://nuxtjs.org/api/context/.

Some examples of things you could do in this plugin file:

Set a base url for all request
Create new axios instances and inject to the application
Attach a token to every request
Intercept response before using it in the application

Set a base url for all requests

If all requests are targeting the same api, for example the open Star Wars api https://swapi.dev/api/. We can configure the axios instance to have this as a base url. Which means we do not have to configure it in every request we want to make. Just add this in the plugin function:

$axios.setBaseUrl('https://swapi.dev/api/')

Using $axios now will always have this as a base url. Making it possible to make an api call like this:

$axios.get('/people/1')

Create new axios instances and inject to the application

But what if you want to make calls to multiple apis? You can create new instances of axios with any name you prefer and inject it to the application.

Lets say we want to fetch both Star Wars and Pokemon data. We could setup two different axios instances with different base urls.

const starWarsApi = $axios.create()
const pokemonApi = $axios.create()

starWarsApi.setBaseUrl('https://swapi.dev/api')
pokemonApi.setBaseUrl('https://pokeapi.co/api/v2')

inject('starWarsApi', starWarsApi)
inject('pokemonApi', pokemonApi)

Here we use the inject method provided by Nuxt plugins. Inject takes two arguments. The first is the key, the second one is the value. The key will be attached to the Nuxt context and will refer to the value. Nuxt will automatically add a dollar sign to the injected key. To use the axios instances we created and injected you can run:

this.$starWarsApi.get('/people/v1')

this.$pokemonApi.get('/pokemon/snorlax')

This makes it easier to use and more explicit what you are requesting. The custom created axios instances have the exact same helper functions as the orignal $axios instance.

Attach a token to every request

If your api calls requires some kind of token this can also be setup in the plugin file. To set the authorization header on a request we must set it in the option parameter. Lets say for the sake of this example the Star Wars api required authentication. This is one way of achieving this:

this.$starWarsApi.get('/people/1', {
    headers: {
        Authorization: `token ${token}`,
    },
})

his works fine but quickly feels annoying when you need to add this in multiple places. With the @nuxtjs/axios module we can set this is up in the plugin file. If we want to use a Bearer token we could do like this:

const token = '123'
$axios.setToken(token, 'Bearer')

This will add the token to the Authorization header. Usually you have this token in localstorage or the vuex store. I'm used to keep the current user's token in the vuex state. In the plugin function you have access to the store from the Nuxt context. We can then check if the token exists and use it on the axios instances we created.

const token = store.state.currentUser.token
starWarsApi.setToken(token, 'Bearer')
pokemonApi.setToken(token, 'Bearer')

If you use a refresh token or update the current token in any way you can also add setToken where you update the users token. In a component or vuex store module you can for example run:

this.$starWarsApi.setToken(newToken, 'Bearer')

Intercept response before using it in the application

If you want to check the status of the response every time you make a call you can register a global interceptor. @nuxtjs/axios provides helper methods to handle this. Lets say we want to log something specific every time the response status is 404. This could be setup using the onResponse method.

$axios.onResponse((response) => {
    if (response.status === 404) {
        console.log('Oh no it returned a 404')
    }
})

Complete plugin file

To wrap things up the complete plugin file (/plugins/axios.js) with all the configuration mentioned in this article could look something like this:

export default function ({ $axios, store }, inject) {
    const starWarsApi = $axios.create()
    const pokemonApi = $axios.create()

    starWarsApi.setBaseUrl('https://swapi.dev/api')
    pokemonApi.setBaseUrl('https://pokeapi.co/api/v2')

    const token = store.state.currentUser.token
    starWarsApi.setToken(token, 'Bearer')
    pokemonApi.setToken(token, 'Bearer')

    starWarsApi.onResponse((response) => {
        if (response.status === 404) {
            console.log('Oh no it returned a 404')
        }
    })

    inject('starWarsApi', starWarsApi)
    inject('pokemonApi', pokemonApi)
}

This was just a quick glance on what and how you can configure axios for a better developer experience. You can do alot more and you can refactor this code for sure. This was just an example to show what you can do. I hope you found this useful.