Przeciwny pogląd na niezmienność
TL / DR: Niezmienność jest bardziej modnym trendem niż koniecznością w JavaScript. Jeśli używasz React, zapewnia to porządne obejście niektórych mylących wyborów projektowych w zarządzaniu stanem. Jednak w większości innych sytuacji nie doda wystarczającej wartości nad złożonością, którą wprowadza, służąc więcej do uzupełnienia CV niż do zaspokojenia faktycznej potrzeby klienta.
Długa odpowiedź: przeczytaj poniżej.
Dlaczego niezmienność jest tak ważna (lub potrzebna) w javascript?
Cóż, cieszę się, że zapytałeś!
Jakiś czas temu bardzo utalentowany facet o imieniu Dan Abramov napisał bibliotekę zarządzania stanem javascript o nazwie Redux, która wykorzystuje czyste funkcje i niezmienność. Nakręcił także kilka naprawdę fajnych filmów , dzięki którym pomysł był naprawdę łatwy do zrozumienia (i sprzedaży).
Czas był idealny. Nowość Angulara zanikała, a świat JavaScript był gotowy skupić się na najnowszej rzeczy, która miała odpowiedni stopień fajności, a ta biblioteka była nie tylko innowacyjna, ale idealnie pasowała do React, który był sprzedawany przez inną potęgę w Dolinie Krzemowej .
Choć może to być smutne, w świecie JavaScript rządzą mody. Teraz Abramow zostaje okrzyknięty półbogiem i wszyscy, zwykli śmiertelnicy, musimy poddać się Tao Niezmienności ... Czy to ma sens, czy nie.
Co jest złego w mutowaniu obiektów?
Nic!
W rzeczywistości programiści mutowali obiekty dla er ... tak długo, jak istnieją obiekty do mutacji. Innymi słowy, ponad 50 lat rozwoju aplikacji.
A po co komplikować? Kiedy masz obiekt cat
i umiera, czy naprawdę potrzebujesz sekundy, cat
aby śledzić zmianę? Większość ludzi powiedziałaby cat.isDead = true
i skończyła.
Czy (mutowanie obiektów) nie ułatwia rzeczy?
TAK! .. Oczywiście, że tak!
Szczególnie w JavaScript, który w praktyce jest najbardziej przydatny do renderowania widoku stanu, który jest utrzymywany gdzie indziej (np. W bazie danych).
Co się stanie, jeśli mam nowy obiekt Wiadomości, który należy zaktualizować? ... Jak mogę osiągnąć w tym przypadku? Usunąć sklep i odtworzyć go? Czy dodanie obiektu do tablicy nie jest tańszą operacją?
Możesz przejść do tradycyjnego podejścia i zaktualizować News
obiekt, aby zmieniła się twoja reprezentacja tego obiektu w pamięci (i widok wyświetlany użytkownikowi, a przynajmniej można mieć nadzieję) ...
Lub alternatywnie ...
Możesz wypróbować seksowne podejście FP / Immutability i dodać swoje zmiany do News
obiektu do tablicy śledzącej każdą historyczną zmianę, aby następnie iterować tablicę i dowiedzieć się, jaka powinna być poprawna reprezentacja stanu (uff!).
Próbuję dowiedzieć się, co jest tutaj. Proszę, oświeć mnie :)
Mody przychodzą i odchodzą, kolego. Istnieje wiele sposobów na skórowanie kota.
Przykro mi, że musicie znosić ciągle zmieniający się zestaw paradygmatów programowania. Ale hej, WITAMY W KLUBIE !!
Teraz kilka ważnych punktów do zapamiętania w odniesieniu do Niezmienności, a dostaniesz je w gorączkową intensywność, którą może zdobyć tylko naiwność.
1) Niezmienność jest świetna do unikania warunków wyścigowych w środowiskach wielowątkowych .
Środowiska wielowątkowe (takie jak C ++, Java i C #) są winne praktyki blokowania obiektów, gdy więcej niż jeden wątek chce je zmienić. Jest to niekorzystne z punktu widzenia wydajności, ale lepsze niż alternatywa uszkodzenia danych. A jednak nie tak dobre, jak uczynić wszystko niezmiennym (chwała Haskellowi!).
ALE NIESTETY! W JavaScript zawsze działasz na jednym wątku . Nawet pracownicy sieci (każdy działa w osobnym kontekście ). Ponieważ więc nie możesz mieć powiązanego z wątkiem stanu wyścigu w kontekście wykonywania (wszystkie te piękne zmienne globalne i zamknięcia), główny punkt na korzyść Niezmienności wychodzi poza okno.
(Mimo, że nie jest zaletą przy użyciu czystych funkcji pracowników internetową, która jest, że będziesz mieć żadnych oczekiwań dotyczących błahy z obiektami na głównym wątku).
2) Niezmienność może (jakoś) uniknąć warunków wyścigu w stanie twojej aplikacji.
Oto prawdziwy sedno sprawy, większość programistów (React) powie ci, że Immutability i FP mogą w jakiś sposób działać na magii, która pozwala na przewidywalność stanu twojej aplikacji.
Oczywiście nie oznacza to, że możesz uniknąć warunków wyścigu w bazie danych , aby to zrobić, musisz koordynować wszystkich użytkowników we wszystkich przeglądarkach , a do tego potrzebujesz technologii push back-end, takiej jak WebSockets ( więcej na ten temat poniżej), które będą rozpowszechniać zmiany wśród wszystkich użytkowników aplikacji.
Nie oznacza to również, że istnieje jakiś nieodłączny problem w JavaScript, w którym stan twojej aplikacji wymaga niezmienności, aby stać się przewidywalnym, każdy programista, który kodował aplikacje frontowe, zanim React powie ci o tym.
To dość mylące twierdzenie oznacza po prostu, że dzięki React stan zgłoszenia stanie się bardziej podatny na warunki wyścigowe , ale ta niezmienność pozwala ci usunąć ten ból. Czemu? Ponieważ React jest wyjątkowy .. został zaprojektowany jako wysoce zoptymalizowana biblioteka renderująca z spójnym zarządzaniem stanem zajmującym drugie miejsce, a zatem stanem komponentu zarządza się poprzez asynchroniczny łańcuch zdarzeń (inaczej „jednokierunkowe wiązanie danych”), nad którymi nie masz kontroli i polegaj na tym, że pamiętasz, aby nie mutować stanu bezpośrednio ...
Biorąc pod uwagę ten kontekst, łatwo jest zauważyć, że potrzeba niezmienności ma niewiele wspólnego z JavaScriptem, a wiele z warunkami wyścigu w React: jeśli masz kilka wzajemnie zależnych zmian w swojej aplikacji i nie ma łatwego sposobu, aby dowiedzieć się, co twój stan jest obecnie w stanie, będziesz się mylić , a zatem nie ma sensu używać niezmienności do śledzenia każdej historycznej zmiany .
3) Warunki wyścigu są kategorycznie złe.
Mogą być, jeśli używasz React. Ale są rzadkie, jeśli wybierzesz inną strukturę.
Poza tym zwykle masz znacznie większe problemy do rozwiązania… Problemy takie jak piekło uzależnienia. Jak rozdęta baza kodu. Jak twój CSS nie ładuje się. Jak powolny proces kompilacji lub utknięcie w monolitycznym zapleczu, który sprawia, że iteracja jest prawie niemożliwa. Jak niedoświadczeni deweloperzy, którzy nie rozumieją, co się dzieje i robią bałagan.
Wiesz. Rzeczywistość. Ale hej, kogo to obchodzi?
4) Niezmienność wykorzystuje typy referencyjne w celu zmniejszenia wpływu na śledzenie każdej zmiany stanu.
Ponieważ poważnie, jeśli zamierzasz kopiować rzeczy za każdym razem, gdy zmienia się twój stan, lepiej upewnij się, że jesteś inteligentny.
5) Niezmienność umożliwia cofanie operacji .
Ponieważ… to jest najważniejsza funkcja, o którą poprosi kierownik projektu, prawda?
6) Niezmienny stan ma wiele fajnych możliwości w połączeniu z WebSockets
Wreszcie, akumulacja delt stanu stanowi dość interesujący przypadek w połączeniu z WebSockets, co pozwala na łatwe wykorzystanie stanu jako przepływu niezmiennych zdarzeń ...
Gdy grosz spadnie na tę koncepcję (stan jest ciągiem wydarzeń - a nie prymitywny zestaw zapisów przedstawiających najnowszą perspektywę), niezmienny świat staje się magicznym miejscem do zamieszkania. Kraina zdarzeniami pozyskiwane zdumienia i możliwości, które wykracza poza sam czas . I kiedy zrobione dobrze to na pewno może robić w czasie rzeczywistym aplikacje easi er osiągnąć, po prostu nadawać przepływ zdarzeń dla wszystkich zainteresowanych, aby mogli budować własną reprezentację teraźniejszości i odpisać swoje zmiany do strumienia komunalnego.
Ale w pewnym momencie budzisz się i zdajesz sobie sprawę, że cały ten cud i magia nie przychodzą za darmo. W przeciwieństwie do twoich chętnych współpracowników, twoi interesariusze (tak, ludzie, którzy ci płacą) mało dbają o filozofię lub modę, a dużo o pieniądze, które płacą, aby zbudować produkt, który mogą sprzedać. Najważniejsze jest to, że trudniej jest napisać niezmienny kod i łatwiej go złamać, a ponadto nie ma sensu mieć niezmiennego interfejsu, jeśli nie masz zaplecza do jego obsługi. Kiedy (i jeśli!) W końcu przekonasz swoich interesariuszy, że powinieneś publikować i konsumować wydarzenia za pomocą technologii push, takiej jak WebSockets, dowiadujesz się, jak trudno jest zwiększyć skalę produkcji .
Teraz kilka porad, jeśli zdecydujesz się je zaakceptować.
Wybór pisania JavaScript za pomocą FP / Immutability to także wybór, aby baza kodu aplikacji była większa, bardziej złożona i trudniejsza w zarządzaniu. Zdecydowanie argumentowałbym za ograniczeniem tego podejścia do reduktorów Redux, chyba że wiesz, co robisz ... A JEŚLI masz zamiar użyć niezmienności niezależnie od tego, następnie zastosuj stan niezmienności do całego stosu aplikacji , a nie tylko po stronie klienta, ponieważ inaczej tracisz jego prawdziwą wartość.
Teraz, jeśli masz szczęście, że możesz dokonywać wyborów w swojej pracy, spróbuj użyć swojej mądrości (lub nie) i rób to, co właściwe, przez osobę, która ci płaci . Możesz oprzeć to na swoim doświadczeniu, na jelitach lub na tym, co się wokół ciebie dzieje (co prawda, jeśli wszyscy używają React / Redux, istnieje uzasadniony argument, że łatwiej będzie znaleźć zasób, aby kontynuować pracę). Alternatywnie, możesz wypróbować metody Resume Driven Development lub Hype Driven Development . Mogą być bardziej twoją rzeczą.
Krótko mówiąc, niezmienność należy powiedzieć, że sprawi, że będziesz modna w stosunku do swoich rówieśników, przynajmniej do następnego szaleństwa, w którym to momencie będziesz zadowolony z przejścia.
Teraz po tej sesji autoterapii chciałbym zaznaczyć, że dodałem to jako artykuł na moim blogu => Niezmienność w JavaScript: pogląd kontrastyka . Nie wahaj się odpowiedzieć, jeśli masz silne uczucia, które chciałbyś również zdjąć z piersi;).