Imagining native skip links

Rails design patterns - The big picture

Before You memo()

Implement a Skip Link for Navigation-Heavy Sites

Meaningful Motion with Action-Driven Animation

An Interactive Guide to CSS Transitions

Preload: What Is It Good For?

The unreasonable effectiveness of simple HTML

Open Peeps

System Design 101

# Force a locale in Rails I18n from the params

If you want to change the local used for internationalization a single time from the params of the URL you need to use the `with_locale` method.

```ruby
message = I18n.with_local params[:locale] do
  I18n.t("key.to.message")
end
```

Now your `message` will be in the locale received from the params of the URL, if it was not defined it would fallback to the default locale configured in your application.

If you want to change the local used for internationalization a single time from the params of the ...

Force a locale in Rails I18n from the params

# Que es un bundler de JS

Para entender esto es un poco útil que aprendan como funcionaban las dependencias antes, hace mucho tiempo atrás (unos 6 años más o menos) para usar librerías en frontend tenías dos opciones, o te bajabas el código normalmente a una carpeta llamada vendors y subías eso con tu código o cargabas la librería desde un CDN, esto era muy común en la época de jQuery, una vez tenías la URL del CDN o de tu carpeta vendors agregabas un script en tu HTML antes del script de tu código

```html
<script src="url a un cdn de tu librería"></script>
<script src="url a /vendors/tu-librería.js"></script>
<script src="url de tu código que require de las librerías anteriores"></script>
```

El problema de esto es que

1. Todo se carga de forma global, si tu librería se llamaba inputMask entonces ninguna otra función en tu código u otra librería podía usar inputMask como nombre
2. Mantener esta lista de librerías se podía volver super complejo mientras iba creciendo, algunos sitios tenían 15 o 20 scrips de librerías
3. La carga de la página se veía afectada ya que era necesario cargar varios archivos antes de poder ejecutar tu código JS, en esa época no existía HTTP/2 y HTTP/1 solo permitía 5 requests a tu servidor a la vez

Debido a esto se agregaron sistemas de módulos a JS, en Frontend se usaba algo llamado Require.js, era una librería que cargabas una vez y luego usabas:

```js
require([path1, path2]), (lib1, lib2) => /* tu código acá */)
```

De esta forma podías cargar librerías dinámicamente, una librería podía usar Require.js para cargar más dependencias de un CDN y vos ni enterado, el problema de Require.js es que esto generaba un efecto cascada donde tu código importaba dos librerías y cada una luego importaba otras y así, pero hasta que tu código no terminaba de importar las primeras dos, Require.js no sabía que necesitaba más entonces tenía que esperar para poder cargar todas.

Justo al mismo tiempo en Node.js se usaba Common.js con la sintaxis `const lib = require("lib")`, y Node además tenía npm.

npm te permitía bajar dependencias de un registro (registry) único y las bajaba a la carpeta `node_modules` (el nombre viene porque era para Node.js originalmente).

Un tipo inventó entonces una herramienta llamada Browserify la cual te permitía pasarle un archivo `.js` de tu computadora el cual usara Common.js como sistema de módulos, lo que hacía la librería era ver que otros archivos `.js` de tu computadora o `node_modules` eran importados por tu archivo principal y cuales eras las dependencias de estos, así hasta terminar de leer todos los archivos, luego los juntaba en un único archivo y lo guardaba en tu computadora, esto se conoce como crear un bundle o paquete, este bundle tenía todo el código de tu app, luego este archivo lo subías a tu sitio web y en tu HTML lo cargabas con una etiqueta `<script>` y listo, el archivo ya tenía todo el código necesario.

Con el tiempo salió ECMAScript 2015 (o 6 como se le decía al principio) y este traía un sistema de módulos con la sintaxis `import lib from "path"` que es la que se usa ahora, nuevas herramientas como Babel convertían esta sintaxis al equivalente en Common.js (básicamente cambiar `import` por `const` y `from "path"` por `= require("path")`) y así podías usar Browserify como antes.

Pasó más el tiempo y salieron nuevas herramientas a reemplazar Browserify, una de estas, webpack se volvió super popular y básicamente devoró todo el mercado de bundlers ya que permitía importar imágenes, CSS, archivos en formatos como SASS, videos, audios, etc. directamente en tu código JS, los optimizaba al hacer el build (el proceso de bundle) y te daba la URL como resultado, lo que te dejaba hacer `import logo from "./logo.png"` y obtener una URL que podías usar en un tag `<img>`.

En la actualizad, herramientas como Create React App, Next.js, Gatsby, Vite, Vue CLI, etc. usan cosas como webpack y Babel internamente pero te las abstraen para que no tengas que usarlas y configurarlas vos mismo, lo que no solo te hace la vida mucho más fácil sino que te va a dar un resultado mucho mejor al poder aplicar optimizaciones a tu bundle que capaz no sabías que existían o que necesitabas o como configurar.

Mi recomendación es que no te molestes en aprender mucho webpack, entendé que es y listo, algún día capaz lo necesites, mientras usá estar herramientas.

Si no estas usando algún framework en específico existe Parcel.js el cual te permite pasarle un archivo HTML y busca que CSS y JS son cargados usando `<link>` y `<script>` y los optimiza y hace el build para generar el JS y CSS final, todo eso incluyendo el HTML actualizado te lo deja en una carpeta y esa carpeta la podés subir a GitHub Pages o algún otro servidor de archivos estáticos (Netlify, Vercel, etc.).


Para entender esto es un poco útil que aprendan como funcionaban las dependencias antes, hace mucho tiempo atrás (unos 6...

Que es un bundler de JS

# Remix vs Next.js Comparison

## Static Site Generation

Next.js has built-in support for SSG using the `getStaticProps` and `getStaticPaths` methods in a page module.

Remix doesn't support SSG, you could however run your Remix app and use something like Puppeteer to prerender the HTML and server that. However you may want to double check if you really want to do SSG and if so maybe try another tool like Next.js.

## Incremental Static Regeneration

Next.js has built-in support for ISR using the `revalidate` attribute in the result of `getStaticProps` and `fallback` in `getStaticPaths`.

Remix doesn't support ISR, but due the lack of support for SSG it's not necessary. 

## Server Side Rendering

Next.js has built-in support for SSR using the getServerSideProps method or the old getInitialProps method in a page module.

Remix also has built-in support for this using the loader function in a route module. Remix always do SSR even if you are not defining a loader.

## API Routes

Next.js has built-in support to define API routes by creating a function inside the `pages/api` directoy exporting a Node.js HTTP request listener.

Remix doesn't support yet API-only routes, however because Remix is just a route inside your server you can easily add any custom route you want to your server depending on what you are using as your server.

## Forms

Next.js doesn't come with some built-in utility to handle forms, you need to either manually point to an API route or use Fetch to do a POST/PUT/PATCH/DELETE request againts an API route.

Remix comes with built-in support to handle forms, a route module can export an action function which will receive any non GET request against that route, this will be used by forms doing a non GET submit.

Remix also has a useful Form component you can use as a drop-in replacement for the form HTML tag and it will change the submit to be done via Fetch instead of reloading the page, when using this component you can use non POST and GET methods.

Remix also has a useSubmit hook useful to submit your form programatically and correctly call your action via Fetch. This hook is useful when you need to call the action outside a form submit, e.g. after keystroke or in an interval.

## Router

Next.js comes with a built-in custom router which uses the file system to define routes. It also has an API used to navigate your app programatically.

Remix also uses your file system to define your routes, however since it's built on top of React Router v6 it let you define your routes in a custom way and you can also use all the React Router hooks and components in your application.

## Cookies

Next.js doesn't come with built-in support for working with cookies, there are popular libraries in the community thought.

Remix has built-in support to work with cookies using the `createCookie` function provided by the framework.

## Sessions

Next.js doesn't come with built-in support for working with sessions, there are popular libraries in the community thought.

Remix has built-in support to work with sessions using cookies, the file system, the server memory, or a custom storage. The latest one lets you use your database or something like Redis to store your session.

## Adapters

Next.js uses the Node.js HTTP Request and Response interfaces, when using the serverless deployment it expects the platform to support this or the user manually transform the platform request/response interface to the expected by Next.js. There are popular libraries in the community thought.

Remix uses the Fetch API Request and Response interfaces and it comes with built-in adapters to some deployment platforms, with an Express adapter useful to deploy it to any platform supporting Node.js deployments. For serverless it supports Vercel and Architect for AWS Lambda.

## Disabling JavaScript

Next.js doesn't has stable support for disabling runtime JavaScript in a specific page, it only has a prefixed unstable API.

Remix lets you control if you want to add or note runtime JavaScript in your routes and has a documented approach to control it in a per route basis.

## Link, Meta and other `<head>` tags

Next.js lets you add content to your page `<head>` by using the `next/head` component to wrap what you want to render there.

Remix lets you export a links and meta functions on any route module and return a list of links/metas to add a simple array of plain objects. It also has documentation on how to use PostCSS, TailwindCSS and any CSS in JS which doesn't require Babel. This functions will access your route data got in a loader function as a way to use it to define the content.

## Styling

Next.js comes with styled-jsx as a default CSS in JS solution and has support for importing global CSS and CSS Modules.

Remix doesn't come with built-in support for any CSS in JS solution or another styling technique. It has support to import CSS files and it provides a unique hashed URL. This URLs can be returned from the links function in route module to load that specific stylesheet.

## Page and Data Preload

Next.js automatically prefetch the runtime JavaScript required of any page linked in the current page using the `next/link` component. You can manually disable this in a per link basis.

Remix doesn't preload anything automatically, but it lets you return a list of assets to preload in the links function of any route module. Along the usual link with the `rel="preload"` you can add there a an object with the property `page` and a URL, then Remix will preload the runtime JavaScript and other assets that page will need, it's also possible to define `data: true` and then Remix will preload the data for the page along the assets for instant page navigation.

Remix also has support for client-side only blocking navigation assets, this lets you define which assets you are adding as links you want to ensure they are loaded by the user browser before completing the navigation to that page. This way you can block the navigation to a route until images or another asset is completely loaded.

## Nested Layouts

Next.js has a special `_app` page you can use to wrap your whole application in a consistent layout, if you want to add more nested layouts you need to either render the layout on each page manually and implement some logic to add it form the `_app` page based on some condition. Community documented approaches exists.

Remix has built-in support for nested layouts, any route created inside a folder will be nested inside a route with the same name as folder in the parent folder. This is thanks to the power of React Router.

## Internationalized Routing

Next.js has built-in support for internationalized routing and can use popular libraries for content i18n.

Remix doesn't has built-in support for internationalized routing, however thank to the possibility to completely replace file system routing with something custom it's possible to add it.

## Image Optimization

Next.js has built-in automatic image optimization support when using the `next/image` component.

Remix lets you import images and get a URL back or use the `img:` prefix in the import path and get the image URL and perform some simple transformation, algo get multiple URLs to use in `srcset`, a placeholder URL and change the quality.

## Error Handling

Next.js lets you define some special pages for 500, 404 and any error, then renders that in case of an error.

Remix lets you export an ErrorBoundary component inside any route module which will handle any error of that specific route. If a route is nested it will only handle errors on that part, the parent route will continue to work.

## Live Reload vs Fash Refresh

Next.js has support for React Fash Refresh wich will update your components as you save files without reloading the whole page and losing UI state.

Remix has support to enable Live Reload (not enabled by default) which will reload the page as you save files. This will cause the UI state to be lost but will allow you to easily see updates on loaders.

## Zero Config

Next.js is zero config by default, you can still customize the webpack and Babel if needed, together with other parts of the internal stack.

Remix is also zero config by default, it comes with everything you need to run it after installing it.

## TypeScript Support

Both, Next.js and Remix has built-in support for TypeScript without any special setup.

## Environment Variables

Next.js comes with `.env` support out of the box, it also has a convention to prefix environment variables you want to expose to the client-side code. There's additionally a way to avoid the convention and manually expose a variable.

Remix comes with `.env` support out of the box too, but it only expose `process.env.NODE_ENV` to the client-side code, it has a guide in the docs on their recommended approach to expose environment variables to the client.

## Automatic Polyfilling

Next.js automatically polyfill `fetch`, `Object.assign` and `URL` in servers so you can use it inside API routes, getStaticProps, getStaticPaths and getServerSideProps.

Remix automatically polyfill `fetch` in the server so you can use it inside your loaders and actions.

## Google's AMP

Next.js has out of the box support for AMP, you can enable it in a per page basis.

Remix doesn't come with any special support for AMP.

Static Site Generation

Next.js has built-in support for SSG using the getStaticProps and getStaticPaths meth...

Remix vs Next.js Comparison

# Add missing `created_at` and `updated_at` columns in Rails

If, like me, you forgot to add the `t.timestamps` when creating a new table, you may want to add them in the future, however, most likely you already have data there.

To add those columns you can create a new migration and run this code in the `change` method

```rb
add_timestamps(:table_name)
```

This may work if you don't have data, but if you already have rows in your table you want to add a default value, one option is do do

```rb
add_timestamps(:notifications, default: DateTime.now)
```

The problem with this is that you are now storing the datetime value in your databaoption thisas a fixed value, so new rows will use this fixed value, to solve this problem change it to:

```rb
add_timestamps(:notifications, default: -> { "CURRENT_TIMESTAMP" })
```

This way it will work correctly and for already existent row it will use the timestamp of when you run the migration.

Add missing created_at and updated_at columns in Rails

If, like me, you forgot to add the t.timestamps when creating a new table, you may ...

Add missing `created_at` and `updated_at` columns in Rails

# How to rename a column in a Rails migration

If, for some reason, you need to rename a column in a table you need to create a new migration and run this code:

```rb
rename_column :table, :original_name, :new_name
```

With this, after running the migration your `schema.db` will be updated to have the correct name and you can start using it in your codebase.

If, for some reason, you need to rename a column in a table you need to create a new migration and r...

How to rename a column in a Rails migration

# Usar variables de entorno en Next.js

Las variables de entorno nos permiten configurar como un software se ejecuta dependiendo de la computadora (entorno) donde corre, un uso muy común de estos es definir datos de conexión a una base de datos los cuales van a cambiar si estamos en un entorno de desarrollo (nuestra computadora), uno de testing (CI) o producción.

Next.js tiene integrado soporte para estas variables de varias formas.

## Usando `.env`

Lo primero es crear un archivo `.env`, en este podemos poner cada variable en su propia lína en un formato `KEY=VALUE`.

Cuando iniciamos nuestra aplicación de Next con `next dev` o hacemos build con `next build` este detecta la existencia del archivo `.env` y se encarga de que nuestro código pueda acceder a estas variables a través de `process.env`.

Hay una única regla sin embargo, dado que normalmente las variables de entorno se usan para datos sensibles como contraseñas o tokens de acceso es peligroso que nuestro Frontend pueda, por accidente, exponerlos y debido a que las variables no existen en el navegador la única forma de usarlas es poniendo el valor donde se use, un ejemplo de esto es que este código:

```ts
const token = process.env.TOKEN;
```

Si el TOKEN es igual a `abc123` entonces el código de arriba se convierte en el siguiente:

```ts
const token = "abc123";
```

Para evitar esto, Next te obliga a poner el prefijo `NEXT_PUBLIC_` a todas las variables que querramos leer desde el Frontend, el resto van a ser accesibles sin problemas en `getStaticProps`, `getServerSideProps`, `getStaticPaths` y en las rutas del API.

Para usar nuestro token entonces habría que tener un `.env` con el contenido:

```dotenv
NEXT_PUBLIC_TOKEN=abc123
```

Y luego en nuestro código usar:

```ts
const token = process.env.NEXT_PUBLIC_TOKEN;
```

## Usando `next.config.js`

Si bien con el `.env` vas a tener todo lo que necesites la mayor parte del tiempo, es posible definir variables que no necesiten el prefijo `NEXT_PUBLIC_` para variables públicas.

Para esto creamos un `next.config.js`, si no tenemos uno, y en este exportamos un objeto con la key `env`, esta propiedad debe ser un objeto cuyas keys van a ser variables de entorno, ejemplo:

```js
module.exports = {
  env: {
    TOKEN: "abc123",
  },
};
```

Con esto, ya no estamos atados al prefijo de `NEXT_PUBLIC_`, por lo que tenemos que tener cuidado de no exponer en el Frontend valores sensibles.

## En producción

Cuando estamos en un entorno de producción, y también en uno de testing, lo mejor es no usar un archivo `.env`, este debería ser solo para entornos de desarrollo para evitar definir de forma global nuestras variables de entorno.

Para esto, normalmente las plataformas de hosting como Vercel, Netlify, Heroku, AWS, etc. viene con formas de definir estas variables, lo mejor es buscar como funciona en la plataforma que vayamos a usar y usar eso.

Las variables de entorno nos permiten configurar como un software se ejecuta dependiendo de la computadora ...

Usar variables de entorno en Next.js

# Build your own RSS Reader

RSS is a standard way to use XML to share content from a website so other apps could read it and show it in a different format.

Years ago, Google Reader was the best tool in the market to consume RSS. When Google killed it to promote Google+ (which was also killed) other tools started to compete but most of them are not as good Google Reader was or they are pay ones.

I used Feedly since 2005, until now, I build my own RSS Reader and you can see it clicking Reader in the navigation. Let's see how you can build one yourself and host it for free.

## Stack

The stack I used is the same of this blog, Airtable, Next.js and Vercel.

- Airtable as my DB, I need it to have a list of feeds I can update without re-deploying
- Next.js as the framework to build the UI and fetch data
- Vercel as my hosting platform

## Airtable, the database

First of all, we need a way to store our list of RSS feed, this could be a JSON in the repository or any database, I used Airtable. A simple table with three columns

- `id` as an auto incremental number
- `url` as a string
- `name` as a string

## Next.js, the framework

We need to fetch our list of feeds, I have a function `getRSSFeeds` like this one:

```ts
import Airtable from "airtable";
import { RSSFeed } from "types";

const base = new Airtable({
  apiKey: process.env.AIRTABLE_API_KEY,
}).base(process.env.AIRTABLE_BASE);

export async function getRSSFeeds(limit = 100): Promise<RSSFeed[]> {
  const table = base("feeds") as Airtable.Table<RSSFeed>;

  const records = await table.select({ maxRecords: limit }).firstPage();

  return records.map((record) => record.fields);
}
```

The `RSSFeed` type has this shape:

```ts
type RSSFeed = {
  id: number;
  url: string;
  name: string;
};
```

---

In the `pages/reader/index.tsx` file I have a super short getStaticProps function.

```ts
import { GetStaticProps } from "next";
import { ReaderProps } from "types";
import { ReaderLayout } from "layouts/reader";
import { getRSSFeeds } from "utils/get-rss-feeds";

export const getStaticProps: GetStaticProps<ReaderProps> = async () => {
  const feeds = await getRSSFeeds();
  return { props: { feeds }, revalidate: 1 };
};

export default ReaderLayout;
```

The `ReaderProps` type has this shape:

```ts
type ReaderProps = { feeds: RSSFeed[] };
```

As we can see it's basically two lines of code. Note how `revalidate` is defined, this enables the incremental regeneration behavior of Next.js for this page, with this if a new feed is added to the Airtable database there is no need to deploy, the page will update itself in background the next time someone access it.

You may notice our `ReaderLayout` we export. This has the UI, you can do whatever you can, if you like the one I built for myself [check it on GitHub](https://github.com/sergiodxa/personal-site/blob/master/src/layouts/reader.tsx).

---

Now that we have our list of feeds we can create a page for each individual feed, we can create one in `pages/reader/[feed].tsx`, here we need to define a `getStaticProps` and a `getStaticPaths` methods.

```ts
import { GetStaticProps, GetStaticPaths } from "next";
import Parser from "rss-parser";
import { FeedPageProps, FeedPageQuery, Feed } from "types";
import { FeedLayout } from "layouts/feed";
import { getRSSFeeds } from "utils/get-rss-feeds";

export const getStaticProps: GetStaticProps<
  FeedPageProps,
  FeedPageQuery
> = async ({ params }) => {
  const id = Number(params.feed);
  const parser = new Parser();
  const feeds = await getRSSFeeds();
  const { url, name } = feeds.find((feed) => feed.id === id);
  const res = await fetch(url);
  const rss = await res.text();
  const feed = ((await parser.parseString(rss)) as unknown) as Feed;
  return { props: { feed, id, name, url }, revalidate: 1 };
};

export const getStaticPaths: GetStaticPaths<FeedPageQuery> = async () => {
  const feeds = await getRSSFeeds();

  const paths = feeds.map((feed) => {
    return { params: { feed: feed.id.toString() } };
  });

  return { paths, fallback: "blocking" };
};

export default FeedLayout;
```

Here we need to import the `rss-parser` lib which will let us read a string with RSS in XML and return an object with the data from the feed. The code for this is in the `getStaticProps` function.

In the `getStaticPaths` we call `getRSSFeeds` and transform the list of feeds from the Airtable DB to the list of paths. We also enable `fallback` as blocking which means if a user access a feed we didn't considered initially in our list of paths we will do SSR and then cache the HTML and continue with SSG.

The `FeedPageProps`, `FeedPageQuery` and `Feed` types have this shapes:

```ts
type FeedPageProps = {
  id: RSSFeed["id"];
  url: RSSFeed["url"];
  name: RSSFeed["name"];
  feed: Feed;
};

type FeedPageQuery = { feed: string };

type Feed = {
  title: string;
  description: string;
  lastBuildDate: string;
  items: Array<{
    guid: string;
    title: string;
    link: string;
    content: string;
    contentSnippet: string;
    isoDate: string;
    pubDate: string;
  }>;
};
```

And as with the `ReaderLayout`, the exported `FeedLayout` is the UI of each individal feed. You can see the code for the one in my blog [on GitHub too](https://github.com/sergiodxa/personal-site/blob/master/src/layouts/feed.tsx).

### Vercel, the hosting platform

Lastly, we can deploy our site to Vercel, go to [Vercel project importer](https://vercel.com/new) import your GitHub repository.

Vercel will give you free hosting with a small limit of server functions, thank to using `getStaticProps` for everything our RSS reader will not be counted and we can have any number of feeds.

RSS is a standard way to use XML to share content from a website so other apps could read it and show it in a differen...

Build your own RSS Reader

# Keep Heading Levels Consistent with React Context

When building for the web one of the most common elements are the heading tags (`h1` to `h6`) which are intended to define as the name implies the heading of each section of your web. In a document-like website (e.g. a blog) is not too hard to keep consistency and use them in the correct order, mostly because they are static pages. However, when building an application-like website (or WebApp) it becomes harder, specially when you are using a component system to build your UI.

Nevertheless, keeping consistency in your heading levels is important for the accesibility of your app to help visually impaired users navigate your app and understand it.

The hardest part I have found is to know what heading level to use. Is this card an h3 or h4? What about this other one? This is even harder if your UI components can be used in different parts and with different nesting levels, in which case you need to increase the heading level.

> tl;dr see the code https://codesandbox.io/s/keep-heading-levels-consistent-with-react-context-90bud

## A Heading component

One thing you can do first is to create a Heading component which abstract you this, something like this one:

```tsx
type HeadingProps = React.HTMLAttributes<HTMLHeadingElement> & {
  level: 1 | 2 | 3 | 4 | 5 | 6;
};

function Heading({ level, ...props }: HeadingProps) {
  // We use createElement directyl so we don't need to define each possible tag based on the level
  return React.createElement(`h${level}`, props);
}
```

And then we could use it with

```tsx
<Heading level={1}>Timeline</Heading>
```

## More than 6 levels

You probably know the heading level go from 1 to 6, as we defined above, however it's possible to use higher levels thank to the ARIA attributes, let's update our Heading to support any level.

```tsx
type HeadingProps = React.HTMLAttributes<HTMLHeadingElement> & {
  level: number;
};

function Heading({ level, ...props }: HeadingProps) {
  if (typeof level === "number" && level <= 0) {
    throw new Error(
      "The level of a Heading must be a positive value greater than zero."
    );
  }
  if (level <= 6) return React.createElement(`h${level}`, props);
  return React.createElement("div", {
    ...props,
    role: "heading",
    "aria-level": level,
  });
}
```

And then we could use it with

```tsx
<Heading level={100}>Some super nested title</Heading>
```

While we are using a `div` tag we use the `role` attribute to tell the browser and screen readers that element is actually a heading, then we use the `aria-level` attribute to define the heading level. Doing this we can use any level we want, even 100 as in the example or higher numbers.

## Defining the level automatically

Now we have a component to abstract us the creating of a heading, and support any level. But we didn't solve, yet, our problem of what level to use. Let's solve this.

First we need to know that there is a role called `region`, this is the actual role of a `<section />` if it has a heading inside, so we know that a region has a heading, so we could say a nested region should have a higher heading, right? This way we could create our application as a region with an heading level 1 and more regions inside. Let's build a simple region component.

```tsx
function Region(props: React.HTMLAttributes<HTMLDivElement>) {
  return <section {...props} />;
}
```

> Note: The role is not actually required.

### Enter Context

Context is a way we could inject data from a parent component to a nested component without manually passing props. We could use that to define the level of the heading in the Region and make our Heading get the level and use it. Let's create this Context.

```ts
const HeadingLevelContext = React.createContext<number>(0);
```

This Context will start with a value of `0` which is not a valid heading level, this will let us know we are not using our code correctly because if a Heading receives this level it means it's not inside a Region.

```tsx
function Heading({ level, ...props }: HeadingProps) {
  const headingLevel = React.useContext(HeadingLevelContext);
  if (level === "auto" && headingLevel === 0) {
    throw new Error(
      "To use auto heading levels wrap your Heading in a Region."
    );
  }
  if (typeof level === "number" && level <= 0) {
    throw new Error(
      "The level of a Heading must be a positive value greater than zero."
    );
  }
  if (level <= 6) return React.createElement(`h${level}`, props);
  return React.createElement("div", {
    ...props,
    role: "heading",
    "aria-level": level,
  });
}
```

However, in some cases we may want to overwrite the heading level, so let's support that too.

```tsx
type HeadingProps = React.HTMLAttributes<HTMLHeadingElement> & {
  level?: number | "auto";
};

function Heading({ level = "auto", ...props }: HeadingProps) {
  const headingLevel = React.useContext(HeadingLevelContext);
  if (level === "auto" && headingLevel === 0) {
    throw new Error(
      "To use auto heading levels wrap your Heading in a Region."
    );
  }
  if (typeof level === "number" && level <= 0) {
    throw new Error(
      "The level of a Heading must be a positive value greater than zero."
    );
  }
  const actualLevel = level === "auto" ? headingLevel : level;
  if (actualLevel <= 6) return React.createElement(`h${actualLevel}`, props);
  return React.createElement("div", {
    ...props,
    role: "heading",
    "aria-level": actualLevel,
  });
}
```

With the changes we did, the default level is `"auto"` which means or Heading component will try to get the level from our Context, and in that case it must be greater than zero.

The next step is to render the Provider of our Context in the Region.

```tsx
function Region(props: React.HTMLAttributes<HTMLDivElement>) {
  return (
    <HeadingLevelContext.Provider value={1}>
      <section {...props} />
    </HeadingLevelContext.Provider>
  );
}
```

With this the Heading components inside our Region components will have a level of one, which is not great, we want to support nested, right? What we could do is to read the level from Context inside the Region too, this way we could get the current level and increase it by one, so if it's zero it will be one, if it's one it will be two, etc.

```tsx
function Region(props: React.HTMLAttributes<HTMLDivElement>) {
  const headingLevel = React.useContext(HeadingLevelContext);
  const nextLevel = headingLevel + 1;
  return (
    <HeadingLevelContext.Provider value={nextLevel}>
      <section {...props} />
    </HeadingLevelContext.Provider>
  );
}
```

This will work because our default value in Context is zero.

Another improvement we could do is to ensure we have our Region and our Heading correctly linked, we can do that with the attribute `aria-labelledby` which receives the ID of the element used as label. In our case the Region is labelled by the Heading. So let's receive an ID in the Region and use it as `aria-labelledby`.

```tsx
function Region({ id, ...props }: React.HTMLAttributes<HTMLDivElement>) {
  const headingLevel = React.useContext(HeadingLevelContext);
  const nextLevel = headingLevel + 1;
  return (
    <HeadingLevelContext.Provider value={nextLevel}>
      <section {...props} aria-labelledby={id} />
    </HeadingLevelContext.Provider>
  );
}
```

And we could use them all together with.

```tsx
<Region id="timeline">
  <Heading id="timeline">Timeline</Heading>
</Region>
```

And it will render the following HTML

```html
<section aria-labelledby="timeline">
  <h1 id="timeline">Timeline</h1>
</section>
```

### Automatic ID Generation

Manually defining an ID is another error prone task, we may duplicate the ID, so let's support automatic generation, we could build our own generator or use a lib, let's use Reach UI Auto ID utility which generate ID's for you.

```tsx
import { useId } from "@reach/auto-id";

const HeadingIdContext = React.createContext<string | undefined>(undefined);

function Region({ id, ...props }: React.HTMLAttributes<HTMLDivElement>) {
  const internalId = useId(id); // We use the received ID to overwrite it
  const headingLevel = React.useContext(HeadingLevelContext);
  const nextLevel = headingLevel + 1;
  return (
    <HeadingIdContext.Provider value={internalId}>
      <HeadingLevelContext.Provider value={nextLevel}>
        <section {...props} aria-labelledby={internalId} />
      </HeadingLevelContext.Provider>
    </HeadingIdContext.Provider>
  );
}

type HeadingProps = React.HTMLAttributes<HTMLHeadingElement> & {
  level?: number | "auto";
};

function Heading({ level = "auto", ...props }: HeadingProps) {
  const id = React.useContext(HeadingIdContext);
  const headingLevel = React.useContext(HeadingLevelContext);

  if (id !== undefined && props.id !== undefined && id !== props.id) {
    // We need to ensure if we pass an ID to the Heading we must pass the same ID to the parent Region
    // If we don't do this the ID and labelledby will not match
    throw new Error(
      "When wrapping a Heading in a Region, ensure you provide the same `id` to both components."
    );
  }

  if (level === "auto" && headingLevel === 0) {
    throw new Error(
      "To use auto heading levels wrap your Heading in a Region."
    );
  }

  if (typeof level === "number" && level <= 0) {
    throw new Error(
      "The level of a Heading must be a positive value greater than zero."
    );
  }

  if (actualLevel <= 6) return React.createElement(`h${actualLevel}`, props);

  if (actualLevel <= 6) {
    return React.createElement(`h${actualLevel}`, {
      ...props,
      id: id ?? props.id,
    });
  }

  return React.createElement("div", {
    ...props,
    id: id ?? props.id,
    role: "heading",
    "aria-level": actualLevel,
  });
}
```

With this, we can now pass an ID to both Region and Heading to use a custom one, we could even pass it only to the Region and this one will propagate it to the Heading inside.

[Check a running demo in CodeSandbox.](https://codesandbox.io/s/keep-heading-levels-consistent-with-react-context-90bud)


When building for the web one of the most common elements are the heading tags (h1 to h6) ...

Keep Heading Levels Consistent with React Context

# About

![A photo of me](https://photos.collectednotes.com/photos/55/ebdece0b-40ee-4452-ad24-6e96064c2695)

Hi there! I'm a web developer currently based on Lima, Perú.

I'm currently working in [Silverback Ventures](https://silverback.ventures) as the web developer for our product, before I worked at [Able](https://able.co), [Vercel](https://vercel.com), and [Platzi](https://platzi.com).

I have also taught Web Development at Platzi and [Codeable](https://codeable.la), a full-stack development bootcamp created by Able to teach our development stack, React and Rails. At Codeable I created the initial curriculum for Frontend.

A photo of me

Hi there! I'm a web developer currently based on Lima, Perú.

I'm currently working in Silverback Ventures as the web devel...

About

---
tags: twitter, react, ssr, ssg, isr, csr
---
# ¿Qué son Server Components de React y cómo se relacionan con SSR/SSG/ISR?

Ayer el team de React anunció un nuevo feature, super, experimental, voy a intentar explicar de que trata, pero primero vamos a definir algunos conceptos para estar todos en la misma, CSR, SSR, SSG y ISR

Client-side Rendering (CSR) es la forma normal de usar React, hacemos un bundle de JS con nuestros componentes, React, ReactDOM, hacemos render y listo, todo funciona en el navegador. Todo el HTML se genera ahí mismo

Server-side Rendering (SSR) es tomar estos mismo componentes de React y hacer render en el servidor al recibir una petición, este render genera un string de HTML que se envia al navegador para que lo muestre, después se carga el JS y se hace CSR como siempre

Static Site Generation (SSG) es hacer lo que hace SSR pero al momento de hacer el build de la app en vez de que cada petición, esto esta bueno para evitar montar un servidor, pero es posible solo si el contenido es público y más o menos estático (ej. blog, e-commerce, landings)

Incremental Static Regeneration (ISR) es hacer SSG, pero manteniendo un servidor corriendo que pueda, cada tanto, hacer SSR, esto permite tener el performance de SSG con la capacidad de actualización de SSR, que con SSG requeriría un nuevo build (usualmente asociado a un deploy)

Con esto explicado, los nuevos Server Component que anunciaron no tiene nada que ver con todo lo anterior, la idea acá no es hacer SSR/SSG/ISR ya que esto siempre se pudo, desde hace varios años, incluso sin Next/Remix/Gatsby. La idea es reducir el bundle de JS

Al crear una app hay muchos componentes que no son totalmente dinámicos, componentes que simplemente reciben algunos props y los renderizan, o hacen un fetch y renderizan esa data y otros componentes capaz más dinámicos

Que hace a un componente dinámico? Por ejemplo tener estados propios o tener efectos. En estos casos el componente necesita ejecutarse en el navegador para poder funcionar. Pero los componentes más estáticos en realidad no lo necesitan

La idea de los Server Component es poder decirle a React "este componente X no es dinámico" y entonces React (el bundler en realidad) va a evitar agregar ese componente a tu bundle de JS, por lo que el usuario ya no descargaría nada del JS de ese componente

¿Cómo hace React entonces para renderizarlo? Cuando React necesite el HTML de este componente va a hacer una petición a un servidor que va a generar una especie de JSON con la respuesta, esta incluye que etiquetas HTML renderizar y si es necesario un componente dinámico

React recibe esta respuesta, que llega como un stream para no esperar a que este completa, y va renderizando, si hay un componente dinámico (aka Client Component) este se renderiza en el navegador, la respuesta incluye también que props debe React pasar a este Client Comoponent

Con esto, el bundle de JS se va a reducir un montón ya que ahora solo se va a enviar React, React DOM y tus Client Component, más las dependencias de estos. Que pasa si un Server Component depende de alguna librería externa? Esta se queda en el servidor y no se suma al bundle

Ahora… Al mover algunos componentes al servidor abre la puerta a usar APIs del servidor que no estaban disponibles en el navegador, un Server Component podría hacer un fetch a un API directo desde el servidor o incluso podría hacer una query directa a la base de datos

Esto nos permitiría crear componentes Client que usen API del navegador y componentes Server que usen API del servidor. El poder leer datos desde el mismo servidor incluso ayudaría a reducir la cascada de peticiones que normalmente ocurre en el navegador

Esto es posible porque una petición de localhost a localhost sería muy rápida, cuestión de ms, en vez del tiempo normal que toma a un navegador comunicarse con un API.

¿Cómo afecta todo esto a SSR/SSG/ISR? En primera instancia no afectaría, simplemente al hacer cualquiera de estos algunos componentes serían Server y otros Client así que tendrían que saber leer el output de los Server Component para generar el HTML y listo, el resto no cambia

Para terminar

- ¿Necesito aprender esto ahora? No, es 100% experimental
- ¿Va a afectarme de alguna forma? No en el corto plazo
- ¿Cómo afecta a frameworks como Next? Next va a soportar esto de forma nativa

@sergiodxa

Latest Articles