👈🏽 🧑🏿 🏇🏿 Redux vs MobX sin confusión 👨‍❤️‍👨 🧚🏽 ♈️

En los últimos años, a menudo he usado Redux , pero recientemente he estado usando MobX como alternativa a la administración del estado. Las alternativas de Redux parecen convertirse naturalmente en un desastre. La gente no está segura de qué solución elegir. El problema no es necesariamente Redux vs MobX. Siempre que hay una alternativa, las personas sienten curiosidad por saber cómo resolver mejor su problema. Estoy escribiendo estas líneas para eliminar la confusión sobre las soluciones de administración de estado de Redux y MobX.

¿De qué se tratará este artículo? Primero, quiero volver brevemente al problema que resuelve la biblioteca de administración de estado. Al final, todo estará bien si solo usa this.setState () y this.state en React o su variación en otra biblioteca de nivel de presentación o en un entorno SPA. En segundo lugar, continuaré ofreciéndole una visión general de ambas soluciones, mostrando coherencia y diferencias. Por último, pero no menos importante, si ya tiene una aplicación que funciona con MobX o Redux, quiero informarle sobre la refactorización de una biblioteca de estado a otra.

Contenido:

¿Qué problema resolvemos?

Todos quieren tener administración de estado en la aplicación. Pero, ¿qué problema nos resuelve esto? La mayoría de las personas comienzan con una pequeña aplicación y ya implementan una biblioteca de administración de estado. Todos hablan de eso, ¿verdad? Redux! MobX! Pero la mayoría de las aplicaciones no necesitan una gestión estatal ambiciosa desde el principio. Esto es aún más peligroso porque la mayoría de las personas nunca se enfrentarán a problemas como bibliotecas como Redux o MobX .

El status quo actualmente está creando una aplicación front-end con componentes. Los componentes tienen un estado interno. En una aplicación en crecimiento, la administración del estado puede volverse caótica con un estado local porque:

un componente debe compartir el estado con otro componente
un componente debe modificar el estado de otro componente

En algún momento, se vuelve cada vez más difícil hablar sobre el estado de la aplicación. Esto se convierte en una red sucia de objetos de estado y mutaciones de estado en su jerarquía de componentes. En la mayoría de los casos, los objetos de estado y las mutaciones de estado no están necesariamente asociados con un componente. Están vinculados a través de su árbol de componentes, y debe subir y bajar el estado.

La solución, por lo tanto, es introducir una biblioteca de administración de estado como MobX o Redux. Le brinda herramientas para guardar su estado, cambiar el estado y recibir actualizaciones de estado. Tiene un lugar para buscar, un lugar para cambiar y un lugar para recibir actualizaciones de estado. Sigue el principio de una sola fuente de verdad.. Esto facilita razonar sobre los cambios en su estado y condiciones, ya que se separan de sus componentes.

Las bibliotecas de administración de estado como Redux y MobX a menudo tienen complementos para utilidades, por ejemplo, para Angular tienen angular-redux y mobx-angular para dar acceso a sus componentes al estado. A menudo, estos componentes se denominan componentes en contenedores o, para ser más precisos, componentes relacionados . Desde cualquier lugar de su jerarquía de componentes, puede acceder al estado y cambiarlo actualizando su componente a uno relacionado.

¿Cuál es la diferencia entre REDUX y MOBX?

Antes de sumergirnos en la diferencia, quiero contarles sobre las similitudes entre MobX y Redux.

Ambas bibliotecas se utilizan para controlar el estado en aplicaciones JavaScript. No están necesariamente asociados con una biblioteca como Angular. También se usan en otras bibliotecas, como ReactJs y VueJs.

Si elige una de las soluciones de administración del estado, no se encontrará con un bloqueo de proveedor. Puede cambiar a otra solución de administración de estado en cualquier momento. Puede actualizar de MobX a Redux o de Redux a MobX. Más tarde te mostraré cómo sucede esto.

Redux diseñado por Dan Abramov y Andrew Clark es un derivado de la arquitectura Flux. A diferencia de Flux, utiliza un repositorio sobre varios para mantener el estado. Además, en lugar de un despachador, utiliza funciones puras para cambiar el estado. Si no está familiarizado con el flujo y es nuevo en la administración del estado, no se preocupe por el último párrafo.

Redux está influenciado por los principios de la programación funcional (FP). La FP se puede hacer en JavaScript, pero muchas personas provienen de un entorno orientado a objetos, como Java, y tienen dificultades para aceptar los principios de la programación funcional en primer lugar. Esto explica más adelante por qué MobX puede ser más fácil de aprender como principiante.

Como Redux incluye programación funcional, utiliza funciones puras .

Una función pura es una función que recibe entrada, devuelve salida y no tiene otras dependencias que no sean las mismas funciones. Dicha función siempre produce la misma salida con la misma entrada y no tiene efectos secundarios. Más detalles

(state, action) => newState

Su estado de Redux no ha cambiado . En lugar de mutar, siempre devuelve un nuevo estado. No realiza mutaciones de estado y no depende de referencias de objetos.


//     Redux,     
function addAuthor(state, action) {
  return state.authors.push(action.author);
}
//       
function addAuthor(state, action) {
  return [ ...state.authors, action.author ];
}

Y por último, pero no menos importante, en Redux idiomático, su estado está normalizado , como en una base de datos. Las entidades se refieren entre sí solo por id . Esta es la mejor práctica. Aunque no todos lo hacen, puede usar una biblioteca como normalizr para lograr un estado tan normalizado. El estado normalizado le permite mantener un estado plano y entidades como una sola fuente de verdad .

{
  post: {
    id: 'a',
    authorId: 'b',
    ...
  },
  author: {
    id: 'b',
    postIds: ['a', ...],
    ...
  }
}

En comparación, MobX de Michel Weststratt está influenciado no solo por la programación orientada a objetos, sino también por la programación reactiva. Envuelve su estado en objetos observables. Por lo tanto, tiene todas las características de " Observable " en su estado. Los datos pueden tener configuradores y captadores simples, pero observables le permiten recibir actualizaciones después de los cambios de datos.

En Mobx, tu estado es volátil . De esta manera cambia el estado directamente:

function addAuthor(author) {
  this.authors.push(author);
}

Además, las organizaciones permanecen en una estructura de datos (profundamente) anidadas entre sí. No normalizas tu condición. La condición permanece desnormalizada e incrustada.

{
  post: {
    id: 'a',
    ...
    author: {
      id: 'b',
      ...
    }
  }
}

Un repositorio versus varios

En Redux, almacena todo su estado en un repositorio global o en un estado global . Un único objeto de estado es su única fuente de verdad. Numerosas cajas de cambios, por otro lado, le permiten cambiar un estado inmutable.

En comparación, MobX usa varios repositorios. Al igual que los reductores Redux, puede aplicar separación y conquista por nivel técnico, dominio, etc. Puede almacenar sus objetos de dominio en repositorios separados, pero también puede controlar el estado de visualización en sus repositorios. Al final, coloca el estado más apropiado para su aplicación.

Técnicamente, también puede tener múltiples repositorios en Redux. Nadie te obliga a usar solo uno. Pero este no es un caso de uso anunciado de Redux. El uso de múltiples repositorios va en contra de las mejores prácticas. En Redux, desea tener un repositorio que responda a través de sus reductores a eventos globales.

¿Cómo se ve la implementación?

En Redux, agregar la configuración de una aplicación a un estado global requiere las siguientes líneas de código.

const initialState = {
  users: [
    {
      name: 'Alex'
    },
    {
      name: 'Nik'
    }
  ]
};
// reducer
function users(state = initialState, action) {
  switch (action.type) {
  case 'USER_ADD':
    return { ...state, users: [ ...state.users, action.user ] };
  default:
    return state;
  }
}
// action
{ type: 'USER_ADD', user: user };

En MobX, el almacenamiento solo administrará el subestado (ya que el reductor en Redux controla el subestado), pero puede cambiar directamente el estado. La anotación @observable le permite observar cambios de estado.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}

Ahora puede llamar a userStore.users.push (usuario); en la copia de la tienda. Sin embargo, se recomienda que las mutaciones estatales sean más explícitas a través de la acción.

class userStore{
@observable users = [
    {
      name: 'Nikita'
    }
  ];
}
@action addUser = (user) => {
    this.users.push(user);
  }

Puede aplicarlo estrictamente configurando MobX con configure ({empceActions: true}) ;. Ahora puede cambiar su estado llamando a userStore.addUser (usuario); en la copia de la tienda.

Has visto cómo actualizar el estado en Redux y MobX. En Redux, su estado es de solo lectura . Solo puede cambiar el estado con acciones explícitas . En contraste, en MobX, el estado incluye lectura y escritura. Puede mutar el estado directamente sin usar acciones, pero puede seleccionar acciones explícitas usando la configuración de enforceActions.

Curva de aprendizaje del estado de reacción

Tanto Redux como MobX se utilizan principalmente en aplicaciones React. Pero estas son bibliotecas de administración de estado independientes que se pueden usar en todas partes sin React. Sus bibliotecas de interacción facilitan su combinación con componentes angulares. Estos son react-redux para React + Redux y mobx-react para React + MobX . Más adelante explicaré cómo usar ambos en el árbol de componentes Angular.

En discusiones recientes, ha sucedido que la gente discutió sobre la curva de aprendizaje en Redux. Esto sucedió a menudo en el contexto de React: las personas comenzaron a aprender React y ya querían usar la administración de estado con Redux. La mayoría de las personas afirman que React y Redux tienen una buena curva de aprendizaje, pero ambos pueden ser abrumadores. Por lo tanto, MobX será una alternativa, porque es más adecuado para principiantes.

Sin embargo, sugeriría un enfoque diferente para que los nuevos usuarios de React aprendan sobre la gestión del estado en el ecosistema de React. Comience a aprender Reaccione con sus propias funciones locales de administración de estado en componentes. En una aplicación React, primero aprende sobre los métodos del ciclo de vida de React y comprende cómo administrar los estados locales con setState () y this.state. Recomiendo esta ruta de aprendizaje. De lo contrario, se verá rápidamente abrumado por el ecosistema React. Al final, en el camino te darás cuenta de que administrar el estado (interno) de los componentes se vuelve complicado.

¿Redux o MobX para principiantes?

Al familiarizarse con los componentes angulares y la administración de estado interna, puede elegir una biblioteca de administración de estado para resolver su problema. Después de usar ambas bibliotecas, diría que MobX puede ser muy conveniente para principiantes. Ya hemos visto que MobX necesita menos código, aunque usa algunas notas mágicas que aún no necesitamos saber.
Con MobX, no necesita estar familiarizado con la programación funcional. Los términos como inmutabilidad aún pueden ser extranjeros.

— , JavaScript. , , - , , MobX.

Redux

A medida que su aplicación crece y varios desarrolladores trabajan en ella, debería considerar usar Redux. Por naturaleza, se compromete a utilizar acciones explícitas para cambiar de estado. La acción tiene un tipo y una carga útil que la caja de cambios puede usar para cambiar de estado. Es muy fácil para el equipo de desarrollo hablar sobre los cambios de estado de esta manera.

Redux le proporciona una arquitectura completa para administrar el estado con claras limitaciones. Historia de éxito de Redux .

Otra ventaja de Redux es su uso en el lado del servidor. Como estamos trabajando con JavaScript simple, puede enviar estado a través de la red. La serialización y deserialización de un objeto de estado funciona de forma inmediata. Sin embargo, esto también es posible con MobX.

MobX es menos seguro de sí mismo, pero con configure ({empceActions: true}) puede aplicar restricciones más precisas, como en Redux. Es por eso que no diría que no puede usar MobX para escalar aplicaciones, pero Redux tiene una forma clara de hacer algo. La documentación de MobX incluso dice: " [MobX] no le dice cómo estructurar su código, dónde almacenar el estado o cómo manejar los eventos ". El equipo de desarrollo primero tendría que crear una arquitectura de gestión de estado.

Después de todo, la curva de aprendizaje de gestión estatal no es tan empinada. Cuando repetimos las recomendaciones, un novato en React aprenderá primero a usar setState () y this.state correctamente . Después de un tiempo, comprenderá los problemas de usar solo setState ()para mantener el estado en la aplicación React. Cuando busca una solución, se encuentra con bibliotecas de administración de estado como MobX o Redux. Pero ¿cuál escoger? Dado que MobX es menos seguro de sí mismo, tiene una plantilla más pequeña y se puede usar de la misma manera que setState (), recomendaría darle una oportunidad a MobX en proyectos pequeños. Tan pronto como la aplicación crezca en tamaño y aumente el número de participantes, debería considerar aplicar restricciones adicionales en MobX o darle una oportunidad a Redux. Me gustó usar ambas bibliotecas. Incluso si no usa uno de ellos al final, tiene sentido ver una forma alternativa de administrar el estado.

Últimos pensamientos

Cada vez que leo los comentarios en la discusión de Redux vs MobX, siempre hay un comentario: “ Redux tiene demasiado estándar, en su lugar deberías usar MobX. Pude eliminar XXX líneas de código ". El comentario puede ser cierto, pero nadie considera un compromiso. Redux viene con muchas plantillas como MobX porque se ha agregado para restricciones de diseño específicas. Esto le permite razonar sobre el estado de su aplicación, incluso si es a mayor escala. Toda la ceremonia asociada con el tratamiento del estado, no es justa.

La biblioteca de Redux es bastante pequeña. La mayoría de las veces solo se trata de simples objetos y matrices de JavaScript.. Esto está más cerca de JavaScript vainilla que MobX. En MobX, los objetos y las matrices están envueltos en objetos observables que ocultan la mayor parte de la plantilla estándar. Se basa en abstracciones ocultas en las que ocurre la magia, pero es más difícil entender los mecanismos básicos. Redux facilita hablar sobre esto con JavaScript simple. Esto facilita probar y depurar la aplicación.

Además, debe volver a pensar de dónde venimos en el SPA. Un conjunto de marcos de una página y bibliotecas de aplicaciones tenían los mismos problemas de administración de estado que finalmente se resolvieron utilizando un modelo de flujo integral. Redux es el sucesor de este enfoque.

En MobX, nuevamente se mueve en la dirección opuesta. Nuevamente comenzamos a mutar el estado directamente, sin aprovechar la programación funcional. Para algunas personas, esto se acerca nuevamente al enlace de datos bidireccional. Después de un tiempo, las personas pueden volver a encontrar los mismos problemas antes de que aparezca una biblioteca de administración de estado como Redux. La gestión del estado está dispersa entre los componentes y termina en desorden.

Mientras que en Redux tienes una ceremonia establecida para configurar las cosas, MobX es menos seguro de sí mismo. Pero sería prudente aceptar la mejor experiencia MobX. La gente necesita saber cómo organizar la gestión estatal para mejorar sus argumentos al respecto. De lo contrario, las personas tienden a cambiar de estado directamente en los componentes.

Ambas bibliotecas son geniales. Aunque Redux ya está bien establecido, MobX se está convirtiendo en una alternativa viable a la gestión estatal.

Más recursos

comparación de Michel Weststratt - creador de
MobX

Redux vs MobX sin confusión