<button>{t('OPEN')}</button>

Y en alguna otra parte tendrás un JSON con la traducción asociada a la clave OPEN, por ejemplo en español:

{
  "OPEN": "Abrir"
}

Esto es maravilloso, pero ¿y si escribo mal la clave? 🤔

<button>{t('OPEM')}</button>

Lógicamente i18next viene con declaraciones TypeScript y debería avisarme de que la clave no existe...

... ¿verdad?...

... ¿¡VERDAD!?

Spoiler: no 🙃

Cuál es el problema

El problema es que el sistema de tipos no ve tus JSON, que contienen las claves existentes.

Para TypeScript, la función t simplemente acepta un parámetro de tipo string, algo así:

type TFunc = (key: string) => string

Y por eso t('OPEN') es tan válido como t('pepe'), porque ambos valores son string y la función acepta string. La build pasa ✅ 🤦

Pero claro, si la clave no existe en el JSON al correr la app... no habrá traducción disponible y veremos pepe como placeholder 😱

¡PAM! 💥 Otro nuevo bug al backlog 🐛

Let's fix this forever.

Función t a prueba de balas

Considerando que tenemos este JSON de traducciones al español:

{
  "OPEN": "Abrir",
  "CLOSE": "Cerrar"
}

Lo que nos interesaría es un tipado más específico que tenga en cuenta las claves:

type TFunc = (key: 'OPEN' | 'CLOSE') => string

La pregunta es: ¿cómo puedo dopar a mi función t para que sepa exactamente qué claves puede recibir?

Pues desde la v22.0 i18next te ofrece una solución. ¿Lo malo? No es automático. Pero no worries, ¡es muy fácil!

Como se explica en la documentación, creamos un archivo de declaración. Se recomienda colocarlo en src/@types/i18next.d.ts

// Importamos nuestro JSON para leer las claves
import type jsonKeys from '../i18n/es.json'

// Aumentamos los tipos del módulo i18next
declare module 'i18next' {
  interface CustomTypeOptions {
    resources: {
      // Añadimos las claves JSON en el namespace por defecto
      translation: typeof jsonKeys
    }
  }
}

Esto funciona gracias a una característica de TypeScript llamada aumento de módulos, que permite sobrescribir los tipos de cualquier librería.

La interface CustomTypeOptions la han preparado desde i18next para que podamos meter ahí nuestra estructura JSON, y así i18next la tenga en cuenta.

¡Ya está!

¿Qué pasa ahora si me equivoco en una clave?

<button>{t('OPEM')}</button>
// ❌ Argument of type '["OPEM"]' is not assignable to
// parameter of type '[key: "OPEN" | "CLOSE"]'

✅ Nunca más llegará a producción un typo en una clave de traducción.

✅ Además del IntelliSense mejorado, ya que pulsando ctrl + espacio dentro de t('') recibirás una lista de claves disponibles.

<SomeInputField setValue={setValue} /> // 🤔

Si tienes suficiente experiencia en React puede que evites esto sin siquiera pensarlo. No obstante, qué bueno es poder razonarlo para ayudar al equipo a estar en la misma página.

Si por el contrario llevas poco tiempo o ya has cogido el vicio, puede que estés pensando que no es tan malo.

Bueno, yo también he estado ahí. Let's talk about this.

Cuál es el problema

Tal vez sea verdad que hay casos pequeños donde no supone un problema aparente, pero por favor, echa un vistazo a este otro ejemplo:

<SomeComponent
  setForm={setForm}
  setCart={setCart}
  setUser={setUser}
  setMeFree={setMeFree}
/>

Ahora considera estas preguntas básicas:

• ¿Cuándo cambia cada estado?

• ¿Qué o quién los hace cambiar?

• ¿Cómo cambian exactamente?

• ¿Dónde está el código que lo hace?

Como puedes observar, el código no nos da información suficiente para responder a ninguna de las preguntas. Básicamente, no sabemos nada de estos estados.

Pero solo tengo que entrar al código de SomeComponent, ¿no? — Alguien dirá

Pues vamos adentro:

// En algún lugar de SomeComponent.jsx
<YetAnotherComponent
  setForm={setForm}
  setCart={setCart}
  setUser={setUser}
  setMeFree={setMeFree}
/>

¡Vaya! Empieza la frustración. Un bucle al más puro estilo Inception, y seguimos sin respuestas.

Es más, los setter pasarán a otros componentes hermanos y seguirán enviándose mediante props a más y más hijos en la jerarquía, multiplicando la cantidad de archivos de código a revisar.

¿Ves cuál es el problema? El estado es un elemento clave de la aplicación ¡y así es difícil saber lo que hace!

Cómo escapar de esto

Volvamos a las preguntas de antes: ¿cuándo cambia el estado? ¿cómo? ¿dónde?... ¿No sería genial poder responderlas sin tener que ir a otros archivos?

Atentos, porque hay una forma y es estándar. Y si existe un estándar es porque presenta ventajas frente a otros métodos.

Seguir estándares suele ahorrar muchos problemas.

Fíjate en el código nativo

Definitivamente no hay ninguna prop estándar con nombre de setter.

Un input no recibe setValue

¿Lo has visto en componentes nativos? ¿kits de UI? ¿librerías populares? Nada.

Lo que sí habrás visto es esto:

<input onChange={...} /> // 👀

Así es, un input nativo no ofrece una prop setValue, sino una prop onChange.

Esta prop de evento espera una función, donde típicamente se usa el contenido del argumento event para hacer una actualización de estado:

<input onChange={
  event => setValue(event.target.value)
} />

Piensa en la información tan valiosa que tenemos aquí:

• El nombre de la prop ya te da una idea de cuándo sucede

• Es fácil imaginar la acción responsable del cambio

• Se ve exactamente cómo cambia el estado

• Todo el código relevante está a la vista

¿No es genial?

La clave: división de responsabilidad

Vamos a señalar el motivo por el que esto funciona tan bien.

Cuando hay división de responsabilidad, cada pieza del sistema tiene un propósito bien definido y delimitado. A menudo se puede entender por sí misma sin acudir al resto.

Esto es importante en esta profesión, porque cuanto menos tiempo tardes en entender, antes podrás empezar a tocar.

Siguiendo con la división de responsabilidad: el input nativo no quiere saber nada de cómo se cambia tu estado, eso es problema de tu componente padre.

El input solo te habla de lo que él controla gracias a la event prop onChange:

• Cuándo ocurre un cambio

• Los detalles de ese cambio

Así que, en vez de enviar un state setter como prop, ha llegado el momento de imitar el patrón nativo: las event props.

Hazlo en tus componentes

El estado y sus valores son responsabilidad única del componente que declara el useState. Por ejemplo, si tuvieras un componente que gestiona una lista:

// List.jsx
const [list, setList] = useState([])

Digamos que vamos a tener un hijo Item con la capacidad de borrarse del listado.

El padre List es responsable de hacer cada setList en su propio código. No delegará esa responsabilidad en Item:

// También en List.jsx
const handleRemoveItem = id => setList(list.filter(...))
return <Item onRemove={handleRemoveItem} />

Item no debe saber nada sobre la lista completa del padre ni cómo ha de cambiar, pero hay dos cosas que sí son su responsabilidad:

• Cuándo se ha de borrar: porque tendrá un botón para hacerlo

• Cuál se ha de borrar: porque sabrá su propio id

Como ya hemos visto, en lugar de recibir setList directamente vamos a exponer una event prop que permita al padre estar al tanto de estas cosas:

function Item ({ onRemove }) {
  const myId = 27
  return <button onClick={() => onRemove(myId)}>❌</button>
}

Pero Item nunca decidirá qué hacer con un estado que no es suyo, y de hecho desde su código no tendrá acceso explícito a ningún setter ajeno.

Ya está, cada componente tiene su responsabilidad y ninguno invade la del otro. Vamos a mirar el código completo de List una última vez:

// ✅
function List () {
  const [list, setList] = useState([])
  const handleRemoveItem = id => setList(list.filter(...))
  return <Item onRemove={handleRemoveItem} />
}

Todas las preguntas sobre el estado tienen respuesta sin salir del archivo:

• ¿Cuándo cambia el estado? — Al suceder la acción "borrar"

• ¿Qué o quién lo hace cambiar? — El usuario que interactúa con Item

• ¿Cómo cambia exactamente? — Con un .filter(), está a la vista

• ¿Dónde está el código que lo hace? — En el mismo archivo

Pero, solo por saborear una vez más la diferencia:

// ❌
function List () {
  const [list, setList] = useState([])
  return <Item setList={setList} />
}

En contraste, aquí ya no tendríamos ni idea de cuándo, dónde, cómo o qué se está haciendo con el estado.

Conclusión

❌ Pasar state setters como props oscurece la lógica de estado fragmentándola en diferentes archivos, lo que resulta en dificultades para entenderla.

const [value, setValue] = useState('')
<SomeInputField setValue={setValue} /> // ???

✅ El estándar nativo de las event props ayuda a delimitar correctamente la responsabilidad del estado y sus cambios junto al código donde se declara el estado.

const [value, setValue] = useState('')
<AwesomeInputField onChange={next => setValue(next)} />