Wpis z mikrobloga

@Snowdr0p: W reduxie i jego podobnych alternatywach super jest to, że nie zależy od Reacta, więc można spiąc ze sobą części appki pisane w różnych technologiach. A szczerze mówiąc jest to feature który przydaje mi się zaskakująco często. No chyba, że ktoś stawia codziennie nowe greenfieldy i zmienia libki do zarządzania stanem jak rękawiczki. ( ͡° ͜ʖ ͡°)
@Pesio brak zależności od reacta jest jednocześnie wada i zaletą. Dla Ciebie zaletą, bo możesz trzymać stan między aplikacjami, dla mnie wadą, bo nie ma go w drzewie Reacta przez co nie bedzie działać Suspense choćby nawet. Stąd pojawiły się alternatywy typu recoil/jotai choć i tak uważam że 90 procent aplikacji nie wymaga żadnej biblioteki do przetrzymywania stanu, bo jest React Context API. Facebook np który jest na dzień dzisiejszy wielką aplikacja
@LepiejWcaleNizPozno Nie na React Summit twórca Recoila mówił że używają wewnętrznie do innych aplikacji, ale sam Facebook nie korzysta z niego, do tego sam mówił że Recoil powinien być używany dopiero wtedy kiedy context API wdraża problemy wydajnościowe, bardzo rzadki case. Do tego oczywiście, że nie służy do przekazywania refa. Skąd takie podejście? Context ApI jest świetne przy pisaniu własnych bibliotek, design systemów. Nie wyobrażam sobie zapinania dependency typu redux do biblioteki
@Snowdr0p Glownie dlatego że korzysta z jeszcze unstable rzeczy typu suspense przy data fetching, czy Concurrent mode. Na wielu konferencjach jest poruszany ten temat i zanim cokolwiek zostaje wypuszczone produkcyjnie do biblioteki React jest przetestowane na produkcyjnym Facebooku. Poza tym Instagram też stoi na context API, a problemow z perfem nie ma. Już nie wspominając o SSR, gdzie na dzień dzisiejszy każda większa firma implementuje Next.js i niektórzy bardzo chcą wykorzystać Remix
via Wykop Mobilny (Android)
  • 0
@mocpapieza: tak, rozumiem. Ja osobiście bym teraz na greenfieldzie użył Recoila. Ale context nie nadaje się do niczego bardziej złożonego niż accordian o którym wspomniałeś. Piszesz apke, dodajesz kilkadziesiąt providerow przy rootcie i w efekcie masz masę niepotrzebnych rerenderow, które trzeba ogrywac wyrzucaniem hookow do innych komponentów z memo. A z Reduxem cyk seleketorek na reselect i całe bst drzewko robi się zbalansowane oob.
@LepiejWcaleNizPozno To prawda i rozwiązaniem problemu o którym mówisz zajął się Recoil. Przy czym miałem okazję porozmawiać z twórcą Recoila na konfie która była dwa tygodnie temu i mówił, że Recoil jest jeszcze daleko od 'production ready'. W Facebooku z niego korzystają ale mówią że sporo się może zmienić. Wspominał też o tym że w w większości przypadków recoil nie jest potrzebny. Ja z założenia podchodzę do projektów 'przedwczesna optymalizacja źródłem wszelkich
@LepiejWcaleNizPozno poza tym też patrząc na takie biblioteki jak React-Query też korzystają z context API a to jest wrapper na całą aplikację. Podstawa działania Blitz.js będzie React query więc da się zrobić to dobrze korzystając z plain Reacta jak polecają ludzie którzy pracuje w FB. Ale to tylko moje zdanie. Piona
@mirasKo-Kalwario: Dlatego, że wszsytkie asynchroniczne metody są wykonywane w Redux poprzez middleware, gdzie Promise jest rozwiązywany. Natomiast Suspense do działania potrzebuje promise'a, na podstawie którego będzie w stanie stwierdzić kiedy wyrenderować fallback.
Tutaj masz naiwną implementację takiego rozwiązania które pozwala na zwrócenie promise'a:
https://github.com/mauricedb/react-suspense-2020/blob/master/src/utils/createResource.tsx
Oczywiście być może ktoś w przyszłości znajdzie rozwiązanie problemu dla Redux'a.
Jak ktoś chce zaznajomić się z przyszłością React'a to ten filmik pokazuje wiele ciekawych feature'ów nad