Unknown dynamic nested routes in NuxtJS allow you to serve the same page for URLs of varying depths that aren't statically known in advance. They can be based on data in an external data source such as a hierarchy of folders or categories, for example. In such a scenario, you'll need to decide how to handle URLs that don't match the data in the data source. Redirecting to another valid URL can often be a good strategy.
Apollo module for NuxtJS makes GraphQL querying very approachable even to complete GraphQL beginners. However, any query involving a union type will fail. Resolving the issue will require you to learn more about the Apollo client internals.
There are a lot of ways to handle errors in NuxtJS and they are all documented. Despite that, it's sometimes still difficult to determine what options are available in a specific scenario. This post is my attempt at creating an overview to use as a reference in the future.
If you want to share your Vue.js components across multiple projects, you would typically package them into a component library. However, the people behind the Bit platform propose that distributing each component as a separate package is a better approach. I decided to try implementing a basic solution for per-component packaging myself to see what it would take to get it working.
Although Vue CLI has built-in support for building component libraries, there's still some work in creating one, especially if you want it to be TypeScript and SSR compatible.
Vuex store code can be quite verbose, especially with wrappers for type-safety in TypeScript. A lot of that plumbing can be avoided with the vuex-module-decoorators package. There's some extra configuration required to get it working in NuxtJS.
Unlike Angular, Vue.js doesn't have a built-in dependency injection framework and neither has NuxtJS. There's a way to inject members into components with Vue.js and NuxtJS plugins but that's just a small subset of what a real dependency injection framework can do. Of course, nothing is stopping you from using one in your Vue.js or NuxtJS application. InversifyJS is a popular choice in the JavaScript ecosystem.
Even if you select TypeScript and Jest support when creating a new NuxtJS project, it still isn't fully configured for writing tests in TypeScript, let alone for testing components written with JSX syntax. This post describes my journey to a working configuration.
Although both Vue.js and NuxtJS have TypeScript support, it often seems incomplete. For example, there's no compile-time type checking in Vue.js templates. Any errors will only be reported at runtime. Currently, the only way to achieve compile-time type safety is to use render functions with JSX syntax instead.
One of the options for creating a Vuex module in NuxtJS is to create separate state.ts, getters.ts, mutations.ts, and actions.ts files in the module folder. Especially for large modules, this can make the code easier to navigate. However, a very important detail about this approach is mentioned very briefly in the documentation.
The NuxtJS application framework for Vue.js replaces a lot of the low-level configuration through conventions, e.g. routing. But what if you need access to that configuration to implement a certain feature? For example, the vuex-router-sync module watches for route changes to sync the current route with the Vuex state. How could this be done in NuxtJS?