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

# 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 [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.

@sergiodxa

Latest Articles