Dominar el Principio de Responsabilidad Única en React

Una de las mejores formas de destacar como desarrollador de React es interiorizar y aplicar realmente los principios de la ingeniería de software — especialmente el Principio de Responsabilidad Única (SRP, por sus siglas en inglés).

Aunque SRP proviene del diseño orientado a objetos, es extremadamente relevante en el mundo de React, donde la estructura de los componentes y su mantenibilidad pueden definir el éxito o fracaso de una base de código.

¿Qué es SRP en términos simples?

Un componente debe encargarse de una sola cosa, y hacerlo bien.

¿Qué significa SRP en React?

• Un componente debe ser responsable de una única parte de la lógica de la interfaz de usuario — por ejemplo, renderizar una lista, mostrar el perfil de un usuario o manejar la entrada de un formulario.
  No debería mezclar responsabilidades no relacionadas como gestión de diseño, obtención de datos y manejo de eventos en un solo lugar.
• Debe enfocarse en presentar datos (componentes de UI) o en manejar lógica/estado (componentes contenedor), pero no ambas cosas.
• Los efectos secundarios, las mutaciones de estado y la obtención de datos deben extraerse fuera de los componentes puros de UI.

¿Por qué es importante?

1. Legibilidad y previsibilidad

Componentes pequeños y con responsabilidades bien definidas son más fáciles de leer y depurar.
Cuando algo falla, sabes exactamente dónde buscar. Esto es clave al trabajar en equipos grandes o en proyectos de código abierto.

2. Reutilización

Los componentes reutilizables surgen de forma natural cuando aplicas SRP.
Si tu componente de botón no intenta también manejar el estado de un formulario, puedes usarlo en cualquier parte sin efectos secundarios inesperados.

3. Testeo

Es mucho más sencillo testear un componente cuando tiene una tarea clara y aislada:

• Las pruebas de UI se centran en el renderizado.
• Las pruebas de lógica en el comportamiento, sin superposición.

En el ecosistema de React:

• Las pruebas de UI verifican que los componentes rendericen el HTML esperado según los props o el estado.
  Herramientas como React Testing Library son comúnmente utilizadas aquí.
• Las pruebas de lógica validan el comportamiento de custom hooks o funciones utilitarias, como la obtención de datos o lógica de negocio, generalmente sin necesidad de renderizar nada en el DOM.

Esta separación te permite testear la lógica sin simular la interfaz, y testear la interfaz sin depender de la lógica interna.

Ejemplos prácticos

❌ Incorrecto (viola SRP):

const UserProfile = () => {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);

  return user ? <div>{user.name}</div> : <div>Loading...</div>;
};

✅ Mejor (sigue SRP):

// Lógica de obtención separada
const useUser = () => {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch('/api/user')
      .then(res => res.json())
      .then(data => setUser(data));
  }, []);
  return user;
};

// Componente de presentación
const UserProfile = () => {
  const user = useUser();
  return user ? <div>{user.name}</div> : <div>Loading...</div>;
};

Aquí separamos la obtención de datos de la presentación — cada función y componente tiene una sola responsabilidad.
Eso es aplicar SRP en la práctica.