javascript - vue - De AngularJS a Flux-The React Way

vue js angular react (1)

Como desarrollador con buena experiencia práctica en AngularJS, ¿cómo puedo ajustar mi modelo mental de escritura de aplicaciones web en Flux usando React?

No estoy buscando una respuesta de Flux + React vs Angular (ya bastante de eso en línea), pero me gustaría saber cuáles son las diferencias más grandes en las dos "mentalidades": de antemano, fui introducido en The Angular Way ; comparativamente, ¿qué es The React Way ?

Cuando salgo del universo Angular y hago la transición a Flux, ¿cuáles son las cosas clave que necesito para comenzar a prestar atención ?

Diferencias primero, y ahora similitudes: AngularJS es muy crítico y tiene algunos no-no muy grandes, como - no ponga el código UI / DOM en los controladores. ¿Cuáles son los grandes no-no y las opiniones de React?

Por último, pero no menos importante, Facebook se refiere a Flux como una alternativa a MVC , pero como lo estoy viendo, React es el motor de visualización, las tiendas son contenedores de modelos centrados en un solo dominio y el despachador y las acciones forman un controlador. Entonces, ¿no es esto realmente MVC con un nombre diferente?

Dejaré que otros hagan la comparación / contraste con Angular, pero aquí hay algunas respuestas a dos de sus preguntas.

Entonces, ¿no es esto realmente MVC con un nombre diferente?

La presencia en Flux de una separación de preocupaciones entre la capa de datos / lógica y la capa de vista no la convierte en MVC. Muchos otros patrones tienen una división similar, sobre todo CQRS, posiblemente el primo más cercano de Flux. No hay controlador en Flux, en el sentido de MVC. Las acciones y el despachador no equivalen a un controlador. Las vistas de controlador están cerca, pero en realidad son bastante limitadas en su aspecto de controlador. Una diferencia clave es que los controladores MVC contienen lógica de aplicación y actúan sobre modelos. Las tiendas Flux, por el contrario, contienen toda la lógica de la aplicación y no tienen setters.

Cuando salgo del universo Angular y hago la transición a Flux, ¿cuáles son las cosas clave que necesito para comenzar a prestar atención?

Valores clave de Flux:

Simplicidad sobre complejidad.
El modelo mental del programador es al menos tan importante como el propio código.
Las partes de la aplicación deben estar altamente desacopladas y "saber" lo menos posible sobre las otras partes.
Inversión del control: todo el control debe residir en las tiendas, donde se gestiona el estado. Las tiendas no actúan, sino que son informadas por acciones.
Las aplicaciones deben ser resistentes y flexibles a medida que crecen, permitiendo que se desarrollen nuevas características inesperadas de forma más rápida y sencilla.

Conceptos clave en Flux:

Flujo de datos unidireccional: acción → despachador → tiendas → vistas
- Cada cambio en el estado y todos los datos nuevos comienza con una Acción enviada.
- Este flujo de datos de cuatro pasos es el modelo mental central para el programador Flux.
Un envío provoca una transformación del estado de la aplicación en toda la aplicación.
- Este es un momento en el tiempo, creando una instantánea del cambio. Esto es fácil de razonar.
- No podemos enviar durante el envío y preservar esta simplicidad. Por lo tanto, cualquier cambio de corolario debe ser impulsado por la acción original.
Las tiendas de flujo son modelos de dominio, no modelos ORM. Contienen toda la lógica y administran todo el estado de un dominio lógico particular dentro de la aplicación. Pueden contener colecciones, valores singulares o una combinación de ambos.
Flux asume que los datos derivados , donde una tienda depende de los cambios en otra tienda, es una eventualidad en aplicaciones complejas donde los modelos o tiendas manejan datos normalizados. Para hacer frente a esto, un despachador de flujo debe exponer un mecanismo para gestionar declarativamente esta dependencia dentro de la tienda . En el Dispatcher de Facebook, esto se hace con el método waitFor() . Esto permite que una tienda espere la respuesta de otra tienda a una acción antes de seguir adelante con su propia respuesta.

Partes primarias de una aplicación Flux:

Acciones : un objeto literal que contiene datos nuevos y un tipo específico, lo que permite a las Tiendas discernir si es relevante para su dominio.
Despachador : un registro de devoluciones de llamada que, a través de las devoluciones de llamada, distribuye una carga útil (una Acción) a los solicitantes de registro (las Tiendas). No tiene inteligencia propia. Toda la inteligencia está en las tiendas.
Tiendas : un modelo de dominio que se registra con el Dispatcher y emite un evento de ''cambio'' cada vez que se produce un cambio en su estado.
Controlador de vistas : vea los componentes cerca de la raíz del árbol de componentes. Escuchan los eventos de "cambio" en las tiendas y responden a este evento recuperando datos nuevos a través de los métodos getter expuestos de la tienda y pasándoselos a sus hijos. La única diferencia entre las vistas de Controlador y Vistas es esta funcionalidad de escucha.
Vistas : hijos sin estado de los componentes de la vista del controlador, recibiendo y transmitiendo datos, al igual que las funciones puras. Las vistas y las vistas de controladores se implementan más a menudo con React, ya que ofrecen la posibilidad de volver a procesar a voluntad con muy poca pérdida de rendimiento.
Utils : bibliotecas de funciones puras que se pueden compartir fácilmente entre diferentes módulos.

Descripción general, en profundidad: http://facebook.github.io/flux/docs/overview.html

Tutorial: http://facebook.github.io/flux/docs/todo-list.html

Ejemplos: https://github.com/facebook/flux/tree/master/examples

Acciones y el Dispatcher: http://facebook.github.io/react/blog/2014/07/30/flux-actions-and-the-dispatcher.html

Pruebas: http://facebook.github.io/react/blog/2014/09/24/testing-flux-applications.html

Más en la naturaleza: http://facebook.github.io/react/blog/2014/10/17/community-roundup-23.html