reactjs - helmet - react meta tags

Om pero en javascript (2)

Puede tener un estado de aplicación similar a Om sin otro contenedor de React y con Flux puro: compruébelo aquí https://github.com/steida/este Ese es mi kit de inicio de React muy completo.

Voy a ser fanático de la biblioteca Om de David Nolen.

Quiero crear una aplicación web no demasiado grande en nuestro equipo, pero realmente no puedo convencer a mis compañeros de equipo para que cambien a ClojureScript.

¿Hay alguna forma en que pueda usar los principios utilizados en om pero construyendo la aplicación en JavaScript?

Estoy pensando algo como:

immutable-js o mori para estructuras de datos inmutables
js-csp para CSP
solo un objeto javascript normal para el átomo de estado de la aplicación
immutable-js para cursores
algo para realizar un seguimiento del estado de la aplicación y enviar notificaciones a los cursores

Estoy luchando con el número 5 anterior.

¿Alguien se ha aventurado en este territorio o tiene alguna sugerencia? ¿Tal vez alguien ha intentado construir una aplicación react.js usando immutable-js?

Edición de julio de 2015 : ¡actualmente el marco más prometedor basado en la inmutabilidad es Redux ! ¡echar un vistazo! No usa cursores como Om (ni Om Next no usa cursores).

Los cursores no son realmente escalables, a pesar de utilizar los principios de CQRS descritos a continuación, todavía crea demasiada repetitiva en los componentes, que es difícil de mantener, y agrega fricción cuando desea mover los componentes en una aplicación existente.

Además, no está claro para muchos desarrolladores sobre cuándo usar y no usar cursores, y veo que los desarrolladores que usan cursores en su lugar no deberían usarse, lo que hace que los componentes sean menos reutilizables que los componentes que tienen accesorios simples.

Redux usa connect() y explica claramente cuándo usarlo (componentes del contenedor) y cuándo no (componentes sin estado / reutilizables). Resuelve el problema repetitivo de pasar cursores por el árbol y funciona enormemente sin demasiados compromisos.

He escrito sobre los inconvenientes de no usar connect() here

A pesar de que ya no uso cursores, la mayor parte de mi respuesta sigue siendo válida en mi humilde opinión

Lo he hecho yo mismo en nuestro marco interno de inicio atom-react

Algunas alternativas en JS son Morearty , React-cursors , Omniscient o Baobab

En ese momento todavía no había immutable-js y no hice la migración, todavía usando objetos JS simples (congelados).

No creo que sea realmente necesario utilizar una biblioteca de estructuras de datos persistentes a menos que tenga listas muy grandes que modifique / copie a menudo. Puede usar estos proyectos cuando observe problemas de rendimiento como una optimización, pero no parece ser necesario implementar los conceptos de Om para aprovechar shouldComponentUpdate . Una cosa que puede ser interesante es la parte de immutable-js sobre las mutaciones por lotes. Pero de todos modos, sigo pensando que es la optimización y no es un requisito previo fundamental para tener actuaciones muy decentes con React utilizando los conceptos de Om.

Puede encontrar nuestro código de código abierto aquí:

Tiene el concepto de un Clojurescript Atom que es una referencia intercambiable a un objeto inmutable (congelado con DeepFreeze ). También tiene el concepto de transacción, en caso de que desee que varias partes del estado se actualicen atómicamente. Y puede escuchar los cambios de Atom (fin de la transacción) para activar la representación de React.

Tiene el concepto de cursor , como en Om (como una lente funcional). Permite que los componentes puedan representar el estado, pero también modificarlo fácilmente. Esto es útil para formularios, ya que puede vincular directamente a los cursores para el enlace de datos bidireccional:

<input type="text" valueLink={this.linkCursor(myCursor)}/>

Tiene el concepto de render puro, optimizado de fábrica , como en Om

Diferencias con Om:

Ningún estado local (this.setState (o) prohibido)

En los componentes de Atom-React, no puede tener un estado de componente local. Todo el estado se almacena fuera de React . A menos que tenga necesidades de integración de las bibliotecas Js existentes (aún puede usar las clases React regulares), almacena todo el estado en el Atom (incluso para valores asíncronos / de carga) y toda la aplicación se vuelve a procesar desde el componente React principal. React es solo un motor de plantillas, muy eficiente, que transforma un estado JSON en DOM. Esto me parece muy útil porque puedo registrar el estado actual de Atom en cada renderizado, y luego depurar el código de renderizado es muy fácil. Gracias a la shouldComponentUpdate , es lo suficientemente rápido, que incluso puedo shouldComponentUpdate a shouldComponentUpdate la aplicación completa cada vez que un usuario presiona una nueva tecla del teclado en una entrada de texto, o desplaza un botón con el mouse. ¡Incluso en un teléfono móvil!

Manera de administrar el estado de forma expresiva (inspirada en CQRS / EventSourcing y Flux)

Atom-React tiene una manera muy obstinada de administrar el estado inspirado en Flux y CQRS . Una vez que tenga todo su estado fuera de React, y tenga una manera eficiente de transformar ese estado JSON a DOM, descubrirá que la dificultad restante es administrar su estado JSON.

Algunas de estas dificultades encontradas son:

Cómo manejar valores asincrónicos
Cómo manejar los efectos visuales que requieren cambios DOM (desplazamiento del mouse o foco por ejemplo)
Cómo organizar tu estado para que se adapte a un equipo grande
Dónde disparar las solicitudes de ajax.

Así que termino con la noción de Tienda, inspirada en la arquitectura Facebook Flux . El punto es que realmente no me gusta el hecho de que una tienda Flux realmente puede depender de otra, lo que requiere orquestar acciones a través de un despachador complejo. Y terminas teniendo que entender el estado de varias tiendas para poder renderizarlas.

En Atom-React, la Tienda es solo un "espacio de nombres reservado" dentro del estado que posee Atom.

Por lo tanto, prefiero que todas las tiendas se actualicen desde una secuencia de eventos de lo que sucedió en la aplicación. Cada tienda es independiente y no accede a los datos de otras tiendas (exactamente como en una arquitectura CQRS, donde los componentes reciben exactamente los mismos eventos, están alojados en diferentes máquinas y administran su propio estado como lo desean). Esto hace que sea más fácil de mantener, ya que cuando está desarrollando un nuevo componente solo tiene que entender el estado de una tienda. Esto de alguna manera conduce a la duplicación de datos porque ahora varias tiendas pueden tener que mantener los mismos datos en algunos casos (por ejemplo, en un SPA, es probable que desee la identificación de usuario actual en muchos lugares de su aplicación). Pero si 2 tiendas colocan el mismo objeto en su estado (proveniente de un evento), esto en realidad no consume ningún dato adicional ya que todavía es 1 objeto, al que se hace referencia dos veces en las 2 tiendas diferentes.

Para comprender las razones detrás de esta elección, puede leer publicaciones de blog del líder de CQRS, Udi Dahan, The Fallacy Of ReUse y otros sobre Componentes autónomos.

Por lo tanto, una tienda es solo una pieza de código que recibe eventos y actualiza su estado de espacio de nombres en Atom.

Esto mueve la complejidad de la gestión del estado a otra capa. Ahora lo más difícil es definir con precisión cuáles son los eventos de su aplicación.

Tenga en cuenta que este proyecto todavía es muy inestable e indocumentado / no está bien probado. Pero ya lo usamos aquí con gran éxito. Si desea debatir al respecto o contribuir, puede comunicarse conmigo en IRC: Sebastien-L en #reactjs .

Esto es lo que se siente al desarrollar un SPA con este marco. Cada vez que se procesa, con el modo de depuración, tiene:

El tiempo que tomó transformar el JSON en DOM virtual y aplicarlo al DOM real.
El estado registrado para ayudarlo a depurar su aplicación
React.addons.Perf gracias a React.addons.Perf
Una diferencia de ruta en comparación con el estado anterior para saber fácilmente qué ha cambiado

Mira esta captura de pantalla:

Algunas ventajas que este tipo de marco puede traer que aún no he explorado tanto:

Realmente tienes undo / redo incorporado (esto funcionó de fábrica en mi aplicación de producción real, no solo un TodoMVC). Sin embargo, en mi humilde opinión, la mayoría de las acciones en muchas aplicaciones en realidad están produciendo efectos secundarios en un servidor, por lo que no siempre tiene sentido revertir la interfaz de usuario a un estado anterior, ya que el estado anterior sería obsoleto
Puede grabar instantáneas de estado y cargarlas en otro navegador. CircleCI ha mostrado esto en acción en este video
Puede grabar "videos" de sesiones de usuario en formato JSON, enviarlos a su servidor back-end para depurar o reproducir el video. Puede transmitir en vivo una sesión de usuario a otro navegador para obtener asistencia del usuario (o espiar para verificar el comportamiento de UX en vivo de sus usuarios). El envío de estados puede ser bastante costoso, pero probablemente formatos como Avro pueden ayudar. O si la secuencia de eventos de su aplicación es serializable, simplemente puede transmitir esos eventos. Ya lo implementé fácilmente en el marco y funciona en mi aplicación de producción (solo por diversión, todavía no transmite nada al backend)
La depuración del viaje en el tiempo puede ser posible como en ELM

He hecho un video de la función "grabar sesión de usuario en JSON" para los interesados.