Pourquoi est immutabilité si important (ou au besoin) en JavaScript?

Je suis actuellement en train de travailler sur Réagir JS et Réagir Natif cadres. À mi-chemin de la route, je suis tombé sur l'Immuabilité ou la Immuable-bibliothèque JS, quand j'ai lu sur Facebook Flux et Redux mise en œuvre.

La question est, pourquoi est immutabilité si important? Ce qui est faux dans la mutation des objets? N'est-ce pas faire des choses simples?

Donner un exemple, considérons un simple lecteur de News app avec l'ouverture de l'écran étant une vue de liste de titres de l'actualité.

Si je dis une tableau d'objets avec une valeur initialement je ne peux pas la manipuler. C'est ce principe de l'immutabilité dit, à droite? (Corrigez-moi si je me trompe.)
Mais, que faire si j'ai une nouvelle News de l'objet qui doit être mis à jour? Dans le cas d'habitude, j'aurais juste ajouté de l'objet dans le tableau.
Comment puis-je atteindre dans ce cas? Supprimer le stocker et de le recréer?
N'est pas d'ajouter un objet à la matrice une opération moins cher?

  • Simple oui. Simple à briser. L'immutabilité, fondamentalement signifie que vous pouvez faire confiance qu'elle ne changera pas. Selon les circonstances, ce n'est pas seulement important, mais essentiel.
  • Pertinentes: programmers.stackexchange.com/questions/151733/...
  • Les données immuables de la structure et de la fonction pure conduire à la transparence référentielle, ce qui rend beaucoup plus facile de raisonner sur le comportement de votre programme. Vous bénéficiez également de retour en arrière pour gratuit lors de l'utilisation fonctionnelle de la structure de données.
  • J'ai fourni un Redux du point de vue @bozzmob.
InformationsquelleAutor bozzmob | 2015-12-20
  1. 159

    J'ai été récemment des recherches sur le même sujet. Je vais faire de mon mieux pour répondre à votre question(s) et d'essayer de partager ce que j'ai appris jusqu'à présent.

    La question est, pourquoi est immutabilité si important? Ce qui est mauvais dans
    la mutation des objets? N'est-ce pas faire des choses simples?

    Fondamentalement, il s'agit du fait que l'immutabilité augmente la prévisibilité, de la performance (indirectement) et permet la mutation de suivi.

    Prévisibilité

    Mutation cache changer, ce qui créer (inattendue) des effets secondaires, qui peuvent causer des méchants bugs. Lorsque vous appliquez l'immuabilité vous pouvez garder votre architecture de l'application et modèle mental simple, ce qui rend plus facile de raisonner sur votre application.

    Performance

    Même si l'ajout de valeurs d'un Objet immuable signifie qu'une nouvelle instance doit être créé où les valeurs existantes doivent être copiés et les nouvelles valeurs doivent être ajoutés à la nouvelle de l'Objet dont le coût de la mémoire, des Objets immuables pouvez utiliser structurels de partage pour réduire la surcharge de la mémoire.

    Toutes les mises à jour de retour de nouvelles valeurs, mais en interne, les structures sont partagés à
    réduire de façon drastique l'utilisation de la mémoire (et GC raclée). Cela signifie que si
    vous ajoutez à un vecteur avec des éléments de 1000, il ne fait pas de créer
    un nouveau vecteur 1001-éléments de long. Le plus probable, à l'interne seulement quelques
    les petits objets sont alloués.

    Vous pouvez lire plus sur ce ici.

    Mutation De Suivi

    Outre l'utilisation réduite de la mémoire, l'immuabilité vous permet d'optimiser votre application en faisant usage de la référence et de la valeur de l'égalité. Cela le rend vraiment facile de voir si quelque chose a changé. Par exemple, un changement d'état dans un réagir composant. Vous pouvez utiliser shouldComponentUpdate pour vérifier si l'état est identique en comparant l'état des Objets et éviter de rendu.
    Vous pouvez lire plus sur ce ici.

    Ressources supplémentaires:

    Si je dis un tableau d'objets avec une valeur de départ. Je ne peux pas
    de la manipuler. C'est ce principe de l'immutabilité dit, à droite?(Correct
    moi si je me trompe). Mais, que faire si j'ai un nouvel objet d'informations qui a pour
    être mis à jour? Dans le cas d'habitude, j'aurais juste ajouté l'objet de la
    tableau. Comment puis-je atteindre dans ce cas? Supprimer la boutique & de le recréer?
    N'est pas d'ajouter un objet à la matrice une opération moins cher?

    Oui, c'est correct. Si vous êtes confus sur la façon de l'implémenter dans votre demande, je vous recommande de regarder comment redux fait cela pour se familiariser avec les concepts de base, il m'a beaucoup aidé.

    J'aime utiliser Redux comme exemple, car il embrasse l'immuabilité. Il a un seul état immuable de l'arbre (appelé store), où tous les changements d'état sont explicites par l'envoi d'actions qui sont traitées par un réducteur qui accepte de l'état précédent avec dit des actions (un à la fois), et renvoie le prochain état de votre demande. Vous pouvez en lire plus à ce sujet les principes fondamentaux de ici.

    Il y a un super redux cours sur tête d'oeuf.io où Dan Abramov, l'auteur de redux, explique ces principes comme suit (j'ai modifié un peu le code pour mieux répondre à la scénario):

    import React from 'react';
import ReactDOM from 'react-dom';
//Reducer.
const news = (state=[], action) => {
switch(action.type) {
case 'ADD_NEWS_ITEM': {
return [ ...state, action.newsItem ];
}
default: {
return state;
}
}
};
//Store.
const createStore = (reducer) => {
let state;
let listeners = [];
const subscribe = (listener) => {
listeners.push(listener);
return () => {
listeners = listeners.filter(cb => cb !== listener);
};
};
const getState = () => state;
const dispatch = (action) => {
state = reducer(state, action);
listeners.forEach( cb => cb() );
};
dispatch({});
return { subscribe, getState, dispatch };
};
//Initialize store with reducer.
const store = createStore(news);
//Component.
const News = React.createClass({
onAddNewsItem() {
const { newsTitle } = this.refs;
store.dispatch({
type: 'ADD_NEWS_ITEM',
newsItem: { title: newsTitle.value }
});
},
render() {
const { news } = this.props;
return (
<div>
<input ref="newsTitle" />
<button onClick={ this.onAddNewsItem }>add</button>
<ul>
{ news.map( ({ title }) => <li>{ title }</li>) }
</ul>
</div>
);
}
});
//Handler that will execute when the store dispatches.
const render = () => {
ReactDOM.render(
<News news={ store.getState() } />,
document.getElementById('news')
);
};
//Entry point.
store.subscribe(render);
render();

    Aussi, ces vidéos démontrer plus en détail comment faire pour obtenir l'immutabilité pour:

    • Jusqu'-voter pour, généralement, une bonne réponse. Toutefois, votre code par exemple. Donc addNews retourne une nouvelle news de tableau et l'original news est intacte, mais alors quoi? Allez-vous attribuer à ... news2? Et puis le prochain appel est news3? Il semble y avoir une erreur dans l'approche spécifique pour ce morceau de code. (Indice: est-il judicieux d'utiliser const pour un état variable? L'état est spécifiquement destiné à changer au fil du temps; je dirais même implicitement garantie)
    • merci pour les commentaires! Mon intention était d'illustrer le concept et montrent explicitement que les Objets ne sont pas muté, et pas nécessairement pour montrer comment la mettre en œuvre dans tous les sens. Cependant, mon exemple peut être un peu déroutant, je vais le mettre à jour dans un peu.
    • Le reactjs exemple rendu les choses tellement plus clair. Merci pour cet instructif et détaillé de réponse. Juste une question rapide, Redux déjà utiliser immutablejs droit? Si je commencer à utiliser redux, il n'est pas nécessaire d'exiger immutablejs. Suis-je le droit à ce sujet?
    • vous êtes les bienvenus! Non, ce n'est pas correct, vous devez appliquer l'immuabilité dans le réducteur de vous-même. Cela signifie que vous pouvez suivre les stratégies comme démontré dans les vidéos ou utiliser une bibliothèque comme immutablejs. Vous pouvez trouver plus d'info ici et ici.
    • Qui aide certainement. Prévisible de l'INTERFACE utilisateur en fonction de l'état était vraiment un bon point à mentionner. Merci pour la réponse ailleurs.
    • ES6 const n'est pas à propos de l'immuabilité. Mathias Bynens, a écrit un grand blog à ce sujet.
    • merci pour le partage du lien. Je suis d'accord c'est une distinction importante. ^_^
    • Veuillez expliquer cette "Mutation cache changer, ce qui créer (inattendue) des effets secondaires, qui peuvent causer des méchants bugs. Lorsque vous appliquez l'immuabilité vous pouvez garder votre architecture de l'application et modèle mental simple, ce qui rend plus facile de raisonner sur votre demande." Parce que ce n'est pas vrai dans le contexte de JavaScript.

    InformationsquelleAutor danillouz
  2. 94

    Allant à contre-courant de l'Immuabilité

    Réponse courte: l'Immuabilité est plus une tendance de la mode que d'une nécessité en JavaScript. Il y a un peu étroit cas, quand il devient utile (Réaction/Redux pour la plupart), mais généralement pour les mauvaises raisons.

    Réponse longue: lire ci-dessous.

    Pourquoi est immutabilité si important(ou au besoin) en javascript?

    Bien, je suis content que vous avez demandé!

    Il y a quelques temps un très talentueux gars qui s'appelle Dan Abramov a écrit un script javascript de l'état de gestion de bibliothèque appelée Redux qui utilise les fonctions pures et d'immuabilité. Il a également fait quelques vraiment cool les vidéos qui ont fait l'idée est vraiment facile à comprendre (et de vendre).

    Le timing était parfait. La nouveauté de Angulaire a été la décoloration, et JavaScript monde était prêt à se concentrer sur la dernière chose qui avait le bon degré de frais, et cette bibliothèque n'était pas seulement innovant, mais à fente parfaitement avec Réagir qui a été colporté par un autre Silicon Valley de la centrale.

    Triste que cela puisse être, la mode, la règle dans le monde du JavaScript. Maintenant Abramov est saluée comme un demi-dieu et tous les nous, simples mortels ont pour objet de nous-mêmes à la Dao de l'Immuabilité... Si elle a du sens ou pas.

    Ce qui est faux dans la mutation des objets?

    Rien!

    En fait, les programmeurs ont été mutation des objets pour euh... tant qu'il y a des objets à muter. 50 ans et+ du développement de l'application dans d'autres mots.

    Et pourquoi compliquer les choses? Lorsque vous avez un objet cat et il meurt, avez-vous vraiment besoin d'un deuxième cat pour suivre le changement? La plupart des gens serait juste de dire cat.isDead = true et être fait avec elle.

    N'est pas (mutation des objets) faire des choses simples?

    OUI! .. Bien sûr il ne!

    Spécialement en JavaScript, ce qui dans la pratique est le plus utile, utilisé pour le rendu de la vue de quelque état que se trouve ailleurs (comme dans une base de données).

    Ce que si j'ai une nouvelle News de l'objet qui doit être mis à jour? ... Comment puis-je atteindre dans ce cas? Supprimer la boutique & de le recréer? N'est pas d'ajouter un objet à la matrice une opération moins cher?

    Bien, vous pouvez aller de l'approche traditionnelle et la mise à jour de la News objet, de sorte que votre représentation en mémoire de l'objet de modifications (et la vue affichée à l'utilisateur, ou alors on l'espère)...

    Ou sinon...

    Vous pouvez essayer de le sexy FP/Immutabilité approche et ajouter vos modifications à la News objet à un tableau de suivi à chaque changement historique de sorte que vous pouvez ensuite parcourir le tableau et la figure ce que la bonne représentation de l'état devrait être (ouf!).

    Je suis en train d'apprendre ce qui est bon ici. S'il vous plaît ne m'éclairer 🙂

    Les modes passent copain. Il existe de nombreuses façons à la peau d'un chat.

    Je suis désolé que vous avez à supporter la confusion de changer constamment de paradigmes de programmation. Mais hey, BIENVENUE AU CLUB!!

    Maintenant quelques points importants à retenir en ce qui concerne l'Immutabilité, et vous obtiendrez ces jeté à vous avec la fébrile intensité que seule la naïveté peut rassembler.

    1) l'Immuabilité est génial pour éviter des conditions de course dans les environnements multi-threads.

    Les environnements Multi-threads (comme C++, Java et C#) se sont rendus coupables de la pratique de verrouillage des objets lorsque plus d'un thread veut les modifier. C'est mauvais pour la performance, mais mieux que l'alternative de la corruption des données. Et pourtant, pas aussi bon que rendre tout ce qui est immuable (Seigneur louange Haskell!).

    MAIS HÉLAS! En JavaScript vous toujours fonctionner sur un seul thread. Même des web workers (chaque exécute à l'intérieur d'un contexte distinct de). Donc, puisque vous ne pouvez pas avoir un fil condition de course à l'intérieur de votre contexte d'exécution (toutes ces belles variables globales et fermetures), le principal argument en faveur de l'Immuabilité va à la fenêtre.

    (Ceci dit, il est un avantage de l'utilisation de fonctions pures dans des web workers, qui est que vous n'aurez pas d'attentes au sujet de jongler avec des objets sur le thread principal.)

    2) l'Immuabilité peut (en quelque sorte) d'éviter des conditions de course dans l'état de votre application.

    Et là est le véritable nœud de la question, la plupart (Réagir) les développeurs vont vous dire que l'Immutabilité et de la FP peut en quelque sorte le travail de cette magie qui permet à l'état de votre demande pour devenir prévisible.

    Bien sûr, cela ne signifie pas que vous pouvez éviter des conditions de course dans la base de données, à tirer que l'on off vous auriez à coordonner tous les utilisateurs dans tous les navigateurs, et pour cela vous aurez besoin d'un back-end de la technologie de push comme Les WebSockets (plus sur ce ci-dessous) qui permettront la diffusion de modifications à tout le monde de lancer l'application.

    Ce plutôt déroutant revendication signifie simplement que la dernière valeur affectée à un objet d'état (définie par un seul utilisateur d'exploitation au sein de leur navigateur) devenir prévisible. Ce qui n'est vraiment pas de progrès du tout. Parce que vous pourriez avoir utilisé un simple vieux muté variable pour le suivi de votre état et vous savez que vous avez affaire avec les dernières informations à chaque fois que vous accédez à elle, et que cela fonctionne avec n'importe quoi, mais Réagir/Redux.

    Pourquoi? En raison de Réagir est spécial.. et composant de l'état est géré par l'intermédiaire d'une chaîne d'événements que vous n'avez aucun contrôle sur, et comptons sur vous se rappelant de ne pas muter état directement. Cela a été manipulé étonnamment à partir d'un PR perspective, comme le Réagir battage médiatique a tourné une lacune dans un mode sexy. La mode de côté, je préfère voir l'immutabilité pour ce qu'elle est, c'est à dire un outil permettant de brancher un écart lors de votre choix de cadre ne traite pas de l'état de manière intuitive.

    3) conditions de Course sont catégoriquement mauvais.

    Bien, elle pourrait être si vous êtes à l'aide de Réagir. Mais ils sont rares, si vous chercher un cadre différent.

    En outre, vous avez normalement beaucoup plus de problèmes pour faire face à... des Problèmes comme la dépendance de l'enfer. Comme un ballonnement de base de code. Comme votre CSS de ne pas consommer. Comme un lent processus de construction ou d'être coincé à un monolithe de back-end qui fait de l'itération presque impossible. Comme inexpérimenté devs de ne pas comprendre ce qui se passe et faire un gâchis de choses.

    Vous savez. La réalité. Mais bon, qui se soucie de qui?

    4) Immutabilité fait usage de Les Types De Référence pour réduire l'impact sur les performances de suivi de chaque changement d'état.

    Parce que sérieusement, si vous voulez copier des trucs à chaque fois vos modifications de l'état, de mieux vous assurez-vous que vous êtes intelligent à ce sujet.

    5) Immutabilité vous permet d'ANNULER les choses.

    Parce er.. c'est le numéro un de la fonctionnalité de votre chef de projet est le point de demander, non?

    6) état Immuable a beaucoup de fraîcheur potentiel en combinaison avec les WebSockets

    Dernier mais non le moindre, l'accumulation de l'état deltas donne un joli cas en combinaison avec les WebSockets, ce qui permet une consommation facile de état des flux de immuable événements...

    Une fois que la pièce tombe sur ce concept (l'état étant un flux d'événements -- plutôt que d'un brut de l'ensemble d'enregistrements qui représente la dernière vue), l'immuable monde devient un endroit magique à habiter. Une terre de l'événement d'origine l'émerveillement et la possibilité que transcende le temps lui-même. Et quand c'est fait droit, cela peut certainement faire en temps réel des applications easier à réaliser, vous de diffuser le flux d'événements pour tous les intéressés afin qu'ils puissent construire leur propre représentation de la présenter et d'écrire leurs propres changements dans la commune de flux.

    Mais à un certain point de vous réveiller et de réaliser que tout ce que l'émerveillement et la magie ne sont pas gratuits. Contrairement à vos désireux collègues, vos parties prenantes (oui, les gens qui vous payer) soucient peu de la mode et beaucoup de choses sur l'argent qu'ils paient pour fabriquer un produit qu'ils peuvent vendre. Et la ligne de fond est que plus difficile de l'écrire immuable code et plus facile à casser, plus il y a peu de point ayant une immuable front-end si vous n'avez pas de back-end pour la soutenir. Quand (et si!) vous avez enfin convaincre les parties prenantes de votre organisation que vous devriez publier et de consommer des événements par l'intermédiaire d'un poussez le techology comme les WebSockets, vous trouverez ce qu'un la douleur c'est-à-échelle dans la production.

    Maintenant pour quelques conseils, si vous choisissez de l'accepter.

    Un choix à écrire du code JavaScript à l'aide de PF/Immutabilité est aussi un choix à faire votre demande de code de base plus vaste, plus complexe et plus difficile à gérer. Je soutiens fermement pour la limitation de cette approche à votre Redux réducteurs.. sauf si vous savez ce que vous faites. En d'autres mots: Keep It Simple™. Vous serez mieux dans la plupart des cas. Et où vous n'êtes pas, je voudrais mettre l'accent sur l' les avantages de données immuables qui coule à travers votre (ensemble) application, plutôt que de construire un point de vue purement fonctionnel avant la fin de l'appel et la chose faite.

    Pourquoi est immutabilité si important (ou au besoin) en JavaScript?

    Maintenant, si vous êtes assez chanceux pour être en mesure de faire des choix dans votre travail, puis d'essayer et d'utiliser votre sagesse (ou pas) et faire ce qui est juste par la personne qui paie, vous. Vous pouvez vous baser sur votre expérience, sur votre intestin, ou ce qui se passe autour de vous (il est vrai que si tout le monde est à l'aide de Réagir/Redux puis il y a un argument valable qu'il sera plus facile de trouver une ressource pour continuer votre travail).. Alternativement, vous pouvez essayer soit Résumé De Développement Axée Sur L' ou Hype Développement Piloté Par Les approches. Ils pourraient être plus votre genre de chose.

    En bref, la chose à dire pour l'immutabilité, c'est qu'il sera vous faire la mode avec vos pairs, au moins jusqu'à la prochaine engouement vient autour, par quel point vous serez heureux de passer sur.

    Maintenant, j'ai ajouté ce que un article dans mon blog => L'immutabilité en JavaScript: allant à contre-courant. Hésitez pas à répondre si vous avez des sentiments forts vous souhaitez obtenir votre poitrine trop ;).

    • Bonjour Steven, Oui. J'ai eu tous ces doutes lorsque j'ai envisagé de immutable.js et redux. Mais, votre réponse est incroyable! Il ajoute beaucoup de valeur et merci pour aborder chaque point que j'avais des doutes sur. C'est tellement plus clair/mieux maintenant, même après avoir travaillé pendant des mois sur des objets immuables.
    • Merci! Fallait vraiment sortir ça de mon système. Je suis content qu'il est sorti dans une voie constructive 😉
    • J'ai été en utilisant Réagir avec un Flux/Redux depuis plus de deux ans et je ne pouvais pas être plus d'accord avec vous, excellente réponse!
    • Je suis fortement suspect que les points de vue sur l'immuabilité corrélation plutôt soigneusement à l'équipe et codebase tailles, et je ne pense pas que c'est une coïncidence que le principal promoteur est un géant de la silicon valley. Cela étant dit, je suis en désaccord: l'immuabilité est une discipline utile, comme ne pas utiliser goto est une discipline utile. Ou des tests unitaires. Ou TDD. Ou de type statique de l'analyse. Ne signifie pas que vous ne eux tout le temps, tout le temps (même si certains le font). Je dirais aussi que l'utilité est orthogonal à la hype: dans une matrice d'utile ou superflu et sexy/ennuyeux il y a beaucoup d'exemples de chaque. "hyped" !== "bad"
    • Je pense que vous faites la même erreur que l'immutabilité des adorateurs. L'immutabilité rend certaines choses plus faciles, mais d'autres plus difficiles. Il s'agit d'un compromis et que vous avez à vérifier, pour chaque scénario, individuellement s'il en vaut la peine. La complexité peut être abstrait, mais il ne veut pas disparaître dans l'air mince.
    • Salut @ftor, bon point, prendre les choses trop loin dans l'autre direction. Mais depuis, il y a une telle profusion de " pro-immuabilité dans javascript, des articles et des arguments là-bas, j'ai senti le besoin d'équilibrer les choses. Donc, les débutants ont de la partie adverse point de vue de leur permettre de se faire une opinion à l'autre.
    • Instructif, et brillamment intitulé. Jusqu'à ce que j'ai trouvé cette réponse, je pensais que j'étais la seule à la tenue d'un point de vue semblable. Je reconnais la valeur de l'immuabilité, mais ce qui me dérange, c'est que c'est devenu une toute autre technique de opprimer dogme (par exemple, au détriment des 2 voies de liaison qui est incroyablement utile pour la saisie de mise en forme que mis en œuvre dans KnockoutJS par exemple).
    • Pour info pour les 2 voies de la liaison de données VueJS est encore plus intuitive que knock-out, il utilise des getters/setters au lieu des observables.
    • Je ne pense pas que Redux ferait fonction "annuler" que Gestionnaire de Projet peut demander de plus simple. Revenir à l'état précédent de l'instantané est seulement un peu utile dans le développement de la mode (même si je suis encore à voir quelqu'un qui serait l'utiliser souvent dans la pratique), mais il n'est pas utile de construire quoi que ce soit d'autre sur le dessus. Vous avez encore le besoin de coordonner annuler les mises à jour avec backend/base de données de la même manière que vous avez toujours l'habitude de faire, en plus de l'état instantané contient beaucoup de choses que vous pourriez ne pas vouloir le récupérer.
    • sûr, mais garder à l'esprit que si vous faites de l'immutabilité droit de votre back-end est aussi immuable et reçoit avant la fin des mises à jour (comme une façon de "fluidité" des événements), vous pourriez être l'inversion de modifications dans le navigateur et le magasin de données distant, dans le même temps, et celles-ci seraient en cascade à tous les clients intéressés donc, tout le monde est dans la synchro.. essayant de coordonner les deux solutions de stockage pour l'état de l'application en front-end et back-end est un peu un cauchemar... bien que beaucoup de gens finissent par faire exactement cela.
    • pour la synchronisation de diffusion changefeeds. Avec redux vous avez déjà serializable actions, de sorte que vous pouvez émission. Est-ce vraiment pertinent si vous écrivez des changements sur mutable ou immuable structures?
    • Comment êtes-vous censé utiliser la même technique de stockage, si backend traite ensemble du jeu de données, éventuellement, des centaines de concerts, tandis que chaque client est uniquement intéressé par des sous-ensembles en fonction des ACL et des états de l'INTERFACE utilisateur (filtres etc)
    • Il existe de nombreuses façons à la peau d'un chat ici, mais je dirais que si vous faites de l'immutabilité droit de votre "jeu de données entier" est en fait l'histoire complète de la immuables événements qui l'ont affecté votre état de l'application, et ce que vous pensez de votre jeu de données entier " est en fait un ensemble de views/projections sur le sous-jacent immuable événements qui sont indexés par objet et afficher les propriétés à l'heure actuelle. Comme vous l'avez mentionné, d'autres sous-ensembles (les filtres) sont des vues étroites en bas de ces objets et aider les utilisateurs à trouver ce qu'ils sont intéressés à. Espérons que cela a du sens.
    • Oh mon dieu, je t'aime tellement pour écrire tout cela.

    InformationsquelleAutor Steven de Salas
  3. 49

    La question est, pourquoi est immutabilité si important? Ce qui est faux dans la mutation des objets? N'est-ce pas faire des choses simples?

    En fait, le contraire est vrai: la mutabilité rend les choses plus compliquées, au moins dans le long terme. Oui, c'est votre premier codage plus facile parce que vous pouvez simplement changer les choses là où vous le voulez, mais quand votre programme va plus cela devient un problème – si une valeur a changé, ce qui a changé?

    Quand vous faites tout immuables, cela signifie que les données ne peuvent pas être modifiés par surprise, pas plus. Vous savez pour certain que si vous passez une valeur dans une fonction, il ne peut pas être changé dans cette fonction.

    Dit simplement: si vous utilisez des valeurs inaltérables, il est très facile de raisonner à propos de votre code: tout le monde obtient un unique* copie de vos données, de sorte qu'il ne peut pas futz avec elle et d'endommager d'autres parties de votre code. Imaginez combien cela rend plus facile de travailler dans un environnement multi-thread!

    Note 1: Il existe un potentiel de performance coût de l'immuabilité en fonction de ce que vous faites, mais des choses comme Immutable.js optimiser du mieux qu'ils peuvent.

    Note 2: Dans le cas improbable où vous n'étiez pas sûr, Immutable.js et ES6 const signifier des choses très différentes.

    Dans le cas d'habitude, j'aurais juste ajouté de l'objet dans le tableau. Comment puis-je atteindre dans ce cas? Supprimer la boutique & de le recréer? N'est pas d'ajouter un objet à la matrice une opération moins cher? PS: Si l'exemple n'est pas la bonne façon d'expliquer l'immuabilité, s'il vous plaît ne laissez-moi savoir quel est le bon exemple pratique.

    Oui, de nouvelles de votre exemple est parfaitement bon, et votre raisonnement est tout à fait vrai: vous ne pouvez pas modifier votre liste actuelle, alors vous avez besoin pour créer un nouveau:

    var originalItems = Immutable.List.of(1, 2, 3);
var newItems = originalItems.push(4, 5, 6);
    • Je ne suis pas en désaccord avec cette réponse, mais il n'a pas l'adresse de son "je voudrais apprendre à partir d'un exemple concret d'une" partie de la question. On pourrait arguer du fait qu'une seule référence à la liste des actualités les en-têtes utilisés dans de multiples domaines est une bonne chose. "Je n'ai qu'à mettre à jour la liste une fois et tout référencement de la nouvelle liste est mise à jour gratuite" - je pense qu'une meilleure solution serait de prendre un problème commun, comme il l'a présenté, et de montrer une alternative intéressante qui utilise l'immuabilité.
    • OK; je vais essayer de modifier.
    • Une simple et grande réponse! Merci @TwoStraws ... Juste une question rapide - Dire maintenant que j'ai commencer à utiliser newItems dans mon programme, je devrais effacer les valeurs dans originalItems ou va GC automatiquement prendre soin d'elle? La chose est, si de nombreuses variables(objets je veux dire) sont créés dans le programme, l'utilisation de la mémoire sera trop haut à droite?
    • Je suis content que la réponse a été utile! Au sujet de votre nouvelle question: n'essayez pas à deviner le système 🙂 Dans ce cas précis, quelque chose qui s'appelle "structurelle de partage" réduit GC raclée de façon spectaculaire – si vous avez 10 000 éléments dans une liste et ajouter 10 de plus, je crois Immutable.js vais essayer de ré-utiliser la structure antérieure du mieux qu'elle peut. Laissez Immutable.js vous soucier de la mémoire et les chances sont que vous allez trouver qu'il s'en sort mieux.
    • Imagine how much easier this makes working in a multi-threaded environment! -> Ok pour les autres langues, mais ce n'est pas un avantage en monothread JavaScript.
    • notez que le JavaScript est essentiellement asynchrone et de l'événementiel. Il n'est pas immunisé aux conditions de course.
    • toujours de mon point de vue reste. FP et l'Immuabilité sont puissants utiles paradigmes pour éviter la corruption des données et/ou des ressources serrures multithread environnements mais pas en JavaScript parce que son seul thread. Sauf si je suis absent de la sainte pépite de sagesse le principal commerce-off ici est de savoir si vous êtes prêt à vous rendre le code plus complexe (et lent) dans une quête afin d'éviter des conditions de course ... qui sont beaucoup moins un problème que la plupart des gens pensent.

    InformationsquelleAutor TwoStraws
  4. 35

    Bien que les autres réponses sont beaux, pour répondre à votre question au sujet d'une pratique de cas d'utilisation (d'après les commentaires sur les autres réponses) permet de sortir de votre code en cours d'exécution pendant une minute et regardez omniprésente, la réponse juste sous votre nez: git. Qu'arriverait-il si à chaque fois que vous avez poussé un commit, vous écrasait les données dans le référentiel?

    Nous sommes maintenant à l'un des problèmes, immuable collections de visage: la mémoire de la météorisation. Git est assez intelligent pour ne pas simplement faire de nouvelles copies de fichiers chaque fois que vous faites un changement, simplement, il assure le suivi de la diff.

    Alors que je ne connais pas beaucoup de choses sur le fonctionnement interne de git, je ne peux que supposer qu'il utilise une stratégie similaire à celle des bibliothèques de référence: structurelle de partage. Sous le capot, les bibliothèques utilisent essaie ou d'autres arbres pour ne suivre les nœuds qui sont différents.

    Cette stratégie est aussi assez performant pour les structures de données en mémoire qu'il y a bien connu arbre-fonctionnement des algorithmes qui fonctionnent en temps logarithmique.

    Un autre cas d'utilisation: dites que vous voulez un bouton annuler sur votre webapp. Avec immuables représentation de vos données, la mise en œuvre de telles est relativement trivial. Mais si vous comptez sur la mutation, cela signifie que vous avez à vous soucier de la mise en cache de l'état du monde et de faire les mises à jour atomiques.

    En bref, il y a un prix à payer pour l'immuabilité dans les performances d'exécution et la courbe d'apprentissage. Mais tout programmeur expérimenté vous dira que le débogage de temps l'emporte sur le code-le temps de rédaction d'un ordre de grandeur. Et le léger coup sur les performances d'exécution est probablement compensé par l'état-les bugs liés à vos utilisateurs n'ont pas à endurer.

    • Un brillant exemple je dis. Ma compréhension de l'immuabilité est plus clair maintenant. Merci Jared. En fait, l'une des implémentations bouton ANNULER 😀 Et vous faites des choses assez simple pour moi.
    • Juste parce qu'un motif de sens dans git ne signifie pas la même chose du sens partout. Dans git, vous se soucient réellement de toute l'histoire stockées et vous voulez être en mesure de fusionner les différentes branches. En frontend, vous n'avez pas de soins sur la plupart de l'état de l'histoire et vous n'avez pas besoin de toute cette complexité.
    • c'est seulement complexe car ce n'est pas la valeur par défaut. Je n'utilisez pas habituellement mori ou immutable.js dans mes projets: je suis toujours hésitant à prendre des tiers, deps. Mais si c'était la valeur par défaut (à la clojurescript) ou, au moins, avait un opt-in natif option, je ne l'utiliserais tout le temps, parce que quand j'ai par exemple de programme en clojure je n'ai pas immédiatement des trucs tout en atomes.
    InformationsquelleAutor Jared Smith
  5. 6

    Pourquoi est immutabilité si important(ou au besoin) en JavaScript?

    Immutabilité peuvent être suivis dans des contextes différents, mais le plus important serait la suivre à l'encontre de l'état de l'application et à l'encontre de l'INTERFACE de l'application.

    Je vais envisager le JavaScript Redux motif très à la mode et modernes de l'approche et parce que vous avez mentionné.

    Pour l'UI, nous avons besoin de le faire prévisible.
    Il sera prévisible si UI = f(application state).

    Applications (en JavaScript) ne modifiez pas l'état, via des actions mises en œuvre à l'aide de la réducteur de la fonction.

    Le réducteur fonction simplement de l'action et de l'ancien état et renvoie le nouvel état, en gardant l'ancien état intact.

    new state  = r(current state, action)

    Pourquoi est immutabilité si important (ou au besoin) en JavaScript?

    L'avantage: vous voyagez dans le temps des etats-unis depuis tous les objets d'état sont enregistrés et vous pouvez effectuer le rendu de l'application, en tout état depuis UI = f(state)

    De sorte que vous pouvez annuler/refaire facilement.

    Se trouve être la création de tous ces états peuvent encore être efficace en terme de mémoire, une analogie avec Git est grand, et nous avons la même analogie dans le système d'exploitation Linux avec les liens symboliques (basé sur les inodes).

    InformationsquelleAutor prosti
  6. 6

    La question est, pourquoi est immutabilité si important? Ce qui est faux dans la mutation des objets? N'est-ce pas faire des choses simples?

    Sur la mutabilité

    Rien n'est mauvais dans la mutabilité du point de vue technique. Il est rapide, il est de nouveau à l'aide de la mémoire. Les développeurs sont à utiliser à partir du début (que je m'en souvienne). Problème dans l'utilisation de la mutabilité et de troubles qui cela peut apporter.

    Si l'objet n'est pas partagée avec quoi que ce soit, par exemple, existe dans le domaine de la fonction et n'est pas exposée à l'extérieur, il est difficile de voir les avantages de l'immuabilité. Vraiment, dans ce cas, il n'ya pas de sens à être immuable. Le sens de l'immuabilité commence quand quelque chose est partagé.

    De la mutabilité des maux de tête

    Mutable structure partagée pouvez facilement créer de nombreux écueils. Un changement dans une partie du code d'accès à la référence n'a pas d'impact à d'autres parties de la visibilité de cette référence. Cet impact se connecte toutes les pièces ensemble, même quand ils ne devraient pas être au courant des différents modules. Mutation dans une fonction peut se bloquer totalement différente de la partie de l'application. Une telle chose est un mauvais effet de côté.

    Autre problème avec la mutation est corrompu. L'état corrompu peut se produire lorsque la mutation procédure échoue dans le milieu, et certains champs ont été modifiés et d'autres non.

    Qui plus est, avec la mutation, il est difficile de suivre le changement. Simple vérification des références ne montrera pas la différence, à savoir ce qui a changé profondément chèque doit être fait. Également de suivre l'évolution de certaines observables modèle doit être mis en place.

    Enfin, la mutation est en raison du déficit de confiance. Comment vous pouvez être sûr que la structure a voulu valeur, si elle peut être muté.

    const car = { brand: 'Ferrari' };
doSomething(car);
console.log(car); //{ brand: 'Fiat' }

    Comme l'exemple ci-dessus montre, en passant mutable structure peut toujours finir par avoir une structure différente. Fonction doSomething est la mutation de l'attribut donné de l'extérieur. Pas de confiance pour le code, vous vraiment ne savez pas ce que vous avez et ce que vous devrez. Tous ces problèmes parce qu': Mutable structures représentant des pointeurs de la mémoire.

    Immutabilité sur les valeurs

    Immutabilité signifie que le changement ne se fait pas sur le même objet,la structure, mais le changement est représenté dans une nouvelle. Et c'est parce que de référence représente non seulement de la valeur pointeur de la mémoire. Chaque changement crée de nouvelles de la valeur et de ne pas toucher à l'ancienne. De telles règles claires redonne la confiance et le code de la prévisibilité. Les fonctions sont sûrs à utiliser, car au lieu de mutation, ils traitent propres versions avec ses propres valeurs.

    À l'aide de valeurs au lieu d'une mémoire conteneurs donne la certitude que chaque objet représente spécifiques immuable de la valeur et il est sûr à utiliser.

    Immuable des structures représentant les valeurs.

    Je suis plongée encore plus dans le sujet au moyen de l'article https://medium.com/@macsikora/the-state-of-immutability-169d2cd11310

    InformationsquelleAutor Maciej Sikora
  7. 4

    Un autre avantage de l'Immuabilité en Javascript, c'est qu'il réduit Temporelle de Couplage, ce qui a des avantages substantiels pour le design en général. Tenir compte de l'interface d'un objet avec les deux méthodes:

    class Foo {
baz() {
//.... 
}
bar() {
//....
}
}
const f = new Foo();

    Il peut être le cas que d'un appel à baz() est nécessaire pour obtenir l'objet dans un état valide pour un appel à bar() pour fonctionner correctement. Mais comment savez-vous cela?

    f.baz();
f.bar(); //this is ok
f.bar();
f.baz(); //this blows up

    De le comprendre, vous devez examiner de près la classe internes, car il n'est pas immédiatement apparent de l'examen de l'interface publique. Ce problème peut exploser dans une grande base de code avec beaucoup de mutables de l'état et des classes.

    Si Foo est immuable, alors ce n'est plus un problème. Il est sûr de supposer que nous pouvons appeler baz ou bar dans n'importe quel ordre, parce que l'état intérieur de la classe ne peut pas changer.

    InformationsquelleAutor ghostypants
  8. 3

    De Prendre Un Différent...

    Mon autre réponse répond à la question à partir d'un très point de vue pratique, et je l'aime toujours. J'ai décidé d'ajouter ce que une autre réponse plutôt que d'un avenant à celui-là parce que c'est un ennuyeux philosophique coup de gueule qui, espérons-le, répond aussi à la question, mais ne correspond vraiment pas avec ma réponse existant.

    TL;DR

    Même dans de petits projets d'immutabilité peut être utile, mais ne supposez pas que parce qu'il existe, il est là pour vous.

    Beaucoup, beaucoup plus de réponse

    REMARQUE: pour le but de cette réponse, je suis en utilisant le mot "discipline" dans le sens de la négation de soi pour certaines prestations.

    Ceci est similaire dans la forme à une autre question: "dois-je utiliser la Machine? Pourquoi sont les types de si important dans le JavaScript?". Il a une semblable réponse trop. Envisagez le scénario suivant:

    Vous êtes l'unique auteur et mainteneur d'un JavaScript/CSS/HTML codebase de près de 5000 lignes. Votre semi-technique patron lit quelque chose sur la Machine-comme-la-nouvelle-hotness et suggère que nous voulons déplacer, mais laisse la décision à vous. Si vous la lire, jouer avec elle, etc.

    Alors maintenant, vous avez un choix à faire, ne vous déplacez à Tapuscrit?

    Tapuscrit a d'incontestables avantages: intellisense, la capture des erreurs dès le début, en précisant votre Api d'avance, à la facilité de fixer les choses lors d'un refactoring-casse, moins de contrôles. La machine a également une certaine coûts: certains très naturel et bon JavaScript idiomes peut être difficile de modèle, il n'est pas particulièrement puissant type de système, les annotations pousser du col, du temps et de l'effort de réécriture base de code existante, étape supplémentaire dans la construction de pipelines, etc. Plus fondamentalement, il creuse un sous-ensemble possible de corriger les programmes JavaScript en échange de la promesse que votre code est plus susceptibles être correct. C'est arbitrairement restrictive. C'est le point essentiel: vous imposer une certaine discipline qui vous limite (j'espère que de se tirer une balle dans le pied).

    Revenir à la question, reformulé dans le cadre de l'alinéa ci-dessus: est-il la peine?

    Dans le scénario décrit, je maintiens que, si vous êtes très familier avec une petite médiocre, JS base de code, que le choix de l'utilisation de la Machine est plus esthétique que pratique. Et c'est fine, il n'y a rien mal avec l'esthétique, elles ne sont simplement pas nécessairement convaincante.

    Scénario B:

    - Vous changer d'emploi et sont maintenant un métier de programmeur au Foo Corp Vous travaillez avec une équipe de 10 sur un 90000 LoC (et de comptage) en JavaScript/HTML/CSS de base de code est assez compliqué de construire le pipeline impliquant babel, webpack, une suite de polyfills, de réagir avec divers plugins, un état du système de gestion, ~20 bibliothèques de tiers, ~10 bibliothèques internes, éditeur de plugins comme une linter avec des règles pour le guide de style, etc. etc.

    En arrière quand vous étiez 5k LoC gars/fille, il n'a tout simplement pas beaucoup d'importance. Même la documentation n'était pas que un gros problème, même de revenir à une certaine partie du code au bout de 6 mois vous avez pu le comprendre assez facilement. Mais maintenant, la discipline n'est pas seulement agréable, mais nécessaire. Cette discipline ne peut pas porter sur la Machine, mais sera susceptibles d'impliquer une certaine forme de l'analyse statique ainsi que toutes les autres formes de codage de la discipline (documentation, guide de style, scripts de compilation, les tests de régression, CI). La Discipline n'est plus un de luxe, c'est un nécessité.

    Tout cela appliqué à GOTO en 1978: votre dinky peu de jeu de blackjack en C pourrait utiliser GOTOs et les spaghettis de la logique et ce n'était pas un gros problème pour choisir-votre-propre-aventure votre chemin à travers elle, mais que des programmes est devenu plus grand et plus ambitieux, bien, indisciplinés utilisation de GOTO ne pouvait pas être soutenue. Et tout cela s'applique à l'immutabilité aujourd'hui.

    Comme types statiques, si vous ne travaillez pas sur une grande base de code avec une équipe d'ingénieurs de maintenir et de l'étendre, le choix de l'utilisation de l'immuabilité est plus esthétique que pratique: les bénéfices sont toujours là, mais ne peuvent pas l'emporter sur les coûts encore.

    Mais comme avec toutes les disciplines, il arrive un point où il n'est plus facultatif. Si je veux maintenir un poids santé, puis de la discipline impliquant la crème glacée peut être facultatif. Mais si je veux être un athlète de compétition, mon choix de savoir si ou de ne pas manger de la crème glacée est subsumé par mon choix d'objectifs. Si vous voulez changer le monde avec le logiciel, l'immuabilité peut-être partie de ce dont vous avez besoin pour éviter qu'il s'effondre sous son propre poids.

    • +1 je l'aime. Beaucoup plus sur le point de Jared. Et pourtant, l'immutabilité ne sera pas économiser une équipe à partir de son propre manque de discipline.
    • son une forme de discipline. Et en tant que tel, je pense que c'est en corrélation avec (mais ne le remplace pas) les autres formes de discipline du génie logiciel. Il complète, plutôt que de les supplanter. Mais comme je l'ai dit dans un commentaire sur votre réponse, je ne suis pas du tout surpris qu'il est poussé par un géant technologique avec une ribambelle de tous les ingénieurs de broyage de suite sur la même base de code 🙂 ils ont besoin de toute la discipline qu'ils peuvent obtenir. J'ai, pour la plupart, ne pas muter des objets mais aussi de ne pas utiliser toute forme d'application, puisque, bien, c'est juste moi.
    InformationsquelleAutor Jared Smith
  9. 2

    Une fois, il y avait un problème avec la synchronisation des données entre threads. Ce problème a été une grande douleur, il y avait 10+ solutions. Certaines personnes ont essayé de résoudre radicalement. C'était un endroit où la programmation fonctionnelle est né. Il est juste comme le Marxisme. Je ne pouvais pas comprendre comment Dan Abramov vendu cette idée en JS, parce qu'il est mono-thread. Il est un génie.

    Je peux donner un petit exemple. Il y a un attribut __attribute__((pure)) dans gcc. Les compilateurs essaie de le résoudre si votre fonction est pur ou pas, si vous ne declear spécialement. Votre fonction peut être pur, même votre état est mutable. L'immuabilité est seulement un de plus de 100 façons de vous garantir fonction sera pur. En fait 95% de vos fonctions seront purs.

    Vous ne devriez pas utiliser toutes les limitations (comme l'immuabilité) si vous avez réellement n'avez pas de raison sérieuse. Si vous voulez "Défaire" de l'état, vous pouvez créer des opérations. Si vous voulez simplifier les communications que vous pouvez envoyer des événements avec des données immuables. C'est à vous.

    Je suis en train d'écrire ce message post le marxisme de la république. Je suis sûr que la radicalisation de toute idée est une mauvaise façon.

    • Le paragraphe 3 est tellement logique. Je vous remercie pour cela. "Si vous voulez "Défaire" de l'état, vous pouvez créer des transactions"!!
    InformationsquelleAutor puchu
  10. -1

    Je pense que la principale raison pro des objets immuables, est de garder l'état de l'objet valide.

    Supposons que nous avons un objet appelé arr. Cet objet n'est valide que lorsque tous les articles sont de la même lettre.

    //this function will change the letter in all the array
function fillWithZ(arr) {
for (var i = 0; i < arr.length; ++i) {
if (i === 4) //rare condition
return arr; //some error here
arr[i] = "Z";
}
return arr;
}
console.log(fillWithZ(["A","A","A"])) //ok, valid state
console.log(fillWithZ(["A","A","A","A","A","A"])) //bad, invalid state

    si arr devenir un objet immuable, alors nous allons être sûr arr est toujours dans un état valide.

    • Je pense que arr mutera chaque fois que vous appelez fillWithZ
    • si vous utilisez immutable.js, vous obtiendrez une nouvelle copie de l'objet à chaque fois que vous changer. donc, l'objet d'origine conserve intactes
    InformationsquelleAutor bedorlan