Nuxt.js is what comes to mind when we think about server-side rendering (SSR) in Vue. Besides that, it is also a convention-over-configuration style framework which is very extensible. Known for developer experience, it does a wonderful job at abstraction, but as time goes on, we all have reasons and requirements for diving deeper.

For the second time in recent months, I had the requirement to block a page from loading based on a client-side API request.

This may not seem very interesting to a regular Vue developer, who would probably just add a navigation guard to the route in the Vue Router. But in the world of SSR, this is a catch 22 scenario.

A server-side render implies preparing the page on the server, and not just template markup, but executing stages of its lifecycle. All this, before arriving client-side and then some client-side process will need to show a mask and loading spinner, before either allowing the page or redirecting elsewhere. It doesn’t quite fit well together.

Tools of the trade

Before getting to the nuts and bolts, best review what tools that Nuxt provides which could help.

Middlewares are the Nuxt construct which acts as a navigation guard, just like the Vue Router. Nuxt controls the router as part of its abstraction from the intricacies of a universal application (runs on the client or server).

Plugins allow functionality to be executed with the Nuxt context at application bootstrapping. This may be useful as a SSR only occurs at application bootstrapping, we’ll cover some flows below.

Modules can hook into the project build and also many Nuxt hooks. But for our purposes, they don’t offer anything we need that can’t be achieved another way.

Does _serverMiddleware_ provide anything for our use case? This extension point is very useful, but allows functionality to be applied to the Web Server that Nuxt uses, it does not provide any Nuxt context and lives outside and alongside the Nuxt server-side rendering. Short answer, No.

#vuejs #javascript #nuxtjs