React

# React: Using children instead of dedicated render slots

Using component props to pass data (or `JSX` elements directly) that will later
populate internal UI pieces has been a prevalent pattern in the React community,
trying (probably) to emulate [the better-designed slot approach adopted by
Vue][vue-slots].

For example, imagine we are coding a new `Nav` component for our site. It will
render a collection of nav items, the page title, and a call to action link.
Each page might customize any of these elements.

Not surprisingly, I think either of these two would be the most popular examples
we might find out there (or a combination of both):

```jsx
// Passing simple data structures with the desired data
<Nav
  cta={{ text: "Buy the book!", href: "https://url.to/buy-my-book" }}
  menuItems={[
    { text: "Home", href: "/home" },
    { text: "About", href: "/about" },
    { text: "Contact", href: "/contact" },
  ]}
  title="My Site"
/>

// Passing JSX elements directly
<Nav
  cta={<a href="https://url.to/buy-my-book">Buy the book!</a>}
  menuItems={
    <>
      <li>
        <a href="/home">Home</a>
      </li>

      <li>
        <a href="/about">About</a>
      </li>

      <li>
        <a href="/contact">Contact</a>
      </li>
    </>
  }
  title={<h1>My Site</h1>}
/>
```

Even in such as simple example, we can start seeing some of the problems with
this approach: it creeps the component API with render props, it is not very
idiomatic, and it can quickly get worse as we continue adding some more
customization for each element. For example, we may later add specific props to
styling each of the items, title, and call-to-action components:
`menuItemStyle`, `titleStyle`, `ctaStyle`, and so on:

```jsx
<Nav
  cta={{ text: "Buy the book!", href: "https://url.to/buy-my-book" }}
  ctaStyle={{ color: "red" }}
  ctaOnClick={() => alert("Thanks for buying the book!")}
  menuItems={[
    { text: "Home", href: "/home" },
    { text: "About", href: "/about" },
    { text: "Contact", href: "/contact" },
  ]}
  menuItemStyle={{ color: "blue" }}
  onMenuItemClick={(href) => alert(`Navigating to ${href}`)}
  title="My Site"
  titleStyle={{ color: "green" }}
/>
```

Let’s try a different approach. One that resembles how HTML works and that is
supported out-of-the-box by React.

## Using `children` and dedicated components

```jsx
<Nav>
  <Nav.Title>My Site</Nav.Title>

  <Nav.Menu>
    <Nav.Menu.Item href="/">Home</Nav.Menu.Item>
    <Nav.Menu.Item href="/about">About</Nav.Menu.Item>
    <Nav.Menu.Item href="/contact">Contact</Nav.Menu.Item>
  </Nav.Menu>

  <Nav.CallToAction href="https://url.to/buy-my-book">
    Buy the book!
  </Nav.CallToAction>
</Nav>
```

If you have done some React development, you probably know the `children` prop
is how React passes content down to components (for example `<p>Hola</p>`, where
`p` is the component, and `Hola` is the value of the `children` prop).

The example above uses `children` and composition extensively to render the
desired UI. Instead of passing multiple props to the `Nav` component, we create
many small, dedicated components which may of course receive their own props.

As a result, this approach gives us a much more flexible and idiomatic API. If
we later need to add additional elements to the `Nav` component, we can do so
without changing the `Nav` component at all (following the [Open-Closed design
principle][open-closed]).

On the other hand, using this technique comes with some drawbacks worth
mentioning:

- We have to make it clear that these dedicated components are only meant to be
  used as children of the `Nav` component. We can do this by using the `Nav`
  namespace, for example: `Nav.Title`, `Nav.Menu`, and `Nav.CallToAction`.
- We must ensure the `Nav` component is flexible enough to handle the different
  cases we might want to render. For example, if we want to make it possible to
  render the `Nav.Menu` component either after or before the `Nav.CallToAction`
  component, the styles should be sufficiently sophisticated to handle both
  cases.

### Possible implementation

Pay attention to how we export the `Nav` component and its dedicated components.
That’s the secret sauce to namespace them and make it clear they are only meant
to be used as children of the `Nav` component.

```jsx
const Nav = ({ children }) => {
  return <nav>{children}</nav>;
};

const CallToAction = ({ children, href }) => {
  return <a href={href}>{children}</a>;
};

const Menu = ({ children }) => {
  return <ul>{children}</ul>;
};

const MenuItem = ({ children, href }) => {
  return (
    <li>
      <a href={href}>{children}</a>
    </li>
  );
};

const Title = ({ children }) => {
  return <h1>{children}</h1>;
};

Menu.Item = MenuItem;

Nav.CallToAction = CallToAction;
Nav.Menu = Menu;
Nav.Title = Title;

export { Nav };
```

## Notes

- A few weeks after starting to write this post, I received a newsletter from
  [Kent C. Dodds][kentcdodds] featuring a React article. Coincidentally, the
  content of [the post][soul-crushing-components] covered precisely this! So,
  digging a little more, I found this pattern had been documented since a few
  years ago (watch out [this video talk][talk] from Ryan Florence at _Phoenix
  ReactJS Conf_ in 2017), and it is called **_Compound components_**.
- [Radix UI][radix] uses this pattern extensively.
- If you’re curious, I used this pattern to build the whole landing page for my
  tddworkshop.com page. You can check the source code [here][tddworkshop].

Happy hacking!

[vue-slots]: https://vuejs.org/guide/components/slots.html#named-slots
[open-closed]: https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle
[tddworkshop]:
  https://github.com/codecoolture/tddworkshop.com/blob/trunk/pages/en/index.tsx
[radix]: https://www.radix-ui.com/
[kentcdodds]: https://kentcdodds.com/
[soul-crushing-components]: https://epicreact.dev/soul-crushing-components/
[talk]: https://www.youtube.com/watch?v=hEGg-3pIHlE


React: Using children instead of dedicated render slots

# Adding an RSS feed to a Next.js site

Really Simple Syndication (**RSS**) has been a pretty popular format for
syndicating and publishing content on the web. Still, platforms don’t usually
provide an out-of-the-box solution to adopt it.

For Next.js projects, specifically, I’m sure there are probably thousands of
articles explaining how to do it (and probably a handful of `npm` packages,
too!), but in this post, I will try to outline my own approach to this problem
to add [RSS capabilities for this very same blog](/feed.xml).

## How to build the RSS feed

The only thing I didn’t want to do was study the
[RSS](https://validator.w3.org/feed/docs/rss2.html) or
[Atom](https://validator.w3.org/feed/docs/atom.html) spec myself to know how to
create a valid document. For that reason, I browsed the web looking for a
well-maintained `npm` package that could help me externalize part of the work.

[`jpmonette/feed`](https://github.com/jpmonette/feed) ticked all the boxes (some
recent commits, a good amount of stars, and TypeScript support), so I installed
the package and started coding the `RssFeedGenerator` class.

The `RssFeedGenerator` is a simple TypeScript class that receives an array of
paths and gets all the posts that live there. Then, it makes minor adjustments
(flat the collection of posts, order by date) and uses the `jpmonette/feed`
package to return a valid atom feed string. Since this blog is open-sourced, you
may see the actual code for this class in
[`codecoolture/codecoolture.com`](https://github.com/codecoolture/codecoolture.com/blob/fdcbcd2ff6307f5fb42ec463b2547e572edf8047/bin/rss/RssFeedGenerator.ts).

```ts
export class RssFeedGenerator {
  constructor(private paths: string[]) {}

  public async generate(): Promise<string> {
    const feed = new Feed({
      /* Add some feed configuration */
    });

    const allArticles = await Promise.all(
      this.paths.map(async (path) => {
        const repository = await MarkdownRepository.fromDirectory(path);

        return repository.all({ drafts: false });
      }),
    );

    const articlesFromNewestToOldest = orderBy(allArticles.flat(), "date", [
      "desc",
    ]);

    for (const article of articlesFromNewestToOldest) {
      feed.addItem({
        /* Add properties for each item */
      });
    }

    return feed.atom1();
  }
}
```

The `RssFeedGenerator` does not know by itself what the paths are, so it expects
them to be injected during initialization. This decision was driven by my
approach using test-driven development since I wanted to create different
fixtures to test different scenarios without relying on the actual production
data (posts may change title, date, or even get deleted!).

Design-wise, injecting the RSS feed generator would also be desirable, so we
could rely on our own abstractions rather than having this code coupled to a
third-party library. Still, the use case is so simple that I decided to skip the
extra work (I hope it does not bite me in the future!).

## How to integrate `RssFeedGenerator` with Next.js

At this point, this site uses `next export` to build a static website.
Therefore, I couldn’t rely on some of the more advanced Next.js features such as
[API Routes](https://nextjs.org/docs/api-routes/introduction) or even
[middlewares](https://nextjs.org/docs/advanced-features/middleware). So instead,
I decided to integrate the RSS feed generation within the Next.js build by
adding a new `npm script` that executes `bin/rss/index.ts` (a TypeScript script)
and creates a `RssFeedGenerator` instance with the right content paths, using
its output to save a file inside the Next.js `public/` folder. This is what the
script and the new build command look like.

```diff
-    "build": "next build",
+    "build": "yarn build:rss && next build",
+    "build:rss": "NODE_ENV=development yarn ts:exec ./bin/rss/index.ts",
```

```ts
import { writeFile } from "node:fs/promises";
import { join } from "node:path";
import { getConfig } from "../../config";
import { RssFeedGenerator } from "./RssFeedGenerator";

(async function run() {
  const generator = new RssFeedGenerator([
    getConfig().writing.articles,
    getConfig().writing.notes,
  ]);

  const feed = await generator.generate();

  await writeFile(join(__dirname, "../../public/feed.xml"), feed);
})();
```

With all these pieces now working together, new deployments of this site will
always create a valid RSS feed that can be found at [`/feed.xml`](/feed.xml),
keeping the static nature of the website and leveraging a more sophisticated
build process.

What do you think if we make good use of this new feature and subscribe to the
RSS feed? 😃


Adding an RSS feed to a Next.js site

Testing

# Uncovering and conquering async bugs: A trick to testing undesired effects

Imagine you are coding a new React component to upload a file. The component
will receive a callback to notify the app if the upload has been or has not been
successful. You may end with something similar to:

```tsx
/**
 * We will use the `executor` function to simulate different
 * scenarios from our tests.
 */
function UploadButton({ executor, onSuccess }) {
  return (
    <button
      type="button"
      onClick={async () => {
        await executor();

        onSuccess();
      }}
    >
      Upload
    </button>
  );
}
```

To test the most simple scenario, that the `<UploadButton />` component uses the
callback once the upload is completed, we can rely on the standard approach:

```tsx
it("uses the callback to notify that the upload completed", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={success} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(1);
  });
});
```

But things are more complicated if we want to ensure that the `onSuccess`
callback is not executed if something unexpected happens and the process fails.
The initial and most naive implementation might be to assure that the spy is
never called when using the failing executor:

```tsx
it("does not use the callback if something goes wrong", async () => {
  const spy = jest.fn();

  render(<UploadButton executor={fail} onSuccess={spy} />);

  user.click(screen.getByText("Upload"));

  await waitFor(() => {
    expect(spy).toHaveBeenCalledTimes(0);
  });
});
```

**Even if it passes, the test is not checking that the spy never gets called**.
Since the executor is an asynchronous process, and the spy starts with zero
calls, the expectation is valid immediately. You can spot this by replacing
`executor={fail}` with `executor={success}` --that’s the kind of change that
should make the test have a different result, but it continues passing!

To test this scenario, we need to come up with a different approach:

```tsx
it("does not use the callback if something goes wrong", async () => {
  const asyncRender = new Promise<undefined>((resolve, reject) => {
    render(<UploadButton executor={fail} onSuccess={reject} />);

    user.click(screen.getByText("Upload"));

    setTimeout(resolve, 0);
  });

  await expect(asyncRender).resolves.toBeUndefined();
});
```

By embracing the asynchronous nature of this problem, we can wrap the rendering
within a promise and use its reject function as the `onSuccess` callback.
Remember that promises execute immediately but return a delayed response. To
give some room for the component to fail, I use the [setTimeout][settimeout]
trick to force the process to complete pending tasks from the queue.

Now, `asyncRender` should always resolve (with an `undefined` value). If it does
not, our component is having issues handling the `onSuccess` callback and
calling it even when the upload fails (since it is what the failing executor
does). If you change `executor={fail}` to `executor={success}`, you may see the
result keeps consistent, and the test fails.

[settimeout]:
  https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop#zero_delays


Uncovering and conquering async bugs: A trick to testing undesired effects

Software Delivery

# Un acercamiento sencillo a feature flags en una aplicación React con TypeScript

Aunque ya he escrito en otras ocasiones sobre feature flags y como su uso nos
puede ayudar a alcanzar un flujo de entrega continua, en este artículo me
gustaría compartir una implementación sencilla en React utilizando TypeScript.

En esencia, una feature flag es un interruptor que nos permite activar o
desactivar una funcionalidad concreta bajo una serie de condiciones. Los tipos
de condiciones pueden ser muy variados: entorno de ejecución de la aplicación,
tipo de usuaria, porcentaje de tráfico, etc. Además, el cálculo de esa condición
puede realizarse dentro de la propia aplicación, o bien delegarse en otro
sistema.

Este concepto posibilita, entre otras cosas, desacoplar nuestro repositorio del
proceso de entrega de software. Siempre y cuando nuestras funcionalidades
incompletas estén protegidas bajo una feature flag, podremos integrar
continuamente nuestros cambios en la rama principal (aunque eso implique su
despliegue a producción o cualquier otro entorno).

## Publicando feature flags

El primer paso para comenzar a utilizar feature flags es definirlas en algún
sitio. Aunque existan servicios específicamente creados para trabajar con ellas
(que, además, ofrecen flujos y procesos mucho más refinados), yo siempre
recomiendo comenzar con un enfoque humilde, gestionando las feature flags
directamente en la aplicación. En este caso, vamos a crear un módulo que exporte
las diferentes feature flags y una función para obtener su estado:

```tsx
export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};
```

La única razón de asociar una función a la feature flag en lugar de directamente
un booleano es dotarle de cierta flexibilidad (realmente, sería incluso más
interesante hacer que la función devolviese una promesa -de esa manera,
estaríamos cubriendo el caso en el que, para calcular el valor de una feature
flag, tuviésemos que realizar una petición a un servicio externo).

## Integrando la aplicación React con las feature flags

Ahora que ya tenemos un módulo encargado de publicar las feature flags de la
aplicación, es hora de hacerlo accesible desde los componentes React.

El enfoque más directo, sería importar el módulo desde las diferentes páginas o
componentes que lo utilicen y realizar después las operaciones para
mostrar/ocultar alguna parte de la interfaz. Aunque este enfoque funcionaría
estaríamos creando una dependencia no explícita entre nuestros diferentes
componentes y un elemento global (el módulo de `Features`) lo que hará que
probar nuestros componentes en cada uno de los estados sea más complejo.

Vamos a verlo con un ejemplo:

```tsx
import { Features } from "../lib/Features";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {Features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

En esta implementación, `Menu` utiliza directamente el módulo de `Features` para
saber si tiene que mostrar o no la opción de ajustes. A la hora de probar este
componente, tenemos que tener en cuenta esta dependencia y utilizar un _stub_
para poder ajustarlo a ambos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Features } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    jest.spyOn(Features, "newSettingsPage").mockImplementationOnce(() => true);

    render(<Menu />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

Los stubs (o test doubles en general) son recursos muy útiles pero me gusta
reservar su uso para situaciones donde no tengo ninguna otra opción más
idiomática para probar el sujeto bajo test. En este caso, lo ideal sería
convertir esa dependencia no explícita en algo que pudiésemos controlar desde el
exterior, utilizando inyección de dependencias. En React, tendríamos varias
opciones para conseguirlo. Veamos un par de ellas.

### Obtener las feature flags a través de una prop

Por ejemplo, utilizando una prop `features` para poder recibir el objeto
completo de feature flags. El problema con este enfoque es que podría haber
muchos componentes intermedios que necesiten propagar esta prop sin necesidad de
utilizarla. Este fenómeno se denomina
[Prop Drilling](https://kentcdodds.com/blog/prop-drilling) y, aunque no es malo
_per se_, puede convertirse en algo difícil de gestionar cuando nuestra
aplicación crezca en número de componentes.

```tsx
import { Features } from "../lib/Features";

export function Menu({ features }: { features: typeof Features }) {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que el componente `Menu` obtiene la información de las feature flags a
través de una prop, podemos ajustar los diferentes escenarios para las pruebas
sin necesidad de utilizar test doubles:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(<Menu features={{ newSettingsPage: () => false }} />);

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(<Menu features={{ newSettingsPage: () => true }} />);

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

### Obtener las feature flags a través de la API de contextos

Bien utilizada, la
[API de contextos de React](https://reactjs.org/docs/context.html) puede servir
como un contenedor de inyección de dependencias que permita aislar a los
componentes padre de las dependencias concretas de sus componentes hijo. En este
caso, vamos a crear un nuevo contexto que publique las feature flags disponibles
dentro de la aplicación y que permita acceder a ellas a través de un hook
concreto, `useFeatures`.

Lo primero, es definir el propio contexto encargado de devolver las feature
flags existentes. Junto a él, también definiremos el hook que se utilizará
después desde nuestros componentes. Este último es una simple capa de
abstracción que centraliza la lógica común de acceso.

```tsx
import { createContext, useContext } from "react";

export const Features = {
  newSettingsPage: () => process.env.NODE_ENV === "development",
};

export const FeaturesContext = createContext(Features);

export function useFeatures() {
  return useContext(FeaturesContext);
}
```

Los contextos en React se crean con un valor por defecto. En caso de que no
exista ningún proveedor que sobrescriba el valor para el contexto, nuestros
componentes recibirán ese valor al acceder a él. En este caso, hemos creado el
contexto utilizando como valor por defecto el propio objeto exportado por
`Features`.

```tsx
import { useFeatures } from "../lib/Features";

export function Menu() {
  const features = useFeatures();

  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        {features.newSettingsPage() && (
          <li>
            <a href="/settings">Settings</a>
          </li>
        )}
      </ul>
    </nav>
  );
}
```

Ahora que nuestro componente `Menu` utiliza el nuevo contexto, sólo necesitamos
envolver el componente en diferentes proveedores cuando queramos probar
distintos escenarios:

```tsx
/**
 * @jest-environment jsdom
 */

import { render, screen } from "@testing-library/react";
import { FeaturesContext } from "../lib/Features";
import { Menu } from "./Menu";

describe("Menu", () => {
  it("doesn't show Settings if the feature is disabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => false }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).toBeNull();
  });

  it("shows Settings if the feature is enabled", async () => {
    render(
      <FeaturesContext.Provider value={{ newSettingsPage: () => true }}>
        <Menu />
      </FeaturesContext.Provider>,
    );

    expect(screen.queryByText("Settings")).not.toBeNull();
  });
});
```

## `<FeatureFlag />`, un componente para abstraernos por completo

Si utilizamos la API de contextos, podemos ir todavía un paso más allá y
abstraernos por completo de la gestión de funcionalidades disponibles. En este
caso, vamos a crear un componente `FeatureFlag` que recibirá la flag sobre la
que queremos trabajar y los nodos que queremos ocultar en caso de no estar
disponible:

```tsx
import { ReactNode } from "react";
import { Features, useFeatures } from "../lib/Features";

type FeatureFlagProps = { children: ReactNode; flag: keyof typeof Features };

export function FeatureFlag({ children, flag }: FeatureFlagProps) {
  const features = useFeatures();

  if (features[flag]()) {
    return <>{children}</>;
  }

  return null;
}
```

Al definir la prop de `flag` como `keyof typeof Features` estamos tomando
ventaja de la ayuda del compilador de TypeScript, que nos dirá automáticamente
que funcionalidades existen y evitará que utilicemos flags que no se encuentran
en el objeto global de `Features`.

```tsx
import { FeatureFlag } from "./FeatureFlag";

export function Menu() {
  return (
    <nav>
      <ul>
        <li>
          <a href="/dashboard">Dashboard</a>
        </li>

        <li>
          <a href="/profile">Profile</a>
        </li>

        <FeatureFlag flag="newSettingsPage">
          <li>
            <a href="/settings">Settings</a>
          </li>
        </FeatureFlag>
      </ul>
    </nav>
  );
}
```

Con este último enfoque, nuestras pruebas anteriores utilizando el proveedor del
contexto de feature flags seguirán funcionando (ya que es el mecanismo sobre el
que se construye todo) a la vez que tomamos ventaja de un diseño mucho más
idiomático, encapsulando la gestión de feature flags en su propio componente
React.


Un acercamiento sencillo a feature flags en una aplicación React con TypeScript

Test-Driven Development

# Test-driven front-end development

> Este artículo fue publicado originalmente en la edición de 2020 de
> [Octuweb](https://octuweb.com/test-driven-front-end-development/).

En la edición de 2018 **Cristina Ponce** publicó
[Testing en el front](https://octuweb.com/testing-front/), una guía sobre los
diferentes tipos de pruebas que podemos realizar en aplicaciones front-end.
Apoyándonos en ese artículo, vamos a hablar aquí de cómo aprovechar la nueva
generación de herramientas para alcanzar flujos de desarrollo que, hasta hace
solo unos años, no eran (tan) fácilmente aplicables en este contexto:
**Test-Driven Development** (o **TDD**).

## Pero primero, ¿qué es TDD?

Test-Driven Development es una metodología que se basa en aplicar pequeños
ciclos de desarrollo con el objetivo de resolver casos de prueba. De manera más
concreta, lo podemos definir en 3 pasos:

1. Codificar una prueba que defina el nuevo comportamiento que queremos añadir a
   nuestro sistema
2. Escribir la menor cantidad de código posible que nos permita hacer pasar el
   test anterior
3. Mejorar el código anterior utilizando las pruebas como red de seguridad
   (a.k.a _refactoring_)

En TDD clásico, lo habitual es comenzar por las entidades más internas de
nuestro sistema para ir construyendo capas una encima de otra hasta terminar de
implementar la funcionalidad. En front-end sin embargo, y con las herramientas
actuales, lo más natural es utilizar una variación denominada **ATDD**
(inspirada en **Outside-in**, un enfoque de TDD que se originó en la comunidad
de eXtreme Programming de Londres), donde se empieza creando un primer test en
la capa más externa del sistema (en este caso, la interfaz o un componente) para
ir construyendo desde ahí el resto de la funcionalidad.

## Escribiendo nuestro primer test

En su sentido más estricto, TDD es una herramienta de desarrollo (un flujo de
trabajo, una metodología) y no tiene que verse como un instrumento de calidad
(entendiendo esta como la disciplina para el control de defectos). Por tanto, su
objetivo es ayudar a las programadoras a entregar valor lo antes posible, con
confianza. En ATDD, por ejemplo, el primer test nos tiene que permitir poner el
foco en el problema que vamos a resolver y servirnos como guía durante el
desarrollo de la funcionalidad. Lo habitual es intentar reflejar en este primer
test los criterios de aceptación que perseguimos cumplir con la historia de
usuario en curso.

Por ejemplo, supongamos que estamos trabajando en el front-end para la web de
una editorial de libros y queremos añadir una página de contacto:

> Es posible acceder a una página de contacto para, indicando email, asunto y
> mensaje, ponerse en contacto con la editorial. Una vez completada la
> operación, se realizará una redirección a una página de éxito con un mensaje
> que indique que todo ha ido bien.
>
> Hay disponible un endpoint `/api/contact` que completa la operación en el
> back-end.

Utilizando [**Cypress**](https://www.cypress.io/), podemos trasladar esta
descripción a una prueba de alto nivel como la siguiente:

```tsx
// Location: cypress/integration/sendContactMessage.test.ts

context("sendContactMessage", () => {
  specify("A user can send a contact message", () => {
    // Setup
    cy.server();
    cy.route2("/api/contact", { statusCode: 200 });

    // Act
    cy.visit("/contact");
    cy.findByLabelText(/tu email/i).type("hola@codecoolture.com");
    cy.findByLabelText(/asunto/i).type("Información sobre próximos libros");
    cy.findByLabelText(/mensaje/i).type(
      "Hola, me gustaría obtener más información sobre próximos libros.",
    );
    cy.findByText(/enviar/i).click();

    // Assert
    cy.url().should("eql", Cypress.config().baseUrl + "/contact/success");
    cy.findByText(/tu mensaje ha sido enviado con éxito/i).should("exist");
  });
});
```

La prueba anterior codifica el escenario de aceptación básico: primero, hacemos
que Cypress simule la respuesta al endpoint `/api/contact` para indicar que todo
ha ido bien (devolverá un código `200`), y después interactuamos con la
aplicación para ir a la página de contacto y completar el formulario. Por
último, validamos que se ha llevado al usuario a la página de éxito tras enviar
el formulario.

> Ahora que hemos visto un ejemplo, seguramente nos sea más sencillo explicar
> qué es Cypress: un framework de testing para construir pruebas de aceptación
> sobre un navegador, utilizando JavaScript.

En el ejemplo anterior, la prueba se ejecutará sobre nuestra propia aplicación.
En este caso, **como todavía no hemos escrito código de producción, lo que
esperamos es que el test falle**. Es ahora cuando tenemos que escribir la mínima
cantidad posible de código para que este test pueda pasar.

```tsx
// Location: pages/contact.tsx

export default function Contact() {
  return (
    <main>
      <Formik
        initialValues={{ email: "", subject: "", message: "" }}
        onSubmit={async ({ email, subject, message }) => {
          const response = await fetch("/api/contact", {
            body: JSON.stringify({ email, subject, message }),
            headers: { "content-type": "application/json" },
            method: "post",
          });

          if (response.ok) {
            window.location.href = "/contact/success";
          }
        }}
      >
        {() => {
          return (
            <Form>
              <label>
                Tu email <Field id="email" name="email" />
              </label>

              <label>
                Asunto <Field name="subject" />
              </label>

              <label>
                Mensaje <Field name="message" />
              </label>

              <button type="submit">Enviar</button>
            </Form>
          );
        }}
      </Formik>
    </main>
  );
}
```

```tsx
// Location: pages/contact/success.tsx

export default function ContactSuccess() {
  return <p>¡Enhorabuena! Tu mensaje ha sido enviado con éxito</p>;
}
```

Obviando algunos detalles de implementación (como el uso de
[Formik](https://formik.org/) para el formulario), los dos fragmentos de código
anteriores muestran una posible implementación (básica pero funcional) que sirve
para hacer pasar nuestro primer test de aceptación. En este punto, podemos
añadir CSS a nuestra nueva página o extraer comportamientos a otro tipo de
entidades (por ejemplo, mover la operación de `onSubmit` a un servicio). Si
nuestro test sigue en verde al completar los cambios, tendremos la certeza de
que no hemos roto nada ✅

## Aplicando ciclos de desarrollo más pequeños

Aunque Cypress es un magnífico framework de testing, las pruebas de tan alto
nivel suelen venir con algunos compromisos: es difícil poder ejercitar todos los
caminos de ejecución posibles y son lentas. Recordad que con TDD estamos
buscando mejorar nuestra productividad por lo que **necesitamos que los ciclos
de feedback sean lo más cortos posibles**. Para ello, mi consejo es utilizar
pruebas de aceptación para cubrir el _happy path_ de la funcionalidad (y quizás
algún escenario de error clave) y después iterar en ciclos de desarrollo más
pequeños facilitados por pruebas de una granularidad más baja (en front-end,
podríamos entenderlas como híbridos de integración + unitaria, centradas en
componentes).

Si volvemos al ejemplo anterior, seguramente hay ciertas reglas de experiencia
de usuario que queramos validar sobre el formulario de contacto: que no se pueda
completar la operación sin un email de remite o sin el cuerpo del mensaje, que
aparezcan correctamente los mensajes de error, que los campos permitan
únicamente ciertos patrones, etc. Aunque estas pruebas se podrían hacer también
utilizando Cypress, su latencia es a menudo lo suficientemente grande como para
preferir moverlos a tests de más bajo nivel (por lo general, más rápidos).

Para hacer pruebas de componentes (en React, aunque las mismas herramientas
están disponibles en otros frameworks como Vue o Angular) mi consejo es utilizar
[**Testing Library**](https://testing-library.com/) en conjunción con
[**Jest**](https://jestjs.io/). Por ejemplo, vamos a añadir un nuevo
comportamiento a nuestra página de Contacto, aunque esta vez iterando en un
nivel de abstracción más bajo:

> El formulario sólo debe enviarse si contiene un email de remite y un mensaje.

```tsx
// Location: components/ContactForm.test.tsx

describe("ContactForm", () => {
  it("does not submit the form if some required fields are missing", async () => {
    // Setup
    const spy = jest.fn();
    render(<ContactForm onSubmit={spy} />);

    // Act
    await user.type(
      screen.getByLabelText(/asunto/i),
      "Información próximos libros",
    );

    user.click(screen.getByText(/enviar/i));

    // Assert
    await expect(
      screen.findAllByText("Este campo es obligatorio."),
    ).resolves.toHaveLength(2);

    await waitFor(() => expect(spy).not.toHaveBeenCalled());
  });
});
```

El test anterior codifica el nuevo comportamiento que queremos validar. Veréis
que, en un primer vistazo, la apariencia del test es similar al primero que
creamos utilizando Cypress. La única diferencia es que aquí se prueba el
componente de manera aislada en lugar de simular a un usuario real utilizando la
aplicación. En Testing Library, no hay ningún navegador ejecutándose en
paralelo, como sí ocurre con Cypress; así, mientras el último que hemos escrito
podemos ejecutarlo en ~2 segundos, el primero necesita de ~22 segundos.

Cuando trabajamos a un nivel de granularidad más bajo, nuestros tests pueden
afectar al diseño de nuestros componentes (por lo general, haciéndolos más
sencillos de probar). En este caso, he decidido inyectar la función que gestiona
el envío del formulario para poder reemplazarla por un espía que me permita
validar que no se ha invocado cuando no debía (aunque también podríamos haber
espiado el módulo HTTP con [**nock**](https://github.com/nock/nock)). Este es
otro de los beneficios clave de TDD, ser capaces de ir definiendo el diseño de
nuestras interfaces a medida que escribimos las pruebas.

Como todos estos cambios no están repercutiendo en cambios de comportamiento a
nivel de aceptación, nuestro test de Cypress debería seguir pasando después de
cada modificación, ayudándonos de nuevo a garantizar que no hemos roto nada ✅.

Ahora, al igual que en el ejercicio anterior, tendríamos que escribir la menor
cantidad de código que sirva para hacer pasar este test.

> Pss! Podéis ver el ejemplo completo en
> [este repositorio de GitHub](https://github.com/codecoolture/octuweb-2020) 👀

## Conclusión

¿Que conseguiremos aplicando un flujo similar al anterior? En la literatura de
TDD, estaríamos aplicando lo que se conoce como
[Outside-In development with Double Loop TDD](http://coding-is-like-cooking.info/2013/04/outside-in-development-with-double-loop-tdd/)
o el proceso descrito en el libro
[Growing Object-Oriented Software, Guided by Tests](https://www.goodreads.com/book/show/4268826-growing-object-oriented-software-guided-by-tests).

Primero, arrancamos con un test de aceptación (o del nivel de granularidad más
alto que podamos) que nos ayudará a mantener el foco en la funcionalidad que
queremos resolver. En ocasiones, este test puede estar fallando durante varias
horas porque necesite de otros ciclos complementarios más pequeños que nos
ayuden avanzar (el ejemplo anterior era tan sencillo que no lo hemos
necesitado). Para esos ciclos complementarios es donde podemos hacer uso de
flujos como TDD clásico (útil para avanzar en piezas de bajo nivel como
funciones, clases, servicios) y herramientas como Testing Library (para probar
los diversos componentes que construyan la interfaz) o _simplemente_ Jest (para
lógica de negocio como controladores, funciones de utilidad, etc.).

## Otras referencias

- Además de los enlaces contenidos en el artículo, podéis encontrar más
  referencias a TDD en
  [esta página](https://www.notion.so/codecoolture/Public-References-50b1e927fe1641748f95610353e97b7f).
- Cypress tiene una sección de
  [mejores prácticas](https://docs.cypress.io/guides/references/best-practices.html)
  con algunos consejos muy útiles sobre cómo escribir pruebas de aceptación.
- [Kent C. Dodds](https://twitter.com/kentcdodds/) (creador de Testing Library)
  tiene bastantes artículos relacionados con testing de aplicaciones front-end
  (desde TDD hasta diferentes estrategias de testing). Podéis encontrarlos en
  [su blog](https://kentcdodds.com/blog?q=testing).


Test-driven front-end development

# Portfolio y blog utilizando NEXT.js

En esta nota os quiero contar algún detalle sobre cómo construí este website
utilizando NEXT.js, un framework desarrollado por Vercel que utiliza React como
librería principal y que permite, de manera sencilla, servir una aplicación
React desde el servidor utilizando _server-side rendering_ (¡aunque quedarnos
únicamente con esto sería simplificarlo demasiado!).

> Mi intención aquí no es hacer un recorrido en profundidad de NEXT.js o cómo
> implementar un portfolio utilizándolo. Si os pica la curiosidad, el proyecto
> tiene una muy buena [documentación](https://nextjs.org/docs/getting-started),
> con
> [multitud de ejemplos](https://github.com/vercel/next.js/tree/canary/examples)
> y [tutoriales](https://nextjs.org/learn/basics/create-nextjs-app).

## Iterando entre diferentes versiones de Next

El primer commit para desarrollar [codecoolture.com](http://codecoolture.com) es
del 24 de agosto de 2018. Por aquel entonces las necesidades del proyecto eran
tener un montón de ficheros estáticos que explicasen qué servicios tenía pensado
ofrecer como _freelance_ y, para ello, utilicé la funcionalidad de Next:
`next export`, que genera un conjunto de ficheros HTML como resultado de aplicar
_server-side rendering_ a la aplicación y _exportar_ su resultado.

Más adelante, me decidí por añadir un blog (y este apartado de notas) y en ese
punto, las cosas empezaron a complicarse (sobre porqué decidí implementar mi
blog _in house_ en lugar de utilizar plataformas como Medium, las razones son
muy parecidas a las expuestas por Marina Aisa cuando
[escribió sobre su experiencia trabajando con Nuxt](https://marinaaisa.com/es/blog/blog-usando-vue-nuxt-markdown/)).
Para seguir manteniendo ese enfoque estático, tenía que añadir las diferentes
entradas manualmente en alguna página tipo índice que sirviera para que el
proceso de exportación supiese que existían y pudiese crear sus ficheros HTML
relacionados (simplificándolo mucho, sería algo similar a lo que necesita un bot
para hacer _crawling_ de una web).

Para no depender de un proceso manual, me decidí por abandonar la exportación
estática y desplegar Next en una instancia de AppEngine para hacer que las
páginas del blog (junto con su índice) se comenzasen a pintar dinámicamente
utilizando SSR. Veréis que aunque Vercel es una plataforma que le encaje como
anillo al dedo a un proyecto que utilice Next, este se puede desplegar en
cualquier servicio que admita ejecutar aplicaciones Node (aunque no todos son
capaces de sacarle partido al potencial _serverless_ del framework, pero eso
sería un tema para otro momento).

Actualmente, y tras actualizar Next a su versión 9.3, pude recuperar la
exportación estática gracias a la adición de una función `getStaticPaths` que
permite indicarle a Next (de manera programática, en tiempo de compilación) qué
paginas existen y cuáles tiene que exportar. En el mismo fichero que se utiliza
para definir una entrada en el blog, se exporta un función cómo la siguiente:

```tsx
export const getStaticPaths: GetStaticPaths = async () => {
  const repository = await MarkdownRepository.fromDirectory(
    getConfig().writing.articles,
  );

  const paths = (await repository.all()).map((article) => {
    const slug = article.metadata.slug;

    if (!slug) {
      throw new Error(
        `ERROR: Missing slug for article: ${JSON.stringify(article.metadata)}`,
      );
    }

    return { params: { slug } };
  });

  return { fallback: false, paths };
};
```

La función pide a un repositorio de artículos que devuelva todos los documentos
que existen y utiliza esta información para indicar a Next cómo encontrarlos (a
través de la propiedad `slug` de cada _path_). `MardownRepository` es una
entidad de mi proyecto (y no algo que venga con Next), y es que el patrón
_Repository_ es una abstracción que utilizo muy habitualmente ya que encaja en
un montón de escenarios (realmente, en casi cualquiera que tenga acceso a
datos).

> Como [Cassidy Williams](https://twitter.com/cassidoo) lo explica mejor que yo,
> podéis echar un vistazo a
> [este blogpost](https://www.netlify.com/blog/2020/05/04/building-a-markdown-blog-with-next-9.4-and-netlify/)
> donde explica en profundidad cómo crear un blog con Next.

## MDX: escribiendo contenido de manera cómoda

No, la verdad que React + JSX no es la mejor manera para escribir contenido de
manera ágil y cómoda... Para hacerlo, me decidí por un
[plugin de Next](https://github.com/vercel/next.js/tree/canary/packages/next-mdx)
que permite generar páginas escribiendo directamente ficheros
[MDX](https://mdxjs.com/) (que, en resumen, son ficheros en formato Markdown
pero que permiten integrar componentes React directamente en el cuerpo del
documento). Este mismo esquema es el que utilicé para escribir los artículos del
blog y las notas; todo junto, en resumen, hace que el 100% del contenido de la
web se escriba en MDX y únicamente utilice React + JSX para definir los
componentes.

Además, con MDX, podemos indicar qué componentes React queremos mapear con cada
elemento HTML. Esto es especialmente útil para poder reutilizar los mismos
componentes a través de toda la aplicación:

```tsx
import { Blockquote } from "../../components/Blockquote";
import { Link } from "../../components/Link";
import { List } from "../../components/List";
import { Text } from "../../components/Text";
import { Title } from "../../components/Title";

/* ... */

<MDX
  components={{
    a: Link,
    blockquote: Blockquote,
    h1: Title,
    ul: List,
  }}
>
  {post.content}
</MDX>;
```

## Otros detalles

- Para los estilos de la aplicación me decanté por utilizar CSS y no una
  solución CSS-in-JS, aunque seguramente mi decisión ahora hubiese sido distinta
  (después de utilizar `emotion` durante los últimos meses, la verdad es que me
  he sentido muy cómodo). Ambos enfoques se pueden utilizar sin mayores
  problemas en Next (siendo el uso de CSS soportado por defecto, sin necesidad
  de configurar nada).
- La web se sirve desde Firebase Hosting (tengo la mayoría de proyectos en
  Google Cloud y me era más cómodo mantener todo dentro de la misma nube que
  desplegar este site en Vercel o Netlify -opciones también muy válidas y con
  una _developer experience_ muy bien ejecutada). Los despliegues están
  automatizados a través de GitLab CI/CD.


Portfolio y blog utilizando NEXT.js

# React: MultipleRender

El síntoma más claro de este _code smell_ es la aparición de varios métodos de
instancia tipo `render` especializados en construir una parte de la UI de un
componente React. Suele aparecer especialmente en componentes complejos (o de
gran tamaño, como una página) cuando diferentes partes de la interfaz precisan
de alguna comprobación o cálculo extra que afecte a su representación.

```tsx
export class Blog extends React.Component<{ articles: Article[] }> {
  public render() {
    return (
      <>
        {this.renderHeader()}

        {this.renderArticles()}
      </>
    );
  }

  private renderHeader() {
    const {
      articles: { length: numberOfArticles },
    } = this.props;

    if (numberOfArticles === 0) {
      return (
        <header>
          <p>No articles 😯</p>
        </header>
      );
    }

    return (
      <header>
        <p>Yay! {numberOfArticles} articles 🎉</p>
      </header>
    );
  }

  private renderArticles() {
    return this.props.articles.map((article) => {
      return (
        <section>
          <h1>
            <a href={article.url}>{article.title}</a>
          </h1>
        </section>
      );
    });
  }
}
```

En el caso anterior, vemos que la representación de la cabecera de la página
varía en función del número de artículos que se vayan a mostrar. Del mismo modo
que la lógica para pintar la colección de artículos está encapsulada en su
propio método de instancia.

Con echar un simple vistazo al método `render`, ya vemos con claridad cuáles son
las verdaderas responsabilidades de nuestra página: definir un _layout_ que
muestre una cabecera y una colección de artículos.

¿Es, por tanto, responsabilidad de la página conocer los _internals_ de la
cabecera y la lógica necesaria para pintar la colección de artículos? No. Este
componente contiene más de una responsabilidad y no cumple con el
[Principio de Responsabilidad Única](https://en.wikipedia.org/wiki/Single_responsibility_principle).

Para mejorar nuestro diseño, bastaría con definir dos nuevos componentes que
encapsulen la lógica necesaria para pintar ambas partes. Con este enfoque,
ganaríamos cierta capacidad para reutilizar esos componentes en otros lugares de
nuestra interfaz (aunque no es condición necesaria para crear un nuevo
componente) a la vez que reducimos la complejidad del componente padre, que no
necesita ya llevar consigo toda la lógica de las diferentes partes que la
conforman.

Además, si seguís un enfoque de integración y entrega continua, veréis que es
mucho más sencillo [aplicar _feature flags_](/blog/branch-by-abstraction-react)
sobre estos pequeños componentes de vuestra interfaz en lugar de en mitad de
componentes grandes y complejos, donde se estarían mezclando responsabilidades y
requisitos de distintas partes de la aplicación.

```tsx
import { Articles } from "./components/Articles";
import { Header } from "./components/Header";

export function Blog(props: { articles: Article[] }) {
  return (
    <>
      <Header {...props} />

      <Articles {...props} />
    </>
  );
}
```

Este _code smell_ está relacionado con otros de propósito general (no
relacionados directamente con React) como
[_Large Class_](https://sourcemaking.com/refactoring/smells/large-class) y
técnicas de _refactoring_ como
[Extract Class](https://refactoring.guru/extract-class).


Code Smell: React.MultipleRender

# Branch by Abstraction en Componentes React

En ocasiones, nos vemos en la situación de tener que actualizar varios
componentes de nuestra interfaz de usuario para ajustarlos a nuevas directrices
de diseño. Otras veces, necesitamos reemplazar su implementación para hacer
frente a nuevos requisitos de negocio. Si el número de cambios es lo
suficientemente alto, es posible que no se puedan realizar de manera atómica (o
tengan que ser sincronizados con eventos fuera del control del equipo de
desarrollo como, por ejemplo, la publicación de una nueva imagen de marca) a la
vez que necesitamos continuar entregando valor en forma de nuevas
funcionalidades, corrigiendo defectos o aplicando alguna que otra mejora.

En este artículo vamos a hablar sobre una estrategia que nos permita obtener un
flujo de integración continua evitando, por tanto, mantener los cambios en
nuestros componentes en una rama independiente en el sistema de control de
versiones durante el transcurso de su desarrollo.

¿Cómo lo conseguiremos? Haciendo uso de dos técnicas muy habituales en equipos
que trabajan con prácticas como _continuous integration_ o _continuous
delivery_: [Feature Flags](http://featureflags.io/) (o Feature Toggles si
[leéis a Martin Fowler](https://martinfowler.com/bliki/FeatureToggle.html)) y
[Branch By Abstraction](https://martinfowler.com/bliki/BranchByAbstraction.html).

Ambas estrategias nos permitirán fusionar código de manera regular sobre la rama
principal, aún con funcionalidades parcialmente terminadas, evitando así
mantener ramas en paralelo que podrían estar días (o semanas) sin integrarse con
el trabajo realizado por el resto del equipo.

> Las feature flags son, conceptualmente, bloques condicionales que permiten
> habilitar o deshabilitar una funcionalidad (o un camino de ejecución) en base
> a un conjunto de condiciones (como pueden ser: el entorno de ejecución, el
> perfil del usuario o un porcentaje de tráfico)

Pongamos como ejemplo que, en nuestra aplicación, llevamos ya un tiempo
utilizando `<AwesomeCalendar />` (un componente de terceros) como _widget_ de
calendario. En los puntos donde es necesario mostrar un calendario, importamos
el componente y lo insertamos en el _layout_ de la página.

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <AwesomeCalendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

Debido a una serie de requisitos, tenemos que crear un nuevo componente para
mostrar un calendario que sustituya a `AwesomeCalendar` y le añada un _extra_ de
funcionalidad para dar cabida a nuevas historias de usuario. El desarrollo del
componente se extenderá durante varias semanas.

El primer paso para poder integrar nuestro componente de manera continua es
asegurar que somos capaces de controlar cuándo y cómo se utiliza para poder
aislar a los consumidores de `AwesomeCalendar` de los cambios en el mismo. Para
ello, vamos a empezar creando una nueva _abstracción_ `Calendar` que pasará a
ser utilizada por el resto de componentes y mantendrá la misma interfaz que
ofrecía `AwesomeCalendar`:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

export function Calendar({ date }: { date: Date }) {
  return <AwesomeCalendar date={date} />;
}
```

Como vemos, la manera de consumir este nuevo componente sería muy parecida a la
versión anterior:

```tsx
import React from "react";

import { Calendar } from "../components";

function Page() {
  return (
    <Page>
      <Header />

      <Body>
        <Calendar date={new Date(2018, 6, 21)} />
      </Body>
    </Page>
  );
}
```

> En este punto, ya podríamos fusionar nuestros cambios con la rama de código
> principal para que el resto de trabajo en curso pueda ir haciendo uso de
> nuestro (no tan) _nuevo_ componente.

A continuación, vamos a crear una implementación muy sencilla de nuestro propio
calendario, que empezará apoyándose en una implementación nativa de `datetime`
pero respetando la interfaz original del componente `AwesomeCalendar`:

```tsx
import React from "react";

export function NewCalendar({ date }: { date: Date }) {
  const value = /* implementation details */;

  return <input type="datetime-local" value={value} />;
}
```

Una vez hemos eliminado la responsabilidad de elegir qué calendario utilizar de
los consumidores del componente, podemos utilizar _feature flags_ para
determinar qué calendario mostrar en cada momento.

En este caso, vamos a permitir que cualquier entorno que **no sea producción**
utilice siempre nuestro propio calendario, con el objetivo de obtener _feedback_
sobre su experiencia de uso a medida que avanzamos en su desarrollo:

```ts
export function isNewCalendarEnabled() {
  return process.env.NODE_ENV !== "production";
}
```

> Este caso, representamos la feature flag con una simple función que comprueba
> el entorno de ejecución actual, pero existen
> [sistemas más sofisticados](https://github.com/Unleash/unleash) para gestionar
> el estado de los _toggles_ en nuestra aplicación.

Ahora, nuestra nueva abstracción `Calendar` (que hace las veces de factoría)
puede hacer uso de esta función para determinar qué componente de calendario
utilizar, manteniendo al resto de consumidores aislados de toda complejidad:

```tsx
import React from "react";

import { AwesomeCalendar } from "awesome-calendar";

import { NewCalendar } from "./components";

import { isNewCalendarEnabled } from "../features";

export function Calendar(props: { date: Date }) {
  return isNewCalendarEnabled() ? (
    <NewCalendar {...props} />
  ) : (
    <AwesomeCalendar {...props} />
  );
}
```

A partir de este momento, todas las pantallas de nuestra interfaz de usuario que
necesiten de un calendario, utilizarán la abstracción `Calendar` y será esta
misma abstracción la que se encargará de utilizar la implementación concreta del
calendario que corresponda en función del entorno de ejecución.

Como vemos, aplicar técnicas como _branch by abstraction_ y _feature flags_ nos
permite alcanzar un flujo de integración (y entrega) continua en nuestros
componentes aportándonos beneficios cómo:

- Minimizar la superficie de cambios a fusionar cuando integramos trabajo en
  curso
- Tomar el control sobre cuándo se ejercita un camino de ejecución y poder
  habilitarlo y deshabilitarlo en base a una serie de condiciones
- Dotar a los equipos de negocio de visibilidad sobre el trabajo en curso en
  tareas de larga duración (sin sacrificar ninguna de las premisas anteriores)


Collection: React

2022

2021

2020

2019

Browse all collections