Forem: Daniel Charvát

V-model support without requiring value prop

Daniel Charvát — Fri, 22 Jan 2021 09:08:17 +0000

Have you ever wished to create a component that supports v-model directive, but works without it as well? First things first. If you've tried Vue.js you've probably learned that you can bind variables on inputs. This creates a two-way data binding which syncs the variable and the input's state. All you need to do is to use the v-model directive.

You may also have learned that you can use this directive with any custom component since v-model is just a syntax sugar to cover both ways of the data binding. You can learn more about this here. Hence

<input v-model="searchText">

turns into

<input
  v-bind:value="searchText"
  v-on:input="searchText = $event.target.value"
>

As you can see, in order to implement the support, you have to declare a prop variable called value and emit an event labeled input. And that's it.

However, you will quickly find out that at this point the component indeed supports the v-model directive, but it doesn't work at all without it. That's often undesirable. For instance, imagine you'd like to create a custom search component that includes a text input. Since it's a mere extension of a text input, it's reasonable that it should support v-model. But it is also reasonable that you'd like to be able to use it without it since the input inside would normally work straight away had it been a plain HTML element. Let's tackle this.

Optional v-model support

Let's start by creating a simple search component that will accept value as prop. If the user doesn't provide it, it's initiated to an empty value.

  props: {
    value: {
      type: String,
      default: "",
    },
  },

However, we can't use this prop directly in the input since that would mutate it which is not recommended. To circumvent this problem we'll create a clever computed value that will use the value prop if passed from the parent, or a custom local value otherwise. We'll make use of the extended computed property syntax where one can declare different functions for setter and getter of the computed function.

  data() {
    return {
      localValue: this.value,
    };
  },
  computed: {
    searchValue: {
      get() {
        return this.isValuePropSet() ? this.value : this.localValue;
      },
      set(value) {
        this.$emit("input", value);
        this.localValue = value;
      },
    },
  },
  methods: {
    isValuePropSet() {
      return (
        !!this.$options.propsData && this.$options.propsData.value !== undefined
      );
    },
  },

Let's first take a look at the getter. When retrieving the value, the isValuePropSet() method is invoked. This method returns true when the value prop was set by the parent, not initialized to empty string by the default property. So when it was set from the outside, we'll just return the value property and the component works as if it was implemented as a regular component with v-model support. However, when the value was not set, then the getter returns localValue instead. In the setter the current value is both emitted as an input event and stored in the localValue.

With this pattern, we can bind the clever searchValue computed property to the input as usual

<input v-model="searchValue" />

And that's it. The search component works with v-model attached as well as without it. Check out the example sandbox to see it wholly in action.

Automated Localization: GitLab CI/CD ❤ Localazy

Daniel Charvát — Sat, 09 Jan 2021 10:09:59 +0000

Setup fully automated localization for your project once and forget about all the hassle forever. It’s fun with GitLab's CI/CD!

Why integrate Localazy into the build process?

Localization can be challenging on its own and having to regularly remind developers (or yourself) to include the latest localization version before the release is not going to end up well at one point. With GitLab's powerful CI/CD, you need only to configure it properly once. Afterward, you can peacefully take this off your mind.

Integrate your app with Localazy

Let's suppose that your mobile, desktop, or web app is ready for localization, and strings in the source language are stored in JSON, YAML, iOS' strings, Flutter's ARB, or some other common format.

Sign up to Localazy, create a new app, install the CLI tool, and then create and test your localazy.json configuration. You should be able to upload the source language files and download the localized ones.

The basic configuration could look like this.

{
  "readKey": "your-read-key",
  "writeKey": "your-write-key",

  "upload": {  
    "type": "json",
    "files": "locales/en.json"         
  },

  "download": {
    "files": "locales/${lang}.json"
  }
}

Given that you've filled in your readKey and writeKey, you are already able to manually upload and download strings between your app and Localazy. Let's move on to automating this process.

Setup Secrets

Oftentimes it is desirable to hide secrets away from the repository and Localazy keys are no different. We'll use GitLab's variables for this. In your GitLab project, go to Settings -> CI / CD - > Variables and create two variables called LOCALAZY_WRITE_KEY and LOCALAZY_READ_KEY. The result should look like this.

Automated upload

The GitLab CI/CD is a powerful automation tool with tons of options. If you only need to automate the upload part without any special configuration (such as triggering it only on certain branches or for pull requests), you don't need to know much about it. However, if you're aiming to create complex automation rules, you should check out their documentation.

In the root of your project, create a file called gitlab-ci.yml and paste in the following.

# This is a base template for Gitlab CI / CD 
# that integrates Localazy upload process into your workflow
# For available upload options https://localazy.com/docs/cli/command-line-options

default:
  image:
    name: localazy/cli:latest

# There three ways how to authorize the operations (https://localazy.com/docs/cli/authorization)
# - authorization keys in the configuration file (localazy.json)
# - authorization keys in a separate file (localazy.keys.json)
# - authorization keys provided as command-line arguments
#
# If you wish to keep the writeKey and readKey as secrets, we recommend opting for the third option.
# - In Gitlab, define new environment variables (In project: Settings -> CI / CD - > Variables) 
#   called LOCALAZY_WRITE_KEY and LOCALAZY_READ_KEY.
# - Type in your writeKey and readKey respectively

localazy-upload:
    # For additional CLI options, see https://localazy.com/docs/cli/command-line-options
    script: 
        - localazy upload
          -w $LOCALAZY_WRITE_KEY
          -r $LOCALAZY_READ_KEY

This file will be automatically picked up by GitLab and will trigger a single job called localazy-upload. As you can see, we use -w $LOCALAZY_WRITE_KEY and -r $LOCALAZY_READ_KEY arguments for authorization. With each push to the repository (regardless of the target branch), the upload operation to Localazy will be triggered.

Automated download

The download example here is a bit artificial as normally this would be only one of the jobs that would trigger during the build process of your app. However, it is a good starting point nonetheless.

The configuration is going to be very similar to the upload example. You can naturally put these two jobs into the same gitlab-ci.yml file if you will.

# This is a base template for Gitlab CI / CD 
# that integrates Localazy download process into your workflow
# For available download options https://localazy.com/docs/cli/command-line-options

default:
  image:
    name: localazy/cli:latest

# There three ways how to authorize the operations (https://localazy.com/docs/cli/authorization)
# - authorization keys in the configuration file (localazy.json)
# - authorization keys in a separate file (localazy.keys.json)
# - authorization keys provided as command-line arguments
#
# If you wish to keep the writeKey and readKey as secrets, we recommend opting for the third option.
# - In Gitlab, define new environment variables (In project: Settings -> CI / CD - > Variables) 
#   called LOCALAZY_WRITE_KEY and LOCALAZY_READ_KEY.
# - Type in your writeKey and readKey respectively

localazy-download:
    # For additional CLI options, see https://localazy.com/docs/cli/command-line-options
    script: 
      - localazy download
        -w $LOCALAZY_WRITE_KEY
        -r $LOCALAZY_READ_KEY

As you can see, this job is identical except it triggers download operation instead of upload.
Of course, this example effectively does nothing as files are only downloaded during the CI/CD pipeline, and if we don't use them to produce the release build, they are lost once the pipeline is finished and cleared. The exact build configuration strongly depends on your requirements.

Closing Words

This is only a starter template for GitLab CI/CD. It's quite likely that you do not wish to fire this automation with each push to each branch, but rather only with accepted pull requests to your staging or production branch. If that is the case, see the documentation about only/except. Nonetheless, this is a perfect basic configuration on which you can build further.

How to localize React app with react-i18next and Localazy

Daniel Charvát — Mon, 30 Nov 2020 17:59:38 +0000

Localization is hardly the most favorite part of development for anyone. Regardless of whether it is a web, mobile, or desktop app, it is time-consuming and error-prone. This article will show you that there is a quick and seamless way to integrate localization that does not slow down development. We'll use Localazy and react-i18next.

Localazy is a universal localization management platform that supports a wide variety of frameworks and an even wider range of formats through its CLI. Localazy's most prominent features are a pro-active review process, highly accurate translation memory supported by community-shared translations and non-disturbing, and crystal clear UI which is not bloated with rarely used options. And as I'll show shortly, it works seamlessly with react-i18next. Thanks to that, managing translation strings, even with open-source projects where anybody can contribute (with varying quality), is a piece of cake 🍰.

tldr;

sign up for Localazy,
create an app with English as source language and Use community translations (ShareTM) option enabled,
select React integration option and install Localazy CLI,
install and configure react-18next,
create localazy.json in root and paste in and modify the configuration
create locales folder and in it create en.json. Add any translation key-value pair,
run localazy upload,
in Localazy, add any language. Then review it and accept the suggested phrases,
run localazy download and check locales folder for the new locale,
run the app npm run start

Sign up and app creation

First of all, let's set up a new account on Localazy and create a new application. In this article, we'll use English as the source language, but you can generally choose any other. Make sure that the Use community translations (ShareTM) option is enabled. ShareTM is the highly accurate translation memory I mentioned. Thanks to it, most of the new applications have as much as 50 % of their strings automatically available for translation into 80+ languages.

Proceed to create the app. Afterward, select React on the integration screen. We'll use the powerful CLI tool to manage the upload and download of phrases. Installation is available for Linux, MacOS and Windows. Note the read and write keys in step 2. We'll need it shortly.

Set up React app

If you don't want to follow the step-by-step guide here, you can take a look at the finished repo. Otherwise, stay awhile and listen.

Create a new React project with npx create-react-app react-i18next-example. Once everything is installed, add react-i18next.

npm install react-i18next i18next --save

Now it's time to add integration with Localazy. Create localazy.json in the root folder and paste the following configuration. Use the write and read keys from the step 2 of the integration guide page.

{
    "writeKey": "your-write-key",
    "readKey": "your-read-key",

    "upload": {  
      "type": "json",
      "files": "src/assets/locales/en.json"         
    },

    "download": {
      "files": "src/assets/locales/${lang}.json"
    }
}

Additionally, create src/assets/locales folder and en.json file inside. Since we've set English to be the source language, this file will contain the source phrases for our application. You can fill in any key-value pair you like. I'll add this.

{
    "translation": {
        "hello": "Hello, my friend",
        "stay_awhile_and_listen": "Stay awhile and listen"
    }
}

At this point, the application is ready to have localization managed by Localazy. Before we upload the first bunch of strings, let's prepare a test scenario with react-18next to get it off our plates.

First, create i18n.js in src folder.

import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';

import en from "./assets/locales/en.json"

const resources = {
    en
}

i18n
  .use(initReactI18next)
  .init({
    resources,
    lng: "en",
    interpolation: {
      escapeValue: false
    }
  });


export default i18n;

Then modify index.js.

import React from 'react';
import ReactDOM from 'react-dom';
import './index.css';
import "./i18n"
import App from './App';
import reportWebVitals from './reportWebVitals';

ReactDOM.render(
  <React.StrictMode>
    <App />
  </React.StrictMode>,
  document.getElementById('root')
);

And then App.js

import { useTranslation } from 'react-i18next';

function App() {
  const { t } = useTranslation();
  return (
    <div className="App">
        <h1>{t('hello')}</h1>
        <h2>{t('stay_awhile_and_listen')}</h2>
    </div>
  );
}

export default App;

When you run npm run start, you should see the two English phrases. Nothing fancy so far.

Uploading and downloading phrases

Let's upload the English file to Localazy. From the root folder, run the following command

localazy upload -s

The -s argument stands for simulate. It is a good practice to test out the configuration without uploading anything to assure that nothing unexpected happens (such as some of the key-value pairs are incorrectly matched and override each other). The output should be something along these lines, depending on the CLI version.

Localazy CLI, v1.1.9
Advanced file uploader/downloader for the Localazy translation platform.

Read more information at https://localazy.com/docs/cli

Uploading...
  - deprecate missing: false
  - import as new: false
  - app version: 0
  - groups: (default only)
  - folder: .

Processing files...

./src/assets/locales/en.json
  (file=file.json, lang=inherited, type=json)

Verifying...

Validating...

Done.

Everything worked out well and our English file was matched. This time let's let upload it for real.

localazy upload

Refresh your app page and you should see the English language on the list. Open the Add languages tab and there you find a couple of languages with info about the percentage of automated translations. It is possible that you will see either 50 % or 100 %. The automated matching with ShareTM improves all the time and it's likely that thanks to this article you would have all the phrases automatically translated. How cool is that? 🙂

One way or another, look up Spanish and add it to your app. You'll see there is a review button. Every time ShareTM provides a translation suggestion it will have candidate status. This means that it will be ready for review and any reviewer can either approve it or decline. Go ahead and approve the suggested phrase(s).

In case that the ShareTM did not translate 100 % of phrases, come back to the languages list and notice that the review button now reads translate. Localazy recognizes that there is nothing to review but still something to translate, so it offers you the next most likely action in one click. Translate the other phrase (you may use a suggested phrase on the translation page). This time you do not need to go through the review process since you are a trusted translator as owner by default, so the translation is immediately approved.

It's time to go back to the React project.

localazy download

With this command, you'll download all the newly accepted phrases and newly added languages. In the locales folder, we can see there is newly es.json.

The last thing to be done is to update i18n.js, add the Spanish locale resource file and switch the app's language.

import i18n from 'i18next';
import { initReactI18next } from 'react-i18next';

import en from "./assets/locales/en.json"
import es from "./assets/locales/es.json"

const resources = {
    en,
    es
}

i18n
  .use(initReactI18next)
  .init({
    resources,
    lng: "es",
    interpolation: {
      escapeValue: false, // not needed for react as it escapes by default
    }
  });


export default i18n;

Now when you run the app again, you'll see that the phrases were correctly translated to Spanish.

Closing words

I hope you've enjoyed this short intro into Localazy with react-i18next. If you'd like to get closer to us, join us on Discord.

This article was originally published on Localazy

How to localize Vue.js app with vue-i18n and Localazy

Daniel Charvát — Tue, 27 Oct 2020 15:41:42 +0000

Localization of any type of application, be it a web, mobile or desktop app, can be tedious and irritating. In this article, I'll show you how can you handle that easily with Localazy and vue-18n in a way that you'll spend your time effectively and actually enjoy the localization process.

Localazy is a universal localization management platform that supports a wide variety of frameworks and an even wider range of formats through its CLI. Localazy's most prominent features are a pro-active review process, highly accurate translation memory supported by community-shared translations and non-disturbing, and crystal clear UI which is not bloated with rarely used options. And as I'll show shortly, it works seamlessly with vue-i18n. Thanks to that, managing translation strings, even with open-source projects where anybody can contribute (with varying quality), is a piece of cake 🍰.

tldr;

sign up for Localazy,
create an app with English as source language and Use community translations (ShareTM) option enabled,
select Vue.js integration option and install Localazy CLI,
install and configure vue-i18n
create localazy.json in root and paste in and modify the configuration
create locales folder and in it create en.json. Add any translation key-value pair
run localazy upload,
in Localazy, add any language. Then review it and accept the suggested phrases,
run localazy download and check locales folder for the new locale,
run the app npm run serve

Sign up and app creation

Proceed to create the app. Afterward, select Vue.js on the integration screen. We'll use the powerful CLI tool to manage the upload and download of phrases. Installation is available for Linux, MacOS and Windows. Note the read and write keys in step 2. We'll need it shortly.

Set up Vue project

If you don't want to follow the step-by-step guide here, you can take a look at the finished repo. Otherwise, stay awhile and listen.

Create a new Vue project with vue create vue-i18n-example (if you don't have Vue CLI installed, run npm install -g @vue/cli) and use Vue 2 preset. Once everything is installed, add vue-i18n.

npm install vue-i18n

{
    "writeKey": "your-write-key",
    "readKey": "your-read-key",

    "upload": {  
      "type": "json",
      "files": "src/assets/locales/en.json"         
    },

    "download": {
      "files": "src/assets/locales/${lang}.json"
    }
}

{
  "hello": "Hello, my friend",
  "stay_awhile_and_listen": "Stay awhile and listen"
}

At this point, the application is ready to have localization managed by Localazy. Before we upload the first bunch of strings, let's prepare a test scenario with vue-i18n to get it off our plates.

First modify main.js.

import Vue from 'vue'
import App from './App.vue'
import VueI18n from "vue-i18n";
import en from "../src/assets/locales/en.json";

const messages = {
    en,
}

Vue.use(VueI18n);
const i18n = new VueI18n({
    locale: 'en',
    messages
})


Vue.config.productionTip = false

new Vue({
  i18n,
  render: h => h(App),
}).$mount('#app')

And then App.vue

<template>
  <div id="app">
    <h1>{{$t('hello')}}</h1>
    <h2>{{$t('stay_awhile_and_listen')}}</h2>
  </div>
</template>

<script>

export default {
  name: 'App',
}
</script>

<style>
#app {
  font-family: Avenir, Helvetica, Arial, sans-serif;
  -webkit-font-smoothing: antialiased;
  -moz-osx-font-smoothing: grayscale;
  text-align: center;
  color: #2c3e50;
  margin-top: 60px;
}
</style>

When you run npm run serve, you should see the two English phrases. Nothing fancy so far.

Uploading and downloading phrases

Let's upload the English file to Localazy. From the root folder, run the following command

localazy upload -s

Localazy CLI, v1.1.9
Advanced file uploader/downloader for the Localazy translation platform.

Read more information at https://localazy.com/docs/cli

Uploading...
  - deprecate missing: false
  - import as new: false
  - app version: 0
  - groups: (default only)
  - folder: .

Processing files...

./src/assets/locales/en.json
  (file=file.json, lang=inherited, type=json)

Verifying...

Validating...

Done.

Everything worked out well and our English file was matched. This time let's let upload it for real.

localazy upload

One way or another, look up German and add it to your app. You'll see there is a review button. Every time ShareTM provides a translation suggestion it will have candidate status. This means that it will be ready for review and any reviewer can either approve it or decline. Go ahead and approve the suggested phrase(s).

It's time to go back to the Vue project.

localazy download

With this command, you'll download all the newly accepted phrases and newly added languages. In the locales folder, we can see there is newly de.json.

The last thing to be done is to update main.js and add the German locale resource file.

import Vue from 'vue'
import App from './App.vue'
import VueI18n from "vue-i18n";
import en from "../src/assets/locales/en.json";
import de from "../src/assets/locales/de.json";


const messages = {
    en,
    de
}

Vue.use(VueI18n);
const i18n = new VueI18n({
    locale: 'de',
    messages
})


Vue.config.productionTip = false

new Vue({
  i18n,
  render: h => h(App),
}).$mount('#app')

Now when you run the app again, you'll see that the phrases were correctly translated to German.

Closing words

I hope you've enjoyed this short intro into Localazy with vue-i18n. If you'd like to get closer to us, join us on Discord.

This article was originally published on Localazy

How to pass function to Web Workers

Daniel Charvát — Sun, 11 Oct 2020 08:22:45 +0000

Web Workers allow for something similar to multithread operations that are common in languages such as Java or C++. In front end world, they are tool which is yet to be more frequently used.
That's, in my opinion, mainly due to lack of knowledge about their use cases, misjudgment that most people have fast PCs and modern browsers, and force of habit of sticking to what one knows (I second that). Additionally, there some limitations to their usage, such as the inability to pass functions into them.

Why to use Web Workers

Web worker is a mere script that runs in the background, in another thread, which means that any calculation, however expensive, will not block the UI's thread. That's huge. People hate when websites become slow or even worse, non-responsive. With Web Workers, you can do the heavy lifting in the background while showing the user a loading indicator and letting him or her do whatever else in the meantime.

You may ask when this is useful. We've put this into good use when we worked with a recursive tree structure. We were processing the whole tree with thousands of nodes each time the user interacted with the tree. That included loads of calculations and had we had done all of that in the main thread + render the result at the end, even the most beastly pc sets would have growled about it.

Limitations of Web Workers

Since the Web Workers run in another thread, there are limitations to what it can and cannot do.

It cannot access the DOM directly and you lose direct access to window object.
you cannot rely on a global state within them.
you cannot send in data that cannot be handled by structured clone algorithm

The last has turned out to be the most painful for me. You see, when you have an instance of a Web Worker, you may send in data through postMessage

worker.postMessage({
    string: 'string',
    number: 0,
    array: [],
    ...
});

Those value types above can be handled by the structured cloning. However, you cannot send in functions because they can be neither cloned nor transferred. That was a problem, because we wanted to send in an evaluator for each of the nodes (e.g. whether its name matches a search term), for which we needed a function inside of the worker.

Overcoming the no-functions limitation

There is a simple trick on how to solve this. As any other object or value, and in javascript especially since functions here are First-class citizens, we may define functions within objects and stringify them through JSON.stringify. This transforms the function declaration a bit, so parsing them back requires a bit of effort. Luckily, there's JSONfn plugin that handles it well both ways.

And that's that is required. Now you can declare and object which includes functions for the Web Worker, stringified with JSONfn:

// From main thread
worker.postMessage({
    myFunction: JSONfn.stringify( (arg) => ... )
    payload: ... // any kind of data, let the function decide whether it's useful
});

And reconstructed inside of the Web Worker's script

// inside of worker
self.addEventListener("message", function(e) {
    // `e.data` contains data sent from main thread
    const myFunction = JSONfn.parse(e.data.myFunction);
    myFunction(e.data.payload); // reconstructed and callable
});

As you can see, if we have several functions which need different arguments, we have to be careful. This is similar to an observer pattern in the way commonly implemented in C# for instance, where several observers subscribe to the dispatcher, and when they receive data, the observers have to handle the payload and decide whether they can use that message. Here it is the same. The most scalable option I've found is to have two stable parameters, one for functions and one for their arguments a simply send it both in arrays. Then when the event occurs, send all the arguments to all the functions and let them handle it.

A side note about classes

Be aware that the above-described approach will not work if you use classes. Although from the maintainability and readability perspective it would have made a perfect sense to use classes and typescript interfaces, it is not possible. The stringify method can turn to a string only those values it has access to directly. However, when you define something as a class method, it is attached merely to the object's prototype. It does not directly exist on the object itself.

This article has been originally published on localazy.com.

Sharing asynchronous data between Nuxt.js modules

Daniel Charvát — Wed, 16 Sep 2020 08:07:57 +0000

If you’ve developed some sites in Nuxt.js, there’s a decent chance that you’ve had to asynchronously fetch data during the generation. However, there are often times when several modules such as the internal route module, sitemap module, or the RSS feed module require the same data from the database. Alas, there is no easy way to share the fetched data between the modules as they run in an isolated synchronous order. Or is there?

Behind the Localazy scenes

We've found ourselves in a spot where we generate dozens of dynamic routes and that kind of data has to be used for dynamic routes, sitemap generation and the RSS feed for our blog posts. In truth, it's already quite challenging to generate all the dynamic routes with each website update itself. Since the Nuxt v2.13 there is a crawler option that enables detection of all the reachable dynamic routes by crawling through the statically generated content. However, I've had mixed success with it and doing it manually still seems like a safer option.

I will not go into much detail on how to fetch the data and generate all the dynamic routes. If you would like to know more, join us on Discord and reach out to me. Anyways, once you have the data, the trick to share them lies in having access to the filesystem through fse-extra within the Nuxt modules. So once you fetch the data, you can store them as a JSON file in the distribution folder.

Preparing the data

In our case, we begin in our custom module for data retreival and route generation. One of the final parts of it looks as follows:

const generateRoutes = (tablesToRoutes) => {
  const routes = [];
  Object.entries(tablesToRoutes).forEach((entry) => {
    const table = entry[0];
    entry[1].forEach((route) => {
      routes.push({
        route: table !== '' ? `/${table}/${route.route}` : `/${route.route}`,
        payload: route.payload
      });
    });
  });

  return routes;
};

Essentially, for each entry we resolve the proper route path, not important. The crucial part is this:

payload: route.payload

We're storing the whole object that we've fetched under payload property. The route.payload is manufactured in one of the previous steps.

Once we have this gigantic array of route objects, we can step in into the final Nuxt's generation hook and store it as JSON.

import fse from 'fs-extra'; // comes with Nuxt already

moduleContainer.nuxt.hook('generate:done', async () => {
    await fse.outputJson(`${this.nuxt.options.generate.dir}/routes.json`, routes, {
      spaces: 2,
      EOL: '\n'
    });
});

The above is quite self-explanatory, perhaps except for this.nuxt.options.generate.dir. When you read more about the Nuxt modules, you'll find in which context is the code executed and this is just one of the properties you have access to by default.

Sharing the data

Now when you run npm run generate, you'll find in your distribution folder (dist by default) a file called routes.json. The file contains an array of the data we've fetched in the module, in our case one entry may look like this:

...
{
  "route": "/blog/kotlin-mpp-and-http-with-wininet-api-on-windows",
  "payload": {
    "modified_on": "2020-09-09T12:57:04+00:00",
    "slug": "kotlin-mpp-and-http-with-wininet-api-on-windows",
    "priority": "0.7",
    "changefreq": "monthly",
    ...
  }
},
...

That's everything we need in the other modules, so there is absolutely no need to refetch anything :) Let's show how to utilize this in the commonly used sitemap module.

First, let's modify the config in nuxt.config.js.

  sitemap: {
    path: '/sitemap.xml',
    hostname: 'https://localazy.com',
    sitemaps: [
      {
        path: '/static.xml',
        routes: () => generateSitemap(this.default.generate.dir),
      },
  }

We'll dive into the generateSitemap in a second, but notice the argument first. We'll need to know where to find the JSON file and since we're not creating a module, but only a function to generate routes for the sitemap module, we will not have access to nuxt.options as before. But we have access to it still within nuxt.config.js, so let's just pass the path to the generated folder.

The definition of generateSitemap would vary for everyone, but the important bit are the first lines

import fse from 'fs-extra';

export default async function sitemapRoutes (generateDir) {
  const routesJson = await fse.readJson(`${generateDir}/routes.json`);

  return ...
}

As we know path to the JSON file, it's enough to read it's content. This grants us access to all the data we've prepared in the previously executed module and there is no need to re-fetch anything. This makes the generation considerably faster and puts less load on your database.

Obviously we could repeat this pattern for any other Nuxt module. Needless to say that with every additional module that would require such data, the benefits become even more obvious.

This article has been originally published on localazy.com.