Pregunta ¿Por qué utilizar Redux en Facebook Flux?


he leído esta respuesta, reduciendo la repetición, miré algunos ejemplos de GitHub e incluso intenté reducir un poco (aplicaciones de todo).

Según entiendo, motivaciones oficiales oficiales del redux proporcionar profesionales en comparación con las arquitecturas MVC tradicionales. PERO no proporciona una respuesta a la pregunta:

¿Por qué deberías usar Redux en Facebook Flux? 

¿Es solo una cuestión de estilos de programación: funcional vs no funcional? ¿O la pregunta está en habilidades / herramientas dev que siguen del enfoque redux? Tal vez escalar? O prueba?

¿Tengo razón si digo que redux es un flujo para las personas que provienen de idiomas funcionales? 

Para responder a esta pregunta, puede comparar la complejidad de los puntos de motivación de la implementación redux en flujo versus reducción.

Aquí hay puntos de motivación de motivaciones oficiales oficiales del redux:

  1. Manejo de actualizaciones optimistas (según entiendo, apenas depende del quinto punto. ¿Es difícil implementarlo en facebook flux?)
  2. Representación en el servidor (facebook flux también puede hacer esto. Cualquier beneficio que se compare con redux?)
  3. Obtener datos antes de realizar transiciones de ruta (¿Por qué no se puede lograr en Facebook Flux? ¿Cuáles son los beneficios?)
  4. Recarga caliente (Es posible con React Hot Reload. ¿Por qué necesitamos redux?)
  5. Deshacer / Rehacer la funcionalidad
  6. ¿Algún otro punto? Como estado persistente ...

1003
2017-09-08 15:05


origen


Respuestas:


¡Autor de Redux aquí!

Redux no es ese diferente de Flux. En general, tiene la misma arquitectura, pero Redux es capaz de cortar algunas esquinas de complejidad mediante el uso de la composición funcional donde Flux utiliza el registro de devolución de llamada.

No hay una diferencia fundamental en Redux, pero creo que hace que ciertas abstracciones sean más fáciles, o al menos posibles de implementar, que serían difíciles o imposibles de implementar en Flux.

Composición del reductor

Tome, por ejemplo, paginación. Mi Ejemplo de Flux + React Router maneja la paginación, pero el código para eso es horrible. Una de las razones por las que es horrible es que Flux hace que no sea natural reutilizar la funcionalidad en las tiendas. Si dos tiendas necesitan manejar la paginación en respuesta a diferentes acciones, o bien deben heredar de una tienda base común (¡malo! Te estás encerrando en un diseño en particular cuando usas herencia), o llamar a una función del manejador, que necesitará operar de alguna manera en el estado privado de la tienda Flux. Todo es desordenado (aunque definitivamente en el ámbito de lo posible).

Por otro lado, con Redux la paginación es natural gracias a la composición del reductor. Son reductores hasta el fondo, para que pueda escribir Fábrica de reductores que genera reductores de paginación y entonces Úselo en su árbol reductor. La clave de por qué es tan fácil es porque en Flux, las tiendas son planas, pero en Redux, los reductores se pueden anidar mediante la composición funcional, al igual que los componentes React se pueden anidar.

Este patrón también permite características maravillosas como el código sin usuario deshacer rehacer. ¿Te imaginas conectar Undo / Redo en una aplicación Flux con dos líneas de código? Apenas. Con Redux, es-de nuevo, gracias al patrón de composición del reductor. Debo destacar que no hay nada nuevo al respecto: este es el patrón iniciado y descrito en detalle en Elm Architecture que fue influenciado por Flux.

Representación del servidor

La gente ha estado procesando bien el servidor con Flux, pero dado que tenemos 20 bibliotecas Flux cada una intentando hacer que el procesamiento del servidor sea "más fácil", tal vez Flux tiene algunas asperezas en el servidor. La verdad es que Facebook no hace mucho renderizado de servidores, por lo que no han estado muy preocupados por eso, y dependen del ecosistema para hacerlo más fácil.

En Flux tradicional, las tiendas son singletons. Esto significa que es difícil separar los datos para diferentes solicitudes en el servidor. No imposible, pero difícil. Esta es la razón por la cual la mayoría de las bibliotecas Flux (así como también las nuevas Flux Utils) ahora sugiera que use clases en lugar de singletons, para que pueda crear instancias de tiendas por solicitud.

Todavía hay los siguientes problemas que debe resolver en Flux (ya sea usted mismo o con la ayuda de su biblioteca Flux favorita, como Desconcertar por o Alt)

  • Si las tiendas son clases, ¿cómo las creo y las destruyo con el despachador por solicitud? ¿Cuándo registro tiendas?
  • ¿Cómo hidrato los datos de las tiendas y luego los vuelvo a hidratar en el cliente? ¿Debo implementar métodos especiales para esto?

Es cierto que los frameworks Flux (no vanilla Flux) tienen soluciones a estos problemas, pero los encuentro demasiado complicados. Por ejemplo, Flummox le pide que implemente serialize() y deserialize() en tus tiendas. Alt lo soluciona mejor proporcionando takeSnapshot() que serializa automáticamente su estado en un árbol JSON.

Redux va más allá: dado que solo hay una tienda (administrada por muchos reductores), no necesita ninguna API especial para administrar la (re) hidratación. No necesita "tirar" o "hidratar" las tiendas: solo hay una tienda, y puede leer su estado actual o crear una nueva tienda con un nuevo estado. Cada solicitud obtiene una instancia de tienda separada. Obtenga más información sobre la representación del servidor con Redux.

De nuevo, este es un caso de algo posible tanto en Flux como en Redux, pero las bibliotecas de Flux resuelven este problema al introducir un montón de API y convenciones, y Redux ni siquiera tiene que resolverlo porque no tiene ese problema en el primer lugar gracias a la simplicidad conceptual.

Experiencia de Desarrollador

En realidad, no tenía la intención de que Redux se convirtiera en una popular biblioteca de Flux, la escribí mientras trabajaba en mi ReactEurope habla sobre la recarga en caliente con viajes en el tiempo. Yo tenía un objetivo principal: permite cambiar el código del reductor sobre la marcha o incluso "cambiar el pasado" tachando acciones, y ver el estado que se vuelve a calcular.

No he visto una sola biblioteca de Flux que pueda hacer esto. React Hot Loader tampoco le permite hacer esto; de hecho, se rompe si edita las tiendas Flux porque no sabe qué hacer con ellas.

Cuando Redux necesita volver a cargar el código del reductor, llama replaceReducer()y la aplicación se ejecuta con el nuevo código. En Flux, los datos y las funciones se enredan en las tiendas Flux, por lo que no puede "simplemente reemplazar las funciones". Además, de alguna manera tendría que volver a registrar las nuevas versiones con Dispatcher, algo que Redux ni siquiera tiene.

Ecosistema

Redux tiene un ecosistema rico y de rápido crecimiento. Esto se debe a que proporciona algunos puntos de extensión como middleware. Fue diseñado con casos de uso tales como explotación florestal, apoyo para Promesas, Observables, enrutamiento, comprobaciones de inmutabilidad, persistencia, etc., en mente. No todos estos serán útiles, pero es bueno tener acceso a un conjunto de herramientas que se pueden combinar fácilmente para trabajar juntas.

Sencillez

Redux conserva todos los beneficios de Flux (grabación y reproducción de acciones, flujo de datos unidireccional, mutaciones dependientes) y agrega nuevos beneficios (fácil deshacer, recargar en caliente) sin introducir el registro de Dispatcher y la tienda.

Mantenerlo simple es importante porque te mantiene sano mientras implementas abstracciones de mayor nivel.

A diferencia de la mayoría de las bibliotecas de Flux, la superficie de la API de Redux es pequeña. Si elimina las advertencias, los comentarios y los controles de cordura del desarrollador, es 99 líneas. No hay un código asincrónico complicado para depurar.

Puedes leerlo y entender todo Redux.


Ver también mi respuesta sobre las desventajas de usar Redux en comparación con Flux.


1804
2017-10-03 08:26



En Quora, alguien dice: 

Antes que nada, es totalmente posible escribir aplicaciones con React sin   Flujo.

También esto diagrama visual que he creado muestran una vista rápida de ambos, probablemente una respuesta rápida para las personas que no quieren leer toda la explicación: Flux vs Redux

Pero si aún te interesa saber más, sigue leyendo.

Creo que deberías comenzar con Reac puro, luego aprender Redux y Flux.   Después de que tengas alguna experiencia REAL con React, verás   si Redux es útil para usted o no.

Quizás sienta que Redux es exactamente para su aplicación y tal vez   se dará cuenta de que Redux está tratando de resolver un problema que usted no es   realmente experimentando.

Si comienzas directamente con Redux, puedes terminar con over-engineered   código, código más difícil de mantener y con aún más errores y que sin   Redux.

De Documentos de Redux:

Motivación 
 Como los requisitos para las aplicaciones de JavaScript de una sola página se han vuelto cada vez más complicadas, nuestra   el código debe administrar más estado que nunca antes. Este estado puede incluir   respuestas del servidor y datos en caché, así como datos creados localmente que   aún no se ha conservado en el servidor. El estado de IU también está aumentando   en complejidad, ya que necesitamos administrar rutas activas, pestañas seleccionadas,   hilanderos, controles de paginación, etc.

Gestionar este estado cambiante es difícil. Si un modelo puede actualizar   otro modelo, luego una vista puede actualizar un modelo, que actualiza otro   modelo, y esto, a su vez, puede causar que otra vista se actualice. En algún   punto, ya no entiendes lo que sucede en tu aplicación ya que tienes   perdió el control sobre cuándo, por qué y cómo de su estado. Cuando un sistema   es opaco y no determinista, es difícil reproducir errores o agregar   nuevas características.

Como si esto no fuera lo suficientemente malo, considere los nuevos requisitos que se convierten   común en el desarrollo de productos front-end. Como desarrolladores, somos   se espera que maneje las actualizaciones optimistas, la representación del lado del servidor, la búsqueda   datos antes de realizar transiciones de ruta, y así sucesivamente. Nos encontramos   tratando de manejar una complejidad con la que nunca tuvimos que lidiar   antes, e inevitablemente nos hacemos la pregunta: ¿es hora de darse por vencido? los   la respuesta es No.

Esta complejidad es difícil de manejar ya que estamos mezclando dos conceptos   que son muy difíciles de razonar para la mente humana: mutación y   asincronicidad Los llamo Mentos y Coke. Ambos pueden ser grandiosos cuando   separados, pero juntos crean un desastre. Bibliotecas como React   intentar resolver este problema en la capa de vista eliminando ambos   asincronía y manipulación DOM directa. Sin embargo, manejando el estado de   tus datos son de tu elección. Aquí es donde entra Redux.

Siguiendo los pasos de Flux, CQRS y Event Sourcing, Redux   intenta hacer predecibles las mutaciones estatales imponiendo ciertas   restricciones sobre cómo y cuándo pueden ocurrir las actualizaciones. Estas restricciones   se reflejan en los tres principios de Redux.

También de Documentos de Redux:

Conceptos básicos
 Redux en sí es muy simple.

Imagine que el estado de su aplicación se describe como un objeto simple. Por ejemplo,   el estado de una aplicación de tareas puede verse así:

{
  todos: [{
    text: 'Eat food',
    completed: true
  }, {
    text: 'Exercise',
    completed: false
  }],
  visibilityFilter: 'SHOW_COMPLETED'
}

Este objeto es como un "modelo", excepto que no hay instaladores. Esta   es para que las diferentes partes del código no puedan cambiar el estado   arbitrariamente, causando errores difíciles de reproducir.

Para cambiar algo en el estado, necesita enviar una acción. Un   acción es un objeto JavaScript simple (observe cómo no introducimos ningún   ¿magia?) que describe lo que sucedió. Aquí hay algunas acciones de ejemplo:

{ type: 'ADD_TODO', text: 'Go to swimming pool' }
{ type: 'TOGGLE_TODO', index: 1 }
{ type: 'SET_VISIBILITY_FILTER', filter: 'SHOW_ALL' }

Hacer cumplir que cada cambio se describe como una acción que nos permite tener un   comprensión clara de lo que está sucediendo en la aplicación. Si algo   cambiado, sabemos por qué cambió. Las acciones son como migas de pan de   pasó. Finalmente, para unir estados y acciones, escribimos un   función llamada un reductor. Una vez más, no tiene nada de mágico, es solo una   función que toma estado y acción como argumentos, y devuelve el   siguiente estado de la aplicación. Sería difícil escribir esa función para un   gran aplicación, por lo que escribimos funciones más pequeñas que gestionan partes del estado:

function visibilityFilter(state = 'SHOW_ALL', action) {
  if (action.type === 'SET_VISIBILITY_FILTER') {
    return action.filter;
  } else {
    return state;
  }
}

function todos(state = [], action) {
  switch (action.type) {
  case 'ADD_TODO':
    return state.concat([{ text: action.text, completed: false }]);
  case 'TOGGLE_TODO':
    return state.map((todo, index) =>
      action.index === index ?
        { text: todo.text, completed: !todo.completed } :
        todo
   )
  default:
    return state;
  }
}

Y escribimos otro reductor que maneja el estado completo de nuestra   aplicación llamando a esos dos reductores para las claves de estado correspondientes:

function todoApp(state = {}, action) {
  return {
    todos: todos(state.todos, action),
    visibilityFilter: visibilityFilter(state.visibilityFilter, action)
  };
}

Esta es básicamente la idea de Redux. Tenga en cuenta que no hemos usado   cualquier API de Redux. Viene con algunas utilidades para facilitar esto   patrón, pero la idea principal es que describa cómo es su estado   actualizado en el tiempo en respuesta a los objetos de acción, y el 90% del código   tu escribes es simplemente JavaScript, sin uso de Redux, es   APIs, o cualquier magia.


74
2018-03-22 12:59



Es posible que lo mejor sea comenzar leyendo esta publicación de Dan Abramov, donde analiza varias implementaciones de Flux y sus intercambios en el momento en que escribía redux: La evolución de los marcos de flujo

En segundo lugar, la página de motivaciones a la que se vincula no discute tanto las motivaciones de Redux como las motivaciones detrás de Flux (y React). los Tres principios es más específico de Redux, aunque todavía no se ocupa de las diferencias de implementación de la arquitectura estándar de Flux.

Básicamente, Flux tiene varias tiendas que calculan el cambio de estado en respuesta a las interacciones UI / API con los componentes y transmiten estos cambios como eventos a los que los componentes pueden suscribirse. En Redux, solo hay una tienda a la que se suscribe cada componente. IMO siente al menos que Redux simplifica y unifica aún más el flujo de datos unificando (o reduciendo, como diría Redux) el flujo de datos a los componentes, mientras que Flux se concentra en unificar el otro lado del flujo de datos. modelo.


50
2017-09-23 14:51



Soy uno de los primeros en adoptar e implementé una aplicación de una sola página mediana usando la biblioteca Facebook Flux.

Como llego un poco tarde a la conversación, señalaré que, a pesar de mis mejores esperanzas, Facebook parece considerar que su implementación de Flux es una prueba de concepto y nunca recibió la atención que merece.

Te animo a que juegues con él, ya que expone más del funcionamiento interno de la arquitectura Flux, que es bastante educativo, pero al mismo tiempo no proporciona muchos de los beneficios que brindan las bibliotecas como Redux (que no son eso es importante para proyectos pequeños, pero se vuelve muy valioso para los más grandes).

Hemos decidido que de avanzar nos trasladaremos a Redux y te sugiero que hagas lo mismo;)


22
2018-01-05 13:45



Aquí está la explicación simple de Redux sobre Flux. Redux no tiene un despachador. Se basa en funciones puras llamadas reductores. No necesita un despachador. Cada acción es manejada por uno o más reductores para actualizar la tienda individual. Dado que los datos son inmutables, los reductores devuelven un nuevo estado actualizado que actualiza la tiendaenter image description here

Para más información http://www.prathapkudupublog.com/2017/04/flux-vs-redux.html


13
2018-04-18 14:27



Trabajé bastante tiempo con Flux y ahora utilicé Redux bastante tiempo. Como Dan señaló, ambas arquitecturas no son tan diferentes. El caso es que Redux hace las cosas más simples y limpias. Te enseña un par de cosas además de Flux. Como, por ejemplo, Flux es un ejemplo perfecto de flujo de datos en una dirección. Separación de preocupaciones donde tenemos datos, sus manipulaciones y la capa de vista separada. En Redux tenemos las mismas cosas, pero también aprendemos sobre la inmutabilidad y las funciones puras.


2
2018-01-25 12:26



Flujo es un patrón y Redux es una biblioteca

Flux es un nombre elegante para el patrón de observador modificado un poco para adaptarse a React, pero Facebook lanzó algunas herramientas para ayudar a implementar el patrón Flux, por lo que la siguiente es la diferencia entre el uso de estas herramientas (que comúnmente se conoce como Flux ) y usando Redux.

Tanto Flux como Redux tienen acciones. Las acciones se pueden comparar con eventos (o qué desencadenar eventos). En Flux, una acción es un objeto JavaScript simple, y ese es el caso predeterminado en Redux también, pero cuando se utiliza el middleware Redux, las acciones también pueden ser funciones y promesas.

Con Flux, es una convención tener múltiples tiendas por aplicación; cada tienda es un objeto singleton. En Redux, la convención es tener una sola tienda por aplicación, generalmente separada en dominios de datos internamente (puede crear más de una tienda Redux si es necesario para escenarios más complejos).

Flux tiene un único despachador y todas las acciones tienen que pasar por ese despachador. Es un objeto singleton. Una aplicación Flux no puede tener múltiples despachadores. Esto es necesario porque una aplicación Flux puede tener múltiples tiendas y las dependencias entre esas tiendas necesitan un solo administrador, que es el despachador.

Redux no tiene entidad distribuidora. En cambio, la tienda tiene el proceso de envío incorporado. Una tienda de Redux expone algunas funciones simples de la API, una de ellas es enviar acciones.

En Flux, la lógica de qué hacer con los datos basados ​​en la acción recibida se escribe en la tienda misma. La tienda también tiene la flexibilidad de qué partes de los datos exponer públicamente. El jugador más inteligente en una aplicación Flux es la tienda.

En Redux, la lógica de qué hacer con los datos basados ​​en las acciones recibidas está en la función reductora a la que se llama para cada acción que se despacha (a través de la API de la tienda). Una tienda no se puede definir sin una función de reducción. Un reductor Redux es una función simple que recibe el estado anterior y una acción, y devuelve el nuevo estado en función de esa acción. En una aplicación Redux, puede dividir su reductor en funciones más simples como lo haría con cualquier otra función. El jugador más inteligente en Redux es el reductor.

En Redux, además, no hay mucha flexibilidad sobre qué exponer como estado de la tienda. Redux solo expondrá lo que devuelva el reductor de la tienda. Esta es una restricción.

La otra restricción más grande es que el estado de la tienda no puede ser mutable (o realmente, no debería ser). No existe tal restricción en Flux, puede mutar el estado como lo desee. La inmutabilidad del estado, en Redux, se logra fácilmente haciendo que los reductores sean funciones puras (sin efectos secundarios). Los reductores Redux siempre copian el estado que reciben y devuelven una versión modificada de la copia del estado, no el objeto original en sí. Si bien esta es una gran limitación, hace la vida mucho más fácil a largo plazo.


0
2018-06-24 07:13