React Native: Offline First - co to znaczy

0.62.2+

0:00Przerobiliśmy już sporo rzeczy w naszej aplikacji ale nie wspomnieliśmy o w sumie czymś

0:04bardzo bardzo ważnym znaczy o naszym storage'u o pamięci to znaczy jedną

0:09z najważniejszych rzeczy która spowodowała że aplikacje były tak użyteczne na

0:14początku zwłaszcza było to że pozwalały nam na korzystanie

0:18z rzeczy bez dostępu do internetu tak 10 12 lat temu nie

0:23wszędzie internet był tak dobry nie wszędzie był tak szybki więc to że po pierwsze aplikacja

0:27właśnie pamięta nasze urządzenie i nie mieliśmy za każdym razem wchodzić na stronę i pobierać na

0:31nowo a po drugie to że ona sama sobie mogła trzymać dane było naprawdę czymś wielkim

0:35i mimo tego że upływ czasu jest znaczący

0:39i internet jest wszędzie dostępny to dalej jest wiele przypadków użycia w których

0:43po prostu aplikacja powinna działać offline i takie podejście nazywa się

0:47offline first czyli to jest taki dobry ux aplikacji nie

0:51zawsze ma to zastosowanie bo są przypadki w których po prostu musimy mieć dane jakieś live

0:56natomiast w wielu sytuacjach a nie wiem mamy na przykład mapy to

1:00możliwość zapisania tych map albo trzymania wartości cache'owanych

1:05jest naprawdę czymś co zmienia cały ux

1:09tego podejścia i to podejście mega istotne i mega

1:13ważne i tak naprawdę od niego powinniśmy zaczynać projektowanie naszej aplikacji czyli

1:17nasza aplikacja czy jest scenariusz użycia w której nasza aplikacja mogłaby się przydać

1:21użytkownikowi kiedy ten na przykład nie wiem byłby w garażu w parkingu gdzie

1:25dostępu do internetu by nie miał przykład fajnego

1:30zastosowania tego podejścia no to jest nie wiem mamy aplikacje z newsami okej newsy

1:34pobieramy oczywiście z internetu natomiast jeśli włączymy aplikację to te ostatnie trzy

1:38cztery newsy które mieliśmy plus może parę które gdzieś tam się doładowało moglibyśmy mieć zapisane

1:42już na urządzeniu dzięki temu użytkownik po pierwsze nie czekałby na to aż pobiorą mu się

1:47nowe artykuły a po drugie jakbym miał jakiś problem z internetem to

1:51może te kilka na przykład w samolocie kilka pozostałych artykułów sobie przeczytać

1:55nie musząc nigdzie klikać zapisz i tak dalej tylko po prostu nasza aplikacja zakłada że tak jest

1:59no i taki schemat w bardzo dużym uproszczeniu wygląda w ten sposób że mamy

2:04aplikację która po prostu się łączy z jakimś z jakąś grą i to jest okej gorzej

2:08jak tego internetu tego dostępu tej

2:12usługi bo też sama usługa może się coś nie ma no i wtedy jest klops bo tak naprawdę nasza aplikacja

2:16jest bezużyteczna i takie podejście offline first zakłada właśnie

2:21taki schemat to znaczy że nasza aplikacja nie łączy się bezpośrednio nigdy z usługami

2:25zewnętrznymi takimi asynchronicznymi które mogą być niedostępne tylko zawsze to robi

2:29przez naszą bazę danych lokalną ta baza danych oczywiście to duże słowo

2:33a to może być w uproszczeniu po prostu jakiś json który jest gdzieś zapisywany natomiast

2:38tak to taki schemat jest dużo lepszy bo nawet jeśli utracimy dostęp

2:42tutaj do jakiejś usługi jakiegoś

2:46internetu to ciągle aplikacja może korzystać z tych danych które już sobie kiedyś pobrała

2:50i to jest bardzo fajne a i jest kilka podejść

2:54kilka narzędzi które możemy używać w aplikacji żeby przybliżyć środkiem

2:58schematu bo to jest oczywiście schemat idealny i takim pierwszym podejściem dość skomplikowanym i

3:04dużym to jest po prostu skorzystanie postawienie sobie bazy sqlite lokalnie

3:08na naszym urządzeniu ponieważ zarówno android jak i iOS wspiera sqlite

3:13czyli taką prostą bazę sql z której możemy korzystać możemy wysyłać do niej

3:17zapytania i wygląda to mniej więcej tak czyli tworzącymy

3:21sobie jakąś tam bazę otwieramy ją mamy jakieś hasła pobieramy wiersze wykonujemy

3:25to normalnym sql-em i to generalnie jest okej

3:29natomiast jak ja bym miał się zastanowić tak rzeczywiście

3:33kiedy to miałoby sens to może w całej swojej karierze 10-letniej

3:38raz czy dwa faktycznie taka baza lokalnie miałaby sens jeden przypadek to był

3:42taki gdzie aplikacja służyła

3:46pracownikom w drodze na raportowanie

3:50różnych rzeczy i tych raportów było całkiem sporo w jakichs sklepach różnych

3:54magazynach i tam nie można było sobie pozwolić na to żeby czekać na synchronizację danych

3:59i drugi to właśnie był typowo magazynowa aplikacja która trzymała

4:03jakieś informacje trzeba je było synchronizować i tak dalej i też jakby operator nie miał możliwości zawsze

4:08posiadania internetu więc tam tych rekordów było mnóstwo tak

4:12bo naprawdę baza danych była cała baza praktycznie magazynu

4:16była lokalnie postawiona i wtedy taki sql jest super bo jest wydajny

4:20duży i się przydaje w przypadku naprawdę skomplikowanych operacji

4:24natomiast mówię to są dwie aplikacje które gdzieś tam się przewinęły przez moją karierę

4:28natomiast to też nie jest do końca fajnie to znaczy

4:32ja jestem zwolennikiem zawsze wybierania chodzenia od góry jeśli

4:37chodzi o powiedzmy techniczne aspekty to znaczy zaczynam od

4:41najprostszego rozwiązania i ewentualnie schodzę niżej jeśli ono jest niewystarczające

4:45więc jakby taki czysty sql może się okazać że nie jest nam potrzebny

4:49mamy inne rozwiązania które są trochę bardziej abstrakcyjne i są bardziej przyjazne nam

4:53jako programistom i przykładem takiego rozwiązania jest realm narzędzie które

4:57jest bardzo dobrze mi znane z natywnego programowania aplikacji natomiast

5:02ono też ma swoją wersję w react native i tutaj już

5:06nie piszemy zapytań nie tworzymy obiektów typowo sql-owych tylko mamy na to nałożoną

5:10pewną abstrakcje obiektową i korzysta

5:14się z tego dużo fajniej natomiast pod spodem dalej mamy jakąś bazę sql-owo albo no sql-ową

5:18w sumie nie wiemy ale nas to nie interesuje natomiast bardzo wydajną tak jesteśmy w stanie

5:23również trzymać tutaj całkiem pokażne ilości danych a już jakby same

5:27korzystanie jest dużo przyjemniejsze tak mamy tutaj możliwość na przykład pobrania

5:31danych nie musimy tworzyć jakiegoś kodu sql do obsługi tego

5:35tylko sobie po prostu pobieramy obiekty o danym typie z jakąś tam z

5:40jakimś tam conditions czyli tutaj przykład age większy równy 17 możemy

5:44sobie mamy transakcje zapisu mamy możliwość tworzenia tych obiektów to generalnie jest spoko

5:48więc zamiast tworzyć takie brzydkie niskopoziomowe

5:53sql-owe zapytania możemy korzystać z właśnie takich abstrakcji które nam realm nakłada czyli

5:57na przykład zamiast po prostu selecta sql-owego

6:01możemy stworzyć możemy pobierać dane na podstawie takiej konstrukcji bierzemy sobie

6:05objecty danego typu i tutaj podajemy jakieś warunki czyli na przykład tutaj podaj

6:10mi ludzi którzy mają więcej niż 17 lat na podstawie jakiegoś tam schematu transakcje

6:15zapisu też są bardzo proste i takie no user-friendly programmer-friendly bo to właściwie

6:19my z tego będziemy korzystać tworzenie obiektów to wszystko jest takie

6:23no sql-owe ale fajne ale przy okazji szybkie

6:27tak to znaczy naprawdę możemy tych rekordów mieć całkiem dużo i to będzie całkiem fajnie

6:31działało więc jeśli mamy sytuację w której naprawdę trzymamy

6:35pokaźny danych to taki realm może być naprawdę spoko musimy pamiętać o jednym

6:40że zwłaszcza z mojego doświadczenia korzystałem z tego

6:44w przypadku aplikacji natywnych na iOS-ie musimy bardzo mocno przestrzegać pewnych zasad które realm

6:48na nas nakłada to nie jest tak że możemy sobie ot tak gdzieś tam

6:52w pewnym miejscu korzystać z tego realma tylko jednak musimy przestrzegać tych zasad

6:56bo realm ma jakieś wytyczne one są powiedzmy zrozumiałe

7:01i jasne natomiast trzeba się ich trzymać bo inaczej możemy mieć spore problemy

7:05niemniej jednak polecam jeśli już nie lubisz wybierać między sqlite

7:09a takim realmem to zdecydowanie taki realm jest fajniejszy przechodząc

7:13tak konkretnie do tego w jaki sposób się zazwyczaj pisze aplikacje

7:17w react czy w react native no to bardzo często korzystamy z reduxa tak możemy oczywiście korzystać

7:22z apollo on też ma swojego cache'a ale powiedzmy tutaj o reduxie jest coś takiego

7:26jak redux persist widać że całkiem popularne narzędzie

7:31i to mniej więcej sprawia że nasz store który trzymamy sobie w reduxie

7:35w magiczny sposób jest zapisywany generalnie jeśli korzystamy z wielu typów

7:39prostych to sprowadza się do tego że dodajemy takiego redux persistance i

7:43persista i tyle i to po prostu działa czasem musimy sobie troszkę to

7:48skonfigurować bo pewnych rzeczy nie da się tak jeden do jeden zapisać

7:53natomiast kompletnie nie jest to żaden sposób skomplikowane i tutaj jest troszeczkę odwrotna

7:57sytuacja niż do realma bo tutaj jest tak że korzystamy sobie z reduxa i to jakby ten redux

8:01gdzieś tam wyznacza to w jaki sposób korzystamy trzymamy

8:05nasze dane w aplikacji a ten persist tylko gdzieś tam pomaga nam je zapisywać offline

8:09natomiast w przypadku realma jak móiwłem on nam narzuca pewne rzeczy i

8:14taki redux persist korzysta z czegoś czego

8:18o czym zaraz będziemy mówić a czyli z async storage to jest takie

8:22narzędzie taka biblioteka react native która jeszcze do niedawna była

8:26częścią core'a react native ale no z racji tego o czym mówiłem i tego

8:30tej filozofii react native w którym coraz więcej rzeczy jest

8:35odrzucana od tego core'a żeby był niezależnie rozwijany to tak samo ten async storage

8:39jest wyrzucony do jako osobny projekt i

8:43w tego async storage użyjemy w następnej lekcji do tego żeby zapisac

8:47pewne dane w naszej aplikacji