Redux: Comment initialiser redux avec un objet immuable

Je pense que ce que tu veux c'est quelque chose comme ça

// stores/some-store.js
import Immutable from 'immutable'

const { Map, List, fromJS } = Immutable
const initialState = Map({
  foo: 'bar',
  fooList: List()
})

export function someStore (state = initialState, action) {
  if (action.type === 'FOO') {
    return state.set('foo', fromJS(action.foo))
  }
  if (action.type === 'FOO_LIST') {
    return state.set('fooList', fromJS(action.fooList))
  }

  return state
}

// stores/index.js
export { default as someStore } from './some-store'

// application.js
import * as stores from './stores'

const redux = createRedux(stores)

Vous devez laisser les magasins définir leur propre état initial en utilisant le paramètre par défaut comme @emmenko l'a montré.

L'argument initialState est uniquement destiné à être utilisé pour réhydrater l'état du serveur ou localStorage. ( @acdlite , nous voudrions peut-être expliquer cela dans la documentation.)

Cela dit, ce que vous avez essayé devrait fonctionner. Quelqu'un peut-il enquêter?

Non, ce que j'ai essayé ne fonctionne pas. Je veux juste créer les données initiales de tous les magasins en un seul endroit. Je suppose que c'est ce que je ne devrais pas faire.

Je veux juste créer les données initiales de tous les magasins en un seul endroit. Je suppose que c'est ce que je ne devrais pas faire.

C'est à vous. Je trouve préférable de diviser les données initiales.

Pourtant, si quelque chose ne fonctionne pas, gardons-le ouvert? Je reviendrai la semaine prochaine et verrai pourquoi cela n'a pas fonctionné.

Le problème est avec composeStores qui suppose que l'état racine est un objet JS simple, et l'accès aux propriétés avec state[key] , qui échoue avec Immutable.Map . Je pense que cela peut fonctionner avec Immutable.Record car cela rend les champs accessibles via les propriétés JS régulières.

Il peut y avoir d'autres endroits où cela suppose un objet simple.

Oh. C'est une belle prise! Merci d'avoir expliqué. Cela est parfaitement logique.

L'utilisation de connecteurs échoue également pour la même raison: isPlainObject(Immutable.Record) === false .

@pierregm C'est en fait correct. Si cela répartissait les propriétés Record sur les accessoires du composant, cela ne fonctionnerait pas de toute façon. C'est à vous d'écrire select={state => state.get('something').toJS()} .

J'ai pu le faire fonctionner comme ça,

// store
const initialState = Immutable.fromJS({}).toOrderedMap();

export default function streamStore(state = initialState, action) {
  switch (action.type) {

    case actionTypes.FETCH_STREAM_DONE:
      var streamMap = {};

      for (var i in action.stream_data) {
        var item = action.stream_data[i];
        streamMap[item.id] = item;
      }
      return state.merge(Immutable.fromJS(streamMap).toOrderedMap());

    default:
      return state
  }
};

// select
function select(state) {
  return {stream: state.stream.toList()}
}

Cela fonctionne parfaitement mais il finit par re-rendre tous les éléments du flux (une vue de liste). Je me demandais comment on pourrait mettre en œuvre quelque chose qui compare l'ancien état au nouvel état au niveau du magasin et invalide la nécessité de rendre tous les composants là où il n'y a pas de modifications des données. NuclearJS fait cela avec des structures immuables. Quelle serait la manière recommandée d'implémenter quelque chose comme ça dans redux?

@owais

Consultez Reselect: https://github.com/faassen/reselect. Il fournit des fonctionnalités similaires aux getters NuclearJS.

@gaearon Cool! Bonne discussion à ReactEurope BTW! Merci.

C'est ma tentative d'utiliser Immutable.js avec redux 1.0.0, https://github.com/gajus/redux-immutable

Nice @gajus! Tester redux-immutable maintenant et aimer vraiment le modèle https://github.com/gajus/canonical-reducer-composition

Merci @chiplay. J'apprécierais vraiment les commentaires si vous rencontrez des lacunes ou avez des idées d'amélioration.

y a-t-il un avantage à utiliser des structures immuables avec redux? lorsque le redux est basé sur un comportement immuable (par exemple, les magasins renvoient une nouvelle copie de l'état)? Performance (des repères?)? ou autre chose? THX

@jsifalda

Avantages de l'utilisation d'Immutable avec Redux:

• Vous ne pouvez pas muter par erreur
• Des performances bien plus rapides et une meilleure consommation de mémoire avec de grands tableaux et objets

Inconvénients de l'utilisation d'Immutable avec Redux:

• Nouvelle API à apprendre pour votre équipe
• Augmentation de la taille du bundle
• Un peu plus délicat à déboguer

Le compromis est à vous!

@gaearon
merci beaucoup pour la réponse rapide et utile!

Si vous voulez ImmutableJs & Redux conforme aux normes Redux, vous pouvez jeter un œil à https://github.com/indexiatech/redux-immutablejs ,

@gaearon Est-il possible de mettre un lien sur le site web?

Merci Asaf. Je suis sûr que les gens le trouveront utile.

Le 4 septembre 2015, à 18h36, Asaf Shakarchi [email protected] a écrit:

Si vous voulez ImmutableJs & Redux conforme aux normes Redux, vous pouvez jeter un œil à https://github.com/indexiatech/redux-immutablejs ,

@gaearon Est-il possible de mettre un lien sur le site web?

-
Répondez directement à cet e-mail ou affichez-le sur GitHub.

@asaf

Bon truc, voulez-vous faire un PR à Ecosystem.md ?
Je l'ajouterai volontiers si vous ajoutez des tests à votre projet.

@gaearon Fait avec les tests unitaires, PR est: https://github.com/rackt/redux/pull/707

Merci!

Salut à tous,
une petite question pour @gaearon , d'après les tests rapides que j'ai effectués jusqu'à présent pour implémenter ImmutableJS sur mon application React / Redux existante, cela semble un peu plus lent: - / mais est-ce que je fais peut-être quelque chose de mal ...

Cas d'utilisation de base: obtenir une collection de données à partir d'un appel d'API et la stocker dans un réducteur ...

De mon réducteur,
Sans ImmutableJS:

const initialStore = {
    isLoading : false,
    error     : null,
    data      : []
}

// in the switch case
return {
   ...state,
   isLoading: false,
   error: null,
   data: action.result
}

Avec ImmutableJS

const initialStore = Map({
    isLoading : false,
    error     : null,
    data      : List()
})

// in the handler function
return state.merge({
    isLoading: false,
    error: null,
    data: List(result.result)
})

Je me demande si le "traitement" réalisé par ImmutableJS ne coûte pas plus cher ici?

D'après ce que je comprends d'Immutabilité, l'avantage est plus lorsque le rendu est rapide, non?

Merci pour vos commentaires.

L'avantage est que le fonctionnement sur des baies et des objets volumineux coûte moins de mémoire et fonctionne plus rapidement. Cela ne fait pas une grande différence dans les petites applications.

OK merci.
Alors j'ai quand même la bonne approche?

Ouais, ça me va.

Jusqu'à présent, le compromis en valait la peine .. 💯