Hace poco descubrí Redux . Todo se ve bien. ¿Hay inconvenientes, problemas o compromisos de usar Redux sobre Flux? Gracias

¡Autor de Redux aquí!

Me gustaría decir que vas a hacer los siguientes compromisos al usarlo:

• Tendrás que aprender a evitar mutaciones. Flux no está interesado en la mutación de datos, pero a Redux no le gustan las mutaciones y muchos paquetes complementarios a Redux suponen que nunca mutas el estado. Puede aplicar esto con paquetes solo para desarrolladores como redux-immutable-state-invariant , usar Immutable.js o confiar en usted y su equipo para escribir código no mutante, pero es algo que debe tener en cuenta, y esto debe Ser una decisión consciente aceptada por su equipo.

• Tendrás que elegir cuidadosamente tus paquetes. Si bien Flux no intenta explícitamente resolver problemas "cercanos" como deshacer / rehacer , persistencia o formas , Redux tiene puntos de extensión como middleware y potenciadores de tiendas, y ha generado un ecosistema joven pero rico . Esto significa que la mayoría de los paquetes son ideas nuevas y aún no han recibido la masa crítica de uso. Es posible que dependa de algo que claramente será una mala idea unos meses más tarde, pero aún es difícil de decir.

• Aún no tendrá una buena integración de Flow. Flux actualmente le permite hacer comprobaciones de tipo estático muy impresionantes que Redux aún no admite . Llegaremos allí, pero llevará algún tiempo.

Creo que el primero es el mayor obstáculo para los principiantes, el segundo puede ser un problema para los primeros usuarios demasiado entusiastas, y el tercero es mi motivo personal favorito. Aparte de eso, no creo que el uso de Redux tenga inconvenientes particulares que Flux evita, y algunas personas dicen que incluso tiene algunas ventajas en comparación con Flux.

Vea también mi respuesta sobre las ventajas de usar Redux .

Tanto Redux como Flux requieren una cantidad considerable de código repetitivo para cubrir muchos patrones comunes, especialmente aquellos que implican la obtención de datos asincrónicos. La documentación de Redux ya tiene algunos ejemplos para la reducción de repeticiones: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Puede obtener todo lo que necesite de una biblioteca Flux como Alt o Fluxxor, pero Redux prefiere la libertad sobre las funciones. Esto podría ser un inconveniente para algunos desarrolladores porque Redux hace ciertas suposiciones sobre su estado que podrían ignorarse inadvertidamente.

La única forma de responder realmente a su pregunta es probar Redux si puede, tal vez en un proyecto personal. Redux surgió debido a la necesidad de una mejor experiencia del desarrollador, y está sesgado hacia la programación funcional. Si no está familiarizado con los conceptos funcionales como los reductores y la composición de la función, es posible que se ralentice, pero solo ligeramente. La ventaja de adoptar estas ideas en el flujo de datos es una prueba y previsibilidad más fáciles.

Descargo de responsabilidad: migré de Flummox (una implementación popular de Flux) a Redux y las ventajas superan con creces cualquier desventaja. Prefiero mucho menos magia en mi código. Menos magia tiene un costo de un poco más repetitivo, pero es un precio muy pequeño a pagar.

Flux y Redux . . .

Redux no es una implementación pura de Flux, pero definitivamente está inspirado en Flux. La mayor diferencia es que utiliza una única tienda que envuelve un objeto de estado que contiene todo el estado de su aplicación. En lugar de crear tiendas como lo haría en Flux, escribirá funciones reductoras que cambiarán el estado de un solo objeto. Este objeto representa todo el estado en su aplicación. En Redux obtendrá la acción y el estado actuales, y devolverá un nuevo estado. Eso significa que las acciones son secuenciales y el estado es inmutable. Eso me lleva a la estafa más obvia en Redux (en mi opinión).

¿Por qué la inmutabilidad?

Hay algunas razones para eso:
1. Coherencia : el estado de la tienda siempre cambia por un reductor, por lo que es fácil rastrear quién cambia qué.
2. Rendimiento : debido a que es inmutable, Redux solo necesita verificar si el estado anterior! == estado actual y si es así para renderizar. No es necesario repetir el estado cada vez para obtener una representación determinada.
3. Depuración : nuevos conceptos asombrosos como Depuración de viajes en el tiempo y Recarga en caliente .

ACTUALIZACIÓN: si eso no fue lo suficientemente persuasivo, vea la excelente charla de Lee Byron sobre las interfaces de usuario inmutables .

Redux requiere una disciplina de desarrollador (s) a través de la base de código / bibliotecas para mantener esta idea. Deberá asegurarse de elegir bibliotecas y escribir código de manera no mutable.

Si desea obtener más información sobre la implementación diferente de los conceptos de Flux (y lo que funciona mejor para sus necesidades), consulte esta útil comparación.

Después de decir eso, debo admitir que Redux es el destino futuro de JS (en cuanto a escribir estas líneas).

Uno de los mayores beneficios al usar Redux sobre las otras alternativas de Flux es su capacidad para reorientar su pensamiento hacia un enfoque más funcional. Una vez que comprenda cómo se conectan todos los cables, se dará cuenta de su impresionante elegancia y simplicidad en el diseño, y nunca podrá regresar.

Prefiero usar Redux, ya que usa una tienda que hace que la administración de estado sea mucho más fácil en comparación con Flux , también Redux DevTools son herramientas realmente útiles que le permiten ver lo que está haciendo con su estado con algunos datos útiles y está realmente en línea con las herramientas de desarrollo React.

Además, Redux tiene más flexibilidad al usar otros marcos populares como Angular . De todos modos, veamos cómo Redux se presenta como un marco.

Redux tiene tres principios que pueden introducir a Redux muy bien y también son la principal diferencia entre Redux y Flux.

Fuente única de verdad

El estado de toda su aplicación se almacena en un árbol de objetos dentro de una sola tienda.

Esto facilita la creación de aplicaciones universales, ya que el estado de su servidor puede ser serializado e hidratado en el cliente sin esfuerzo adicional de codificación. Un solo árbol de estado también facilita la depuración o inspección de una aplicación; también le permite persistir el estado de su aplicación en desarrollo, para un ciclo de desarrollo más rápido. Algunas funcionalidades que tradicionalmente han sido difíciles de implementar, como Deshacer / Rehacer, por ejemplo, pueden volverse triviales de implementar, si todo su estado está almacenado en un solo árbol.

console.log(store.getState())

/* Prints
{
  visibilityFilter: 'SHOW_ALL',
  todos: [
    {
      text: 'Consider using Redux',
      completed: true,
    },
    {
      text: 'Keep all state in a single tree',
      completed: false
    }
  ]
}
*/

El estado es de solo lectura

La única forma de cambiar el estado es emitir una acción, un objeto que describe lo que sucedió.

Esto asegura que ni las vistas ni las devoluciones de llamada de la red escribirán directamente al estado. En cambio, expresan una intención de transformar el estado. Debido a que todos los cambios están centralizados y ocurren uno por uno en un orden estricto, no hay condiciones sutiles de carrera a tener en cuenta. Como las acciones son simplemente objetos simples, pueden registrarse, serializarse, almacenarse y luego reproducirse con fines de depuración o prueba.

store.dispatch({
  type: 'COMPLETE_TODO',
  index: 1
})

store.dispatch({
  type: 'SET_VISIBILITY_FILTER',
  filter: 'SHOW_COMPLETED'
})

Los cambios se realizan con funciones puras.

Para especificar cómo las acciones transforman el árbol de estado, escriba reductores puros.

Los reductores son solo funciones puras que toman el estado anterior y una acción, y devuelven el siguiente estado. Recuerde devolver nuevos objetos de estado, en lugar de mutar el estado anterior. Puede comenzar con un solo reductor y, a medida que su aplicación crezca, divídala en reductores más pequeños que administren partes específicas del árbol de estado. Debido a que los reductores son solo funciones, puede controlar el orden en que se llaman, pasar datos adicionales o incluso hacer reductores reutilizables para tareas comunes como la paginación.

function visibilityFilter(state = 'SHOW_ALL', action) {
  switch (action.type) {
    case 'SET_VISIBILITY_FILTER':
      return action.filter
    default:
      return state
  }
}

function todos(state = [], action) {
  switch (action.type) {
    case 'ADD_TODO':
      return [
        ...state,
        {
          text: action.text,
          completed: false
        }
      ]
    case 'COMPLETE_TODO':
      return state.map((todo, index) => {
        if (index === action.index) {
          return Object.assign({}, todo, {
            completed: true
          })
        }
        return todo
      })
    default:
      return state
  }
}

import { combineReducers, createStore } from 'redux'
let reducer = combineReducers({ visibilityFilter, todos })
let store = createStore(reducer)

para más información visita aquí

Redux requiere disciplina con respecto a la inmutabilidad. Algo que puedo recomendar es ng-freeze para informarle sobre cualquier mutación accidental del estado.

Hasta donde yo sé, redux está inspirado en el flujo. Flux es una arquitectura como MVC (controlador de vista modelo). Facebook introduce el flujo debido a un problema de escalabilidad al usar MVC. entonces Flux no es una implementación, es solo un concepto. En realidad, redux es la implementación de flujo.