Asynchroniczność przestała być dodatkiem, a stała się mechanizmem bez którego nie wyobrażamy sobie budowy aplikacji. Możemy do tego podejść na różne sposoby. Możemy albo utknąć w "callback hellu" albo poszukać czegoś co umożliwi nam pisanie czytelnego, łatwego w utrzymaniu a zarazem prostego kodu, który dodatkowo bez najmniejszych przeszkód możemy testować. Jak zredukować efekty uboczne związane z pobieraniem, przetwarzaniem danych, dostępem do cache’a na rzecz prostej integracji z popularnymi frontendowymi bibliotekami takimi jak redux? Jak modelować skomplikowane transakcje biznesowe wymagające synchronizacji wielu kroków? Podczas mojej prezentacji opowiem na bazie doświadczeń w projektach komercyjnych jak sagi oraz generatory wykorzystane w bibliotece redux-saga mogą poprawić czytelność Twojego kodu, ułatwić jego testowanie, oraz oszczędzić Twój cenny czas.

1. Sagi na frontendzie
Bartłomiej Glac
Future Processing

2. Kim jestem?
• Programista
• Odkrywca
• Prelegent

3. Kamil Programista
• Rok doświadczenia
• Jeden projekt
• Nastawiony na klienta

4. Misja
Giphy.com

5. Pierwszy kontakt z kodem
Giphy.com

6. Co jest nie tak?
Giphy.com

7. Efekt?
Wiele zmarnowanego czasu
Niewielkie efekty
Frustracja

8. Jaki powinien być dobry kod?
Czytelny
Przewidywalny
Testowalny

9. Poprawmy to!

12. Jak zaradzić?Rada?

13. Redux
twitter.com/reactjs_news

14. Akcja

15. Redux
twitter.com/reactjs_news

16. Reducer

17. Redux
twitter.com/reactjs_news

18. Komponent

19. smalldata.tech/blog/2017/08/21/writing-an-application-in-react-redux

20. Główne zasady
• Jedno źródło prawdy
• Stan aplikacji jest dostępny tylko do odczytu
• Zmiana stanu możliwa tylko poprzez czyste funkcje zwracające nowy
obiekt stanu

21. Jak redux pomaga pisać lepszy kod?
• Czytelność – stan i logika wydzielone
• Przewidywalność - stan aplikacji modyfikowany w jednym miejscu
• Testowalność - zmiana stanu możliwa tylko poprzez czyste funkcje

22. Kiedy przydaje się redux?
• Wiele propercji stanu jest współdzielona przez komponenty
• Wieloetapowe przekazywanie stanu w głąb aplikacji
• Zapamiętywanie wyborów użytkownika
• Wydajność

23. A co z komunikacją z API?
medium.com/@aksudupa11/redux-sagas-714370b61692

24. Redux-thunk

25. Test

26. Promise hell

27. Problem?
• Czytelność thunk’ów
• Mockowanie asynchronicznych akcji
• Sztuczna komunikacja poprzez store

28. Czym są sagi?

29. redux-saga
medium.com/@aksudupa11/redux-sagas-714370b61692

30. Jak zaimplementować sagę?

31. Benefity redux saga
medium.com/@ruslanmalogulko/redux-saga-how-to-make-real-good-things-with-generators-7d91a8916f0e

33. Redux saga test plan

34. Jak redux-saga pomaga pisać lepszy kod?
• Czytelność – brak callback-hell, piszemy deklaratywnie
• Przewidywalność - logika biznesowa w jednym miejscu
• Testowalność - zmiana stanu możliwa tylko poprzez czyste funkcje

35. Kiedy przydaje się redux-saga?
• Kiedy mamy skomplikowaną logikę biznesową
• Kiedy logika jest rozciągnięta w czasie i wymaga akcji użytkownika
• Zależy nam na łatwości testowania kodu

36. Kiedy lepiej byłoby się zastanowić
• Prosta aplikacja
• Nie chcemy dokładać dodatkowych konceptów

37. Materiały: bartlomiejglac.com/redux-saga
@bartlomiejglac
bartek@glac.pl

38. Twoja opinia na temat mojej prelekcji jest dla mnie bardzo ważna.
1. Wejdź w mój wykład znajdujący się w agendzie w aplikacji
Eventory.
2. Oceń moją prelekcję i dodaj swój komentarz.
Dzięki temu będę wiedział/a, co Ci się podobało a co
powinienem/am ulepszyć!