DEV Community: Dan Calderon

🚀 React 19 Cheat Sheet

Dan Calderon — Mon, 09 Dec 2024 20:00:01 +0000

After several months we finally have a stable version of React 19.

This post is just a small cheat sheet for context, for more in-depth data and examples, please check
react docs
vercel docs

⚙️ Client and Server Markers

'use client': Marks client-side React code.
'use server': Marks server-side functions callable by the client.

 'use server'
  export async function fetchUserData() { /*...*/ }

Keep in mind: All components are server components by default, and using 'use server' doesn't convert a component or enforce it to be a server component

🔥 React Server Components

What it is: Server-rendered components that execute at build time or per request.

Why?: Makes server-side rendering (SSR) workflows faster and scalable, leading to better app performance.

✨ Actions

What it is: Async functions to handle form submission, errors, and optimistic updates.

Why ?: Simplifies handling complex form logic while creating smoother and more user-friendly experiences.

You have 2 ways to create a server action

Create them in a dedicated file where you call. the use server and import it in the server component

Create them directly at the server component

📋 Form Management Hooks

useFormStatus: Tracks the status of a form for enhanced usability when JavaScript is disabled.

useOptimistic: Implements optimistic updates for a faster and more seamless user experience.

🐛 Better Error Reporting

What it is: Adds onCaughtError and onUncaughtError for root components.

Why ?: Makes debugging easier with clear.

🌟 New Hooks and Features

use: Lets you read promises or other resources directly during render; can be called within loops, conditional statements, and early returns

useDeferredValue Initial Value: Adds support for setting initial values.

🛠️ Async Script Support

What it is: Allows async scripts to be rendered anywhere in your component tree.
Why ?: Prevents duplicate scripts and speeds up loading.

<script async src="https://example.com/script.js" />

💡 Improved Third-Party Script Compatibility

What it is: Skip unexpected <head> or <body> tags during hydration.
Why?: Fixes those mismatch errors when working with third-party scripts.

🎨 Stylesheets with Precedence

What it is: Lets you control stylesheet loading order in concurrent rendering.

Why ?: Ensures styles are applied as intended.

<link rel="stylesheet" href="default.css" precedence="default" />
<link rel="stylesheet" href="specific.css" precedence="high" />

🎯 Streamlined APIs

Streamlined Context API: Use <Context> directly instead of <Context.Provider>.

<UserContext value="Jane Doe">
  {children}
</UserContext>

Ref Callback Cleanup: Ref callbacks now return cleanup functions.

 <input ref={(ref) => () => console.log('Cleaning up 🧹')} />

💡 Hydration Error Diffs

What it is: Improve the difference hydratation errors making it easier to debug and actually fix them.

React 19 introduces several new API and workflows that potentially coudl benefit your applications, but all of them are optionals, so don't feel the presure to rush into them and convert all your components, you can do it component by component and step by step.

There are still a lot of things to improve and change, the waterfall issues related to the server actions and the suspense is one of the more popular, but the list is big, so hopefully the react team will implement some changes and updates here.

By "Linter/Formatter" do you mean Eslint/Prettier?

Dan Calderon — Mon, 13 May 2024 19:23:16 +0000

When I met some of the devs who would work with me on a new project, I asked them some small questions to be aware of their preference, experiences, and backgrounds.

They were mostly frontend developers with 2-4 years of experience, all of them worked with different stacks and had a good knowledge of the architecture and stack that I had in mind for the new project, but when I asked one of the more small and trivial questions, I got more questions than answers

What formatter and linter do you prefer?
By "Formatter and linter" do you mean Eslin/Prettier? 🤔

This was a valid counter-question since most of us always install eslint/prettier no matter the project or product, and never stop to think about other options.

This was a new project so I asked them if they wanted to try Biome as our new linter/formatter, and all of them agreed under the promise of "faster deploys" or an easy way back

Biome as an alternative to Eslint/Prettier

Biome -formerly known as Rome- is a library that intends to replace, or at least, compete with Eslint and Prettier, merging both functionalities in a single tool.

It is a tool built in Rust that could lint and format Javascript, Typescript, and CSS.

Biome pros💪

Simpler configuration
It can be run without project installation
Faster to lint and faster to format the supported languages
Easier way to share the configuration between teams
Smaller packages
A single tool to deliver the same functionality
Migration from eslint/prettier to biome can be done with a simple script in a couple of minutes

Biome Cons💔

Not all the rules are supported or documented
It is a new tool and has a smaller community
It only supports a few languages at the moment, but the team is pushing to include more and they are working speedily.

And that's all, the cons seem pretty small when we compare them against the cons 🤩

Configuration 🔧

We can configure Biome with or without previous eslint/prettier settings

we just need to

pnpm add --save-dev --save-exact @biomejs/biome

or we can even avoid the installation and use the Vscode extension.

Biome will use the default configuration and rules for us.

We can create a biome.json where we would store the configuration and rules

//biome.json

{
  "linter": {
    "enabled": true,
    "rules": {
      "recommended": true
    }
  }
}

and that's all that Biome requires to run the configuration, it will detect the path in the root of our project and run the linter for us.

But what if we already have some prettier/eslint configuration that we don't want to lose?

Well, that would be as easy as running a simple migration script provided for the biome team and available to use if we already installed the tool in our system

biome migrate eslint --write
biome migrate prettier --write

This script will read the prettier/eslint .json files and parse the rules into biome rules for us, even the rules from eslint pluggings that we are extending in the eslint.json configuration.

once that script is finished, we are set and done, we now use biome in our project

Run on save💻

If we are using vscode, we would just need to disable eslint/prettier extensions, be sure to install and enable biome extension, and then just go to the type of file that you want to enable biome, do ⇧⌘P search the "Format document with" > Configure default formatter > select biome

This will set biome as our formatter for the type of file, allowing us to just use it where we want

We can add to the vscode settings

"editor.formatOnSave": true,

and we are ready to run biome for use on save, and you would probably notice the time difference immediately

What about Github actions?🚀

Well, that is also covered in an easy way

Just go to your .github/workflows directory and add the pull_request.yml

name: Code quality

on:
  push:
  pull_request:

jobs:
  quality:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v4
      - name: Setup Biome
        uses: biomejs/setup-biome@v2
        with:
          version: latest
      - name: Run Biome
        run: biome ci --config-path 'configuration path in the project' 'what files should format/lint'

In our case, we probably want something like this

biome ci --config-path './' './src/'

This would use the configuration in the root of our project and run biome in all the supported files inside the /src directory

In our project, we tested the build in GitHub with eslint/prettier vs biome, and it went from 7 minutes to 1/2 minutes🤯🤯

Maybe 5 minutes doesn't sound that much, but when you add them for every pull request and every update on those pull requests, it starts to sound a little higher.

And when you think about the automation tool times -cypress in our case- and how much money we could save reducing the times of linting and formatting, those 5 minutes started to sound even better

So, yeah, not only the team is using biome at the moment, but now we are all aware of what is a linter/formatter and why is it important to have alternatives in each aspect of our application build process as developers.