7 pakietów Flutter, bez których nie wyobrażam sobie pracy

Niektóre paczki Flutter są dla mnie obowiązkowe w każdym projekcie, który tworzę, ponieważ sprawiają, że development jest o wiele łatwiejszy. Ułatwiają lokalne przechowywanie danych, a także pozwalają zastąpić część aplikacji. Niektóre z nich od razu włączam do moich projektów Flutter, zanim jeszcze na dobre zacznę kodować.

Jeśli akurat pracujesz nad aplikacją i chciałbyś ją szybko wydać, to myślę, że będziesz chciał wiedzieć o pakietach Flutter nieco więcej.

A jeśli masz jakieś swoje, bez których nie wyobrażasz sobie pracy, zostaw komentarz i daj mi znać — zawsze chętnie się czegoś nauczę!

UWAGA: Wszystkie pakiety posiadają mechanizm null safety!

1. Hive / hive_flutter

Zacznę od tego, że nie jestem fanem baz danych NoSQL — uważam, że sztywny schemat tworzy przewidywalność i determinuje organizację zadań bez konieczności martwienia się o brakujące dane lub niezdefiniowane pola.

Jeśli więc jesteś fanem NoSQL, to wiem dlaczego! Nie krytykuję tutaj NoSQL — ma swoje zalety. Szczególnie front-end.

Kolejna zaleta relacyjnych baz danych to możliwość zarządzania w tym samym miejscu tenantami i danymi należącymi do wielu użytkowników — pojedyncza tabela o nazwie „Chat Messages” może przechowywać każdą wiadomość z czatu, z każdej grupy, a jeśli zapytasz poprawnie, nie musisz się martwić, że otrzymasz wiadomości od kogoś innego.

Jeśli chodzi o front-end to nie jest to problem, ponieważ po prostu przechowujesz dane, które albo pochodzą od ciebie, albo pochodzą z bazy danych i są już przefiltrowane. Oznacza to, że NoSQL ma wszystkie zalety i żadnych niebezpiecznych punktów... a to znowu oznacza, że Hive jest moim ulubionym rozwiązaniem do przechowywania danych we front-endzie.

Zwykłe boksy mogą być używane jako bazy danych, umożliwiając całkowitą separację. Dane są zawsze przechowywane w intuicyjny i przejrzysty sposób — i co najlepsze — (przeważnie) synchronicznie!

Jeśli przechowujesz dużą ilość danych po stronie klienta, takich jak logi czatu, cache itp., to gorąco zachęcam do zapoznania się z Hive — dla mnie jest to najlepszy sposób na przechowywanie danych we frontendzie.

(ZAUWAŻ: jest to dla mnie stosunkowo nowe! Zacząłem korzystać z Hive nie tak dawno, ale zakochałem się już od pierwszego wejrzenia i po prostu musiałam go tutaj dodać. Jeśli masz już jakieś doświadczenie z Hive, podziel się ze mną wskazówkami i trikami!)

2. fluttertoast

Pozwól, że zadam Ci pytanie: W ostatnim projekcie Flutter, który napisałeś, co by się stało, gdyby użytkownik nie miał Internetu?

Jeśli odpowiedziałeś “katastrofalna awaria”, nie wstydź się: nie jesteś sam. Obsługa błędów jest często ostatnią rzeczą, o której pomyśli programista w trakcie tworzenia aplikacji, podczas gdy powinna być jedną z pierwszych rzeczy, na którą powinien zwrócić uwagę po happy path.

Jednak przekazywanie użytkownikowi informacji zwrotnej jest trudną sprawą. Przez większość czasu trzeba kodować niestandardowy komunikat na każdej stronie dla każdego błędu, co jest po prostu niewykonalne dla ludzi, którzy chcą zbudować MVP.

Tak wygląda psuedokod mojego http_client: 

try {
http request
} on TimeoutError catch (e) {
if (hasInternet) { //http_connectivity package
toast("Servers down, sorry.")
else {
toast("Are you sure you're connected to the internet?")
}
rethrow
}

To wszystko! Zajęliśmy się tym błędem. Nasz użytkownik dostał informacje zwrotną na temat tego, co się stało: albo nie ma internetu, albo padły serwery. To wszystko, co musimy zrobić.

Ostatnia wskazówka dotycząca obsługi błędów: korzystaj z try catch. Następnie powinieneś mieć metodę, która zgłasza błędy do backendu i następnie ponownie zgłasza błąd. W ten sposób otrzymasz szczegółowe logi błędów, dzięki czemu będziesz mógł szybko naprawić bugi :) W tym przypadku nie przechwytujesz wyjątków (okropny, bolesny code smell), ale masz je, raportujesz i ponownie zgłaszasz. Przenosisz logi błędów do backendu, aby programista mógł je łatwo czytać i powtórzyć czynności.

Flutter Toast jest dobry tylko do obsługi błędów! Jeśli użytkownik wykona jakąś czynność, np. wyloguje się lub zmieni swój nick, chce mieć natychmiastową informację zwrotną, że to, co zrobił zadziałało. Zamiast męczyć swojego UX Designera, pytając jak to zrobić, możesz po prostu zastosować toast("Logged Out.").

3. pedantic

Formatowanie kodu jest ważne. Niektórzy ludzie uważają, że jest to.... no cóż, pedantyczne, ale ja uważam, że formatowanie  w projekcie jest naprawdę ważne dla dobra  Posiadanie różnych zasad w różnych częściach aplikacji przerywa ciągłość , co sprawia, że adaptacja do poszczególnych części kodu będzie trudna.

Ale, powiedzmy to jeszcze raz, jesteśmy zajętymi programistami! Nie mamy czasu, aby martwić się o używanie pojedynczych lub podwójnych cudzysłowów — chcemy, aby nasz produkt ujrzał światło dzienne.

Odpal Pedantic.

Pedantic zlintuje cały twój projekt — jeśli zapomniałeś napisać const tam, gdzie coś może być const, pedantic poinformuje Cię o tym.

Pedantic wykonuje świetną robotę, utrzymując  w projekcie  podobne formatowanie  kodu i powstrzymuje współpracowników przed dodawaniem komentarzy do twojego PR typu LINT: Use single quoted string where possible.

4. auto-route

Nawet z routerem 2.0, trasowaniejest nadal trudne. Zarządzanie routerami, wiedza o tym, co jest na szczycie stosu, odpowiednie parametry, to wszystko jest dość trudne.

Chyba, że używasz auto_route!

auto_route pozwala na skalowanie dużej liczbystron bez zwiększania złożoności — na przykład, można mieć zagnieżdżone trasy, indywidualne tranzycje, a nawet routery z tablicami trasowaniabez martwienia się o zarządzanie parametrami lub ścieżkami.

Generator kodu auto_route wygeneruje dla Ciebie dużo kodu, dzięki czemu zobaczysz, że nieużywanie go zmarnuje dużoTwojego czasu.

Moją ulubioną częścią, jak dotąd, są ściśle typowane parametry.

Takiej paczki szukałem zawzięcie: cóż, jestem ogromnym fanem przenoszenia problemów z runtimem do momentu kompilacji, ponieważ o wiele łatwiejsze jest debugowanie “missing parameter” niż “tried calling toString on nul”.

Przekazywanie parametrów przez trasy jest jednym z tych miejsc, gdzie szybko możesz wpaść w pułapkę bugów. Wyobraź sobie, że masz trasę, która wymagała stringa: musisz ręcznie upewnić się, że za każdym razem, gdy tworzysz trasę, zawierasz w tym string. Nie powie ci o tym Twój kompilator, musisz po prostu o tym pamiętać.

Dodanie auto_route jest banalnie proste, a pozwala na dobry development bez poświęcania jego szybkości.

5. json_serializable

Kolejna bułka z masłem. Każda nowoczesna aplikacja łączy się z backendem i wykonuje wiele wywołań http. Ręczna deserializacja typu string w json zajmuje czas — szczególnie, gdy jesteś w trakcie developmentu i być może dodajesz kolejne pola.

Paczka pozwala dodać 4 linijki do klasy, a następnie uczynienie jej automatycznie gotową do przesłania przez wywołanie http.

Tematem przewodnim ninejszego zestawienia  jest przeniesienie jak największej ilości pracy z programisty na kompilator — i nie inaczej jest w tym przypadku. Jeśli mam pole użytkownika i dodaję e-mail w backendzie, muszę przejść do mojego niestandardowego deserializera i dodać e-mail. Jeśli zapomnę, mój e-mail zawsze będzie wartości null. Jeśli użyję json_serializable, wtedy kompilator powie mi “Hej... Twoja klasa User ma pole email, ale nie szukamy go w serializatorze. Może trzeba ponownie uruchomić wbudowany generator?”

Jeśli wykonujesz jakiekolwiek wywołania http, gorąco polecam zapoznanie się z tym pakietem.

6. google_sign_in

Ok, więc ten jest trochę bardziej związany z infrastrukturą niż z paczkamifluttera, ale to wciąż jest mój system logowania do zarządzania użytkownikami.

Dlaczego? Cóż, po pierwsze, nie ufam sobie, że będę w stanie bezpiecznie zarządzać użytkownikami. Uwierzytelnianie to pole minowe — jeśli niepoprawnie hashujesz hasła, przypadkowo wycieknie Twoja baza haseł, pozwolisz na IDOR, itp. to wtedy masz duży problem z bezpieczeństwem.

Po drugie, Google wykonało dobrą robotę ułatwiając ten rodzaj uwierzytelniania: 1. Stwórz politykę prywatności i ToS (i tak będziesz musiał to zrobić), 2. Utwórz aplikację na Firebase, a następnie zezwól na google sign in. 3. W razie potrzeby skopiuj dane uwierzytelniające. 4. Zweryfikuj token dostępu na backendzie.

Autoryzacja na własną rękę jest trudna i podatna na błędy, więc korzystanie z dostawców jest kolejną najlepszą rzeczą, jaką możesz zrobić. Logowanie z Apple jest świetne dla iOS, ale co z Androidem? Ten pakiet sprawia, że tworzenie systemów auth jest niezwykle proste i gorąco polecam pójście tą drogą zamiast ręcznego logowania.

Dodatkowo, jest to o wiele łatwiejsze dla użytkowników! Większość ludzi ma konta w Google, a procent rynku, który nie ma konta w Google nie jest znaczący dla MVP (w większości przypadków).

Autoryzacja jest często jednym z tych kroków w rozwoju projektu, który musi być wykonany, ale nikt nie chce tego robić, ponieważ jest to trudne i czasochłonne. google_sign_in pozwala pominąć ten krok!

7. flutter_bloc

Jeśli pokierował Cię tutaj mój artykuł flutter state management in 2021 , pewnie zastanawiasz się dlaczego bloc a nie riverpod.

Prawda jest taka: tamten artykuł wymaga aktualizacji. Nie używałem cubit w takim stopniu, w jakim powinienem, zanim go oceniłem. Myślę, że cubit rozwiązuje większość problemów bloc w takim stopniu, że naprawdę łatwo jest zarządzać stanem w aplikacji, i możesz przeskakiwać między cubit a bloc w zależności od tego, czy masz architekturę opartą  na zdarzeniach, czy na stanach.

Niezależnie od tego, to miejsce na liście zajmuje nie tylko bloc, ale jakikolwiek pakiet zarządzania stanem. Moim preferowanym rozwiązaniem co do zarządzania stanem jest bloc, ale każde rozwiązanie ma swój własny problem i przypadek użycia, i powinieneś wybrać odpowiednio do tego, co próbujesz osiągnąć.

W każdej większej aplikacji, zarządzanie stanem jest wymogiem. Nie da się tego uniknąć: nie chcesz powielać tego samego obiektu User w każdej klasie, więc musisz udostępnić go klasom dziedziczącym.

Niezależnie od tego, czy używasz dziedziczonego widżetu, czy w pełni rozwiniętego zarządzania stanem, to jednak ważne, aby zarządzać stanem w sposób czysty. Jak dla mnie bloc robi to najlepiej: bloc i cubit pozwalają na czyste i wydajne rozwiązania zarządzania stanem, a także pozwalają twórcom aplikacji lepiej utrzymywać swoje dane zgodnie z  DRY i w sposób łatwy w utrzymaniu.

To wszystko! Oto 7 paczek, z których korzystam przy budowaniu każdej aplikacji, od kiedy flutter został wydany. Myślę, że dzięki nim łatwiej i szybciej można budować solidniejsze aplikacje.

Wiem, że wiele osób jest przeciwnych używaniu paczek, i chociaż mają one wady, takie jak zależność od kodu innych osób, myślę, że korzyści są zbyt duże, aby je zignorować.

Może polecasz jakiś pakiet? Chciałbyś coś dodać, a może mnie poprawić? Daj znać w komentarzach! Zawsze chętnie się czegoś nauczę.

Oryginał tekstu w języku angielskim możesz przeczytać tutaj.