Thanks to Vue's reactivity, it usually does not matter where and when Vuex state is initialized. State can be exposed in components as computed properties, and the page is automatically updated when their values change. However, if a value from the state is used programmatically on the page, Vue reactivity cannot be relied upon to trigger that code when the Vuex state is initialized and the value is ready.
By default, the Apollo GraphQL client caches query responses. When using SSR with data sources that change frequently, this can be a problem. Fortunately, caching can be disabled, but setting this as the default behavior in a NuxtJS application proved more difficult than one would expect.
Although NuxtJS routing is based on the file system, it also supports dynamic routes that are unknown in advance and based on an external data source. Unknown dynamic nested routes even allow this for arbitrary nesting depths. I've already written about using middleware to implement redirects. But what about displaying a 404 page for invalid routes?
Server-side rendering is a great way to make your NuxtJS site more SEO-friendly, as it sends a fully rendered page to the client. However, this doesn't work with libraries that require access to DOM objects like document and window. These can only be used on the client. To ensure that such code is not executed on the server, you can place it in the beforeMount or mounted hooks, which are only triggered on the client. Unfortunately, this is not sufficient for some libraries.
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?