Using MirageJS with Nuxt

brattonross — Sun, 01 Mar 2020 13:57:38 +0000

Update 11th March 2020

If you are running Nuxt in universal mode you can still take advantage of Mirage by ensuring that you only make api calls on the client side. If you attempt to make api calls from the server-side then Mirage won't be able to capture them, as it only runs in the browser.

If you don't need to make use of Nuxt's asyncData method and you are just going to make your api calls in a lifecycle hook like created, then you just need to check that your code is running on the client-side first:

async created() {
  if (process.client) {
    const response = await this.$axios.get('/api/stuff')
  }
}

Otherwise, we find ourselves in a bit of a situation. If we want to use asyncData, then the issue we have is that the initial call will be made on the server-side. All subsequent route changes are client-side, so Mirage will work in asyncData on every route change aside from the initial request to our app.

One quick hacky way to get around this is to use the created hook for the initial render, and then asyncData on every other call.

const isDevelopment = process.env.NODE_ENV === 'development'

export default {
  async asyncData({ $axios }) {
    // If we're in development mode and running this 
    // code on the server-side, then return early
    if (isDevelopment && !process.client) {
      return
    }

    const { data } = await $axios.get('/api/stuff')
    return {
      data,
      // Set this so that subsequent calls to the
      // `created` hook don't make the api call
      initialCallDone: true
    }
  },

  data() {
    return {
      initialCallDone: false
    }
  },

  async created() {
    // Only make this api call when we're in development mode,
    // it isn't the initial call to the app,
    // and we're running the code on the client-side
    if (isDevelopment && !this.initialCallDone && process.client) {
      await this.$axios.get('/api/stuff')
    }
  }
}

I recently learnt about MirageJS, a library that helps you build out and test a frontend app without having an api in place. The best thing about this library in my opinion is how it hijacks the browser's network requests, so you can continue using exactly the same code for interacting with Mirage and your real api.

When integrating this into a Nuxt app, I soon stumbled upon some issues. Making an HTTP request that Mirage should have been able to handle would throw a 404:

At this point I was running my app in universal mode, since for my production site I wanted to make use of Nuxt's SSR capabilities. I tried switching Nuxt over to spa mode to see if the issue was caused by using universal mode, and voila! Switching Nuxt to spa mode allows Mirage to work as expected. I'm using the following code to run my app in spa mode during development, but then switching to universal mode for production, where I don't depend on Mirage:

// nuxt.config.js

export default {
  mode: process.env.NODE_ENV === 'development' ? 'spa' : 'universal'
}

There seems to be some underlying conflict between Nuxt and Mirage when running in universal mode. I'm no expert in either of these technologies, so I can't say where the issue lies, but this workaround is suitable for me and perhaps it will help some others too.

Do you need to use the Vue Composition API?

brattonross — Mon, 04 Nov 2019 23:10:10 +0000

If you're keeping up with the Vue ecosystem, you'll likely know that Vue 3 is currently in pre-alpha, and coming with it is the new Composition API. This is a new optional syntax for writing "composition functions" -- functions that can easily be reused between components.

Current ways to reuse code in Vue

Vue 2 supports a few ways to reuse code between components;

Mixins
Renderless components
Higher-order components

These methods of reuse each come with their own drawbacks, namely:

Unclear where component options are coming from (mixins)
Namespace clashes (higher-order components, mixins)
Performance costs (higher-order components, renderless components)

Composition API to the rescue

The Composition API aims to solve these issues by offering a mechanism for logic reuse that doesn't encounter these issues. Re-usable code can be extracted into "composition functions", which any component can then use within the new setup component option.

Unclear component options are no longer an issue because any properties exposed to the template are now returned from an explicit call to a composition function
Namespace clashes are no longer an issue because you can assign any name you like to both the composition functions and their return values
Performance costs are reduced because no unnecessary component instances are created for logic reuse

Do you need to use it?

If we take a look at the issues with the current API that we listed above, we'll notice that these are only prominent in larger projects, which make heavy use of the code reuse patterns. In small to medium size projects, these issues are often not a problem.

The Composition API was built with these large-scale projects in mind, where components get extremely large and contain multiple features that become difficult to reason about.

So do you need to use the Composition API for smaller projects? Probably not. That being said, I do believe that there are some benefits to using it in small to medium size projects, those being readability and type-checking.

The Composition API improves the readability of Vue code by making it obvious where the properties exposed on the template come from. If you want to know where a property comes from you can trace it back to the composition function that declared it in the setup method. You can then scope your focus to the contents of that composition function, making it much easier to reason about what you are reading.

Type inference is another great benefit of the Composition API. Vue 3 is being written in TypeScript, and first-class support for the new API is being added to the Vetur VS Code extension. This will add a nice boost to developer experience, since even JavaScript users will be able to benefit from type-checking.

Closing Thoughts

Personally I am quite a big fan of the Composition API, hence why I am writing about it. I think however that you should not immediately rewrite your app using the new API. If and when you do start to migrate your app, you should definitely take advantage of the fact that the new API is purely additive and is able to be used seamlessly with the current API to slowly migrate parts of your app that suffer from the re-usability issues that the Composition API aims to solve.

What are your thoughts?