👴🏿 👹 💯 Reaccionar forma de desarrollo. Principios de KISS, YAGNI, DRY en la práctica 🚤 ⬅️ ♣️

Hola, en este tutorial veremos cómo desarrollar una forma muy simple pero controlada en React, centrándonos en la calidad del código.

Al desarrollar nuestro formulario, seguiremos los principios de "BESO", "YAGNI", "SECO". Para completar con éxito este tutorial no necesita conocer estos principios, los explicaré a lo largo del camino. Sin embargo, creo que tiene un buen dominio del javascript moderno y puede pensar en React .

Estructura tutorial

A la causa! Escribir un formulario simple usando KISS y YAGNI

Entonces, imaginemos que tenemos la tarea de implementar un formulario de autorización:

Código de copia

const logInData = {
  nickname: 'Vasya',
  email: 'pupkin@gmail.com',
  password: 'Reac5$$$',
};

Comenzamos nuestro desarrollo analizando los principios de KISS y YAGNI, olvidando temporalmente el resto de los principios.

BESO - "Deje el código simple y tonto". Creo que está familiarizado con el concepto de código simple. Pero, ¿qué significa el código "tonto"? Según tengo entendido, este es un código que resuelve el problema utilizando el número mínimo de abstracciones, mientras que el anidamiento de estas abstracciones entre sí también es mínimo.

YAGNI: "No lo necesitarás". El código debe poder hacer solo para lo que está escrito. No creamos ninguna funcionalidad que pueda ser necesaria más adelante o que mejore la aplicación en nuestra opinión. Hacemos solo lo que se necesita específicamente para la implementación de la tarea.

Sigamos estrictamente estos principios, pero también consideremos:

initialDatay onSubmitpara LogInFormviene de la parte superior (esta es una técnica útil, especialmente cuando el formulario debe ser capaz de procesar createy updateal mismo tiempo)
debe tener para cada campo label

Además, echemos de menos la estilización, ya que no es interesante para nosotros y es válida, ya que este es un tema para un tutorial por separado.

Implemente el formulario usted mismo, siguiendo los principios descritos anteriormente.

Mi forma de implementación

const LogInForm = ({ initialData, onSubmit }) => {
  const [logInData, setLogInData] = useState(initialData);

  const handleSubmit = e => {
    e.preventDefault();
    onSubmit(logInData);
  };

  return (
    <form onSubmit={handleSubmit}>
      <label>
        Enter your nickname
        <input
          value={logInData.nickname}
          onChange={e => setLogInData({ ...logInData, nickname: e.target.value })}
        />
      </label>
      <label>
        Enter your email
        <input
          type="email"
          value={logInData.email}
          onChange={e => setLogInData({ ...logInData, email: e.target.value })}
        />
      </label>
      <label>
        Enter your password
        <input
          type="password"
          value={logInData.password}
          onChange={e => setLogInData({ ...logInData, password: e.target.value })}
        />
      </label>
      <button>Submit</button>
    </form>
  );
};

Su decisión, muy probablemente, es algo diferente, porque cada desarrollador piensa de manera diferente. Puede crear su propio estado para cada campo o colocar funciones de controlador en una variable separada, en cualquier caso, esto no es importante.

Pero si creó inmediatamente una función de controlador para todos los campos, entonces esta ya no es la solución "más tonta" del problema. Y nuestro objetivo en esta etapa es crear el código más simple y "tonto" para que luego podamos ver la imagen completa y seleccionar la mejor abstracción.

Si tiene exactamente el mismo código, ¡esto es genial y significa que nuestro pensamiento converge!

Además trabajaremos con este código. Es simple, pero aún lejos de ser ideal.

Refactorización y SECO

Es hora de lidiar con el principio DRY.

DRY, redacción simplificada: "no duplique su código". El principio parece simple, pero tiene un inconveniente: para deshacerse de la duplicación de código, debe crear abstracciones. Si estas abstracciones no son lo suficientemente buenas, violaremos el principio KISS.

También es importante comprender que DRY no es necesario para escribir código más rápido. Su tarea es simplificar la lectura y el soporte de nuestra solución. Por lo tanto, no se apresure a crear abstracciones de inmediato. Es mejor hacer una implementación simple de alguna parte del código, y luego analizar qué abstracciones necesita crear para simplificar la lectura del código y reducir el número de lugares para los cambios cuando sean necesarios.

Lista de verificación de la abstracción correcta:

el nombre de la abstracción es totalmente consistente con su propósito
la abstracción realiza una tarea específica y comprensible
La lectura del código del que se extrajo la abstracción mejoró

Entonces, vamos a refactorizar.
Y hemos pronunciado código duplicado:

Código de copia

  <label>
    Enter your email
    <input
      type="email"
      value={logInData.email}
      onChange={e => setLogInData({ ...logInData, email: e.target.value })}
    />
  </label>
  <label>
    Enter your password
    <input
      type="password"
      value={logInData.password}
      onChange={e => setLogInData({ ...logInData, password: e.target.value })}
    />
  </label>

Este código duplica una composición de 2 elementos: label, input. Fusionémoslos en una nueva abstracción InputField:

Código de copia

  <label>
    Enter your email
    <input
      type="email"
      value={logInData.email}
      onChange={e => setLogInData({ ...logInData, email: e.target.value })}
    />
  </label>
  <label>
    Enter your password
    <input
      type="password"
      value={logInData.password}
      onChange={e => setLogInData({ ...logInData, password: e.target.value })}
    />
  </label>

Ahora el nuestro se LogInFormve así:

Código de copia

const LogInForm = ({ initialData, onSubmit }) => {
  const [logInData, setLogInData] = useState(initialData);

  const handleSubmit = e => {
    e.preventDefault();
    onSubmit(logInData);
  };

  return (
    <form onSubmit={handleSubmit}>
      <InputField
        label="Enter your nickname"
        value={logInData.nickname}
        onChange={e => setLogInData({ ...logInData, nickname: e.target.value })}
      />
      <InputField
        type="email"
        label="Enter your email"
        value={logInData.email}
        onChange={e => setLogInData({ ...logInData, email: e.target.value })}
      />
      <InputField
        type="password"
        label="Enter your password"
        value={logInData.password}
        onChange={e => setLogInData({ ...logInData, password: e.target.value })}
      />
      <button>Submit</button>
    </form>
  );
};

Leer se ha vuelto más fácil. El nombre de la abstracción corresponde a la tarea que resuelve. El propósito del componente es obvio. El código se ha vuelto menos. ¡Entonces vamos en la dirección correcta!

Ahora está claro que la InputField.onChangelógica está duplicada.
Lo que sucede allí se puede dividir en 2 etapas:

Código de copia

const stage1 = e => e.target.value;
const stage2 = password => setLogInData({ ...logInData, password });

La primera función describe los detalles para obtener el valor del evento input. Tenemos la opción de 2 abstracciones en las que podemos almacenar esta lógica: InputFieldy LogInForm.

Para determinar correctamente a cuál de las abstracciones necesitamos referir nuestro código, tendremos que recurrir a la formulación completa del principio DRY: "Cada parte del conocimiento debe tener una representación única, consistente y autorizada dentro del sistema".

Parte del conocimiento en el ejemplo concreto es saber cómo obtener el valor del evento en input. Si almacenaremos este conocimiento en el nuestro LogInForm, entonces es obvio que al usar nuestroInputFielden otra forma, tendremos que duplicar nuestro conocimiento, o llevarlo a una abstracción separada y usarlo desde allí. Y según el principio KISS, deberíamos tener el mínimo número posible de abstracciones. De hecho, ¿por qué necesitamos crear otra abstracción si solo podemos poner esta lógica en la nuestra InputFieldy el código externo no sabrá nada sobre cómo funciona la entrada en el interior InputField? Simplemente tomará un significado ya hecho, lo mismo que pasa hacia adentro.

Si está confundido de que pueda necesitar un evento en el futuro, recuerde el principio de YAGNI. Siempre puedes agregar un accesorio adicional onChangeEventa nuestro componente InputField.

Hasta entonces se InputFieldverá así:

Código de copia

const InputField = ({ label, type, value, onChange }) => (
  <label>
    {label}
    <input
      type={type}
      value={value}
      onChange={e => onChange(e.target.value)}
    />
  </label>
);

Por lo tanto, se observa uniformidad del tipo durante la entrada y salida en el componente y se oculta la verdadera naturaleza de lo que está sucediendo para el código externo. Si en el futuro necesitamos otro componente ui, por ejemplo, casilla de verificación o selección, entonces también mantendremos la uniformidad de tipo en la entrada-salida.

Este enfoque nos brinda flexibilidad adicional, ya que nuestro formulario puede funcionar con cualquier fuente de entrada-salida sin la necesidad de producir controladores únicos adicionales para cada uno.

Este truco heurístico está incorporado de forma predeterminada en muchos marcos. Por ejemplo, esta es la idea principal v-modelen la Vueque muchas personas adoran por su facilidad para trabajar con formularios.

Volvamos al negocio, actualice nuestro componente LogInFormde acuerdo con los cambios en InputField:

Código de copia

const LogInForm = ({ initialData, onSubmit }) => {
  const [logInData, setLogInData] = useState(initialData);

  const handleSubmit = e => {
    e.preventDefault();
    onSubmit(logInData);
  };

  return (
    <form onSubmit={handleSubmit}>
      <InputField
        label="Enter your nickname"
        value={logInData.nickname}
        onChange={nickname => setLogInData({ ...logInData, nickname })}
      />
      <InputField
        type="email"
        label="Enter your email"
        value={logInData.email}
        onChange={email => setLogInData({ ...logInData, email })}
      />
      <InputField
        type="password"
        label="Enter your password"
        value={logInData.password}
        onChange={password => setLogInData({ ...logInData, password })}
      />
      <button>Submit</button>
    </form>
  );
};

Ya se ve bastante bien, ¡pero podemos hacerlo aún mejor!

Callbackque se pasa onChangesiempre hace lo mismo. Solo se cambia la clave: contraseña, correo electrónico, apodo. Por lo tanto, podemos sustituirla por una llamada a la función: handleChange('password').

Implementemos esta función:

Código de copia

  const handleChange = fieldName => fieldValue => {
    setLogInData({
      ...logInData,
      [fieldName]: fieldValue,
    });
  };

Como puede ver, la función recibe el argumento y lo almacena en el cierre del controlador, y el controlador vuelve inmediatamente al código externo. Las funciones que parecen tomar argumentos uno a la vez para una llamada también se denominan curry.

Veamos el código resultante:

Código de copia

  const LogInForm = ({ initialData, onSubmit }) => {
    const [logInData, setLogInData] = useState(initialData);
  
    const handleSubmit = e => {
      e.preventDefault();
      onSubmit(logInData);
    };
  
    const handleChange = fieldName => fieldValue => {
      setLogInData({
        ...logInData,
        [fieldName]: fieldValue,
      });
    };
  
    return (
      <form onSubmit={handleSubmit}>
        <InputField
          label="Enter your nickname"
          value={logInData.nickname}
          onChange={handleChange('nickname')}
        />
        <InputField
          type="email"
          label="Enter your email"
          value={logInData.email}
          onChange={handleChange('email')}
        />
        <InputField
          type="password"
          label="Enter your password"
          value={logInData.password}
          onChange={handleChange('password')}
        />
        <button>Submit</button>
      </form>
    );
  };
  
  // InputField.js
  const InputField = ({ type, label, value, onChange }) => (
    <label>
      {label}
      <input type={type} value={value} onChange={e => onChange(e.target.value)} />
    </label>
  );

Este código es una implementación breve, concisa y moderadamente declarativa de la tarea. Refactorizar más en el contexto de la tarea, en mi opinión, no tiene sentido.

Qué más se puede hacer?

Si tiene muchas formas en el proyecto, puede colocar el cálculo de handleChange en un gancho separado useFieldChange:

Código de copia

  // hooks/useFieldChange.js
  const useFieldChange = setState => fieldName => fieldValue => {
    setState(state => ({
      ...state,
      [fieldName]: fieldValue,
    }));
  };
  // LogInForm.js
  const handleChange = useFieldChange(setLogInData);

Como se trata de una función pura (es decir, la primera vez que se llama porque siempre devuelve la misma función), no tiene que ser un enlace. Pero el gancho parece conceptualmente una solución más correcta y natural para React.

También puede agregar soporte callbacken el lugar fieldValuepara replicar completamente el comportamiento habitual setStatede React:

Código de copia

  const isFunc = val => typeof val === "function";

  const useFieldChange = setState => fieldName => fieldValue => {
    setState(state => ({
      ...state,
      [fieldName]: isFunc(fieldValue) ? fieldValue(state[fieldName]) : fieldValue,
    }));
  };

Un ejemplo de uso con nuestro formulario:

Código de copia

  const LogInForm = ({ initialData, onSubmit }) => {
    const [logInData, setLogInData] = useState(initialData);
    const handleChange = useFieldChange(setLogInData);
  
    const handleSubmit = e => {
      e.preventDefault();
      onSubmit(logInData);
    };
  
    return (
      <form onSubmit={handleSubmit}>
        <InputField
          label="Enter your nickname"
          value={logInData.nickname}
          onChange={handleChange('nickname')}
        />
        <InputField
          type="email"
          label="Enter your email"
          value={logInData.email}
          onChange={handleChange('email')}
        />
        <InputField
          type="password"
          label="Enter your password"
          value={logInData.password}
          onChange={handleChange('password')}
        />
        <button>Submit</button>
      </form>
    );
  };

Pero si su solicitud tiene solo un formulario, ¡no necesita hacer todo esto! Porque contradice el principio YAGNI, siguiendo el cual no debemos hacer lo que no necesitamos para resolver un problema específico. Si solo tiene una forma, los beneficios reales de tales movimientos no son suficientes. Después de todo, redujimos el código de nuestro componente solo en 3 líneas, pero introdujimos una abstracción adicional, ocultando una cierta lógica de la forma, que es mejor mantener en la superficie.

¡Oh no! ¡No lo hagas, por favor!

Formas de configuración en forma

Las configuraciones bloqueadas son como una configuración de paquete web, solo para el formulario.

Mejor con un ejemplo, mira este código:

Código de copia

  const Form = () => (
    <form onSubmit={handleSubmit}>
      <InputField
        label="Enter your nickname"
        value={state.nickname}
        onChange={handleChange('nickname')}
      />
      <InputField
        type="email"
        label="Enter your email"
        value={state.email}
        onChange={handleChange('email')}
      />
      <InputField
        type="password"
        label="Enter your password"
        value={state.password}
        onChange={handleChange('password')}
      />
      <button>Submit</button>
    </form>
  );

A algunos les puede parecer que el código está duplicado aquí, porque llamamos al mismo componente InputField, pasando allí la misma etiqueta, valor y parámetros onChange. Y comienzan a SECAR su propio código para evitar la duplicación imaginaria.
A menudo hacen esto así:

Código de copia

const fields = [
  {
    name: 'nickname',
    label: 'Enter your nickname',
  },
  {
    type: 'email',
    name: 'email',
    label: 'Enter your email',
  },
  {
    type: 'password',
    name: 'password',
    label: 'Enter your password',
  },
];

const Form = () => (
  <form onSubmit={handleSubmit}>
    {fields.map(({ type, name, label }) => (
      <InputField
        type={type}
        label={label}
        value={state[name]}
        onChange={handleChange(name)}
      />
    ))}
    <button>Submit</button>
  </form>
);

Como resultado, con 17 líneas de código jsx obtenemos 16 líneas de la configuración. ¡Bravo! Esto es lo que entiendo DRY. Si tenemos 100 de estas entradas aquí, entonces obtenemos 605 y 506 líneas, respectivamente.

Pero, como resultado, obtuvimos un código más complejo, violando el principio KISS. De hecho, ahora consta de 2 abstracciones: campos y un algoritmo (sí, un algoritmo también es una abstracción), lo que lo convierte en un árbol de elementos React. Al leer este código, tendremos que saltar constantemente entre estas abstracciones.

Pero el mayor problema con este código es su soporte y extensión.
Imagina lo que le sucederá si:

Se agregarán algunos tipos de campos más con diferentes propiedades posibles
los campos se representan o no se basan en la entrada de otros campos
algunos campos requieren un procesamiento adicional al cambiar
los valores en selecciones dependen de selecciones anteriores

Esta lista puede continuar durante mucho tiempo ...

Para implementar esto, siempre tendrá que almacenar algunas funciones en su configuración, y el código que representa la configuración se convertirá gradualmente en Frankenstein, tomando un montón de accesorios diferentes y lanzándolos sobre diferentes componentes.

El código que se escribió anteriormente, basado en la composición de los componentes, se expandirá silenciosamente, cambiará a su gusto, sin ser muy complicado debido a la falta de abstracción intermedia, un algoritmo que construye un árbol de elementos React desde nuestra configuración. Este código no está duplicado. Simplemente sigue un cierto patrón de diseño y, por lo tanto, parece "modelado".

Optimización inútil

Después de que aparecieron los ganchos en React, hubo una tendencia a envolver todos los manipuladores y componentes indiscriminadamente en useCallbacky memo. ¡Por favor, no hagas eso! Los desarrolladores de React no proporcionaron estos ganchos porque React es lento y todo necesita ser optimizado. Proporcionan espacio para optimizar su aplicación en caso de que tenga problemas de rendimiento. E incluso si encuentra tales problemas, no necesita envolver todo el proyecto memoy useCallback. Use Profiler para identificar problemas y solo luego memorizar en el lugar correcto.

La memorización siempre hará que su código sea más complicado, pero no siempre más productivo.

Veamos el código de un proyecto real. Compare cómo se ve la función con useCallbacky sin:

Código de copia

  const applyFilters = useCallback(() => {
    const newSelectedMetrics = Object.keys(selectedMetricsStatus).filter(
      metric => selectedMetricsStatus[metric],
    );
    onApplyFilterClick(newSelectedMetrics);
  }, [selectedMetricsStatus, onApplyFilterClick]);

  const applyFilters = () => {
    const newSelectedMetrics = Object.keys(selectedMetricsStatus).filter(
      metric => selectedMetricsStatus[metric],
    );
    onApplyFilterClick(newSelectedMetrics);
  };

La legibilidad del código aumentó claramente después de la eliminación del contenedor, porque el código ideal es su falta.

El rendimiento de este código no ha aumentado, porque esta función se usa así:

Código de copia

  <RightFooterButton onClick={applyFilters}>APPLY</RightFooterButton>

De dónde RightFooterButton: es solo styled.buttonde styled-components, que se actualizará muy rápidamente. Pero el consumo de memoria aumenta nuestra aplicación porque React siempre se mantendrá en la memoria selectedMetricsStatus, onApplyFilterClicky la versión de la función applyFilters, relevante para estas dependencias.

Si estos argumentos no son suficientes para usted, lea el artículo que trata este tema más ampliamente.

recomendaciones

Las formas de reacción son fáciles. Los problemas con ellos surgen debido a los propios desarrolladores y la documentación de React, en la que este tema no se divulga con suficiente detalle.
aka value onChange . useFieldChange, , , v-model Vue .
KISS YAGNI. DRY, , .
, , React- .
, .

P.S.

Inicialmente, planeé escribir sobre la validación declarativa de formas anidadas complejas. Pero, al final, decidí preparar a la audiencia para esto, de modo que la imagen fuera lo más completa posible.
El siguiente tutorial tratará sobre la validación del formulario simple implementado en este tutorial.
¡Muchas gracias a todos los que leyeron hasta el final!

No importa cómo escriba el código o lo que haga, lo principal es disfrutarlo.

Reaccionar forma de desarrollo. Principios de KISS, YAGNI, DRY en la práctica

Estructura tutorial

A la causa! Escribir un formulario simple usando KISS y YAGNI

Refactorización y SECO

Qué más se puede hacer?

¡Oh no! ¡No lo hagas, por favor!

Formas de configuración en forma

Optimización inútil

recomendaciones

P.S.

More articles: