javascript - sort - tojs

¿Cuáles son las desventajas de usar el estado inmutable en React? (3)

Construí mi primera aplicación React con las tiendas con estado de la manera "normal", y ahora estoy estudiando el uso de un estado global inmutable como el usado en el starterkit Este .

El estado de todas las tiendas se mantiene unido en una única estructura de datos inmutable
Los componentes no tienen estado, pero acceden a los datos en su representación () basados en una función de obtención de tienda
Las tiendas también son sin estado, pero mutan el estado de la aplicación global para su dominio con un cursor.
El componente de la aplicación de nivel superior escucha los cambios de estado y vuelve a representar todo el árbol de componentes.
Los componentes se implementan como "puros", lo que significa que deben usar shouldComponentUpdate para calcular de manera eficiente que se pueden omitir en la representación.

Simplifica la estructura de la aplicación de varias maneras:

Los componentes no escuchan a las tiendas y tampoco copian los datos de las tiendas a su estado local. Simplemente toman el estado de su tienda en cada render.
El estado global es siempre una instantánea de toda la aplicación, lo que facilita la depuración y la adición de funciones como deshacer trivial.
El estado global parece simplificar la representación isomórfica.

Solo leo cosas positivas sobre el uso de datos inmutables con React, y se recomienda evitar el estado de los componentes, por lo que me pregunto si hay alguna desventaja. Pensé que debía haberlo porque de lo contrario no veo por qué no se recomienda como la forma de estructurar las aplicaciones React.

La inmutabilidad es nueva para mí, ¿hay alguna advertencia que deba tener en cuenta si comienzo a utilizar este enfoque en una aplicación compleja del mundo real?

Lo único menor que se me ocurre es el uso de forceUpdate () ya que Este lo está utilizando, ya que he leído que es una función síncrona. Morearty, por ejemplo, parece diferir las actualizaciones al siguiente cuadro de animación para agruparlas, pero considero que esto es un detalle / optimización de la implementación y no una parte negativa heredada del enfoque de estado único inmutable.

Documentación. Algunas de las preguntas / opiniones más votadas en SO se refieren a cosas triviales, como la actualización de elementos de listas anidadas, ya que la documentación está más orientada hacia un público familiarizado con la programación funcional, lo que hace que sea menos accesible para el resto.
No es trivial separar el conocimiento de la jerarquía del modelo de sus componentes. Odio hacer un this.state.getIn("[parent, child, index]") en un componente porque aumenta la posibilidad de que un modelo cambie el código del componente. Esto se puede prevenir mediante la extensibilidad (más sobre esto más adelante) o mediante los métodos de ayuda, pero sin duda perderá la simplicidad de los miembros de JS.
Un desafío importante que enfrenté fue poder serializar y des-serializar el estado. El método fromJS admite reviversos personalizados, pero son una pita y requieren pruebas y mantenimiento cuidadosos.
El tipo de registro está severamente atrofiado por una debilitación llamada anidación. Esto es triste porque permite una extensibilidad más fácil (en términos relativos), pero alienta solo una jerarquía de un solo nivel. No puede crear fácilmente registros anidados desde JSON. Esto hace que sea difícil mezclarlos con el uso regular e inmutable de JS a menos que use los revisores de pita mencionados anteriormente. ¿Y mencioné lo triste que es eso? Dado que los Registros exponen las propiedades del modelo como miembros de primera clase, aseguran la integridad del modelo y los valores predeterminados.
Y luego está la extensibilidad. Intente agregar ayudantes alrededor de sus modelos de datos inmutables para abstraer la dependencia de la jerarquía de modelos en sus componentes y estará listo para una carrera de obstáculos notable. La des-serialización se convierte en una amarga batalla de divorcio. Necesitarías meterte con los revivientes, si los Registros están en la mezcla llorarán mal y así sucesivamente. Un mecanismo de extensibilidad más fácil ayudaría mucho a hacer que el código de mis componentes sea más limpio.
No hay mejores prácticas documentadas. Aunque esto se ajusta al número 1, aún debo mencionar que la falta de buena documentación impide que uno elija la mejor manera de hacer algo. No estoy seguro de si debo elegir utilizar un actualizador, o forEach o setIn (y así sucesivamente) para actualizar una estructura inmutable. Los métodos no hacen referencias cruzadas entre sí lo suficiente como para hacerle saber qué alternativas existen.

Sé que la respuesta ya ha sido aceptada, pero me parece que la principal desventaja es que usted pasa objetos de JavaScript no simples a su código de componente, lo que significa que no puede usar los accesores de propiedades de JavaScript normales cuando lee valores de los objetos inmutables que se pasan a través de props . En su lugar, tienes que usar la API de lectura de Immutable.js . Esta es una compensación significativa. No puede mantener su uso de Immutable.js contenido donde pertenece, en la tienda; Ahora se ha filtrado en toda su aplicación. Este es un dolor que puede sentir cuando Immutable.js se reemplaza por la próxima biblioteca de inmutabilidad que tiene su propia API o es capaz de usar los accesores de propiedad nativos. Además, es muy probable que el código de un tercero espere objetos de JavaScript antiguos, por lo que los objetos inmutables deberán convertirse antes de pasarlos. Si planea introducir Immutable.js en una aplicación existente, no estará claro muy rápidamente en su código de componente qué props son Inmutables y cuáles son objetos JS, a menos que sea muy disciplinado y cree un esquema de denominación o algún otro método que usted es consistente con cuando pasa objetos por la cadena de renderizado.

Una de las ventajas de pasar datos a través de accesorios es que puede utilizar shouldComponentUpdate para obtener actualizaciones más shouldComponentUpdate . Si asume que los datos siempre provienen del padre (por ejemplo, a través de accesorios), puede evitar de manera efectiva que una gran parte de su árbol de componentes tenga que ser redirigido. Los valores inmutables hacen que esto sea muy bueno, ya que puede hacer verificaciones de igualdad de referencia en shouldComponentUpdate relativamente alto en su jerarquía de componentes.

La única otra desventaja que he encontrado al usar datos inmutables con React es que las herramientas de desarrollo de React no funcionan muy bien con ellos (le muestran la estructura de datos subyacente de los valores inmutables en lugar de un valor compatible con JS).