Od czego zacząć budowę aplikacji (poza tym, że od pomysłu)? To zależy. Jeśli to pomysł komercyjny, który ma z nas zrobić milionerów, to sprawa się mocno komplikuje. Jednak nie będziemy wchodzić w szczegóły tej ścieżki, bo ten projekt będzie typową aplikacją pisaną for fun.

Tutaj chciałbym się na chwilę zatrzymać. Warto mieć świadomość, że zdecydowanie najlepiej jest stworzyć coś, co rozwiązuje realny problem. Tak - nawet, jeśli piszemy to dla frajdy albo (a może: zwłaszcza wtedy) w ramach treningu. Wyjątkiem może być nauka jakichś naprawdę podstawowych zagadnień. Chociaż prawdopodobnie nawet w tej sytuacji można znaleźć coś, co jest jednocześnie łatwe do napisania i praktyczne.

Czemu? Przede wszystkim pozwala to osadzić aplikację w realnym życiu. Dzięki temu wszelkie funkcjonalności nie będą zawieszone w próżni, ale będą odpowiadać na konkretne potrzeby użytkownika. Poza tym, jeśli piszemy coś w ramach nauki, czy pod portfolio (tzw CDD - czyli CV-Driven Development 😉) to posiadanie czegoś nietypowego może pozwolić na wyróżnienie się na tle innych todo list.

Postawmy zatem pytanie - jaki problem rozwiązuje tworzona aplikacja? Ma dać możliwość szybkiego sprawdzenia jakości powietrza w najbliższej okolicy.

Aplikacyjny niezbędnik

We wstępie pisałem, że aplikacja będzie szukać najbliższej stacji pomiarowej, bazując na lokalizacji użytkownika. Prawdopodobnie też podstawowym urządzeniem, gdzie użytkownik ją uruchomi będzie smartfon. To sugeruje podejście mobile first (które i tak jest zalecane w zdecydowanej większości przypadków) oraz zastosowanie PWA (Progessive Web Application). Niegłupim pomysłem byłoby też wysyłanie powiadomienia, jeśli jakość powietrza w okolicy by się pogorszyła.

Użytkownik musi mieć też możliwość ręcznego wyboru stacji pomiarowej na wypadek, gdyby chciał sprawdzić jakość powietrza niekoniecznie w swojej okolicy. Lub gdyby nie chciał udostępnić aplikacji swojego położenia - bo przecież ma takie prawo.

Ponieważ aplikacja ma bazować na danych pochodzących z sieci polskich stacji pomiarowych, to w sposób naturalny jest skierowana do użytkownika przebywającego na terenie Polski. Stąd wspomniane poprzednio języki - polski jako domyślny, dodatkowo angielski i ukraiński.

Tyle z oczywistości. Ale czy na tym trzeba poprzestać? Oczywiście, że nie! Dodatkowo planuję poszukać jakiegoś API albo RSS-a z aktualnymi informacjami dotyczącymi jakości powietrza. Jeśli się uda, to powstanie sekcja (lub podstrona) agregująca takie newsy.

Szukając API z pomiarami powietrza natknąłem się też na kilka innych, które także można wykorzystać - jak choćby dane na temat jakości wód gruntowych. Czy w aplikacji znajdzie się na nie miejsce? Jeszcze nie wiem, ale warto to rozważyć.

Co najpierw

Kiedy wiemy już, czego potrzebujemy bezwzględnie, a co będzie dobrym dodatkiem - wówczas możemy przejść do wyboru technologii.

Jak już wspomniałem, chcę, żeby to była aplikacja reactowa. Dlaczego? Przede wszystkim dlatego, że w tej technologii czuję się najlepiej. Ta apka już raz była tworzona w formie treningowej - wystarczy.

Ale samo powiedzenie React nie daje pełnego obrazu sytuacji. Jest to przecież biblioteka, która oferuje nam bardzo duże możliwości i pozwala na dużą elastyczność. Począwszy od decyzji, co ten React będzie zasilał. Użyjemy create-react-app, czy może zdecydujemy się na Gatsbiego lub Nexta? A może wybierzemy utworzenie aplikacji reactowej przy pomocy Vite?

Wybór technologii

Pamiętam, że za pierwszym razem był problem z API. Niby wszystko działało, ale nijak nie szło go spiąć z frontem. Cały czas majaczyła zmora w postaci CORS. Po kontakcie z supportem dowiedziałem się, że niestety to zamierzone zachowanie. API nie było przeznaczone do pracy bezpośrednio z aplikacją frontendową, trzeba je było wcześniej przepuścić przez backend. Finalnie napisałem proste proxy w Node, które zostało odpalone na Heroku.

Czy obecnie ten problem nadal występuje - nie wiem. Ale na wszelki wypadek chciałbym się na tę okoliczność zabezpieczyć. Dlatego mój wybór padł na NextJS, który oferuje operacje serwerowe. Nawet jeśli API nadal będzie pluło CORSem, to będzie można to szybko rozwiązać, bez posiłkowania się dodatkowymi technologiami.

Idźmy dalej. Wiemy już, co będzie fundamentem naszej aplikacji. A czego użyjemy do stylowania? Nie będę ukrywał, że najlepiej pracuje mi się ze styled components, choć przez chwilę rozważałem też MUI. Miałem z tą biblioteką trochę styczności, dodatkowo potrafi bardzo przyspieszyć pracę i oferuje niemało rozwiązań out of th box. Jednak w chwili większej customizacji może mi nadal sprawić trochę problemów. A chciałbym zachować możliwie dużo z wyglądu pierwowzoru, zatem wybór pada na styled components.

Ok, mamy już fundament oraz narzędzie do stylowania. Przejdźmy do zarządzania stanem. Tutaj robi się ciekawie. Z jednej strony podejrzewam, że poziom skomplikowania pozwoli poprzestać na najprostszym useContext. Z drugiej jednak strony... jeśli wykorzystać Redux Toolkit, to można będzie uprościć pracę a API. Dodatkowo jest to bardzo fajnie skalowalna biblioteka...

I tu właśnie napotkaliśmy na decyzję, która wymaga głębszego przemyślenia. Jasne, nie ma przeciwwskazań, żeby użyć Reduxa nawet do najprostszego na świecie store'u... ale przecież nie ma sensu strzelać z armaty do wróbli! Myślę, że do tego problemu trzeba będzie wrócić po przygotowaniu projektu. Prawdopodobnie pozwoli to lepiej rozeznać się w tym, czego aplikacja potrzebuje i czy useContext ma realne szanse stwarzać problemy w przyszłości.

W kwestii animacji w starej wersji odpowiadał za nie GSAP - i to bym pozostawił bez zmian. Było kilka bardziej zaawansowanych rzeczy, kilka svg-ków było wprawione w ruch - praca z GSAPem powinna bardzo ułatwić implementację.

Formularzy czy newsletterów nie planuję, więc póki co obejdziemy się bez narzędzia wspierającego formularze. Gdyby to się jednak zmieniło, to, cały na biało, wjedzie formik.

Z narzędzi dodatkowych testować będziemy Jestem, ponadto Storybook będzie wspierał dokumentację.

Czas ruszyć dalej

Mamy już bazową technologie, jaką wykorzystamy do napisania aplikacji. Co teraz? Coż... jakiś projekt by się przydał.

I z projektem właśnie wrócę w kolejnej części 😊

Do następnego!

P.S. Tradycyjnie polecam się na twixerze 😉