Reactjs-Graphql-Redux w praktyce

Slajdy z prezentacji 4Developers

Transcript

1. REACTJS-GRAPHQL-REDUX W PRAKTYCE AGNIESZKA LIPSKA EWA WOJTACH
2. DLACZEGO REACT ? Źródło: http://blog.bitovi.com/longevity-or-lack-thereof-in- javascript-frameworks/
4. ZAŁOŻENIA DLA APLIKACJI • Aplikacja do sprawdzania kolejek w urzędach w Warszawie
5. ZAŁOŻENIA DLA CZĘŚCI SERWEROWEJ • Powinien serwować dane dla klienta web oraz aplikacji mobilnej • Dane powinny być dostępne po protokole HTTP (usługi REST) • Dane serwowane z: • API UM Warszawa • Dane tele-adresowe urzędów • Ew. dostęp do danych historycznych
6. STANDARDOWE PODEJŚCIE DO WYSTAWIENIA API • Usługi REST noSql db: - Contact info /GET/groupsForDistrict application Application middleware tier
7. GRAPHQL – KRÓTKA HISTORYJKA
8. OPIS API RootQueryType DistrictOfficeType DistrictOfficeType DistrictOfficeType List ContactInfo Group Group Group List resolve (db) resolve (rest api)
9. GRAPHQL – WYSTAWIENIE API RootQueryType DistrictOfficeType DistrictOfficeType DistrictOfficeType List ContactInfo Group Group Group List resolve (db) resolve (rest api) application noSql db: - Contact info /GET/groupsForDistrict
10. GRAPHQL – SPOSÓB NA WYSTAWIENIE API Reprezentacja całości API w formie grafu • – opis schema Silnie typowane obiekty •
11. GRAPHQL – SPOSÓB NA WYSTAWIENIE API Request • : definicja jsona, bez danych GraphiQL • – narzędzie do ręcznego przeglądania api Przykłady: • https://www.graphqlhub.com/playground • http://graphql.org/swapi • -graphql/ http://hackibmserver.mybluemix.net/graphql • Projekt Apollo: • http://dev.apollodata.com • Narzędzia, klient Android, iOS, • Angular
12. GRAPHQL – MEANDRY ELASTYCZNOŚCI
13. GRAPHQL – BIBLIOTEKA DATA LOADER Cache • Batch • – udostępnia dwie metody: load • (key) loadMany • (keys) zachowanie • kolejnosci: orderedFor
14. PROJEKT APOLLO • Projekty dla aplikacji klienckich: iOS, Angular, React, (Android - w przygotowaniu) • apollo graphql-tools dla części serwerowej: • obsługa błędów, • mockowanie, • testy, …
15. CZYM JEST REACT ? • Biblioteka do tworzenia reużywalnych komponentów javascriptowych • Pozawala tworzyć aplikacje jako kompozycje składającą się z niewielkich komponentów • Bazuje na „Virtual DOM” • Implementuje jednokierunkowy przepływ danych (FLux) • JSX - rozszerzenie składni JavaScript • Każda aplikacja posiada jeden komponent główny
16. CYKL ŻYCIA APLIKACJI REACT JS Źródło: https://tylermcginnis.com/an-introduction-to-life-cycle-events-in-react-js/
17. …
19. LOKKA • Prosty klient Javascriptowy do zapytań i mutacji ze schematów graphql
20. REACT-ROUTER • Każda aplikacja posiada jeden komponent główny, teraz staje się nim komponent Router
22. PARAMETR HISTORY • hashHistory – wykorzystuje # w adresie, nie wymaga konfiguracji na serwerze • browserHistory – wykorzystuje API historii wbudowane w przeglądarkę, adresy wyglądają standardowo • createMemoryHistory – działa w pamięci, nie zmienia adresu przeglądarki https://hackibmserver.mybluemix.net/#/cases
23. PODZIAŁ ODPOWIEDZIALNOŚCI • Komponenty – kontenery • Komponenty prezentacyjne
24. KOMPONENTY - KONTENRY W metodzie • render mają jedynie odwołania do komponentów prezentacyjnych, lub innych kontenerów Znaczniki • HTMLowe tylko do opakowania • Nie zawiera styli (ani inline, ani importowanych) Wie jak pobrać dane • Wie jak obsłużyć zdarzenia • Może posiadać swój wewnętrzny stan •
25. KOMPONENTY PREZENTACYJNE Odpowiadają za to jak coś wygląda • Zawierają informację o stylach ( • inline, lub importując zewnętrzne arkusze) Ma bardziej rozbudowany JSX • W metodzie • render może zawierać odwołania do innych komponentów prezentacyjnych, lub kontenerów Nie zawiera żadnej logiki • Zwykle nie zawiera własnego wewnętrznego stanu •
26. FUNKCJONALNE KOMPONENTY BEZSTANOWE • Upraszczamy implementację • Zamiast klasy możemy zastosować „arrow function” (dostępne w ES6) • Utrudniamy „przypadkowe” dodanie stanu lub metod obsługi cyklu życia aplikacji ReactJS
28. FUNKCJONALNE KOMPONENTY BEZSTANOWE „In an ideal world, most of your components would be stateless functions because in the future we’ll also be able to make performance optimizations specific to these components by avoiding unnecessary checks and memory allocations. This is the recommended pattern, when possible.” Źródło: https://facebook.github.io/react/docs/components-and-props.html
29. ARCHITEKTURY DLA APLIKACJI KLIENCKICH 2010 1998 Desktop and server-side architectures Frontend architectures MVC jQuery 2015 Backbone, AngularJS Unidirectional Data Flow
30. GDZIE SIĘ SPRAWDZIŁ MVC Aplikacje • serwerowe Źródło: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec
31. GDZIE JEST PROBLEM PO STRONIE KLIENTA Controller jest • silnie zależny od elementów widoku W • wielu frameworkach jest nawet tworzony przez widok (np. Angular) Odpowiedzialny • zarówno za obsługę zdarzeń jak i logikę biznesową (!= Single Responsibility) Massive View Controller • Synchronizacja wielu elementów • widoku Źródło: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec
32. GDZIE JEST PROBLEM PO STRONIE KLIENTA • Gruby model: • Elementy biznesowe (User, Product, itd) • Elementy dot. stanu kontrolek UI (showTab, itd.) != Single Responsibility
33. FLUX I COMPONENT BASED ARCHITECTURE - KONCEPCJA Komponenty • UI Widok • Obsługa • zdarzeń Stan • kontrolek UI Flux • Stan • aplikacji (elementy biznesowe) Logika • biznesowa Źródło: https://medium.freecodecamp.com/is-mvc-dead-for-the-frontend-35b4d1fe39ec
34. FLUX - ZAŁOŻENIA https://facebook.github.io/flux/docs/in-depth-overview.html
35. FLUX - ZAŁOŻENIA https://facebook.github.io/flux/docs/in-depth-overview.html
36. REDUX – LEKKA IMPLEMENTACJA https://facebook.github.io/flux/docs/in-depth-overview.html
37. REDUX – LEKKA IMPLEMENTACJA Wszystko • co się zmienia w aplikacji jest przechowywane w jednym obiekcie stanu: ‘State’ lub ‘StateTree’ State jest read • -only – nie można go bezpośrednio modyfikować. Zawsze wymagana jest akcja: ‘Action’ (type) Zmiany • w aplikacji opisane jako funkcje (prevState, action) -> newState (‘Reducer’) – testowalność!
38. REDUX – LEKKA IMPLEMENTACJA Store createStore ( reducer ) dispatch subscribe UI element Reducers Subscribers getState Action (type)
41. IMPLEMENTACJE JEDNOKIERUNKOWEGO PRZEPLYWU DANYCH • Flux – idea, zestaw narzędzi od Facebook’a dla aplikacji web • Redux – biblioteka, zawierająca lekką implementację dla web • Model View Intent – dla web i Android • ReSwift – implementacja bazująca na Redux dla iOS • …Relay – bardzo rozbudowana biblioteka dla web
42. RELAY…
44. KOMPONENTY REACT
45. KOMPONENTY REACT
47. FRAGMENTY GRAPHQL
48. FRAGMENTY GRAPHQL
52. STORE RelayStore • Pojedyńczy • Znormailzowany • Znajdujący się po stronie klienta • Datastore • w pamięci
53. UNIKALNE ID • Wszystkie obiekty Relay dostają unikalne ID • „Diffing algoritm”
54. CONNECTION MODEL • Offset/Limit Model • After/First Model • Connection Model
55. OFFSET/LIMIT MODEL
56. OFFSET/LIMIT MODEL
57. OFFSET/LIMIT MODEL
58. OFFSET/LIMIT MODEL
59. AFTER/FIRST I CONNECTION MODEL
60. PRZYGOTOWANIE SERWERA DLA RELAY Implementacja • GraphQL Export • schematu Zmiana • api na pełen graf (Nodes / Edges)
61. PRZYGOTOWANIE SERWERA DLA RELAY Zmiana • api na pełen graf (Nodes / Edges)
62. PRZYGOTOWANIE SERWERA DLA RELAY
63. PODZIAŁ ODPOWIEDZIALNOŚCI Komponenty • – kontenery Komponenty prezentacyjne •
64. KIEDY WARTO UŻYĆ RELAY • Czy potrzebujemy cache’owania? • Czy potrzebujemy stronnicowania? • Czy potrzebujemy automatycznego ponawiania i obsługi błędów? • Czy potrzebujemy aktualizować dane w locie?
65. CIEKAWE LINKI • O React JS: https://facebook.github.io/react/ • O Redux: https://egghead.io/series/getting-started-with-redux • Przykładowa implementacja RGR(edux): https://github.com/hackibm/HackNodeServer • Przykładowa implementacja Relay w ramach Stacza: https://github.com/ewojtach/HackNodeServer/tree/relay
66. DZIĘKUJEMY ZA UWAGĘ!