Descargo de responsabilidad
Estimado lector! Si no tienes idea de qué son React y Redux, leer más no tiene sentido, más tonterías técnicas. En serio, entender para qué sirve esta nota, requiere trabajar con estas bibliotecas; a pesar del hecho de que trataré de escribir claramente, este artículo no es de nivel de entrada. Y esta es una experiencia personal y una opinión basada en la práctica.
¿Qué hay de malo en usar Redux?
Entonces decidí escribir, pero ¿qué hay de malo en usar redux en mi proyecto y en miles de otros? He estado escribiendo aplicaciones react / redux desde abril de 2016 (tres años). Es hora de descubrir algunas cosas interesantes ... Y luego hubo conferencias e informes, especialmente dirigidos a principiantes, pero no hubo ninguna mirada adulta y ninguna retrospectiva. Mientras tanto, alguien pone asteriscos en paquetes que marcan "no tienes 13 por hora". Romperé el muro de los estereotipos prevalecientes.
¡Pero no se necesita redux!
Dices, y de alguna manera tendrás razón. No se puede usar desde 2018: hay una tonelada de artículos sobre este tema en Internet, pero hasta ahora con el "no uso" que se obtiene una granja colectiva, quedará claro a continuación por qué. Y el número de alternativas está fuera de escala y aún más.
Usamos Redux, porque este es un estándar aceptado (al menos para reaccionar), la previsibilidad y fiabilidad que Redux tiene son importantes para nosotros. Pero realmente lo extrañamos, en realidad en esto
Reclamar
Probablemente, para dejar en claro cuál es la afirmación sobre los puntos, primero debe regresar al pasado, a las raíces, como desee, es decir, abrir la documentación del glorioso redux y leer los postulados. Consideraré solo el primero de ellos. Si le resultará interesante, comparta en los comentarios, analizaré muchos más puntos.
La única fuente de verdad ...
Aquí tenemos una emboscada. Por supuesto, dice que puede haber 1 historia, redux declara su diferencia de la arquitectura de flujo de esta manera. Pero si miras de manera más amplia: ¿se observa la regla en un proyecto real? Dirás: bastante. Declaro (declaro) 1 lado, lo transfiero al proveedor y luego ...
Técnicamente, el proceso se describe correctamente. Pero puedo decir que las personas están sujetas a distorsiones de la percepción, la lógica, y dado que los programadores siguen siendo personas ... Bueno, entiendes a lo que me dirijo (si no entendiste: los programadores son propensos a las distorsiones de la percepción, la lógica, etc.)
La principal distorsión aquí es que yo, como muchos de mis colegas, estamos acostumbrados al hecho de que si no usamos el término "almacenar" en relación con otra cosa que no sea redux, entonces no hay otros.
Y aquí viene la reacción.
Una característica técnica llamada estado interno quería escupir en este postulado. Simplemente crea un tipo de estado interno de tipo en cualquier lugar conveniente. Hay un componente: hay un estado que tiene un mecanismo para actualizar e influir en el componente. La diferencia de uso (estado de la tienda, actualización y cambios de transmisión) es casi invisible. Puede objetar: no está del todo claro por qué no le gusta el estado del componente. No es como los editores, ¿cómo pueden compararse? Es interno, bueno, qué banderas almacenar allí.
Comprende que la esencia no cambia por el hecho de que cambias el nombre del elemento. Hay un mazo el lunes, esto no lo convierte en el día de la semana. Sí, ambos lunes son difíciles, otros días y mazos son más fáciles. Pero por su nombre, el mazo no deja de ser un instrumento de percusión.
La escala del componente de reacción redux y estatal es diferente, pero la esencia, cuando se usa hoy, es una.
Lo explicaré de esta manera: en la mayoría de los casos, los datos del estado interno del componente van al niño a través de accesorios, pero, no importa cuán obvio sea, los datos redux, cuando se integran con react, también van a los componentes a través de accesorios. Desde el punto de vista del componente que acepta accesorios, no importa lo que esté afuera. Es decir, para el usuario final, esa tienda redux, ese estado interno, es el mismo.
Además, este estado interno puede no depender de los accesorios del componente en el que se declara. Luego obtenemos un aislamiento que hace que un estado tan interno sea una tienda aún más grande de lo que puedas imaginar.
Para que sea verdaderamente interno, solo debe afectar el componente donde se declara, sin dar fugas a los componentes secundarios. ¿Es dificil? Absolutamente, porque su significado está casi completamente perdido. Esta es otra señal de que el estado interno es una tienda. Después de todo, simplemente eliminamos un punto del propósito de "almacenar el estado, actualizar y transmitir los cambios": transmitir los cambios. Todo, el estado está perdido.
Es decir, el principal problema con tener un estado interno es que compite con redux por datos, pierde a largo plazo y es una mierda. Tenemos todo tipo de técnicas como el estado de elevación (esto es cuando se necesita el hermano del elemento host, por lo que la parte del estado y toda la lógica de trabajar con él se llevan al padre, pasando mucho tiempo reescribiendo y probando la lógica de trabajo), etc. Aparecen errores y sobrecarga en mejoras y mucha alegría. Este es todo el ruido que estropea nuestro software en la etapa de desarrollo. No hemos alcanzado ventas, pero el software ya es así.
Es decir, para todos los signos y problemas, tenemos más de una historia y muchos problemas asociados con esto. Lo último, probablemente, será lo siguiente:
También me encanta redux por el tipo de herramientas que tiene. Cuando comencé, usamos un registrador que simplemente consolidaba todas las acciones, sin dar, sin embargo, una imagen completa de lo que estaba sucediendo. Ahora, este es el principal asistente y amigo. En React, también están representados. En general, devtools es la razón por la cual cualquier pubsub está lejos de Redux. Como una hormiga para una ballena azul.
Problemas (no habrá pruebas de ADN):
- cambiar el estado interno a través de reaccionar devtools a veces no conduce a una actualización o al resultado deseado: peco en la integración con redux.
- El estado interno rompe el recorrido temporal en las herramientas de desarrollo redux. La función súper con viaje en el tiempo disponible a través de la arquitectura redux no funciona gracias a la arquitectura de estado interno de reacción. El estado interno simplemente no se preocupó por un cambio en redux, tiene su propio estado. Timetravel simplemente no funciona. Algunos elementos simplemente no se actualizan, se actualizan parcialmente, etc. Toda esta épica con sincronización de código asíncrono por el desagüe.
Un ejemplo, por supuesto, aspirado de la práctica.
Está trabajando en un nuevo proyecto para usted, o su colega escribió alguna funcionalidad hace un año, y ahora necesita expandirla. En general, existe la tarea de finalizar el código de otra persona. Comienza a investigar y comprende que no hay datos en los editores. No hay acciones, reductores en el código que almacenan los datos que necesita. Y comienzas el viaje a través del árbol de componentes en busca de los atesorados y los encuentras (¡!) Incluso algunas piezas. Le preguntas a tus colegas, pero la respuesta es estándar: no recuerdo haberle escrito al estado más rápido, no teníamos tiempo, etc. Vas a la fuente y entiendes que su estado actual no implica revisión. Está reescribiendo el código de trabajo probado para realizar cambios y agregar nuevas funcionalidades.
La presencia de una alternativa perniciosa en forma de estado interno hace su acción sucia. Después de todo, ahora es barato y no importa lo que pase en un año.Pocas metáforas
Parece una mala comida, parece sabrosa y barata, pero después de un año o 3, el tracto gastrointestinal deja de obedecer y vive su propia vida. Gastas mucho tiempo y dinero en recuperar tu salud anterior y no siempre tienes éxito en esto.
Redux y React Internal State son competidores , como grandes y pequeñas empresas en un nicho. El producto principal son los datos y la influencia. El software es el consumidor de sus productos. Hay muchas analogías, pero la esencia sigue siendo la misma: cuando desarrollamos software, no necesitamos competencia.
Somos los "dictadores" del código del programa y se debe suprimir cualquier competencia, se debe prohibir el libre mercado y la economía planificada y el monopolio estatal deben dominar al consumidor.Ejem, algo me aburrió. Todo debe ir de acuerdo al plan, en general. Tenemos sprints, lanzamientos y más, y el software tiene un costo finito y una vida / entrada en el mercado. Esto es muy importante, y no podemos permitir los disturbios en el barco, el levantamiento de las bibliotecas.
La conclusión es simple.
No utilice otros repositorios con redux. Las excepciones solo pueden hacer casos muy aislados. Por ejemplo, los componentes que en principio no están controlados por redux sin la capa correspondiente y no la afectan.
Ejemplo
Desarrollé el módulo independiente en una sucursal y refactoricé la tienda en otra; en general, mi enfoque para administrar la tienda y el estado es un tema separado para la publicación. Comencé a refactorizar el módulo, pero en el momento del comienzo y al final de la escritura del módulo, la refactorización para la prueba y para el asistente no desapareció. La refactorización es grande y requiere un recurso reflexivo que debe planificarse; en general, no puede simplemente tomar y refactorizar.
Por lo tanto, al conocer los próximos cambios en la tienda, no lo usé para desarrollar una nueva característica. Esto aumentaría los costos de actualizar la refactorización abandonada y las pruebas a veces.
Lo que hice: me inscribí para obtener un mínimo de datos. Los datos y su estructura no sufrieron refactorización, el código que los generó sufrió, se guardó, etc. No escribí un byte a los editores. Compruebo si el usuario ha iniciado sesión y un par de campos más.
Para mis necesidades, lavé PubSub con canales y una API simple. Sí, sí, pubsab. Falta de dolor doloroso normal. Viaje en el tiempo - Dolor. En general, planeo escribir una extensión para Chrome en forma de herramientas de desarrollo y es posible publicar la reimplementación como un competidor para reducir en el github. Tengo muchas quejas sobre redux, que no mencionaré en este artículo, pero PubSub prácticamente no las tiene. Además del hecho de que recordaba redux logger ...
Y así, el módulo tiene su propio almacenamiento, su propia conexión al servidor.
Es decir, redux no afecta el módulo en absoluto, prácticamente no puede afectar este almacenamiento (solo hay tres campos en la suscripción), pero el módulo y PubSub no afectan redux de ninguna manera. Esta separación excluye la competencia.
La pregunta "¿dónde almacenar los datos?" Al desarrollar el módulo, nunca lo he encontrado. Pero cuando se trata de redux vs estado interno, para muchos esta pregunta surge casi constantemente. Decidí responder esta pregunta de una vez por todas.
Mi opinión arquitectónica es:
Almacene datos solo en redux (todo, incluso "interno"), si está conectado a su proyecto de reacción como el repositorio principal, no use repositorios que compitan con él. Esto aumentará la confiabilidad y el impacto de esta biblioteca y sus herramientas de desarrollo (el seguimiento del tiempo y el seguimiento de todos los datos en pasos aceleran el desarrollo y la búsqueda de posibles problemas: los cambios sincrónicos son más pronunciados y más fáciles de sincronizar).
¿Quizás valga la pena agregar una biblioteca que excluya completamente el estado interno del desarrollo? ¿O reemplaza el estado interno con una selección de redux, por ejemplo? Comencé a escribir uno hace un año, terminé el 90 por ciento e incluso realicé 1 informe. Que dices ¿Necesitas esos?
Espero que hayas disfrutado esta nota :)