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.
Due to the dynamic nature of JavaScript, some libraries encourage you to extend their default types. An example of that is Vue.js. Its plugins often extend the Vue prototype that's available in every component. How can this best be handled with TypeScript?
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.
Storybook is a great tool for component development. But although it supports many frameworks, it still sometimes gives the appearance of being React-first. For example, the default configuration for Vue.js doesn't have TypeScript support.
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?
When creating my first Vue.js project I configured it for TypeScript support and Jest based unit testing. This might not be the most common setup but it does express my tooling preferences. To no surprise, the first component I wanted to unit test used fetch which meant I also had to use jest-fetch-mock to mock its calls. There were a couple of obstacles on the way to the first working test.
Hippo CMS wasn't designed for web application development. While you could theoretically develop an application as a Hippo component, you would miss a lot of tooling that you are taking for granted today. As an alternative, you could develop a single page application (SPA) using any modern JavaScript framework and then serve the resulting static files (HTML, JS and CSS) from Hippo. In this post I will describe my configuration for developing an application in Vue.js.