Last week, I shared my plan to develop a new micro SaaS. I built an MVP using a SaaS boilerplate and quickly realized I need my own SaaS starter kit! That's what I'm working on now — a kit to help me (and potentially others) quickly spin up new SaaS projects. Once it's ready, I'm planning to offer it for sale too. Stay tuned!
👉🏻 This post explore the challenges of icon rendering, the evolution of icon solutions, and how Nuxt Icon combines the best aspects of these methods to offer a seamless experience for developers.
👉🏻 This DejaVue episode covers the Nuxt Security Module.
👉🏻 They also discuss how to avoid common security mistakes as a Vue developer and how to protect your applications from vulnerabilities, and which are the most common ones.
👉🏻 A simple Nuxt module that works on the edge to easily validate incoming webhooks from different services.
💡 Nuxt Tip: When to Use useState
Nuxt provides the useStateuseState composable, which creates a reactive and SSR-friendly shared state. It's an SSR-friendly alternative to the refref function from Vue 3.
You might be confused when to use useStateuseState or refref in your Nuxt app. Let me try to answer this question.
Problem with ref using SSR
Let's take a look at a simple example where we use the refref function to create a shared state in a Nuxt app:
The problem with this code is that the refref function is not SSR-friendly. The code inside the script setup block will be executed on the server and the client. This means that the createRandomStringcreateRandomString function will be executed twice, and we will get different random strings on the server and the client. As a result, we see a flickering effect when the page is loaded, and we get hydration mismatch warnings in the console.
Try it yourself in the following StackBlitz project. Open it in a new tab and check the console for hydration mismatch warnings. If you reload the page, you will see that the random strings are different on the server and the client. First you see the server-rendered random strings and then the client-rendered random strings after the page is hydrated:
The useStateuseState composable from Nuxt solves exactly that problem. It creates a reactive and SSR-friendly shared state. The state is shared between the server and the client, and the useState composable ensures that the state is only created once.
Let's take a look at the same example using the useStateuseState composable:
Try it yourself in the following StackBlitz project, and you will see that the random strings are the same on the server and the client. There are no hydration mismatch warnings in the console:
