We are used to certain ways of reusing code. Usually it happens through libraries and components with strictly defined APIs but sometimes thats not enough. Sometimes we want to reuse our whole codebase in a way that lets us adjust it to a special event like Black Friday or just make a slightly different version of our website for a specific country. In cases like that, we usually have very different needs, and being limited by previously defined extension points could make such tasks painful or even impossible.

Being able to automatically inherit all “standard”, unchanged files from a single source of truth and only adding what we want to change when making a new version of our website could drastically reduce the amount of maintained code. In this article, I will show you how to make all of that possible in Nuxt.js in a relatively simple way.

Taking inspiration from Nuxt itself

What makes Nuxt awesome and unique are out of the box features it comes with like file-based routing or Server Side Rendering. Have you ever wondered why these features doesn’t require you to write any additional code?

Most of the libraries deliver it’s features by exposing a third-party code you need to include into your app. The library is exposing a set of functions and objects that are considered its public API:

import { multiply } from 'fancy-math-library'
multiply(2,2) // 4 

Nuxt works a little bit different though. It takes advantage of having full control over the build process to hide the underlying complexity from its users.

Under the hood Nuxt is building new files on the fly based on directories like pages, components, plugins, etc. along with app configuration from nuxt.config.js. They are generated in the .nuxt folder.

Thanks to this approach you don’t see and interact with a very complex code that is responsible for functionalities that are heavily utilized by framework internals like server-side rendering, routing etc. You can influence how they work only through abstractions like file names in page folder. Because of that Nuxt can output more optimized code and avoid unnecessary breaking changes.

This is what happens when you change a single line of code in one of your Nuxt project files:

1. .nuxt folder is flushed
2. files inside .nuxt folder are recreated
3. webpack HMR updates the changed part on the UI

So Nuxt is doing its own transformations, enrichments and merging of your files before standard webpack build is taking care of them. We will use the same strategy to solve our theme inheritance task.

What we have to do?

To make our inheritance mechanism work we will need 3 folders

• base theme - one that we will inherit from
• new theme where we will put files that should override ones from base directory
• target code which will be used as a final directory that merges new and base directories. It will be our equivalent of .nuxt directory.

 ---| node_modules/
 ---| nuxt.config.js
 ---| package.json
 ---| assets/
 ---| base/
 ---| components/
 ---| layouts/
 ---| middleware/
 ---| new/
 ---| pages/
 ---| target/
 ---| plugins/
 ---| static/

Now when you think for a moment the inheriting itself turns out to be pretty straightforward:

1. First we have to copy files from base theme to target directory.
2. Then we have to copy files from new theme to target and override the ones that has conflicting names.

…and thats it! That’s all you need to have a simple inheritance in place.

Of course it’s a poor developer experience because we will need to run the copying script every time we change something but don’t worry - in a few minutes we will try to make it better!

For now - lets keeps things simple.

#tutorials #nuxt.js #nuxt