Une vision contraire de l'immuabilité
TL / DR: l'immuabilité est plus une tendance de la mode qu'une nécessité en JavaScript. Si vous utilisez React, il fournit une solution de contournement soignée à certains choix de conception confus dans la gestion des états. Cependant, dans la plupart des autres situations, il n'ajoutera pas suffisamment de valeur à la complexité qu'il introduit, servant davantage à remplir un CV qu'à répondre à un besoin réel du client.
Réponse longue: lire ci-dessous.
Pourquoi l'immuabilité est-elle si importante (ou nécessaire) en javascript?
Eh bien, je suis content que vous ayez demandé!
Il y a quelque temps, un gars très talentueux appelé Dan Abramov a écrit une bibliothèque de gestion d'état javascript appelée Redux qui utilise des fonctions pures et l'immuabilité. Il a également fait des vidéos vraiment cool qui ont rendu l'idée très facile à comprendre (et à vendre).
Le timing était parfait. La nouveauté d' Angular était en train de disparaître, et le monde JavaScript était prêt à se concentrer sur la dernière chose qui avait le bon degré de fraîcheur, et cette bibliothèque était non seulement innovante mais parfaitement intégrée à React qui était colporté par une autre centrale électrique de la Silicon Valley .
Aussi triste que cela puisse être, la mode règne dans le monde de JavaScript. Maintenant, Abramov est salué comme un demi-dieu et nous, tous les simples mortels, devons nous soumettre au Dao de l'immuabilité ... Que cela ait un sens ou non.
Qu'est-ce qui ne va pas dans la mutation d'objets?
Rien!
En fait, les programmeurs mutent des objets depuis heu ... tant qu'il y a des objets à muter. Autrement dit, plus de 50 ans de développement d'applications.
Et pourquoi compliquer les choses? Lorsque vous avez un objet cat
et qu'il meurt, avez-vous vraiment besoin d'une seconde cat
pour suivre le changement? La plupart des gens diraient cat.isDead = true
et en finiraient avec.
(Les objets en mutation) ne simplifient-ils pas les choses?
OUI! .. Bien sûr que oui!
Spécialement en JavaScript, qui en pratique est le plus utile pour rendre une vue d'un état qui est maintenu ailleurs (comme dans une base de données).
Que faire si j'ai un nouvel objet News à mettre à jour? ... Comment puis-je réaliser dans ce cas? Supprimer le magasin et le recréer? L'ajout d'un objet au tableau n'est-il pas une opération moins coûteuse?
Eh bien, vous pouvez adopter l'approche traditionnelle et mettre à jour l' News
objet, de sorte que votre représentation en mémoire de cet objet change (et la vue affichée pour l'utilisateur, ou du moins on pourrait l'espérer) ...
Ou bien...
Vous pouvez essayer l'approche sexy FP / Immuabilité et ajouter vos modifications à l' News
objet à un tableau suivant chaque changement historique afin que vous puissiez ensuite parcourir le tableau et déterminer quelle devrait être la représentation d'état correcte (ouf!).
J'essaie d'apprendre ce qui est juste ici. Veuillez m'éclairer :)
Les modes vont et viennent copain. Il existe de nombreuses façons de peiner un chat.
Je suis désolé que vous ayez à supporter la confusion d'un ensemble de paradigmes de programmation en constante évolution. Mais bon, BIENVENUE AU CLUB !!
Maintenant, quelques points importants à retenir en ce qui concerne l'immuabilité, et vous les recevrez avec une intensité fébrile que seule la naïveté peut rassembler.
1) L'immuabilité est géniale pour éviter les conditions de course dans des environnements multi-threads .
Les environnements multithreads (comme C ++, Java et C #) sont coupables de la pratique du verrouillage des objets lorsque plusieurs threads veulent les changer. C'est mauvais pour les performances, mais meilleur que l'alternative de la corruption de données. Et pourtant pas aussi bon que de rendre tout immuable (Seigneur loue Haskell!).
MAIS HÉLAS! En JavaScript, vous opérez toujours sur un seul thread . Même les travailleurs Web (chacun s'exécute dans un contexte distinct ). Donc, comme vous ne pouvez pas avoir de condition de concurrence liée au thread dans votre contexte d'exécution (toutes ces belles variables globales et fermetures), le point principal en faveur de l'immuabilité sort par la fenêtre.
(Cela dit, il y a un avantage à utiliser des fonctions pures dans les travailleurs Web, c'est que vous n'aurez aucune attente à jouer avec des objets sur le thread principal.)
2) L'immuabilité peut (en quelque sorte) éviter les conditions de concurrence dans l'état de votre application.
Et voici le véritable nœud de la question, la plupart des développeurs (React) vous diront que l'immuabilité et la FP peuvent en quelque sorte opérer cette magie qui permet à l'état de votre application de devenir prévisible.
Bien sûr, cela ne signifie pas que vous pouvez éviter les conditions de concurrence dans la base de données , pour retirer celle-ci, vous devrez coordonner tous les utilisateurs dans tous les navigateurs , et pour cela, vous aurez besoin d'une technologie de back-end push comme WebSockets ( plus d'informations ci-dessous) qui diffusera les modifications à tous ceux qui exécutent l'application.
Cela ne signifie pas non plus qu'il existe un problème inhérent à JavaScript où l'état de votre application a besoin d'immutabilité pour devenir prévisible, tout développeur qui a codé des applications frontales avant React vous le dirait.
Cette affirmation plutôt confuse signifie simplement qu'avec React, votre état d'application deviendra plus sujet aux conditions de concurrence , mais cette immuabilité vous permet de supprimer cette douleur. Pourquoi? Parce que React est spécial. Il a été conçu comme une bibliothèque de rendu hautement optimisée avec une gestion d'état cohérente en deuxième position, et donc l'état des composants est géré via une chaîne d'événements asynchrone (alias "liaison de données à sens unique") que vous n'avez aucun contrôle et comptez sur vous pour ne pas muter directement l'état ...
Dans ce contexte, il est facile de voir comment le besoin d'immuabilité a peu à voir avec JavaScript et beaucoup à voir avec les conditions de concurrence dans React: si vous avez un tas de changements interdépendants dans votre application et aucun moyen facile de comprendre ce que votre état est actuellement, vous allez être confus , et il est donc parfaitement logique d'utiliser l'immuabilité pour suivre chaque changement historique .
3) Les conditions de course sont catégoriquement mauvaises.
Eh bien, ils pourraient l'être si vous utilisez React. Mais ils sont rares si vous choisissez un cadre différent.
En plus, vous avez normalement problèmes bien plus importants à régler… Des problèmes comme l'enfer de la dépendance. Comme une base de code gonflée. Comme votre CSS ne se charge pas. Comme un processus de construction lent ou être coincé dans un back-end monolithique qui rend l'itération presque impossible. Comme des développeurs inexpérimentés qui ne comprennent pas ce qui se passe et qui font des dégâts.
Tu sais. Réalité. Mais bon, qui s'en soucie?
4) L'immuabilité utilise des types de référence pour réduire l'impact sur les performances du suivi de chaque changement d'état.
Parce que sérieusement, si vous allez copier des choses à chaque fois que votre état change, vous feriez mieux de vous assurer que vous êtes intelligent à ce sujet.
5) L'immuabilité vous permet d'annuler des choses .
Parce que euh… c'est la fonctionnalité numéro un que votre chef de projet va demander, non?
6) L'état immuable a beaucoup de potentiel cool en combinaison avec WebSockets
Enfin, l'accumulation de deltas d'état constitue un cas assez convaincant en combinaison avec WebSockets, ce qui permet une consommation facile de l' état en tant que flux d'événements immuables ...
Une fois que le sou tombe sur ce concept (l'état étant un flux d'événements - plutôt qu'un ensemble brut de documents représentant la dernière vue), le monde immuable devient un endroit magique à habiter. Une terre d' émerveillement événementiel et de possibilité qui transcende le temps lui-même . Et quand bien fait cela peut certainement faire en temps réel applications EASI er à accomplir, vous venez de diffuser le flux d'événements à toutes les personnes intéressées afin qu'ils puissent construire leur propre représentation du présent et écrire de nouveau leurs propres changements dans le flux communal.
Mais à un moment donné, vous vous réveillez et réalisez que toute cette merveille et cette magie ne viennent pas gratuitement. Contrairement à vos collègues passionnés, vos parties prenantes (oui, les gens qui vous paient) se soucient peu de la philosophie ou de la mode et beaucoup de l'argent qu'ils paient pour construire un produit qu'ils peuvent vendre. Et l'essentiel est qu'il est plus difficile d'écrire du code immuable et plus facile à le casser, et il n'y a pas grand intérêt à avoir un front-end immuable si vous n'avez pas de back-end pour le prendre en charge. Lorsque (et si!) Vous finissez par convaincre vos parties prenantes que vous devez publier et consommer des événements via une technologie push comme WebSockets, vous découvrez à quel point il est difficile de faire évoluer la production .
Maintenant, pour quelques conseils, si vous choisissez de l'accepter.
Le choix d'écrire du JavaScript à l'aide de FP / Immutability est également un choix pour rendre la base de code de votre application plus grande, plus complexe et plus difficile à gérer. Je plaiderais fortement pour limiter cette approche à vos réducteurs Redux, à moins que vous ne sachiez ce que vous faites ... Et SI vous allez continuer et utiliser l'immuabilité malgré tout, puis appliquer un état immuable à l'ensemble de votre pile d'applications , et pas seulement le côté client, car vous en manquez la valeur réelle autrement.
Maintenant, si vous avez la chance de pouvoir faire des choix dans votre travail, essayez d'utiliser votre sagesse (ou non) et faites ce qui est bien pour la personne qui vous paie . Vous pouvez baser cela sur votre expérience, sur votre instinct ou sur ce qui se passe autour de vous (certes, si tout le monde utilise React / Redux, il existe un argument valable selon lequel il sera plus facile de trouver une ressource pour continuer votre travail). Alternativement, vous pouvez essayer les approches Resume Driven Development ou Hype Driven Development . Ils pourraient être plus votre genre de chose.
En bref, la chose à dire pour immuabilité est qu'il va vous faire la mode avec vos pairs, au moins jusqu'à la prochaine folie arrive, par quel point vous serez heureux de passer à autre chose.
Maintenant, après cette session d'auto-thérapie, je voudrais souligner que j'ai ajouté cela en tant qu'article dans mon blog => Immuabilité en JavaScript: une vue opposée . N'hésitez pas à y répondre si vous avez des sensations fortes que vous aimeriez aussi retirer de votre poitrine;).