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

A primer on investing for designers and developers

In Critical Defense of Frontend Develop

# 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 [Able](https://able.co) as the Frontend Lead of an internal product, before Able I worked at [Vercel](https://vercel.com), a Frontend deployment platform, and [Platzi](https://platzi.com), an education platform with content in Spanish, English and Portuguese.

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 Able as the Frontend Lead of an inte...

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

Ayer el team de React...

¿Qué son Server Components de React y cómo se relacionan con SSR/SSG/ISR?

# 🔥 Pro Tip: Name your useEffect functions

When creating an effect in React, avoid arrow function and instead use a function with a name. This will

1. Show the function name in the stack trace of an error
2. Help you and your team know what this effect does
3. Force you to only use this effect for one concern

```ts
React.useEffect(
  function changeDocumentTitle() {
    const currentTitle = document.title;
    document.title = title;
    return function restoreDocumentTitle() {
      document.title = currentTitle;
    };
  },
  [title]
);
```


When creating an effect in React, avoid arrow function and instead use a function with a name. This wil...

🔥 Pro Tip: Name your useEffect functions

# Using MDX with Remote Content

One of the most common ways to use MDX in a website is to have the `.mdx` files together with the rest of the website code. But this has an issue because now any change you these files will need a full deploy, you can’t just open a CMS, change the content and see it live immediately.

But this shouldn’t need to be a white or black decision, there is a nice and simple way to use MDX from a remote source.

Let’s say our CMS give us some content like this:

```mdx
# This is a note with MDX

<CustomComponent />
```

If we are using Next.js, we will need to install the package [next-mdx-remote](https://github.com/hashicorp/next-mdx-remote).

Then, inside the page we want to use MDX we need to import this

```ts
import renderToString from "next-mdx-remote/render-to-string";
import hydrate from "next-mdx-remote/hydrate";
```

In the page we will use them we need to create a components object with all the components we want to enable in our MDX files. They can be named as the HTML tags and in that case it will be used to render them (e.g. an `h1` component will be used to render the `# This is a note with MDX` heading), if we use other names like our `CustomComponent` it will be available to use as in the MDX example above.

```js
const components = { CustomComponent };
```

Inside our `getStaticProps` or `getServerSideProps` we will fetch our data and use `renderToString`.

```js
async function getStaticProps({ params }) {
  // this is fetchnig from Collected Notes
  const note = await cn.read(CN_SITE_PATH, params.path.join("/"));
  // here we parse the front matter and get the content and data
  const { content, data } = matter(note.body);
  // here is where we parse our content to be usable as MDX
  const body = await renderToString(content, { components });
  // and at the end return our note, frontm atter data and body as props
  return { props: { note, body, data }, revalidate: 1 };
}
```

Then, inside our page component we can use `hydrate` with the body we got as props.

```js
function Article({ note, body, data }) {
  // here we hydrate the body with our components
  const content = hydrate(body, { components });
  // and then we can render it however we want
  return (
    <>
      <Header {...note} {...data} />
      <article>{content}</article>
    </>
  );
}
```

And we are done, we can create our `CustomComponent` inside our codebase and import it. The key part is that the `component` objects need to be the same in both `renderToString` and `hydrate`. If in the future we want to use a new component as part of our MDX content we will need to add it to the codebase and deploy it, which makes sense since this is actual code and not only plain content.

---

I used to have a bunch of `.mdx` files in the repository of my blog, each article was a `.mdx` file with the front matter of the article; after being tired of taking a few minutes per change I wanted to migrate to a CMS, I decided to go with [Collected Notes](https://collectednotes.com) which has Markdown and front matter support, aside of other nice features like a native app for Mac and iPhone which allowed me to write easily and even from my phone.

However, doing this change required me to give up on MDX. Thanks to Tailwind Typography it was not a huge issue, my main reason to use MDX was to render custom styles for the elements.

Thanks to `next-mdx-remote` now I can use Collected Notes as my CMS and still use MDX which is a great way to have the best of both worlds.


One of the most common ways to use MDX in a website is to have the .mdx files together with the rest of the webs...

Using MDX with Remote Content

# Use TailwindCSS Typography with Dark Mode Styles

Since TailwindCSS v2 it comes with dark mode support. Enabling it is really simple, in the `tailwind.config.js` add:

```js
module.exports = {
  darkMode: "media", // or "class"
  // ...more config
}
```

Now, you would be able to use the `dark:` prefix which by default is enabled in all color related classes.

Tailwind Labs team also has a really useful [Typography official plugin](https://tailwindcss.com/docs/typography-plugin) you can use to get a single class `prose` and use it to style content, specially useful when you receive HTML content without classes you can't style.

If you are using it with Dark Mode you will see the colors are probably not visible or are hard to read. This is because the Typography uses white colors.

One nice thing about the Typography plugin is that it's possible to add new variants and even replace the default one. We can use this to create a new `prose-dark` variant where we will only change the colors, let's change our Tailwind config to this one:

```js
module.exports = {
  theme: {
    extend: {
      typography(theme) {
        return {
          dark: {
            css: {
              color: theme("colors.gray.300"),
              '[class~="lead"]': { color: theme("colors.gray.400") },
              a: { color: theme("colors.gray.100") },
              strong: { color: theme("colors.gray.100") },
              "ul > li::before": { backgroundColor: theme("colors.gray.700") },
              hr: { borderColor: theme("colors.gray.800") },
              blockquote: {
                color: theme("colors.gray.100"),
                borderLeftColor: theme("colors.gray.800"),
              },
              h1: { color: theme("colors.gray.100") },
              h2: { color: theme("colors.gray.100") },
              h3: { color: theme("colors.gray.100") },
              h4: { color: theme("colors.gray.100") },
              code: { color: theme("colors.gray.100") },
              "a code": { color: theme("colors.gray.100") },
              pre: {
                color: theme("colors.gray.200"),
                backgroundColor: theme("colors.gray.800"),
              },
              thead: {
                color: theme("colors.gray.100"),
                borderBottomColor: theme("colors.gray.700"),
              },
              "tbody tr": { borderBottomColor: theme("colors.gray.800") },
            },
          },
        };
      },
    },
  },

  variants: {
    extend: { typography: ["dark"] }
  },

  plugins: [require("@tailwindcss/typography")],

  darkMode: "media",
};
```

And now you can use our Tailwind classes like this:

```html
<article class="prose dark:prose-dark">{{ html }}</article>
```

And with this you can use the Typography plugin with light and dark mode. You can also change the colors in the snippet above to customize your theme.

Demo? This website is using it, change between light and dark mode in your computer to see it in practice.

Since TailwindCSS v2 it comes with dark mode support. Enabling it is really simple, in the `tai...

Use TailwindCSS Typography with Dark Mode Styles

---
tags: ui, frontend
---
# The States of the UI

Let's say you are in charge of building the UI of Twitter, how many states do you think that UI could be in? One? Two? Five? Ten?

Usually, we identify at least one state, the **Ideal State**, this is what most users see most of the time, in Twitter it's when you have a list of tweets with their authors and the avatar of each one, and the media included in the tweets (images, links, video, audios, etc.).

Most commonly the next state we tend to identify is the **Loading State**, this is when our application is loading the data or the code (when using code splitting).

If you are lucky enough you have also identified the **Loading Error State** which mean our app can handle a case when something failed to load, this could happen if the user is offline or the server returned an error (4xx or 5xx).

The vast majority of the products stop designing states at this point, then you start the development and realize you need another state, because what happens if the user had no tweets? You need an **Empty Data State** too to show something nice when there are no content, maybe to invite the user to create content.

If our Twitter app has a way to search for a tweet we may found a case where there are no results, this means another state, what we need more is an **Empty Results State** to represent how should the UI look like when there is no content because we couldn't find anything.

Let's continue developing the product, while you are on it you realize you need another state again, because what happens if part of the data has already loaded? Are you going to wait until everything is ready or are you going to start rendering part of the UI? Implementing a **Partially Loaded State** is the best user experience, because why not show the data you already have while you continue fetching more data? As an example once you have a Tweet you can render it while you continue fetching the replies of that tweet (Twitter does this).

Then you continue building your product again, just to ask yourself what happens if the user tweet a short message? Or a long one? Or another with only of emojis? And what about non ASCII characters like Kanji's or accent marks? You need to start thinking in a **Weird Data State**, think all the possible edge cases and design for it, as an example Spanish sentences requiere higher line heights due the accents.

Ok, let's go back to building the product, we are building the form to submit a tweet, then your API returns an error, or the user forgot the write the message, or is offline, what should happen in that case? You need yet another state, I call this the **User Error State**, this is how to show validation error, network errors or API errors, basically error generated after the action of a user, which are usually different than Loading Error State because are limited to an small area and not the whole UI.

The form is working. The user can create the tweet and we show something if an error happens, but the API is not immediate, it will take at least a few milliseconds to confirm the tweet was sent, what should we do meanwhile? You have two options, the ideal one is to implement an Optimistic UI where the UI it updated before the API process the request and it rollback the changes when an error occurs, the other option is to show a **User Action Loading State**, this usually is done showing a spinner or another loading indicator and disable the form until the API returns a response (to avoid duplicated request if it takes too long).

If we go for the optimistic UI we could also have a **Pending Optimistic UI State**, this is something apps like Slack do, they show your message immediately in the chat but with a disabled color (gray-ish) so you know the message has not been sent yet, once the API confirms the success the message change to the normal state.

Ok, we have almost everything, the user load the data, can tweet, can see errors and loading states, let say the user leave the app open for a while without being really using it, what should happen when our app recovers the focus? Because a lot of time has passed we may want to revalidate our Server-State with the API to get the latest tweets, but we should show somehow that we are doing that so the user can expect it, this means yet another UI state! We now need a **Revalidating State**, we could make as iOS and show a little spinner somewhere along the old data to while we finish the revalidation, Twitter load it in background and let you know there is more data, GitHub Mobile use the iOS way and show the spinner and replace the data after it loads.

And with all of this we are finally ready to ship our product, we end up with up to 11 different states our UI can be in, a great designer think about all of them since the beginning, most designers will probably think and 4~5 of them and let the developer figure out the rest or manually ask the designer to create them, a great developer will remember the designers they need to think all of this states.

The final list of states is:

- Ideal State
- Loading State
- Loading Error State
- Empty Data State
- Empty Results State
- Partially Loaded State
- Weird Data State
- User Error State
- User Action Loading State
- Pending Optimistic UI State
- Revalidating State

Let's say you are in charge of building the UI of Twitter, how many states do you think that UI ...

The States of the UI

---
title: What I Use
path: uses
tags: setup, ama, uses
lang: en
---

# What I Use

This is my current development setup.

### Tech Stack

- [TypeScript](https://www.typescriptlang.org/) as my main programming language.
- [React.js](https://reactjs.org) for UI creation.
- [Tailwind](https://tailwindcss.com/) for styling.
- [React Query](https://react-query.tanstack.com) for remote data-fetching.
- [Next.js](https://nextjs.org/) as my framework.
- [Jest](https://jestjs.io/) for unit testing.
- [React Testing Library](https://testing-library.com/react) for React testing.
- [Cypress](https://www.cypress.io/) for integration and E2E testing.
- [Vercel](https://vercel.com/) as my deployment platform.
- [GitHub Action](https://github.com/features/actions) for continuous integration, delivery and deployment pipelines.

### Tools

- [Safari](https://www.apple.com/safari/) as my main browser.
- [Sizzy](https://sizzy.co) as my development browser.
- [Hyper](https://hyper.is/) as my terminal, outside VSCode.
- [GitHub](https://github.com) for my code repositories.
- [GitHub Desktop](https://desktop.github.com) to use Git with a GUI instead of via CLI.
- [GitHub Mobile](https://github.com/mobile) to check GitHub on my phone.

### Editor

I use [VSCode](https://code.visualstudio.com) as my only IDE/code editor.

#### Theme

I use [GitHub Theme](https://marketplace.visualstudio.com/items?itemName=GitHub.github-vscode-theme), I enabled VSCode to switch between light and dark versions of this theme together with the system preferences

#### Plugins

- [Atom Keymap](https://marketplace.visualstudio.com/items?itemName=ms-vscode.atom-keybindings), this change the key bindings (shortcuts) to be the same as the Atom editor, I used this editor in the past which has the same shortcuts as Sublime Text and I prefer their shortcuts.
- [Auto Close Tag](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-close-tag), this automatically add the matching close tag of an HTML/XML/JSX tag.
- [Auto Rename Tag](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag), this let me change the name of an HTML/XML/JSX tag and it will change the closing tag automatically for me.
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker), a basic spellchecker with English and [Spanish](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker-spanish) support.
- [CODEOWNERS](https://marketplace.visualstudio.com/items?itemName=jasonnutter.vscode-codeowners), syntax highlight for [GitHub CODEOWNERS files](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners).
- [CSS-in-JS](https://marketplace.visualstudio.com/items?itemName=paulmolluzzo.convert-css-in-js), autocomplete for CSS in JS code.
- [Docker](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker), autocomplete for `Dockerfile` files and a UI to control my Docker images.
- [DotENV](https://marketplace.visualstudio.com/items?itemName=mikestead.dotenv), syntax highlight for `.env` files.
- [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint), run ESLint directly in VSCode.
- [Git Blame](https://marketplace.visualstudio.com/items?itemName=waderyan.gitblame), show latest person who touched (blame) the line of code I’m currently selecting.
- [Git Project Manager](https://marketplace.visualstudio.com/items?itemName=felipecaputo.git-project-manager), let me use my Git repos inside the configured folders as projects and switch between them with a simple shortcut.
- [GitHub Actions](https://marketplace.visualstudio.com/items?itemName=formulahendry.github-actions), syntax highlight for GitHub Actions files.
- [gitignore](https://marketplace.visualstudio.com/items?itemName=codezombiech.gitignore), syntax highlight for `gitignore` files and some other functions which I don’t really use.
- [GraphQL for VSCode](https://marketplace.visualstudio.com/items?itemName=kumar-harsh.graphql-for-vscode), syntax highlight for GraphQL code (inside `.gql` or `.graphql` files or tagged with a `gql` string literal tag.
- [Import Cost](https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost), shows the size of the imported/required modules.
- [indent-rainbow](https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow), show in different colors the indentation levels before a line of code.
- [Jest Snapshot Language Support](https://marketplace.visualstudio.com/items?itemName=tlent.jest-snapshot-language-support), syntax highlight for Jest Snapshot files.
- [JSDoc Markdown highlighting](https://marketplace.visualstudio.com/items?itemName=bierner.jsdoc-markdown-highlighting), syntax highlight for Markdown inside JSDoc comments.
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare), allow others to connect to my VSCode or allow me to connect to other people VSCode, I use it mostly for Pair Programming.
- [MDX](https://marketplace.visualstudio.com/items?itemName=silvenon.mdx), syntax highlight for MDX code.
- [npm](https://marketplace.visualstudio.com/items?itemName=eg2.vscode-npm-script), autocomplete for common `package.json` keys.
- [npm Intellisense](https://marketplace.visualstudio.com/items?itemName=christian-kohler.npm-intellisense), autocomplete import statements for modules installed with npm/yarn.
- [PostCSS Language Support](https://marketplace.visualstudio.com/items?itemName=csstools.postcss), better CSS syntax highlight with support for custom syntax used with PostCSS.
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode), run Prettier directly in VSCode.
- [Ruby](https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby), syntax highlight for Ruby code and other features.
- [SVG](https://marketplace.visualstudio.com/items?itemName=jock.svg), nice tools to work with SVG code.
- [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss), autocomplete and other features for working with [Tailwind CSS](https://tailwindcss.com).
- [VSCode Ruby](https://marketplace.visualstudio.com/items?itemName=wingrunr21.vscode-ruby), improvement for Ruby language support in VSCode.
- [vscode-styled-components](https://marketplace.visualstudio.com/items?itemName=jpoissonnier.vscode-styled-components), syntax highlight and autocomplete for [styled-components](https://github.com/styled-components/styled-components).
- [vscode-styled-jsx](https://marketplace.visualstudio.com/items?itemName=blanu.vscode-styled-jsx), syntax highlight and autocomplete for [styled-jsx](https://github.com/vercel/styled-jsx).

### Prettier

For Prettier I don't like to customize it. The point of Prettier is to stop paying bikeshedding about code style.

### ESLint

I use a few plugins, with their recommended configuration, I don't like to spend too much time thinking about this and I don't like too strict rules, most of the rules I enable are to follow best practices or avoid common mistakes.

- [eslint-plugin-react-hooks](https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks), to enforce the [Rules of Hooks](https://reactjs.org/docs/hooks-rules.html), I use it extending `react-hooks/recommended` to have their recommended config.
- [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier), to let ESLint uses the same code style rules as Prettier, I use it extending `plugin:prettier/recommended` to have their recommended config.
- [eslint-plugin-unicorn](https://github.com/sindresorhus/eslint-plugin-unicorn), lots of rules to help avoid some errors, I use it extending `plugin:unicorn/recommended` to have their recommended config.
- [eslint-plugin-testing-library](https://github.com/testing-library/eslint-plugin-testing-library), some helpful rules to follow best practices of Testing Library, I use it extending ``plugin:testing-library/react` to have their recommended config for React.
- [eslint-plugin-cypress](https://github.com/cypress-io/eslint-plugin-cypress), some helpful ruls to avoid common errors when using Cypress, I use it extending `plugin:cypress/recommended` to have their recommended config.
- [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin), some rules to write better TS code, I use it extending `plugin:@typescript-eslint/recommended ` to have their recommended config.
- [eslint-plugin-import](https://github.com/benmosher/eslint-plugin-import), some rules related to imports, I use rules below:
  - `import/no-unresolved`: avoid importing modules that can't be resolved.
  - `import/no-anonymous-default-export`, avoid using export default with anonymous functions, classes and values.
  - `import/resolver`: configure how to resolve imports (required to support absolute paths)

I also use the next rules from ESLint (no plugins required)

- `yoda`, avoid conditions like `"red" === color` and instead force `color === "red"`.
- `func-style`, force a certain way to define functions (except inline functions), I use with to force `declaration` style, this forbids arrow functions for anything except inline functions.


@sergiodxa

Latest Articles