BehaviorSubject envoie la même référence d'état à tous les abonnés

La seule solution de contournement dont nous disposons jusqu'à présent est de cloner l'état de certains de nos abonnés où nous prenons en charge l'édition via une liaison comme suit:

Je ne pense pas pouvoir répondre à cela sans réécrire votre boutique.

stateFromSubject.data.id = 2;

Cet objet d'état contient des données profondément structurées. Chaque fois que vous devez muter l'état, l'objet doit être reconstruit.

Alternativement ,

const subject = new BehaviorSubject(initialState);

function getStore(): Observable<any> {
   return subject.pipe(
      map(obj => Object.freeze(obj))
   );
}

function getById(id: number): Observable<any> {
   return getStore().pipe(
      map(state => state[id]),
      distinctUntilChanged()
   );
}

function getIds(): Observable<number[]> {
   return getStore().pipe(
      map(state => state._index),
      distinctUntilChanged()
   );
}

C'est à peu près aussi profond d'un objet d'état que je créerais. Utilisez une paire clé / valeur pour mapper entre les ID et les valeurs d'objet. Vous pouvez désormais écrire facilement des sélecteurs.

function append(data: Object) {
    const state = subject.value;
    subject.next({...state, [data.id]: Object.freeze(data), _index: [...state._index, data.id]});
}

function remove(id: number) {
    const state = {...subject.value};
    delete state[id];
    subject.next({...state, _index: state._index.filter(x => x !== id)});
}

Lorsque vous souhaitez modifier un objet de données. Vous devez reconstruire l'état et également définir les données.

function getById(id: number): Observable<any> {
   return subject.pipe(
       map(state => state[id]),
       distinctUntilChanged()
   );
}

function getIds(): Observable<number[]> {
   return subject.pipe(
      map(state => state._index),
      distinctUntilChanged()
   );
}

Une fois que vous avez fait cela. Vous devez geler les consommateurs en aval de votre objet d'état.

const initialState = {
   1: {id: 1, description: 'initial'},
   2: {id: 2, description: 'initial'},
   3: {id: 3, description: 'initial'},
   _index: [1, 2, 3]
};

Plus tard, lorsque vous faites quelque chose comme ceci:

const initialState = {
  data: {
    id: 1, 
    description: 'initial'
  }
}

Vous obtiendrez une erreur d'exécution. p>

Pour info: ce qui précède est écrit en TypeScript

Oui, tous les abonnés reçoivent la même instance de l'objet dans le sujet de comportement, c'est ainsi que fonctionnent les sujets de comportement. Si vous voulez faire muter les objets dont vous avez besoin pour les cloner.

J'utilise cette fonction pour cloner mes objets, je vais les lier aux formes angulaires

data$ | clone as data

Donc si vous avez une donnée observable $ vous pouvez créer un clone observable $ où les abonnés à cet observable obtiennent un clone qui peut être muté sans affecter les autres composants.

clone$ = data$.pipe(map(data => clone(data)));

Donc, des composants qui sont juste l'affichage des données peut s'abonner aux données $ pour plus d'efficacité et celles qui muteront les données peuvent s'abonner au clone $.

Lisez ma bibliothèque pour Angular https://github.com/adriandavidbrand/ngx-rxcache et mon article à ce sujet https://medium.com/@adrianbrand/angular-state-management-with-rxcache-468a865fc3fb il entre dans le besoin de cloner des objets afin de ne pas muter les données que nous lions aux formulaires.

Cela soun ds comme les objectifs de votre magasin sont les mêmes que ma bibliothèque de gestion d'état angulaire. Cela pourrait vous donner quelques idées.

Je ne suis pas familier avec Aurelia ou si elle a des tuyaux mais cette fonction de clonage est disponible dans le magasin avec exposer mes données avec un clone $ observable et dans les templates avec un clone pipe qui peut être utilisé comme

const clone = obj =>
  Array.isArray(obj)
    ? obj.map(item => clone(item))
    : obj instanceof Date
    ? new Date(obj.getTime())
    : obj && typeof obj === 'object'
    ? Object.getOwnPropertyNames(obj).reduce((o, prop) => {
        o[prop] = clone(obj[prop]);
        return o;
      }, {})
    : obj;

L'important est de savoir quand cloner et non cloner. Vous n'avez besoin de cloner que si les données vont subir une mutation. Il serait vraiment inefficace de cloner un tableau de données qui ne sera affiché que dans une grille.

Le gros problème logique avec votre exemple est que l'objet transmis par le sujet est en fait une référence d'objet unique. RxJS ne fait rien hors de la boîte pour créer des clones pour vous, et c'est bien sinon cela entraînerait des opérations inutiles par défaut si elles ne sont pas nécessaires.

Ainsi, bien que vous puissiez cloner la valeur reçue par les abonnés, vous n'êtes toujours pas enregistré pour l'accès à BehaviorSubject.getValue (), qui renverrait la référence d'origine. De plus, avoir les mêmes références pour certaines parties de votre état est en fait bénéfique à bien des égards, car les tableaux par exemple peuvent être réutilisés pour plusieurs composants d'affichage au lieu de devoir les reconstruire à partir de zéro.

Ce que vous voulez faire à la place, c'est tirer parti d'un modèle de source de vérité unique, similaire à Redux, où au lieu de vous assurer que les abonnés obtiennent des clones, vous traitez votre état comme un objet immuable. Cela signifie que chaque modification entraîne un nouvel état. Cela signifie en outre que vous devez limiter les modifications aux actions (actions + réducteurs dans Redux) qui construisent un nouvel état du courant plus les modifications nécessaires et retournent la nouvelle copie.

Maintenant, tout cela peut sembler beaucoup de travail, mais vous devriez jeter un œil à la Aurelia Store Plugin , qui partage à peu près le même concept que vous et s'assure que les meilleures idées de Redux sont apportées au monde d'Aurelia.