Już kilka lat temu Redux stał się de facto standardem w przechowywaniu globalnego stanu w React-ie. Ale świat nie lubi stać w miejscu i ciągle powstają nowe rozwiązania tego samego problemu. Jednym z nich jest Recoil.js, który trochę wywraca cały koncept do góry nogami. Czy warto dać mu szansę?

Przydatne Linki

• Recoil - https://recoiljs.org

Transkrypt

Bartek Witczak: Chciałem porozmawiać o nowej bibliotece do zarządzania stanem w świecie Reacta, a mianowicie RecoilJS. Chciałem zacząć od tego, że to jest, powiedział bym, pierwsza taka biblioteka, która już od samego początku jest wskazywana jako typowa dla Reacta, czyli, jakby, to jest cała biblioteka razem z implementacją, a nie tak jak w przypadku Reduxa, gdzie koncept jest na tyle ogólny, że potem wszystkie inne, takie główne frameworki, czy vue czy angular, po prostu zrobiły swoją implementację, a tak naprawdę koncept jest ten sam.

Marek Piechut: To nie jest spowodowane tym, że po prostu zrobili to ludzie z Fejsa?

Bartek Witczak: Chyba nie, to nie jest to. Bardziej mi chodzi o to, że, jak sobie później porozmawiamy, ona ma od razu zastosowanie przy, na przykład concret mode w Reactcie i tak na przykład Redux, biorąc po uwagę, że to jest jego koncept, nie ma w ogóle na razie rozwiązania do concret mode, tak tutaj, jakby, już w zamyśle, sama idea i implementacja jest ściśle powiązana z Reactem, Więc nie powiedział bym, że to wynika z tego, że to jest zbudowane przez ludzi z Fejsa, bo jednak większość tych rzeczy, z których korzystamy jest zbudowanych przez ludzi z Fejsa i…

Marek Piechut: Redux był zbudowany zanim byli ludzie z Fejsa, potem ludzie przeszli do Fejsa.

Bartek Witczak: No dobra, no to okej.

Marek Piechut: Ale to mówisz, że po prostu nie będzie czegoś takiego jak Recoil Angular, w sensie, że nie można czegoś takie zrobić.

Bartek Witczak: W sensie, że to nie jest takie proste, bo to nie jest tyle właśnie koncepcja, co bym powiedział stricte jakaś implementacja. Tak samo jak mamy kontekst w Reactcie, tak to też jest idea, że będziemy mieli dane dostępne globalnie, no to, jakby, można ją wykorzystać gdzieś indziej, ale nie da się zrobić kontekstu we Vue czy w Angularze, bo to jest mega mocno powiązane z tym całym środkiem.

Marek Piechut: No dobra, powiedz coś więcej. Powiedz, co jest specjalnego w tej bibliotece, czego ludzkość wcześniej nie zaznała.

Bartek Witczak: Noooo, to jest oczywiście. To jest zupełna nowość na rynku ultra fast lightweight, a już tak szczerze mówiąc powstała, żeby rozwiązać kilka problemów. Mianowicie, po pierwsze: do jakiegoś czasu, jeszcze wydawało mi się, że najpopularniejszym rozwiązanie do zarządzania stanem globalnym w Reactcie jest Redux, ale z tych wszystkich, wiesz, state of art, state of JS raportów wynika, że tak naprawdę Redux jest stosowany przez jakiś procent użytkowników. To jest jakiś duży, ale mimo wszystko, jakby główny procent społeczności cały czas obywa się bez żadnego Reduxa i, w jakimś sensie, nie ma pojęcia o istnieniu tego świata.

Marek Piechut: Bałem się, że powiesz, że Mobixa używa większość.

Bartek Witczak: Nie, nie, to właśnie jest zupełnie nie to. Jakby jest taka akcja, że większość osób buduje aplikacje reactowe wykorzystując tylko, po prostu, state i propsy. W ogóle nawet, nie wiem, bez kontekstu, tylko i wyłącznie, po prostu wiesz…

Marek Piechut: W pewnym sensie my też ostatnio się obywaliśmy, bo jechaliśmy GraphQL-em wszystko.

Bartek Witczak: No dokładnie, ale to była jeszcze inna sytuacja, bo mimo wszystko mieliśmy GraphQL i gdzieś tam sobie…, no nie, akurat nie sterowaliśmy tych danych nigdzie lokalnie, tak bardzo, tylko po prostu trzymaliśmy je Apollo.

Marek Piechut: Apollo cache, ale mieliśmy mało lokalnego stanu, że to raczej była synchronizacja z back-endem i cache, niż lokalny stan…, chociaż troszkę był, ale w bardzo małym stopniu.

Bartek Witczak: No dobra, więc wracając do tego zarządzania stanem globalnym, no to jakie do tej pory, powiedzmy, mamy główne opcje, jeżeli chodzi o globalny stan w Reactcie – no to mamy kontekst, czyli coś co jest natywnie, w sensie wbudowanego w Reacta i Reduxa, który swój pomysł zarządzania stanem, no i jakby, z mojej perspektywy, niszowe rozwiązanie jakim jest Modex i pewnie kilka, jakiś tam, pomysłów na zarządzanie stanem globalym. I teraz, szybko mówiąc, jak to wygląda w Reduxie: mamy trzy elementy, czyli mamy store – czyli jedno miejsce, gdzie trzymamy te dane; mega ultra store, który ma jakieś swoje gałęzie, w których trzymamy, powiedzmy, daną część naszej aplikacji, mamy reduser albo przeważnie redusery, które łączą się w jeden reduser, czyli, jakby funkcje, które na dany fakt czy daną akcję powodują zmiany w tym naszym store i powodują zupełnie nową reprezentację, no i mamy te akcje, czyli jakieś eventy, które są wysyłane i będą powodowały te zmiany. I teraz, największe zarzuty odnośnie Reduxa, pomimo tego, że już w porównaniu z F.luxem tego, powiedzmy, boilerplate’u było mniej trochę, to i tak największy zarzut jest taki, że dużo trzeba pisać, żeby tego Reduxa postawić.

Marek Piechut: Ty, no mnie się wydaje, że więcej jest boilerplate’u niż z Fluxem było, w Reduxie. Redux jest masakrycznie taki…, że musisz tego boilerplate’u produkować, już nawet są takie tule, które piszesz co chcesz dodać, a one ci generują redusery…

Bartek Witczak: To nie wiem, to pewnie kwestia podejścia. Dla mnie to był zawsze jakiś dziwny argument, że tego boilerpate’u jest tak dużo, bo dla mnie napisanie akcji czy jakiś tam prostych obiektów i reduser pod każdy fragment drzewa, to nie wiem, czy to jest tak mega dużo pisania.

Marek Piechut: No nie jest, nie jest.

Bartek Witczak: Ja, na przykład, tych generatorów kodu nigdy nie rozumiałem, po co to istnieje, bo w każdym projekcie, który budowaliśmy obywaliśmy się bez tego i pisaliśmy to z palca. I, nieszczególnie czuje, że jest to jakiś tam problem.

Marek Piechut: Znaczy, ja mam osobiście trochę inne problemy z Reduxem, wcale nie takie, bo to jest, moim zdanie, bardzo taki problem wydumany. Ale to, że właśnie całe to drzewo jest wszędzie dostępne jest dużym problemem w Reduxie, bo ludzie chętnie z tego korzystają i potem ten stan nie jest lokalizowany w żaden sposób, czyli faktycznie jest globalny i ludzie sięgają po wszystko. No i jest dużo takich problemów, że ludzie, na przykład, wkładają tam wszystko, naprawdę wszystko. Niektórzy naprawdę chcą każdą literkę, którą wpisujesz, mieć w Reduxie, co sprawia, że jeszcze matka ziemia nie wyprodukowała tyle procesorów, żeby to działało. No i, tam jest dużo takich problemów…, że ten problem, akurat z tym boilerplate, no to, moim zdanie, jest mamy problem.

Bartek Witczak: No dobra, wydaje mi się, że my doświadczyliśmy bardziej tych problemów, o których ty mówisz, czyli z samą strukturą aplikacji, strukturą tego, jak budowany jest ten store reduxowy i z problemami w stylu dostęp do wszystkiego i wkładanie wszystkiego. Ale te rzeczy dopiero widać przy pewnym poziomie, po pierwsze - skomplikowania, a po drugie - dojrzałości developerskiej, gdzie ty zaczynasz patrzeć na to, jak aplikacje są zbudowane.

Marek Piechut: No tak, bo chciało by się wyenkapsulować rzeczy, a to jest taka antyteza enkapsulacji, że Ty, po prostu, zaczynasz już buszować po tym store, jak, po prostu, wszystko sobie samo wyciąga jakieś tam bebeszki i potem nie ma już nic prywatnego.

Bartek Witczak: Dokładnie. Natomiast z takich, powiedzmy, zastrzeżeń, które są ogólnie głoszone, no to jest też to, że koncept, akcja, reducer store jest taki strasznie skomplikowany i to jest functionally, i trudno się w tym odnaleźć. Tutaj trudno z tym dyskutować, to każdy musi sobie sam odpowiedzieć, czy to jest skomplikowane czy nie. Natomiast teraz wchodzi do gry kolejny gracz, czyli Recoil i on jest, tak naprawdę, bardzo taką malutką biblioteką i ta jego filozofia cała jest bardzo prosta. Mianowicie, mamy dwa koncepty: mamy atomy, które są danymi, które będziemy trzymali znowu w jakimś tam głównym miejscu, tutaj akurat mamy taki komponent, który nazywa się Recoil Rute i on, jakby, trzyma wszystkie dane. On jest oczywiście przeważnie dostępny, te dane są dostępne w całej aplikacji, bo to jest biblioteka do rozwiązywania problemu stanu globalnego, natomiast mamy te atomy, które są rozłącznymi danymi i druga rzecz, mamy selektory, czyli mamy jakiś stan, który jest nazywany jako drive state i to po prostu jest stan wyliczany z atomów. Wszytko jest oczywiście już zbudowane na hookach, więc mamy jeden hook od tych atomów, jeden od selektorów, no i analogicznie, jeżeli zmieniają się atomy to hook jest powiadamiany, więc będzie render naszego komponentu i tak samo, jeżeli selektor jest, który bazuje na atomach, to jeżeli atomy od których on zależy się zmieniają, no to oczywiście odpalają się i będziemy mieli nowe dane w tych selektorach. Tak więc mamy bardzo prosty koncept. Znowu mamy możliwość dostępu do, powiedzmy, wszystkich informacji w całym drzewie, bo tutaj, znowu dla mnie, nie ma tej takiej separacji…

Marek Piechut: A to jest taka możliwość, żeby wyciągnąć sobie z tego…

Bartek Witczak: Tak.

Marek Piechut: .. a to nie jest tak, że sobie sięgasz sobie z konkretnego atoma?

Bartek Witczak: To jest tak, że każdy atom to jest, jakby osobna informacją, osobne dane.

Marek Piechut: Nie znam się, to się nie wypowiem, ale z tego co ja widziałem, to wygląda na to, że każdy atom jest anatomiczny i Ty nie możesz, jeżeli wziąłeś sobie ten atom czy selektor do danego atomu, to nie możesz sięgnąć do innego atomu z jego. Czyli nie masz, właśnie chodzi o to, że nie masz tego co w Reduxie, moim zdaniem, dużym problemem, czyli to, że Ty w swoim selektorze możesz grzebać po całym store

Bartek Witczak: To znaczy, mnie o coś innego chodziło. Mnie chodziło o to, że Ty w każdym miejscu hookiem, jak się zapinasz, masz dostęp do całego Recoila. Ty mówisz, z którego atomu czytasz, ale cały czas masz wszędzie dostęp do wszystkiego.

Marek Piechut: Ale musisz mieć, jakby dostęp do tego atoma, tak? Musisz go, skądś tam, zaimportować bezpośrednio.

Bartek Witczak: Tak, tak. Dokładnie.

Marek Piechut: Bo to mi się wydaje, że nie jest właśnie… W Reduxie jest taki problem,że każdy reducer i każdy selektor dostaje cały store, że to jest ten problem, że okej, jeżeli coś tam sobie wygrzebiesz, no to jasne, że będziesz mógł tam buszować po tych atomach, po których nie powinieneś. Tutaj mi się wydaje w tej bibliotece fajne to, że to idzie w przeciwną stronę, że ty musisz powiedzieć z których atomów chcesz czytać i z nich będziesz czytał, a nie, że za każdym razem dostajesz cały świat.

Bartek Witczak: No, wiesz co, zgadzam się z Tobą i dokładnie masz rację w tym co mówisz, też tak to rozumiem, tylko, chyba nie podzielam Twojej opinii, że to cokolwiek zmieni w budowaniu aplikacji. Znaczy, używanie tych selektorów w Reduxie, gdzie bierzesz cały stan i mówisz, załóżmy, że w drzewie mamy userów, użytkowników i bierzemy to state.user, to nie widzę, żeby to rozwiązywało jakikolwiek problem, że teraz mamy atom, który nazywa się users i ktoś go po prostu explicate importuje w komponencie, bo wydaje mi się, że bałagan i chaos w komponentach będzie nadal taki sam. Przeniesiesz tylko to, że do tej pory nie importowałeś zewnętrznych elementów i robiłeś state dot users, a tera będziesz robił jeszcze na górze import users use i atom od userów.

Marek Piechut: Znaczy, ja się nie zgodzę tylko w tym, że wydaje mi się, że to zmienia trochę coś, bo to jest ten standardowy problem, że w Reduxie robienie brzydkich rzeczy jest bardzo proste, a tutaj jest trochę trudniejsze. Zawsze, im więcej musisz się napocić, żeby coś spsocić tym lepiej, w tym sensie, że trudniej będzie psocić. Że będziesz musiał już być takim złośliwcem explicate, gdzie, z resztą, wielu ludzi opowiada, że Redux jest właśnie po to, żebyś miał dostęp do całego stanu i mógł sobie sięgać po te rzeczy, z czym ja się nie do końca zgadzam. A tutaj, wiesz, ten model bazowy jest taki, że ty sięgasz sobie po jeden atom, po dwa, po to co Ci jest faktycznie potrzebne i Ty explicate musisz też robić. To akurat mi się podoba, że to tak wygląda.

Bartek Witczak: No dobra, ale dlaczego wydaje Ci się, że jest różnica między tym, że w pliku będziesz miał import czterech atomów i potem będziesz miał użycie tego hooka, każdy z innym atomem, i czym to się różni od tego, że masz Reduxa, gdzie masz selektor, który po prostu wszystko Ci wyciągnie ze stanu i będziesz miał 4 razy use selektor z danymi selektorami już ze store.

Marek Piechut: No to sprawia tylko taką różnicę, że możesz nie eksportować tych rzeczy i mieć roole np. w linterze, że nie możesz wyeksportowanych rzeczy z folderu brać, więc masz taką enkapsulację dla biedaków, ale jednak. W sensie, że w ogóle masz taką możliwość

Bartek Witczak: Okej, ale to jest przy takim założeniu, że Ty masz w folderach indeksy, eksportujesz rzeczy, tak?

Marek Piechut: Tak, tak. Albo możesz sobie, wiesz, prywatne robić też te atomy wtedy, w ogóle ukryte w pliku, nieeksportowane do żadnego pliku.

Bartek Witczak: Znaczy, ja powiem Ci tak, mnie co się podoba tutaj, w odróżnieniu od Reduxa, to jest to, że w Reduxie często te selektory są trzy, cztery kropki w głąb i rozbijasz całe drzewo, wchodzisz tam w bebechy komuś, wkładasz rękę i wyciągasz jakieś informacje. A tutaj masz explicate powiedziane, jakie są atomy i z których fragmentów Ty możesz korzystać. To co mnie trochę bardziej martwi, to jest ten element, że może te selektory będą takie, że potem będziesz miał po prostu znowu 50 selektorów różnych, każdy będzie robił trochę co innego i będzie bardziej problem przez to, że te selektory, które są budowane na podstawie atomów, będą znowu, jakby, miejscem takiego chaosu i one będą zależały znowu od wielu atomów.

Marek Piechut: No mogą być, no bo znowu masz selektory robić, które zależą od selektorów i… Chociaż to nadal jest spoko, bo to nadal zawęża Ci pole do popisu, że nadal możesz korzystać tylko z tych selektorów, które już są i są dostępne. Mi się akurat to podejście podoba. Nie wiem, co ty myślisz o innych rzeczach związanych z tą biblioteką, bo na przykład ,jak ja patrzyłem, jak wygląda w niej przetwarzanie rzeczy asynchronicznych, na przykład, to mnie się nie podoba takie podejście.

Bartek Witczak: Tu musisz powiedzieć, czy chodzi Ci o te asynchroniczne QRSy, które zakładają, że cały czas masz ten sam stan czy nie.

Marek Piechut: Tam tak, tam jest, moim zdaniem, dużo problemów, że… To jest też problem Reduxa początkowy, że na początku był Redux i wszyscy powiedzieli „O Jezus, jaki świetny Redux”, a potem ludzie zaczęli go używać i zaczęły wypływać problemy w stylu „O, a jak zrobić call na back-end, a jak zrobić 5 calli na back-end” jak one od siebie zależą. I powstawały te wszystkie różne rzeczy, na koniec powstały Redux Saga, który w ogóle jest,…pffff…,o co chodzi. I żeby, wiesz, rozwiązywać te wszystkie use case’y, które w prawdziwym życiu powstają. No i z tym Recoilem podejrzewam, że będzie za chwilę tak samo, że to znowu pięknie wygląda na papierze, to jest świetny marketing, no i trzeba chwilę poczekać, powoli zaczną pojawiać się takie rzeczy w stylu „Ale ty, jak tego użyć, jak ja tam z GrapfQL-em gadam” No nie wiem, zobaczymy…

Bartek Witczak: Mnie się właśnie to wszystko bardzo podoba, bo przejrzałem praktycznie całą tą, nazwijmy to, dokumentację Recoila i bardzo mi się spodobały te wszystkie zakładki odnośnie asynchronous, data QRS czy asynchronous state i myślałem, że tam są elementy, wiesz, które są pokazane, jak się robi, a tak naprawdę, to tam znowu jest tak, że: no okej, to jest dokładnie tak jak było, powiedzmy, w Reduxie, czyli jakby zapytania sobie a Redux czy Recoil sobie. Czyli znowu będzie taka sytuacja, że jak to zostanie użyte w jakiś takich prawdziwych, dużych aplikacjach, to tak naprawdę wszystkie rzeczy sobie trzeba ogarnąć samemu.

Marek Piechut: No to będzie, wiesz, jak z wieloma takimi rzeczami, jak z formsami w Reactcie na początku, czyli jakby Facebook ma swój use case i to rozwiązuje jego use case bardzo dobrze, ale nie musi rozwiązywać Twojego. Dopiero, gdzieś tam, za rok, dwa ludzie zaczną budować coś na tym. Budować, budować i powoli te dziury będą łatane. To znaczy sam kierunek mi się podoba, podoba mi się to, że jest większa szansa na enkapsulację, podoba mi się większa szansa na performance, bo w Reduxie to jest problem, że po każdej drobniejszej zmianie odpalają się te wszystkie reducery, selektory i tak dalej, i na koniec 90% komponentów mówi, że właściwie nie ma co odświeżać.

Bartek Witczak: Tak, tak

Marek Piechut: Ale to jest obciążenie. A tutaj jest szansa taka, że będzie tego dużo mniej, bo tylko te zależne selektory będą się przeładowywać.

Bartek Witczak: Zgadza się.

Marek Piechut: Ale mnie się kierunek podoba. Jak zwykle, to jest kierunek wahadła, także przeszliśmy z wielu store w Fluxie, jednego store w Reduxie do jeszcze więszej ilości store’ów w Recoilu, więc… Kierunek mi się podoba, bo wolę w tą stronę, zobaczymy, czy za dwa, trzy lata nie będziemy mieli biblioteki, która znowu zbiera wszystko do kupy. Będzie Recoil Masterstore i będzie jeden.

Bartek Witczak: No nie, to wiesz, możemy tutaj zasugerować stwierdzenie, że na pewno tak będzie i na pewno będziemy wracali do tej poprzedniej propozycji. Mnie ogólnie kierunek też się bardzo podoba. Fajnie to wygląda. Też podoba mi się jakaś taka separacja, oddzielanie tych elementów stanu między sobą i selektory, które już z założenia, że drive state ma być wyliczany a nie zapisywany. Cały czas to spotykamy w projektach, że w Reduxie jest tak duża duplikacja danych, że czasami każdy fragment drzewa ma zduplikowane informacje pomiędzy drzewami, więc po prostu te same informacje można wyciągnąć z wielu różnych miejsc i czekamy tylko na ten moment, kiedy to się wszystko wysypie

Marek Piechut: No tak, synchronizacja stanu…

Bartek Witczak: Synchronizacja stanu, więc tutaj, to akurat mi się bardzo podoba, że jest explicate powiedziane, że mamy atomy i mamy selektory, i seletkory to jest po prostu wyliczany stan na podstawie atomów. I to co ty mówisz, explicate wyciąganie tych atomów komponentach też pewnie pozwoli nam w dużo łatwiejszy sposób pokazać, że komponenty są dosyć złożone, jeżeli korzystają z wielu atomów, z wielu zależności i one tam kombinują coś w środku. Pewnie będzie to łatwiej wychwycić gołym okiem, niż te wszystkie zależności reduxowe.

Marek Piechut: No dobrze, znaczy ja jestem za. Zobaczmy, jak to się rozwija, biblioteka jest w jakimś tam stanie alfa, czyli to jest idealny moment, żeby były jakieś nowe kursy na ekchadzie? (20:22), bo już widziałem, że jakiś jest kurs, który za pół roku będzie nieaktualny do biblioteki, która jeszcze nie nadaje się do użytku, ale lans już jest. No ja jestem za, jakby kierunek mi się podoba, także myślę, że będziemy to obserwować dalej, no i dzieje się coś ciekawego.

Bartek Witczak: No zdecydowanie. Dla prostych aplikacji ja, zdecydowanie, chciał bym tego użyć, zobaczyć jak to wygląda w praniu, w takim realnym projekcie.

Marek Piechut: Ja bym na nieprostych bardziej chciał użyć, to będzie ciekawiej…

Bartek Witczak: No.., no tak. Dla prostych - to-do lista jest gotowa na tutorialu, także możemy sięgnąć po coś bardziej złożonego.

Marek Piechut: Też właśnie o to chodzi, żeby zobaczyć na nieprostej to wtedy będziemy dopiero widzieć, czego tam brakuje.

Bartek Witczak: Dokładnie. No fajnie, ja daje łapkę w górę, według mnie warto spróbować i zobaczyć o co w tym chodzi.

Marek Piechut: Łapka w górę