Quels pourraient être les inconvénients de l'utilisation de Redux au lieu de Flux [fermé]

243

J'ai récemment découvert Redux . Tout a l'air bien. Y a-t-il des inconvénients, des problèmes ou des compromis liés à l'utilisation de Redux sur Flux? Merci

Ivan Wang
la source

Réponses:

411

Auteur Redux ici!

Je voudrais dire que vous allez faire les compromis suivants en l'utilisant:

  • Vous devrez apprendre à éviter les mutations. Flux n'a pas d'opinion sur la mutation des données, mais Redux n'aime pas les mutations et de nombreux packages complémentaires à Redux supposent que vous ne modifiez jamais l'état. Vous pouvez appliquer cela avec des packages de développement uniquement comme redux-immutable-state-invariant , utiliser Immutable.js , ou faire confiance à vous-même et à votre équipe pour écrire du code non mutatif, mais c'est quelque chose dont vous devez être conscient, et cela doit être une décision consciente acceptée par votre équipe.

  • Vous devrez choisir soigneusement vos colis. Alors que Flux n'essaie explicitement pas de résoudre des problèmes «à proximité» tels que défaire / rétablir , persister ou formes , Redux a des points d'extension tels que des middleware et des améliorateurs de magasin, et il a engendré un écosystème jeune mais riche . Cela signifie que la plupart des packages sont de nouvelles idées et n'ont pas encore reçu la masse critique d'utilisation. Vous pourriez dépendre de quelque chose qui sera clairement une mauvaise idée quelques mois plus tard, mais c'est difficile à dire pour l'instant.

  • Vous n'aurez pas encore une belle intégration Flow. Flux vous permet actuellement d'effectuer des vérifications de type statique très impressionnantes que Redux ne prend pas encore en charge . Nous y arriverons, mais cela prendra un certain temps.

Je pense que le premier est le plus gros obstacle pour les débutants, le second peut être un problème pour les adopteurs précoces trop enthousiastes, et le troisième est ma bête noire personnelle. En dehors de cela, je ne pense pas que l'utilisation de Redux apporte des inconvénients particuliers que Flux évite, et certaines personnes disent qu'il a même des avantages par rapport à Flux.


Voir aussi ma réponse sur les avantages de l'utilisation de Redux .

Dan Abramov
la source
1
Réponse géniale. Existe-t-il une explication simple des raisons pour lesquelles les mutations sont évitées dans redux et les packages complémentaires?
rambossa
7
En bref, les mutations rendent difficile la vérification des parties d'état modifiées pour redessiner efficacement uniquement les parties modifiées de l'interface utilisateur. Ils rendent également le débogage plus difficile et les bibliothèques comme github.com/omnidan/redux-undo impossibles. Enfin, le voyage dans le temps sur github.com/gaearon/redux-devtools ne fonctionnerait pas si l'état était muté.
Dan Abramov
@DanAbramov comment l'immuabilité aide-t-elle à avoir des redessins efficaces dans Redux? Par exemple, dans react-redux, la shallowEqualvérification est utilisée pour déterminer si l'état a changé. Mais il peut être remplacé par deepEqual ou JSON.stringify et comparer. Finalement, ce sont des performances légèrement inférieures - mais ce sont de purs calculs sans traiter avec DOM - donc assez rapidement. Et en tout cas le rendu est le même
amakhrov
@amakhrov deepEqual ou JSON.stringify sont assez lents. Ils ne sont pas "assez rapides" pour de vraies applications, surtout si vous comparez des données pour chaque vue.
Dan Abramov
OK j'ai compris. Sonne que l'immuabilité rend les chèques sales plus efficaces, plutôt que de redessiner plus efficacement.
amakhrov
37

Redux et Flux nécessitent une quantité considérable de code passe-partout pour couvrir de nombreux modèles courants, en particulier ceux qui impliquent l'extraction de données asynchrones. La documentation Redux contient déjà quelques exemples de réduction de passe-partout: http://redux.js.org/docs/recipes/ReducingBoilerplate.html . Vous pouvez obtenir tout ce dont vous pourriez avoir besoin dans une bibliothèque Flux comme Alt ou Fluxxor, mais Redux préfère la liberté aux fonctionnalités. Cela pourrait être un inconvénient pour certains développeurs car Redux fait certaines hypothèses sur votre état qui pourraient être ignorées par inadvertance.

La seule façon pour vous de vraiment répondre à votre question est d'essayer Redux si vous le pouvez, peut-être dans un projet personnel. Redux est né du besoin d'une meilleure expérience de développeur, et il est orienté vers la programmation fonctionnelle. Si vous n'êtes pas familier avec les concepts fonctionnels tels que les réducteurs et la composition des fonctions, vous risquez d'être ralenti, mais seulement légèrement. L'avantage d'intégrer ces idées dans le flux de données est de faciliter les tests et la prévisibilité.

Avertissement: j'ai migré de Flummox (une implémentation de Flux populaire) vers Redux et les avantages l'emportent largement sur les inconvénients. Je préfère beaucoup moins de magie dans mon code. Moins de magie se fait au prix d'un peu plus de passe-partout, mais c'est un très petit prix à payer.

velveteer
la source
16

Flux et Redux . . .

Redux n'est pas une implémentation pure de Flux mais définitivement inspiré par Flux. La plus grande différence est qu'il utilise un seul magasin qui enveloppe un objet d'état contenant tout l'état de votre application. Au lieu de créer des magasins comme vous le ferez dans Flux, vous écrirez des fonctions de réduction qui changeront l'état d'un seul objet. Cet objet représente tout l'état de votre application. Dans Redux, vous obtiendrez l'action et l'état actuels, et retournerez un nouvel état. Cela signifie que les actions sont séquentielles et que l'état est immuable. Cela m'amène au con le plus évident de Redux (à mon avis).


Redux soutient un concept immuable .

Pourquoi l'immuabilité?

Il y a peu de raisons à cela:
1. Cohérence - l'état du magasin est toujours modifié par un réducteur, il est donc facile de suivre qui change quoi.
2. Performances - car il est immuable, Redux n'a qu'à vérifier si l'état précédent! == l'état actuel et si oui à rendre. Pas besoin de boucler l'état à chaque fois pour un rendu déterminé.
3. Débogage - de nouveaux concepts impressionnants comme le débogage dans le temps et le rechargement à chaud .

MISE À JOUR: si cela n'était pas assez convaincant, regardez Lee Byron excellent parler des interfaces utilisateur immuables .

Redux nécessite une discipline de développeur à travers la base de code / bibliothèques pour maintenir cette idée. Vous devrez vous assurer de choisir des bibliothèques et d'écrire du code de manière non modifiable.

Si vous souhaitez en savoir plus sur les différentes implémentations des concepts Flux (et ce qui fonctionne le mieux pour vos besoins), consultez cette comparaison utile.

Après avoir dit cela, je dois admettre que Redux est l'endroit où le développement futur de JS va (comme pour l'écriture de ces lignes).

Lior Elrom
la source
15

L'un des plus grands avantages de l'utilisation de Redux par rapport aux autres alternatives de Flux est sa capacité à réorienter votre réflexion vers une approche plus fonctionnelle. Une fois que vous comprenez comment tous les fils se connectent, vous réalisez son élégance étonnante et sa simplicité de conception, et ne pouvez jamais revenir en arrière.

cnp
la source
4

Je préfère utiliser Redux car il utilise un magasin qui facilite la gestion des états par rapport à Flux , aussi Redux DevTools, ce sont des outils vraiment utiles qui vous permettent de voir ce que vous faites avec votre état avec des données utiles et c'est vraiment en ligne avec les outils de développement React.

Aussi Redux a obtenu une plus grande flexibilité en utilisant avec d' autres cadres populaires comme angulaire . Quoi qu'il en soit, voyons comment Redux se présente comme un framework.

Redux a trois principes qui peuvent très bien présenter Redux et ils sont également la principale différence entre Redux et Flux.

Source unique de vérité

L'état de l'ensemble de votre application est stocké dans une arborescence d'objets dans un seul magasin.

Cela facilite la création d'applications universelles, car l'état de votre serveur peut être sérialisé et hydraté dans le client sans effort de codage supplémentaire. Une arborescence d'état unique facilite également le débogage ou l'inspection d'une application; il vous permet également de conserver l'état de votre application en cours de développement, pour un cycle de développement plus rapide. Certaines fonctionnalités qui étaient traditionnellement difficiles à implémenter - Annuler / Rétablir, par exemple - peuvent soudainement devenir triviales à implémenter, si tout votre état est stocké dans une seule arborescence.

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
    }
  ]
}
*/

L'état est en lecture seule

La seule façon de changer l'état est d'émettre une action, un objet décrivant ce qui s'est passé.

Cela garantit que ni les vues ni les rappels réseau n'écriront jamais directement à l'état. Au lieu de cela, ils expriment une intention de transformer l'État. Parce que tous les changements sont centralisés et se produisent un par un dans un ordre strict, il n'y a pas de conditions de course subtiles à surveiller. Comme les actions ne sont que des objets simples, elles peuvent être journalisées, sérialisées, stockées et rejouées ultérieurement à des fins de débogage ou de test.

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

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

Les modifications sont effectuées avec des fonctions pures

Pour spécifier comment l'arbre d'état est transformé par les actions, vous écrivez des réducteurs purs.

Les réducteurs ne sont que des fonctions pures qui prennent l'état précédent et une action, et retournent l'état suivant. N'oubliez pas de renvoyer de nouveaux objets d'état, au lieu de muter l'état précédent. Vous pouvez commencer avec un seul réducteur et, au fur et à mesure que votre application se développe, le diviser en plus petits réducteurs qui gèrent des parties spécifiques de l'arborescence d'état. Étant donné que les réducteurs ne sont que des fonctions, vous pouvez contrôler l'ordre dans lequel ils sont appelés, transmettre des données supplémentaires ou même créer des réducteurs réutilisables pour des tâches courantes telles que la pagination.

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)

pour plus d'informations, visitez ici

Alireza
la source
0

Redux exige une discipline en ce qui concerne l'immuabilité. Quelque chose que je peux recommander est ng-freeze pour vous informer de toute mutation d'état accidentelle.

Leonardo
la source
-1

Pour autant que je sache, redux est inspiré par le flux. flux est une architecture comme MVC (model view controller). Facebook présente le flux dû au problème d'évolutivité lors de l'utilisation de MVC. donc le flux n'est pas une implémentation, c'est juste un concept. En fait, redux est la mise en œuvre de flux.

Uzama Zaid
la source