Forem: x0s3

Implementando un API Client Generator con Proxies de JavaScript y TypeScript Overloads

x0s3 — Tue, 07 Apr 2026 18:30:10 +0000

Generador de clientes: Centralizando el consumo de APIs con Proxies y TypeScript

Si estás trabajando en un ecosistema de microservicios, probablemente estés harto de configurar instancias de Axios/Ky en cada rincón de tu proyecto. El boilerplate se acumula, el tipado se vuelve inconsistente y mantener las configuraciones base (como headers de tracking o transformación de cases) se vuelve una pesadilla.

Hoy quiero mostrarte cómo pasar de un desorden de configuraciones a una interfaz limpia y centralizada.

Esto es lo que queremos evitar ❌

import { axios } from 'axios';

const url = process.env.SERVICE1;
const response = await axios.get(`${url}/user-data`);

La API Final: Así es como debería verse tu código

Imagina que en lugar de importar configuraciones pesadas, simplemente defines tus servicios y ya tienes clientes listos para usar:

import { clientGenerator } from "./api-utils";
import { connector } from "./base-connector";

// 1. Definimos y generamos
const { service1, service2 } = clientGenerator(connector, {
  service1: process.env.SERVICE1,
  service2: process.env.SERVICE2,
});

// 2. Usamos con tipado automático
const data = await service1.get<MyResponse>("/user"); 
// 'data' es MyResponse directamente.

¿Necesitas la respuesta completa? Solo pasas un flag y el tipado cambia mágicamente:

const data = await service1.get<MyResponse>("/user", {
  resolveWithFullResponse: true,
}); 

console.log(response.status); // 200
console.log(response.data.ok); // Tipado
console.log(response.data.MyResponse); // Tipado

¿Cómo llegamos a esto? La magia por dentro

Para lograr esta sintaxis tan limpia sin repetir código para cada método HTTP (get, post, put...), usamos dos herramientas poderosas: Proxies de JavaScript y Sobrecarga de funciones en TypeScript.

1. El Proxy como "Atrapa-todo"

En lugar de definir un objeto con métodos manuales, usamos un Proxy. Este intercepta cualquier propiedad que intentes acceder (como .get o .post) y la convierte dinámicamente en una llamada al conector.

const client = (connector: Connector, baseURL: string) =>
  new Proxy<Client>({} as Client, {
    get(_target, method: HTTPMethod) {
      const requestMethod: ClientMethod = <TResponse = unknown>(
        endpoint: `/${string}`,
        options: ClientRequestConfig = {},
      ) => {
        const requestBase = {
          ...options,
          baseURL,
          url: endpoint,
          method: method.toUpperCase(),
        };

        // Casting to `any` so that the type inference works correctly :D
        return connector<TResponse>(requestBase as any);
      };

      return requestMethod;
    },
  });

Esto hace que nuestro cliente sea virtualmente infinito y extremadamente ligero. No importa si mañana el conector soporta un nuevo verbo HTTP; el Proxy simplemente lo capturará.

2. Tipado inteligente (Function Overloads)

Uno de los retos era que, a veces, queremos solo la data y otras veces el AxiosResponse completo. Para que TypeScript no nos dé errores ni use any, aplicamos sobrecarga de tipos:

type ClientMethod = {
  // Sobrecarga 1: Si no pides la respuesta completa, devuelve TResponse
  <TResponse = unknown>(
    endpoint: `/${string}`,
    options?: ClientRequestConfigNormal,
  ): Promise<TResponse>;

  // Sobrecarga 2: Si resolveWithFullResponse es true, devuelve AxiosResponse<TResponse>
  <TResponse = unknown>(
    endpoint: `/${string}`,
    options: ClientRequestConfigFullResponse,
  ): Promise<AxiosResponse<TResponse>>;
};

Esto es lo que permite que el IDE sea "inteligente" y sepa exactamente qué tipo de objeto tienes entre manos según las opciones que envíes.

3. La Factoría: `clientGenerator`

Finalmente, unificamos todo en una función que toma un mapa de URLs y nos devuelve el objeto final usando Object.fromEntries:

export const clientGenerator = <T extends ServiceMap, R = { [K in keyof T]: Client }>(
  connector: Connector,
  services: T,
): R =>
  Object.fromEntries(
    Object.entries(services).map(([key, baseURL]) => [key, client(connector, baseURL)]),
  ) as R;

El "Perfect Match": RSC y React Query

Donde esto realmente brilla es en el frontend moderno.

React Server Components (RSC)

Esta estrategia casa perfectamente con la filosofía de tener One API to rule them all. En entornos con Server Components, quieres que tus llamadas a la API sean lo más planas y directas posibles.

Al centralizar todo en un generador, tus componentes de servidor se mantienen limpios de lógica de infraestructura, delegando el manejo de tokens, certificados o headers de tracking al connector base.

Integración con React Query

La integración aquí es increíble. Como el generador devuelve una promesa tipada, react-query infiere el tipo de data automáticamente:

// El tipado de 'data' se hereda de la respuesta del cliente automáticamente
const { data } = useQuery({
  queryKey: ['fines', id],
  queryFn: () => fines.get<FinesDetail>(`/fines/${id}`)
});

Esto elimina la necesidad de declarar genéricos manualmente en cada useQuery y asegura que lo que dice tu API sea exactamente lo que llega a tus componentes.

Conclusión

Al abstraer la creación de clientes con un generador centralizado, no solo limpias tu código de infraestructura, sino que garantizas que todos los microservicios de tu ecosistema se consuman bajo las mismas reglas (mismos headers, mismo manejo de errores, mismo tracking).

Es una inversión pequeña en arquitectura que paga dividendos enormes en mantenibilidad y Developer Experience.

¿Qué les parece este enfoque? ¿Usan Proxies en sus utils o prefieren definiciones más explícitas?

One API to Rule Them All

x0s3 — Thu, 11 Sep 2025 16:02:07 +0000

One API to Rule Them All: Unificando Logs y Más en Proyectos de Gran Escala

Introducción: El Caos de las APIs Dispersas

En proyectos de software con múltiples equipos y un ciclo de vida largo, la fragmentación de las APIs es un problema recurrente. Cada equipo, o incluso cada desarrollador, puede optar por diferentes librerías o enfoques para tareas comunes: logs, manejo de errores, peticiones HTTP, etc. Esto no solo introduce inconsistencias, sino que también aumenta la complejidad de mantenimiento, dificulta el onboarding de nuevos miembros y, en última instancia, ralentiza el desarrollo.

Imaginemos un escenario donde el logging en el frontend usa console.log o una librería específica, mientras que el backend usa otra distinta, quizás con diferentes niveles y formatos. Si necesitas centralizar los logs, o cambiar la implementación subyacente, te enfrentas a una tarea titánica.

La solución reside en la unificación. Crear una "One API to Rule Them All" para ciertas funcionalidades clave puede transformar la forma en que los equipos interactúan con el sistema.

Caso de Estudio: Unificando el Sistema de Logs

El sistema de logs es un candidato perfecto para la unificación. Es transversal a cualquier parte de nuestra aplicación, ya sea en el cliente (navegador, React Native) o en el servidor (Node.js).

El Problema sin Unificación

Inconsistencia: console.log, console.warn, debug, pino, winston, log4js. Cada uno con su sintaxis y capacidades.
Mantenimiento: Si cambiamos el sistema de logs (ej. de un file system a un cloud service), debemos modificar código en múltiples lugares y plataformas.
Capacitación: Los nuevos desarrolladores deben aprender múltiples herramientas de logging.
Centralización: Es difícil consolidar y analizar logs de diferentes fuentes con formatos dispares.

La Solución: Una Interfaz Unificada

Podemos crear una API de logging sencilla y agnóstica de la implementación. El objetivo es que los desarrolladores solo necesiten aprender una interfaz.

// src/infrastructure/log/index.ts

export type LogLevel = "info" | "warn" | "error";

export interface LoggerInterface
  extends Record<LogLevel, (message: string) => void> {
  info(message: string, context?: Record<string, unknown>): void;
  warn(message: string, context?: Record<string, unknown>): void;
  error(
    message: string,
    error?: Error,
    context?: Record<string, unknown>
  ): void;
}

export const log: LoggerInterface =
  typeof document !== "undefined"
    ? (await import("./client")).BrowserLogger
    : (await import("./server")).ServerLogger;

Consejo del abuelo: Entornos como Bun, Cloudflare, Deno definen un objeto window similar al del navegador, aunque no estén ejecutándose en un navegador web. Esto lo hacen para mantener la compatibilidad con el código JavaScript que espera la presencia de este objeto global. Por lo tanto el único que tiene document (es decir elementos html) es el navegador.

Con esta interfaz, cualquier parte de nuestro código, ya sea en el cliente o en el servidor, solo necesita importar log y usar sus métodos.

La Magia de los Bundlers: Implementaciones Específicas para Cada Entorno

La belleza de esta arquitectura se maximiza con bundlers modernos como Turbopack y Vite. Estos nos permiten tener múltiples implementaciones para la misma interfaz, y el bundler se encarga de empaquetar solo el código relevante para el entorno final (cliente o servidor).

Esto se logra gracias a técnicas como el Tree Shaking o la eliminación de código muerto. Cuando el bundler procesa el código para el cliente, se da cuenta de que la implementación del logger para el servidor nunca es utilizada y, por lo tanto, la elimina por completo del bundle final, resultando en un paquete más pequeño y optimizado. Lo mismo ocurre en el lado del servidor, donde la implementación del cliente es descartada.

Implementación para el Navegador (Cliente):

// src/intrastructure/log/browserLogger.ts
"client only";

import type { LoggerInterface, LogLevel } from "./";

const formatMessage = (
  level: LogLevel,
  message: string,
  context?: Record<string, unknown>
) =>
  `[${level.toUpperCase()}] ${message} ${context ? JSON.stringify(context) : ""}`;

export const BrowserLogger: LoggerInterface = {
  info(message: string, context?: Record<string, unknown>): void {
    console.info(formatMessage("info", message, context));
    // Sentry/Datadog/Bugsnag implementation
  },
  warn(message: string, context?: Record<string, unknown>): void {
    console.warn(formatMessage("warn", message, context));
    // Sentry/Datadog/Bugsnag implementation
  },
  error(
    message: string,
    error?: Error,
    context?: Record<string, unknown>
  ): void {
    console.error(formatMessage("error", message, context), error);
    // Sentry/Datadog/Bugsnag implementation
  },
};

Implementación para el Servidor (Node.js):

Aquí podemos usar librerías robustas como pino o winston.

// src/infrastructure/log/server.ts
"server only";

import type { LoggerInterface } from "./log";
import pino from "pino";

const pinoLogger = pino({
  level: process.env.LOG_LEVEL || "info",
  transport: {
    target: "pino-pretty",
    options: {
      colorize: true,
    },
  },
});

export const ServerLogger: LoggerInterface = {
  info(message: string, context?: Record<string, unknown>): void {
    pinoLogger.info(context, message);
  },
  warn(message: string, context?: Record<string, unknown>): void {
    pinoLogger.warn(context, message);
  },
  error(
    message: string,
    error?: Error,
    context?: Record<string, unknown>
  ): void {
    pinoLogger.error({ err: error, ...context }, message);
  },
};

El patrón clave aquí es diferenciar el entorno desde donde vamos a ejecutar nuestro logger, lo que permite a los bundlers como Next.js y Vite optimizar el código para cada entorno.

Beneficios Tangibles de la Unificación

Consistencia: El código se ve y se comporta de manera similar en todo el proyecto.
Mantenimiento Simplificado: Los cambios en la implementación de una API se hacen en un solo lugar.
Facilidad de Testing: Las interfaces claras facilitan la creación de mocks y pruebas unitarias.
Menor Curva de Aprendizaje: Los nuevos desarrolladores solo necesitan aprender la API unificada, no múltiples herramientas.
Reusabilidad del Código: La lógica de negocio puede ser más agnóstica a la plataforma.
Desacoplamiento: El código que usa la API está desacoplado de su implementación específica.

Conclusión

Adoptar el patrón "One API to Rule Them All" para funcionalidades transversales es una inversión que rinde frutos a largo plazo en proyectos complejos. Reduce la fricción, mejora la calidad del código y, gracias a las capacidades de optimización de bundlers como Vite y Webpack/Turbopack, nos permite mantener un código limpio y unificado sin sacrificar el rendimiento. Empezar con el sistema de logs es un excelente primer paso para demostrar el valor de esta estrategia.

Gradual React-Router-Dom Upgrades (complex case)

x0s3 — Tue, 10 Jan 2023 13:49:56 +0000

Demo of Gradual React-Router-Dom Upgrades 🪢🪡

This is a demo of how you can configure a build system to serve two different versions of React-Router-Dom side by side in the same app. This is not optimal, and should only be used as a compromise to prevent your app from getting stuck on an old version of React-Router-Dom.

Learn more about Gradual Upgrades.

I highly recommend using their backward compatible library, it's amazing! compat-lib, congratulations to the team for their wonderful work and how easy they made everything!

Why NOT Do This 🙅‍♂️

Note that this approach is meant to be an escape hatch, not the norm.

Normally, React team encourage us to use a single version of libs across our whole app. When we need to upgrade React-Router-Dom, it is better to try to upgrade it all at once.

Using a single version of React-Router-Dom removes a lot of complexity. It is also essential to ensure the best experience for our users who don't have to download the code twice. Always prefer using one Router if you can.

Why Do This 🕺

However, for some apps that have been in production for many years, upgrading all routes at once may be prohibitively difficult. For example, if the application code does not follow consistency in representing the application's routes or does not have a good test coverage.

Traditionally, this meant that if a legacy API is deprecated, we would be stuck on the old version of React-Router-Dom forever. That prevents our whole app from receiving improvements and bugfixes. This repository demonstrates a hybrid approach. It shows how we can use a newer version of React-Router-Dom for some parts of our app, while lazy-loading an older version of React-Router-Dom for the parts that haven't been migrated yet.

This approach is inherently more complex, and should be used as a last resort when we can't upgrade.

We have to options:

We either wail until the entire application is migrated with the new Router or
We can apply the well known strangler pattern to our frontend application

The strangler pattern comes from the idea of generating incremental value for the business and the user by releasing parts of the applications instead of waiting for the wholly new application to be ready.

Basically, with this gradual upgrade, we can tackle an area of the app where we think we may generate value for the business, build with the new features/router, and deploy them in the production environment living alongside the legacy application. Besides, by doing it incrementally we avoid introducing bugs and in case of failure it is much easier to perform a rollback of the route.

This way we can wait for the team that maintains the library to incorporate the Prompt functionality again 😜

Version Requirements 🎬

This demo uses two different versions of React-Router-Dom: RRD 6 for "modern" routes (in src/modern), and RRD 5 for "legacy" routes (in src/legacy).

I still recommend upgrading the entire application to RRD 6 at once. The remix team, has created some migration guidelines and even a compat layer, but sometimes we are not always fortunate enough to be able to carry out these migrations in the way they are proposed.

However, if you're already stuck on an old version of RRD, you may found this approach useful today.

keep in mind that the usage of third-party libraries included in this demo (React-Router-Dom) may need to be adjusted or removed 👍

Installation 👷‍♂️

To run this demo, clone the project, open its folder and execute:

npm i
npm start

If you want to test the production build, you can run instead:

npm i
npm run build
npx serve -s build

If you want to analyze the production build, you can run:

npm i
npm run build
npm run analyze

This sample app uses client-side routing and consists of five routes:

/ renders a page which uses a newer version of React-Router-Dom
/users/:id renders a page which uses new features such a defer and loader
/about renders a page which uses an older version of React-Router-Dom for a part of its tree. (In the production build, you can verify that both versions of React-Router-Dom are loaded from different chunks.)
/dashboard renders a page which uses an older version of React-Router-Dom for a part of its tree. (In the production build, you can verify that both versions of React-Router-Dom are loaded from different chunks.)
/error renders a page which uses a newer version of React-Router-Dom and catches all non-existent routes in both systems

The purpose of this demo is to show some nuances of such setup:

How to install two versions of React-Router-Dom in a single app with npm side by side
How to avoid the "invalid Hook call" error while nesting React trees
How to pass context between different systems
How to lazy-load the second React bundle so it's only loaded on the routes that use it
How to do all of this without a special bundler configuration

How It Works 👨‍🏫

File structure is extremely important in this demo. It has a direct effect on which code is going to use which version of React. This particular demo is using Create React App without ejecting, so it doesn't rely on any bundler plugins or configuration. The principle of this demo is portable to other setups.

Dependencies 🏭

We will use three different package.jsons: one for non-React code at the root, and two in the respective src/legacy and src/modern folders that specify the React dependencies:

package.json: The root package.json is a place for build dependencies (such as react-scripts) and any React-agnostic libraries (for example, lodash, immer, or redux). We do not include React or any React-related libraries in this file
src/legacy/package.json: This is where we declare the react and react-dom dependencies for the "legacy" trees. In this demo, we're using React-Router-Dom 5.3.4 (although, as noted above, we could downgrade it further below). This is also where we specify any third-party libraries that use React. For example, react-redux or other libs
src/modern/package.json: This is where we declare the react and react-dom dependencies for the "modern" trees. In this demo, we're using React-Router-Dom 6.6.1. Here, we also specify third-party dependencies that use React and are used from the modern part of our app. This is why we also have react-router-dom in this file. (Their versions don't strictly have to match their legacy counterparts, but features that rely on context may require workarounds if they differ, in this case, the contexts follow the same structure and we don't have to make any custom compat layer v6->v5.)

The scripts in the root package.json are set up so that when you run npm install in it, it also runs npm intall in both src/legacy and src/modern folders.

Folders 📁

There are a few key folders in this example:

src: Root of the source tree. At this level (or below it, except for the special folders noted below), you can put any logic that's agnostic of React. For example, in this demo we have src/index.js which is the app's entry point. These regular modules only execute once, and are not duplicated between the bundles.
src/legacy: This is where all the code using the older version of React should go. This includes React components and Hooks, and general product code that is only used by the legacy trees.
src/modern: This is where all the code using the newer version of React should go. This includes React components and Hooks, and general product code that is only used by the modern trees.
src/shared: You may have some components or Hooks that you wish to use from both modern and legacy subtrees. The build process is set up so that everything inside src/shared gets copied by a file watcher into both src/legacy/shared and src/modern/shared on every change. This lets you write a component or a Hook once, but reuse it in both places.

Lazy Loading 📩

Loading two Reacts on the same page is bad for the user experience, so we should strive to push this as far as possible from the critical path of our app. For example, if there is a route that is rarely visited, those are better candidates for staying on an older version of React-Router-Dom than parts of our homepage.

To encourage only loading the older React-Router-Dom when necessary, this demo includes a helper that works similarly to React.lazy. For example, src/modern/LegacyApp.js, simplified, looks like this:

import { Suspense } from "react";
import lazyLegacyRoot from "./lazyLegacyRoot";

// Lazy-load a component from the bundle using legacy Router
const LegacyAppBridge = lazyLegacyRoot(() => import("../legacy/LegacyApp"));

export function LegacyApp() {
  return (
    <>
      <h2>src/modern/LegacyBridge.js 🚨</h2>
      <h3>This component is rendered by the outer React-Router-Dom v6.6.1.</h3>
      <Suspense fallback={null}>
        <LegacyAppBridge />
      </Suspense>
      <br />
    </>
  );
}

As a result, only if the /about page gets rendered, we will load the bundle containing the legacy Router and the legacy AboutPage component. Like with React.lazy(), we wrap it in <Suspense> to specify the loading indicator:

<Suspense fallback={<Spinner />}>
  <LegacyAppBridge />
</Suspense>

If the legacy component is only rendered conditionally, we won't load the second Router until it's shown:

<>
  <button onClick={() => setShowGreeting(true)}>Say hi</button>
  {showGreeting && (
    <Suspense fallback={<Spinner />}>
      <Greeting />
    </Suspense>
  )}
</>

The implementation of the src/modern/lazyLegacyRoot.js helper is included so we can tweak it and customize it to our needs. Remember to test lazy loading with the production builds because the bundler may not optimize it in development.

Navigating between routes of different systems 🏄‍♂️

It is very likely that at some point we will need to redirect our users from a migrated route to a legacy route and vice versa.

To do this, it must be remembered that the navigation performed and managed by React-Router-Dom is relative to the context where it is being rendered.
That is, if the user is in the old system and wants to navigate to a page which is totally managed by the new system, if we make use of Link or history.push it will not work as expected because it will look for the path in the Switch of the old system.

Therefore, to perform such navigations, we must delegate the responsibility of performing those navigations to the native html, using an anchor (aka <a href="/path/en/new/system" />).

by using an anchor we have the disadvantage that all requests will be performed again and the current status on the client side will be lost 😰 but we can fix that 🤫

With DI 🌈

If we find the need to navigate without having to lose the current status of the application and prevent unnecessary requests, we have a solution for this problem ✌️

Basically we will inject the navigate function of the new system into one of the legacy system contexts, this is totally licit to do, since executing a function is possible in JavaScript 😜

i.e:

Disclaimer: this is an example and for this reason best practices are not used, in our projects do it calmly and following the best possible practices 🥶

// ./src/modern/lazyLegacyRoot.js

import { useNavigate } from "react-router-dom";

function lazyLegacyRoot() {
  // ...

  const navigate = useNavigate();

  const context = useMemo(() => ({ router, navigate }), [router]);
  // ...
}

// ./src/legacy/createLegacyRoot.js

import { createContext, useContext } from "react";

const ModernBridge = createContext(null);
export const useModernBridge = () => useContext(ModernBridge);

function Bridge({ children, context }) {
  return (
    <ModernBridge.Provider value={context.navigate}>
      <__RouterContext.Provider value={context.router}>
        <BrowserRouter>{children}</BrowserRouter>
      </__RouterContext.Provider>
    </ModernBridge.Provider>
  );
}

// ./src/legacy/LegacyApp.js

import { useModernBridge } from "./createLegacyRoot";

function AboutPageLegacy() {
  const navigate = useModernBridge();

  return (
    <div>
      <button onClick={() => navigate("/users/120")}>
        Navigate to modern system page
      </button>
    </div>
  );
}

In this way, the state of our application remains intact and the navigation is performed by our new routing system 🤭.

but be careful not to mix too much, there is a fine line that separates the lawful from a failed production 🤪

Context 🏗

If we have nested trees managed by different versions of React-Router-Dom, the inner tree won't "see" the outer tree's Contexts.

This breaks third-party libraries like React-Redux or React-Router, as well as any of our own usage of Context (for example, for theming or auth).

To solve this problem, we read all the Contexts we care about in the outer tree, pass them to the inner tree, and then wrap the inner tree in the corresponding Providers. We can see this in action in two files:

src/modern/lazyLegacyRoot.js: Look for useContext calls, and how their results are combined into a single object that is passed through. We can read more Contexts there if our app requires them.
src/legacy/createLegacyRoot.js: Look for the Bridge component which receives that object and wraps its children with the appropriate Context Providers. We can wrap them with more Providers there if our app requires them.

Note that, generally saying, this approach is somewhat fragile, especially because some libraries may not expose their Contexts officially or consider their structure private. We may be able to expose private Contexts by using a tool like patch-package, but remember to keep all the versions pinned because even a patch release of a third-party library may change the behavior.

Nesting Direction ↩️

In this demo, we use an older Router inside an app managed by the newer Router. However, we could rename the folders and apply the same approach in the other direction.
It all depends on the degree of dependency of the application, such as state management, layouts, etc.

Personally, doing it from the outside in is much simpler since at the end there will come a point when the legacy folder is empty and all we have to do is delete it and return to the initial state, just a src folder 😉 (also known as Strangler Pattern)

Gotchas 🕵️‍♂️

This setup is unusual, so it has a few gotchas.

Don't add package.json to the src/shared folder. For example, if we want to use an npm React component inside src/shared, we should add it to both src/modern/package.json and src/legacy/package.json instead. We can use different versions of it but make sure our code works with both of them — and that it works with both Reacts!
Don't use React outside of the src/modern, src/legacy, or src/shared. Don't add React-related libraries outside of src/modern/package.json or src/legacy/package.json
Remember that src/shared is where we write shared components, but the files we write there are automatically copied into src/modern/shared and src/legacy/shared, from which we should import them. Both of the target directories are in .gitignore. Importing directly from src/shared will not work because it is ambiguous what react refers to in that folder
Keep in mind that any code in src/shared gets duplicated between the legacy and the modern bundles. Code that should not be duplicated needs to be anywhere else in src (but we can't use React there since the version is ambiguous)
We'll want to exclude src/*/node_modules from our linter's configuration, as this demo does in .eslintignorerc

Many points mentioned in the list can be solved by adapting our bundler, such as webpack, and resolving the packages so that they are not duplicated when the application is compiled

This setup is complicated, and is not recommended for most apps. However, I believe it is important to offer it as an option for apps that would otherwise get left behind.
There might be better ways to perform such migrations, but having another alternative as an example is always a good thing ☺️.

A few of my own considerations 🤠

Better not to delegate the status of the application to the router status (saves a lot of unnecessary headaches)
To avoid extremely complexities in handling global states, I highly recommend the use of tools like jotai, apart that we can import this from either folder without duplicating the object/state! 😲
Please, for this to come out with an erotic result, I will not tire of recommending to add observability to our architecture, observability closes the feedback loop when our code runs in a production environment; otherwise, we would not be able to react quickly to any incidents happening durint prime time. (is a must-have feature! 🙏)
Draw up a plan of action to migrate all the routes in a certain period of time, and determine which routes will be the first, it is always good to set a date to force us to work on it and that this migration does not remain in an application with both systems coexisting forever, thus being a new Frankestein 🧟‍♂️

Credits to the React team for this great alternative to make changes to legacy applications in an incremental and painless way also to the remix team for react router dom compatibilities between versions 💚

Repo can be found here ✌️

Reinforcing confidence in our code

x0s3 — Tue, 06 Dec 2022 11:04:56 +0000

Test coverage 📉 🔜 📈

I'll start by sharing what test coverage is with what someone once explained to me with the following analogy:

Warm up == Testing 🧥

The percentage of skin we cover to keep warm is the Code Coverage
No need to cover up completely to keep out the cold and <100% coverage is fine
The ability of the garment to protect us from the cold is the quality of the test
If we wear several layers of clothing, we have duplicate tests, but sometimes it is convenient to cover ourself with more than one garment, each with its own purpose
There are uncomfortable clothes, difficult to take off and put on. There are uncomfortable and difficult to maintain tests
If we have to take off all our clothes and get cold to pee, we are suffering from coupled tests
There are garments that do not last, as well as tests, which can be fragile

Extra point

We can bundle up at home and then go outside (TDD), or we can go outside and wait until we are cold 🥶

That said, let's get down to business 🕵️‍♂️

Where we are today 🏚

Following the points mentioned above, currently our code coverage is almost non-existent:

DISCLAIMER: ⚠️ This is fake data ⚠️

=============================== Coverage summary ===============================
Statements   : 15.53% ( 2732/17590 )
Branches     : 13.17% ( 946/7179 )
Functions    : 11.85% ( 613/5169 )
Lines        : 15.72% ( 2635/16752 )
================================================================================

If we review a little more, we can see that more than half of our project has a.... ¡0%! 🚨

and if we review that 41%, we find that only 56 files have a good coverage (only 12% of our code 😱):

Why is it important?

As engineers we have to care and make sure that our code is functional for our users and that the requirements set by product are met without errors.

One thing I like to think about is that we as software engineers have to make sure that both product and user expectations are met in a realistic way, and one of the tools we have to accomplish that task under our belt is programming.

Therefore, we have to think not only about the present, but beyond that and think about our future and the future partners who will have to take over the project. That is why one of the tools that we also have at our disposal is to check that our code works, and not just now, but over time, and this is very important because it is where over time is where the benefits of the effort in writing tests can be seen.

Next steps 👣

Knowing where we are starting from, let's make a joint approach on how we can increase this lack of coverage.

Here are a few points as entry points to the discussion/brainstorming 🧠:

Focus on case coverage* rather than code coverage
All new code must have tests
If any file is modified, a test case should be added for that case

case coverage*: Since this is a project that is generating revenue and there are thousands of users using it, it will be best to initially focus our energy on covering all those parts that are most important for the proper functioning of the application. The best way to do this is to talk to the stakeholders and find out which of these parts need to be covered with the highest priority.

e.g: If something stopped working, what part would you wish it didn't?

e.g: Which part would have the most impact if it were temporarily down?

Once we know what we have to reinforce first, we will have to make an analysis of the code and know if we are facing a case of detestable code or not, since it is not the same to invest hours and hours in testing something fragile (as mentioned at the beginning) than to look for alternatives and iterate little by little until we have something reliable ⭐.

Since depending on that we will have to apply E2E first and once they are working, we can perform a refactor in that part of the code with the assurance that we will not break anything or introduce regressions, and as the new code must be better than the previous and is intended to be testable we will have both E2E (happy path) and unit tests/integration that will give us the security and confidence that we were missing 🥰.

In future posts we will talk about how to analyze our code to know which parts are urgently asking for a refactor and how to approach this task.

C u in the next post! 🫶💚 (and don't forget to drink 2L of water per day!)

Rethinking the reducer pattern 🧑‍🏭

x0s3 — Tue, 29 Nov 2022 22:03:34 +0000

Reducers and DX 🧑‍🏭

As an introduction to this topic, let's make a small reminder of what a reducer is.

Reducers are functions that take the current state and an action as arguments, and return a new state result.

With that in mind, we can already get an idea that we can work with complex data structures or not, and be able to keep track of how the flow of our state works (aka the famous one way data binding 😬).

That said, let's go into a little more detail about how we can improve our reducers 🤠.

I highly recommend reading the new documentation of the useReducer hook.

Extracting State Logic into a Reducer and useReducer

Where we are right now 😵

Right now we are at a point where we don't know what's going on in our codebase, and worse, we don't know where the problems are coming from.

We started to analyze all the code in detail and we realized from what we were told this morning at the standup that the error occurs when a user performs certain actions, so, we who are very smart, with that little information we can already get an idea that some data in one of these actions is being lost or corrupted.

We get down to work and see that the code has a Switch with 900lines, with very nested state property assignments and side-effects 🤯

Not so cool reducer (code example):

import { useReducer } from "react";

const ADD_PRODUCT = 'ADD_PRODUCT';
const UPDATE_PRODUCT_STATUS = 'UPDATE_PRODUCT_STATUS';

const INITIAL_PRODUCTS_STATE = { products: {} };

// this does not scale, is difficult to track and is very bug prone...
const reducer = (state = INITIAL_PRODUCTS_STATE, action) => {
  switch (action.type) {
    case ADD_PRODUCT:
      return {
        ...state,
        products: {
          ...state.products,
          [action.key]: action.product,
        },
      };
    case UPDATE_PRODUCT_STATUS:
      return {
        ...state,
        products: {
          ...state.products,
          [action.key]: {
            ...state.products[action.key],
            status: action.newStatus,
          },
        },
      };
    default:
      return state;
  }
};

/*
It might seem that our component is super easy, pretty and has hardly any lines of code, but it really hides a dark secret that can make us cry and pull our hair out in the near future...

What would happen if tomorrow we want to change the name of our action in the reducer? 🤔
And what happens if a component makes a mistake in dispatching the wrong action? 🤔
And what happens if we change the component that manages the products? 🤔
And if I have to make a change in the state in which I have to access a very deep property which has a nesting level that is more than 3 levels? 🤔
*/
function Example_withBadReducer() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <div>
      <p>Current products are {JSON.stringify(state.products)}</p>
      <ProductHandler dispatch={dispatch} />
    </div>
  );
}

/*
 In the context of ProductHandler, what is the value of the "dispatch" property? What can I do with that prop? This component is highly coupled to the internal logic of the parent component, which is a bad thing.
*/
function ProductHandler({ dispatch }) {
  return (
    <>
      <button
        onClick={() =>
          dispatch({
            type: "ADD_PRODUCT",
            payload: {
              key: "my_permission",
              status: "PENDING",
            },
          })
        }
      >
        Initialize permission
      </button>
      <button
        onClick={() =>
          dispatch({
            type: "UPDATE_PRODUCT_STATUS",
            payload: { key: "my_permission", newStatus: "FULL" },
          })
        }
      >
        Change permission status
      </button>
    </>
  );
}

Where we want to go 😍

We do not want to have the best code in the world (in fact we want it but it is quite complicated), but to have the code that best suits our circumstances and that we are not afraid to touch in the future.

But, what characteristics should a code have so that we are not afraid to work with it? there are more but let's put those for now

Easy to understand and identify
Easy to maintain and scale
Easy to debug

Let's take note of these 3 characteristics and see what we can do to achieve it 🫡.

Reducer with steroids (code example):

dependencies: userImmer + immer*

import { useMemo } from "react";
import { useImmerReducer } from "use-immer";

/* 
Maybe this reminds us of Redux, but it is a mistake to link this only with Redux, since this is a pattern within the paradigm of functional languages, but that's another topic that we will not deal with now 🤪
*/
function useSelectors([state], mapStateToSelectors) {
  return useMemo(
    () => mapStateToSelectors(state),
    [state, mapStateToSelectors]
  );
}

function useActions([, dispatch], mapDispatchToActions) {
  return useMemo(
    () => mapDispatchToActions(dispatch),
    [dispatch, mapDispatchToActions]
  );
}

/*
Pure functions that can be unit tested without any difficulty 🥰

The only drawback we have here is that our functions are coupled to exist within the context of immer, but under my point of view this is a lesser evil
*/
const ACTION_HANDLERS = {
  ADD_PRODUCT: (state, { payload }) => {
    state.products[payload.key] = payload.status;
  },
  UPDATE_PRODUCT_STATUS: (state, { payload }) => {
    state.products[payload.key] = payload.newStatus;
  },
};

const initialState = { products: {} };
function reducer(state = initialState, action) {
  const handler = ACTION_HANDLERS[action.type];

  return handler ? handler(state, action) : state;
}

function Example_withImmer() {
  const productsReducer = useImmerReducer(reducer, initialState);
  // May seem a bit verbose, but, if it does, perhaps you should not use a reducer 🥵
  const { addProduct, changeProductStatus } = useActions(
    productsReducer,
    (dispatch) => ({
      addProduct: (product) =>
        dispatch({ type: "ADD_PRODUCT", payload: product }),
      changeProductStatus: ({ key, newStatus }) =>
        dispatch({
          type: "UPDATE_PRODUCT_STATUS",
          payload: { key, newStatus },
        }),
    })
  );
  const { getProducts } = useSelectors(productsReducer, (state) => ({
    // here is where we should use `reselect`, `useCallback`/`useMemo` or a stable reference to our custom selectors function
    getProducts: () => state,
    // getProductById: (id) => state.products?.[id]
  }));

  return (
    <div>
      <p>Current products are {JSON.stringify(getProducts())}</p>
      <ProductHandler
        addProduct={addProduct}
        changeProductStatus={changeProductStatus}
      />
    </div>
  );
}

/*
 > Is an example to compare with the case we have been analyzing 🤓

 Instead of prop drilling the dispatch function, here we can see how our code now has a semantic relationship with our action, instead of making an act of faith and interpreting without certainty that the dispatch type is correct (e.g: a typo)*.

 Another problem of using the dispatch in a child component, is that this component should not necessarily know anything about the parent, it should only execute without taking into account the logic that its ancestor is handling.

 > * if we use TypeScript, many of these problems would disappear in dev/build time, since the compiler will tell us that something is wrong. 
*/
function ProductHandler({ addProduct, changeProductStatus }) {
  return (
    <>
      <button
        onClick={() => addProduct({ key: "my_permission", status: "PENDING" })}
      >
        Initialize permission
      </button>
      <button
        onClick={() =>
          changeProductStatus({ key: "my_permission", newStatus: "FULL" })
        }
      >
        Change permission status
      </button>
    </>
  );
}

As we can see in this new scenario, the code is much cleaner and more compact, we have the facility to update our state in a mutable way with the benefit that it will actually be done in an immutable way, without forgetting that we are no longer using an imperative control mechanism ejem switch ejem (and that is O(n)), but now we use a variant of a "hashmap" in JavaScript thanks to the properties of the objects (giving us O(1)).

So, if we analyze this new version with the requirements we have previously set ourselves:

Easy to understand and identify ✅ > By binding actions with their handlers we can give a name and a purpose to the functions that will generate a change in our state, in this way, we comply with the principle of least privilege, also known as PoLP, basically our components will have the bare minimum privileges it needs to perform its intended function (and not the ability to be able to perform other actions without us knowing it, as in the previous case with the dispatch as a prop).
Easy to maintain and scale ✅ > In our reducer, by making use of the object properties, we can find out much faster and without having to affect the rest of the cases if we add or remove any action, and thanks to the use of immer we can find out what purpose this action has in our state. And how wonderful it is to see that your child component is actually no longer coupled to the implementation of the parent, but is bound to the properties that it receives (much easier to modify, change and test).
Easy to debug ✅ > Unwittingly, thanks to the previous modifications, we have managed to obtain a code that is much easier to debug and analyze, we have pure functions that are not complex at all and in the stacktrace we will have also available the name of the function which has caused the problem.

In this scenario we find that we cannot normalize the data coming from the backend, or at least for now, so, thanks to using immer* we drastically reduce the probability of screwing it up.

Tip: Please always normalize the data, working with a flat structure is less prone to failure than having a data structure with deep-nested properties. These people explain it very well, although if you can have a BFF it is always much better than delegating the responsibility of managing the domain structures to the client side. (in another post we can discuss about how and where such data normalization can best be done 🤔)

Conclusion 🏁

As a personal conclusion, I think that reducers are a very powerful pattern but at the same time it is very complex to perform correctly, so I think that following these small guidelines within a professional environment can help a lot to identify what the code does and above all to avoid possible errors.

Mocking apollo hooks

x0s3 — Wed, 30 Dec 2020 14:07:10 +0000

Pues bueno, parece que ha pasado ya más de un año desde mi última publicación (con una pandemia de por medio y mil catástrofes que parecía que se iba a acabar el mundo, o en su defecto el papel higiénico en los supermercados 🧻).

Así que nada antes de empezar me gustaría felicitar a todos los lectores unas felices y seguras fiestas y que Papa Noel os haya traído muchas mascarillas! 🎅 😷

Manos a la obra!

Una de las adversidades que he ido viendo en los proyectos que he estado trabajando y en la gente que lo forma, es la oscuridad que hay detrás de los mocks (en este caso de jest) y el cómo su uso nos puede beneficiar tanto en tiempo de desarrollo como a la hora de escribir nuestras pruebas unitarias.

Un ejemplo que a primera vista parece MUY sencillo, luego a la hora de hacer sus pruebas unitarias puede llegar a ser enrevesado, el caso es el siguiente:

Tenemos un component que queremos transformar sus props a un objeto mas "component friendly", para así luego renderizar nuestro html con dichas props ya mappeadas:

dummy hook que nos facilita la vida (nos olvidamos del ApolloMockProvider y movidas varias)

import * as ApolloReactHooks from '@apollo/react-hooks';
import gql from 'graphql-tag';

const QUERY_USER = gql`
  query getUser {
    user {
      data {
        firstName
        lastName
        age
      }
    }
  }
`;

export function useGetUserLazyQuery(
  baseOptions: ApolloReactHooks.QueryHookOptions
) {
  return ApolloReactHooks.useLazyQuery(QUERY_USER, baseOptions);
}

sí, lo sé, no he importado React, beneficios de usar React 17 😬

fake component que efectúa la llamada a nuestro backend y nos muestra por pantalla la información del usuario una vez recibida la query

import { useState } from 'react';
import { useGetUserLazyQuery } from '@hooks/useGetUserLazyQuery';

interface User {
  name: string;
  age: number;
}

export function User() {
  const [user, setUser] = useState<Partial<User>>({});
  const [queryUser, { called, loading }] = useGetUserLazyQuery({
    onCompleted: ({ data: { firstName, lastName, age } }) => {
      const user: User = {
        name: `${firstName} ${lastName}`,
        age: age,
      };
      setUser(user);
    },
  });

  const performQuery = () => {
    queryUser();
  };

  if (called && loading) return <p>Loading ...</p>;

  if (!called) return <button data-testid="load-users-btn" onClick={performQuery}>Load user</button>;

  return (
    <div>
      <ul>
        <li>Name: {user.name}</li>
        <li>Age: {user.age}</li>
      </ul>
    </div>
  );
}

Ahora viene dónde la matan, como podemos invocar el callback onCompleted en nuestro caso? 🤔

Que no cunda el pánico, no vamos a tener que hacer refactor de nuestro componente para que use un useEffect para reaccionar al cambio de la prop data ni nada por el estilo para que nuestro test pase ✅

import { screen, render, waitFor } from '@testing-library/react';
import userEvent from '@testing-library/user-event';
import { useGetUserLazyQuery } from '@hooks/useGetUserLazyQuery';
import { User } from '../User';

jest.mock('@hooks/useGetUserLazyQuery', () => ({
  useGetUserLazyQuery: jest.fn(),
}));

const userMock = {
  data: {
    firstName: 'Freddy',
    lastName: 'Krueger',
    age: 288,
  },
};

function renderComponent() {
  return render(<User />);
}

function mockQuery({ result }) {
  let onCompletedHasBeenCalled = false;

  const getUserCall = jest.fn();

  (useGetUserLazyQuery as jest.Mock).mockImplementation((d) => {
    // este condicional previene que la llamada a OnCompleted acabe en un bucle infinito y nos fastidie todo, únicamente lo ejecutaremos una única vez
    if (!onCompletedHasBeenCalled) {
      d.onCompleted(result);
      onCompletedHasBeenCalled = true;
    }

    return [getUserCall, { called: true, loading: false }];
  });

  return getUserCall;
}

describe('User component', () => {
  it('renders user data', async () => {
    const mockedQuery = mockQuery({ result: userMock });
    renderComponent();

    userEvent.click(await screen.findByTestId('load-users-btn'))

    const {
      data: { age, firstName, lastName },
    } = userMock;

    expect(screen.getByText(age)).toBeInTheDocument();
    expect(screen.getByText(firstName, { exact: false })).toBeInTheDocument();
    expect(screen.getByText(lastName, { exact: false })).toBeInTheDocument();

    await waitFor(() => {
      expect(mockedQuery).toHaveBeenCalled();
    });
  });
});

Toda la magia recae en el mockImplementation, donde vamos a poder acceder a los argumentos que nuestro custom hook está recibiendo, de esta manera nos evitamos tener que mockear TODA la llamada que esperaría el provider de apollo, así pues, evitamos tener que renderizar componentes externos que para nuestra prueba unitaria no tiene mucho sentido, y nos podemos centrar exclusivamente en la funcionalidad de dicho componente.

Lo bueno si breve, dos veces bueno y aun lo malo, si poco, no tan malo

Como diría el gran don Hector del Mar: "Aquí estoy porque he venido, porque he venido aquí estoy, si no te gusta mi canto como he venido me voy"

Que tengáis una feliz entrada de 2021 donde los mocks de apollo no sean un problema!!!

Nos vamos... pero volveremos!

Módulos nativos para React-Native con Go (3/4)

x0s3 — Tue, 03 Dec 2019 08:55:23 +0000

Ánimo que en este post ya veremos nuestra app en funcionamiento sumando en Go!!

En la parte de RN me he creado un hook para poder usar este módulo que lo he llamado useNativeCounter (el código está en el repo).

Vamos a lo que nos interesa realmente, cómo hago yo para llamar a mis funciones de Go?

Pues si hemos seguido el post anterior ya tenemos nuestros módulos linkeados en nuestro proyecto así que solo toca programar la parte del bridge.(llévame al punto de Android)

iOS

Como siempre, iOS es mucho mas simple de realizarlo que en Android muchas menos cosas a tener en cuenta y hacer.

Creamos 2 archivos: el Header SampleModule.h y los Métodos SampleModule.m

en el archivo SampleModule.h con poner lo siguiente es suficiente

⚠️⚠️ "caution" ⚠️⚠️

El nombre que le demos a esta interfaz debe de ser el mismo que le daremos en Android, si no habra discordancia entre plataformas. Yo lo llamaré SAMPLE_MODULE como ejemplo.

Luego en nuestro archivo SampleModule.m podemos hacer algo tal que así

Android

(No preocuparse si tenemos Hermes habilitado, no afecta)

Podemos ir de varias maneras para poder usar nuestro módulo desde Android, aquí veremos una diferente a la de la documentación oficial de RN 😁 (de todas maneras en el repo dejo los archivos pertinentes para hacerlo de la manera oficial como en la doc.)

Vamos a crearnos una nueva clase que en este caso la llamaré SampleModule para seguir en la misma tónica que en iOS, y nuestra clase se vería algo así:

Como en iOS decía, aquí tenemos que poner el mismo nombre que queremos que el Bridge exponga a la hora de obtener los métodos y para tener ambas plataformas con el mismo nombre por eso el NAME = "SAMPLE_MODULE";

De la manera que lo haremos en este post ya no haría falta crear la clase Package, haremos esto en su lugar, nos vamos a la clase MainApplication y en getPackages añadiremos esto: (estoy usando la versión 0.61.5 de RN)

(Parece que hay mucha magia ahora mismo, pero os dejaré como siempre abajo links de interés para poder comprender todo esto de manera más amplia y que no se haga tan pesado este post también)

JavaScript / TypeScript

Hasta ahora y todavía se sigue haciendo así las llamadas de los módulos nativos en RN, pero aquí hemos venido a jugar e ir un poco más allá de lo normal y nos adelantaremos en el tiempo, os mostraré como olvidarnos del bridge y todos sus beneficios que eso conlleva(o no 🙃).

actualmente react-native funciona así

Módulos nativos para React-Native con Go (2/4)

x0s3 — Mon, 25 Nov 2019 13:01:10 +0000

Creación del primer módulo con Go

Pues ya estamos aquí, en esta segunda parte de esta serie de posts tan interesantes 🤥

(el gif introductorio que no falte)

Haremos algo rápido y sencillo para toda la familia, una función que la llamaremos de manera síncrona y otra de manera asíncrona para tener ambos casos contemplados (esta serie de posts no trata de realizar un módulo de dificultad avanzada ya que no es lo que toca ahora mismo).

código del módulo que usaremos(sumar en js es muy complicado 🌚):

tests (super exhaustivos oiga 🧐):

Cosas a tener en cuenta, tenemos restricción de tipos si vamos de esta manera(parte 3 bridge) ya que solo nos permite jugar con estos actualmente:

Tips/Consejitos de la abuela:

Si compiláis y luego no os aparece en vuestro módulo la función que estabais esperando obtener probablemente sea por problemas de tipado en el return de la función, así que "caution" con esto!! ⚠️⚠️
Si os encontráis en una encrucijada y si o si debéis pasar algo que no esté soportado podéis hacer un stringify o pasarlo a un array de bytes el resultado final, luego acordaos de revertir el cambio en cada plataforma! (algo es algo 🤷‍♂️)

Una vez tengamos nuestro código bien "testeadito" y queramos compilar ya todo esto, haremos uso del paquete que nos proporciona Golang "gomobile" así que si no lo tienes instalado, a qué esperas!?

$ go get golang.org/x/mobile/cmd/gomobile
$ gomobile init

Que lo queremos compilar para Android? mú' fácil!

gomobile bind [-x -v] -target=android $YOUR_FILE_PATH

Que lo queremos compilar para iOS? mú' fácil también!

gomobile bind [-x -v] -target=ios $YOUR_FILE_PATH

[-x -v]: vienen bien para hacer un seguimiento de como esta yendo el proceso de compilación, básicamente -x nos muestra que comandos realiza y -v pues de verbose, ya sabéis, que te lo muestra todo por la consola (ni la RAE con esta definición).
$YOUR_FILE_PATH: fichero de entrada (el compilador ya se encargará de buscar las referencias de otros archivos o librerías que estemos usando), si tenéis problemas compilando esto recomiendo que lo metáis en la "carpetita" ~go/src/github.com/NOMBRE_DE_TU_PAQUETE/NOMBRE_DEL_MAIN

Una vez ejecutado estos comandos (si no tienes mac solo puedes hacerlo para Android, o comprarte un mac y seguir la serie desde él, solo son 3mil eurillos de nada!!) tendremos en nuestra carpeta 3 nuevos archivos:

Android:

/**/.aar
/**/-sources.jar

iOS

/**/.framework

Ahora viene la parte divertida, que es incluir los SDK's en sus correspondientes plataformas

(si solo te interesa la parte de Android, llévame allí)

iOS

Abrimos nuestro gran amigo XCode y seleccionamos nuestro proyecto (.xcworkspace) o desde nuestro proyecto en RN

open $path_de_tu_.xcworkspace

Para iOS es mucho mas sencillo que Android, hay menos pasos a realizar para poder vincular el módulo a nuestro proyecto

Arrastramos nuestro archivo .framework a nuestro proyecto, siempre dentro del proyecto!

Automáticamente se nos vinculara el path con el que utiliza para compilar y hacer build, así que no nos debemos de preocupar de añadir la ruta manualmente (puede llegar a ser una odisea este tipo de tareas 🥵).

Android

(Voy a usar Android-Studio para esto)

Abrimos el proyecto android que tenemos en nuestro proyecto de RN y nos vamos directos a: File > New > New Module...

Se nos abrirá esta nueva ventana y seleccionamos Import .JAR/.AAR Package

Habrá que hacer esto 2 veces para importar ambos archivos

Una vez los tengamos importados ambos, nos vamos a: File > Project Structure... > Modules > app > Dependencies > Add Module dependency

Nos debería de salir ambos archivos importados, los seleccionamos y OK.

Se nos sincronizará el proyecto y ya tendremos añadido el módulo en nuestro proyecto y listo para empezar con la parte de RN en la parte 3 ✌️

Y hasta aquí este capítulo 2, bastante turra por hoy

Si has llegado hasta aquí y quieres dejar tu opinión sobre algo, tienes alguna duda o tienes problemas no dudes en hacérmelo saber!!

links de referencia:

https://godoc.org/golang.org/x/mobile/cmd/gomobile

https://godoc.org/golang.org/x/mobile/cmd/gobind

https://github.com/golang/go/wiki/Mobile#sdk-applications-and-generating-bindings

Nos vemos en la próxima entrega!!! 🥰

Módulos nativos para React-Native con Go (1/4)

x0s3 — Thu, 21 Nov 2019 13:17:25 +0000

Pues sí gente, he vuelto!

Tenía ya ganas de volver a escribir algún post y este tema la verdad que me gustaría compartirlo con todos vosotros 😄

La intención de esta serie de posts es ir de "0 to hero" en el desarrollo de módulos nativos y explicar un poco sobre el futuro de los módulos nativos de RN 🤓

La idea principal es separar por partes cada paso y digerir poco a poco todo sin que sea un tocho que ni Los Pilares de la Tierra:

Contenido previsto

Toma de contacto y motivación
Creación del primer módulo con Go
Unificar y llamar desde RN nuestro primer módulo, bridge(https://dev.to/x0s3/modulos-nativos-para-react-native-con-go-3-4-40o7)
Unificar y llamar desde RN nuestro primer módulo (PARTE 4 JSI/TurboModules 🙄 WIP)

Sin más preámbulos 'amos al lío.

Toma de contacto y motivación

En esta introducción al gran camino del desarrollo de módulos para RN con Go, voy a dar bajo mi punta de vista las ventajas que tiene:

Compatibilidad con Android y iOS con el mismo código base
Mucho mas sencillo que C++
Ahorras tiempo desarrollando la misma funcionalidad
Portabilidad a otras plataformas/entornos tales como Node.js o WASM 😜
Ser capaces de reutilizar ese módulo para futuras apps con diferentes frameworks como Flutter, NativeScript, etc.
Dar la bienvenida a las librerías de Go ya que podremos usarlas 🤩
Foco de errores y tests en un único código fuente

Por desgracia no todo son ventajas también hay que mencionar las desventajas o los pequeños problemas que puedes encontrar:

Actualmente la compatibilidad de tipos entre Go y Java/Objc no es muy amplia aún (ya explicaré en otro post o quizás en la parte 4 como podemos llegar a solventar este "problemilla")
En Android tendremos que pasar por un nuevo bridge (NDK)
Añadimos complejidad al proyecto
El tema debug quizás se hace algo mas complicado de lo normal
Tenemos que saber Go

Y ahora os preguntaréis ¿Qué tiene que ver esto con React-Native?
Pues nada la verdad, pero si que nos podemos beneficiar y se podría decir que podemos desarrollar nuestra app ¿x4 de rápido? 🤔

Básicamente nos ahorramos el tener que aprender Objc o Java (o ambos) para poder llegar a tener nuestras apps a la par en tema de funcionalidades nativas, ya sean algoritmos complejos que requieran alto rendimiento, compartir lógica de negocio o simplemente queremos beneficiarnos de alguna librería ya creada con Go.

La verdad que estoy bastante contento y sorprendido lo rápido que se puede llegar a realizar las cosas haciendo uso de Go con RN, sin ir más lejos tengo por aquí una app que las vistas son RN y todo lo demás funciona bajo un módulo de Go (la verdad que me he quitado un peso de encima al no tener que programar en Objc 😂) Repo ItBooks

Creo que lo podemos ir dejando por aquí de momento, una breve chapa, siento que en este post solo sea soltar "rollo-rollo" pero era algo necesario, los próximos serán mejores!!

Vaya el componente no existe para React-Native y no tenemos tiempo de desarrollarlo ¿qué hacemos?(Android parte I)

x0s3 — Sun, 07 Apr 2019 11:14:59 +0000

¡Buenas lector 🖖! Primero de todo gracias por hacer click en mi primer post, confío en que sea de tu agrado y sea de utilidad lo explicado aquí.

A quién no le ha pasado que desarrollando apps con React-Native no ha encontrado ese componente en JS Coach que justo necesitaba para su proyecto y no tiene tiempo de desarrollarlo él mismo? (aquí servidor 🙋🏻‍♂️)

Una de las cosas que más me costó de entender en RN es que no todo se lo tenemos que delegar a la parte de Javascript, la ventaja de usar este framework es que podemos irnos al mundo nativo y traernos lo que queramos!

Así que para esta primera parte y primer post, nos iremos al mundo nativo y nos traeremos un componente de Android Arsenal.

No será el típico ejemplo de hacer un botón en Android porque para eso ya tenemos lo que nos trae el framework, para ir haciendo una toma de contacto sobre todo lo que podemos traernos del otro mundo, empezaremos trayendo un componente sencillo ya que en nuestro proyecto nos han pedido con urgencia que implementemos un rasca y gana.Que no cunda el pánico porque esto lo solucionamos rápidamente.

Primero de todo añadiremos una librería a nuestro proyecto que nos facilitará la creación de los ficheros nativos para ello:

yarn add react-native-create-bridge

Una vez instalado lo llamamos de esta manera:

react-native new-module

Y se nos mostrará por consola una serie de opciones a elegir dependiendo de lo que queramos crear, para nuestro caso será un componente nativo y escribiremos en Java lo que haya que escribir.

Una vez hecho esto tendremos en nuestro directorio un archivo .js con el nombre que le hayamos dado a nuestro componente(en nuestro caso NativeScratchCard.js), si nos vamos a nuestro directorio Android podemos ver que la librería nos ha generado un package con el nombre "nativescratchcard" donde tenemos 2 archivos Java.

Pues bien antes de hacer nada más, importamos la librería nativa que nos salvará de este aprieto, en nuestro caso usaremos esta misma Scratch Card

(sí, lo sé, a partir de ahora podremos usar casi cualquier cosa que queramos ya hecha jeje)

Añadimos la dependencia a nuestra app, sincronizamos y listo ya podemos empezar a traer este componente.

dependencies {
    implementation 'in.codeshuffle.scratchcardlayout:ScratchCardLayout:1.0.3'
    implementation fileTree(dir: "libs", include: ["*.jar"])
    implementation "com.android.support:appcompat-v7:${rootProject.ext.supportLibVersion}"
    implementation "com.facebook.react:react-native:+"  // From node_modules
}

Nos dirigimos a NativeScratchCardManager.java y haremos unos cuantos cambios en el código generado, el primero de todos es cambiar el tipo de la clase de la que extendemos, con esto le decimos a nuestro querido rn que vamos a traernos el componente ScratchCardLayout y no una simple View.

View -> ScratchCardLayout

cambiaremos el método createViewInstance también de esta forma:

@Override
public ScratchCardLayout createViewInstance(ThemedReactContext context) {
        Log.d(REACT_CLASS, "createViewInstance");
        return new ScratchCardLayout(context);
    }

leyendo la librería nativa podemos ver que se nos expone varios métodos para poder modificar nuestra ScratchCard, nosotros expondremos 3 propiedades para poder usarlas en nuestro componente en rn: el tamaño del pincel, el porcentaje para acabar y si queremos que esté habilitado o no el componente.

¡¡Ánimo que ya casi estamos!

Ahora pensándolo bien, nos damos cuenta que queremos exponer nuestro componente escrito en Javascript dentro de este componente nativo y vaya...parece que no hay ningún tutorial explicando como conseguir esto 😱lamentablemente si queremos traer cosas del lado nativo hay que saber o al menos tener nociones sobre Android, pero no pasa nada porque aquí mostraré como hacerlo en este primer post de manera sencilla(y agradecer a Yoga que esto sea posible).

Para ello cambiaremos la clase de la que extiende nuestra clase componente

SimpleViewManager -> ViewGroupManager

y sobre-escribiremos el método addView

    @Override
    public void addView(ScratchCardLayout parent, View child, int index) {
        Log.d(REACT_CLASS, "addView");
        parent.addView(child);
    }

ya solo nos queda exponer los eventos del componente nativo a nuestro componente en js y ya habremos acabado de tocar Java.

Para no hacer demasiado extenso el post esta parte está explicada muy bien en la documentación oficial de RN (tranquilos, también adjunto captura de nuestro código)

Nos volvemos a nuestro método createViewInstance y lo modificamos para que nos exponga los eventos nativos.

    @Override
    public ScratchCardLayout createViewInstance(@NonNull ThemedReactContext context) {
        Log.d(REACT_CLASS, "createViewInstance");
        ScratchCardLayout card = new ScratchCardLayout(context);
        onReceiveNativeEvent(context, card);
        card.setScratchDrawable(context.getResources().getDrawable(R.drawable.rn_image_scratch));
        return card;
    }

Y pues ya estaríamos o no...para poder exponerlo y usarlo tenemos que añadir el package en nuestro MainApplication

        @Override
        protected List<ReactPackage> getPackages() {
            return Arrays.<ReactPackage>asList(
                    new MainReactPackage(),
                    new NativeScratchCardPackage()
            );
        }

y ahora ya si que estamos listos para pasarnos a escribir un poco de Javascript.

Modificaremos nuestro archivo generado anteriormente para que sea como este:

import React, { useCallback } from 'react';
import { requireNativeComponent } from 'react-native';

const ScratchCardView = requireNativeComponent('NativeScratchCard');

function ScratchCardComponent(props) {
  const onChange = useCallback(event => {
    switch (Object.keys(event.nativeEvent)[0]) {
      case 'started':
        props.onChange({ type: 'STARTED' });
        break;

      case 'progress':
        props.onChange({
          type: 'PROGRESS',
          payload: {
            progress: event.nativeEvent.progress
          }
        });
        break;

      case 'finished':
        props.onChange({ type: 'FINISHED' });
        break;

      default:
        break;
    }
  }, []);

  return <ScratchCardView style={props.style} {...props} onChange={onChange} />;
}

export default ScratchCardComponent;

la propiedad onChange hace referencia a topChange en nuestro código nativo, podéis leer más sobre eso en el link que he dejado más arriba sobre los eventos.

Y nuestro archivo App.tsx podemos dejarlo tal que así:

const initialState = { started: false, finished: false, progress: 0 };

function reducer(state, action) {
  switch (action.type) {
    case 'STARTED':
      return { ...state, started: true };
    case 'FINISHED':
      return { ...state, finished: true, progress: 100 };
    case 'PROGRESS':
      return { ...state, progress: action.payload.progress };
    default:
      throw new Error();
  }
}

export default function App() {
  const [state, dispatch] = useReducer(reducer, initialState);

  return (
    <View style={styles.container}>
      <Text style={styles.text}>
        Scratch started? {state.started ? 'Yep :)' : 'Nop :('}
      </Text>
      <Text style={styles.text}>
        Is finished? {state.finished ? 'Yep :)' : 'Nop :('}
      </Text>
      <Text style={styles.text}>Current progress: {state.progress}</Text>
      <ScratchCard
        onChange={dispatch}
        style={{ width: 300, height: 300 }}
        finishAt={100}
        brushWidth={20}
        enabled={true}
      >
        <Text style={styles.welcome}>HEY IM YOUR JSX COMPONENT!!</Text>
      </ScratchCard>
    </View>
  );
}

Y si todo ha ido bien una vez compilamos la app nos debería de aparecer ya el componente

Y funcionando correctamente

Funciona todo y desde ahora podremos usar componentes tanto nativos como de js!!

Gracias si has llegado hasta aquí, espero que no se te haya hecho muy pesado y ojalá hayas aprendido algo nuevo con este post, cualquier duda o sugerencia no dudes en hacérmelo saber!!

Link al repo de github: Repo

Forem: x0s3

Implementando un API Client Generator con Proxies de JavaScript y TypeScript Overloads

Generador de clientes: Centralizando el consumo de APIs con Proxies y TypeScript

La API Final: Así es como debería verse tu código

¿Cómo llegamos a esto? La magia por dentro

1. El Proxy como "Atrapa-todo"

2. Tipado inteligente (Function Overloads)

3. La Factoría: clientGenerator

El "Perfect Match": RSC y React Query

React Server Components (RSC)

Integración con React Query

Conclusión

One API to Rule Them All

One API to Rule Them All: Unificando Logs y Más en Proyectos de Gran Escala

Introducción: El Caos de las APIs Dispersas

Caso de Estudio: Unificando el Sistema de Logs

El Problema sin Unificación

La Solución: Una Interfaz Unificada

La Magia de los Bundlers: Implementaciones Específicas para Cada Entorno

Implementación para el Navegador (Cliente):

Implementación para el Servidor (Node.js):

Beneficios Tangibles de la Unificación

Conclusión

Gradual React-Router-Dom Upgrades (complex case)

Demo of Gradual React-Router-Dom Upgrades 🪢🪡

Why NOT Do This 🙅‍♂️

Why Do This 🕺

Version Requirements 🎬

Installation 👷‍♂️

How It Works 👨‍🏫

Dependencies 🏭

Folders 📁

Lazy Loading 📩

Navigating between routes of different systems 🏄‍♂️

With DI 🌈

Context 🏗

Nesting Direction ↩️

Gotchas 🕵️‍♂️

A few of my own considerations 🤠

Reinforcing confidence in our code

Test coverage 📉 🔜 📈

Warm up == Testing 🧥

Where we are today 🏚

Why is it important?

Next steps 👣

Rethinking the reducer pattern 🧑‍🏭

Reducers and DX 🧑‍🏭

Where we are right now 😵

Not so cool reducer (code example):

Where we want to go 😍

Reducer with steroids (code example):

Conclusion 🏁

Mocking apollo hooks

Manos a la obra!

Lo bueno si breve, dos veces bueno y aun lo malo, si poco, no tan malo

Módulos nativos para React-Native con Go (3/4)

iOS

Android

JavaScript / TypeScript

Módulos nativos para React-Native con Go (2/4)

Creación del primer módulo con Go

iOS

Android

Y hasta aquí este capítulo 2, bastante turra por hoy

Nos vemos en la próxima entrega!!! 🥰

Módulos nativos para React-Native con Go (1/4)

Contenido previsto

Toma de contacto y motivación

Vaya el componente no existe para React-Native y no tenemos tiempo de desarrollarlo ¿qué hacemos?(Android parte I)

3. La Factoría: `clientGenerator`