Ostatnio wyjaśniliśmy sobie, od czego zacząć pisanie własnej aplikacji. Po przeczytaniu poprzedniego artykułu powinniście mieć już więc pomysł i wybraną technologię. Co robić dalej? Druga część serii “Własna aplikacja krok po kroku” przed Wami!
Wiem, iż raport miał się ukazać wcześniej, ale niestety pokonało mnie przeziębienie i brak czasu. Jednak żonglowanie dużą ilością projektów jest bardzo męczące. Najpierw rozważałam, czy na chwilę nie zawiesić tej serii, ale potem uznałam, iż chcę Wam pokazać jak to naprawdę wygląda. Czyli jak to jest pisać własną aplikację, gdy normalnie pracuje się na cały etat, a do tego ma dodatkowe projekty zawodowe (u mnie blog, konferencje, meet-upy) i osobiste (niech żyje wykańczanie mieszkania!). Pokaże Wam więc, ile udało mi się zrobić pracując dosłownie kwadrans dziennie przez dwa tygodnie nad tym projektem. Do dzieła!
To jest drugi artykuł z serii Własna aplikacja krok po kroku, pierwszy można przeczytać tutaj.
Ja bardzo romantycznie założyłam, iż na początku zakoduję sobie layouty aplikacji. Bardzo miało to być miłe i przyjemne, relaksujące wręcz. Jednak potem do mnie dotarło, iż to wcale nie jest pierwszy krok, który należy zrobić! Jak powinno się to prezentować? Otóż, poniżej krótka lista rzeczy, które trzeba zrobić na początku.
Rozpisz wstępnie zadania
Tego punktu chyba za bardzo tłumaczyć nie trzeba. Ja rozpisuję zadania w Trello. Najpierw tworzę sobie nową tablicę, a potem trzy kolumny o nazwach “TO DO”, “IN PROGRESS” i “DONE” i przeciągam “karteczki” do odpowiednich kolumn, gdy zaczynam pracować nad danym zadaniem. Dbam o to, by nie wypisać od razu 100 zadań (pewnie by się tak dało), ale skupić się na założeniach jakiejś bardzo wstępnej fazy. W tym przypadku celem było dla mnie przygotowanie środowiska i stworzenie szkieletu aplikacji.
Wybierz IDE
To może być IDE lub edytor, z którego aktualnie korzystacie, albo coś, z czym chcecie poeksperymentować. Ja korzystam od ponad roku z Visual Studio Code, które jest darmowym narzędziem i jestem bardzo zadowolona. Postanowiłam nie zmieniać go w tym projekcie (choć kusiło trochę wypróbowanie WebStorma, ale zostawiłam to na inny raz).
Załóż repozytorium na Githubie
Żeby pracować płynnie i nie martwić się, iż stracimy kod, warto od razu założyć repozytorium na Githubie i umieszczać kod w nim. Korzystanie z repozytorium i systemu kontroli wersji to niezwykle ważna umiejętność, która przyda się w każdej programistycznej pracy. jeżeli więc projekt ma być początkiem Waszego portfolio, zadbajcie o pracę z Gitem i GitHubem, wiele sobie dzięki temu poćwiczycie. Dzięki Gitowi widzimy etapy powstawania projektu, możemy cofnąć się do wybranego elementu. Po stworzeniu początkowego stadium projektu rozpoczynam każde zadanie od stworzenia nowej gałęzi. Dzięki temu unikam sytuacji, gdy wszystko nie działa, a ja nie umiem wrócić do poprzedniej wersji. Gdy pomysł, nad którym pracowałam, mi się jednak nie spodoba, albo uznam, iż chcę coś zrobić inaczej, tworzę po prostu nową gałąź. Gdy jestem zadowolona z pracy, łączę moją gałąź z głównym branchem.
Przygotuj środowisko
To już bardzo zależy od tego, w jakiej technologii pracujecie. jeżeli piszecie w czystym JS, adekwatnie nie musicie nic robić, tylko brać się do działania U mnie podstawą miał być React, potrzebowałam więc małego setupu. Użyłam projektu startowego z dokumentacji Reacta, który przystosowałam do swoich potrzeb. Oczywiście wcześniej zadbałam, aby zainstalować wszelkie inne potrzebne paczki (np. takie jak npm czy git).
Dodatkowo chciałam pisać style w SCSS, nie CSS, musiałam więc przygotować to w projekcie. Przyznam, iż nie wiem, czy zostanę przy obecnym rozwiązaniu. Dlaczego? Waham się, czy nie pracować z Webpackiem. Startowy projekt Reactowy, z którego korzystałam, tego nie robi i pomyślałam, iż nie będę utrudniać na początek, szczególnie iż aplikacja ma być prosta. jeżeli więc chodzi o style, zdecydowałam się użyć tego sposobu, tworzy on jeden plik CSS z głównego pliku SCSS, który mamy w projekcie.
Nie wiem, czy w pełni mnie to zadowala, ponieważ muszę wszystkie pomocnicze pliki SCSS jednak manualnie do tego głównego importować, aby wszystkie style były na miejscu. Style nie są też przez to modułowe, będę musiała dbać, aby nazwy klas się nie powtarzały. Jeszcze nie dotarłam do samego stylowania (sprawdzałam jedynie, czy style się prawidłowo aplikują), więc możliwe, iż jednak zdecyduję się na przejście na Webpacka i wprowadzenie CSS-Modules. To zapewnie wyjdzie dopiero “w praniu”, czyli jak faktycznie zacznę mocno kodować.
Stwórz szkielet projektu
Kiedy już postawiłam startowy projekt i sprawdziłam, iż uruchamia się bez problemu (oj, nie było to takie proste!), postanowiłam stworzyć szkielet mojego projektu. Mniej więcej podzieliłam funkcjonalności, które chcę mieć w aplikacji na reactowe komponenty, dodałam foldery. W każdym folderze znajdować się będzie odpowiednio – plik JS z reactowym komponentem, plik SCSS ze stylami oraz plik JS z testami jednostkowymi. Napisałam również bardzo “symboliczne” komponenty, tzn. Takie, które tylko wyświetlają odpowiedni napis.
To pozwoliło mi wprowadzić do aplikacji podstawy routingu. Określiłam, pod jakim adresem ma pojawiać się strona główna, pod jakim inne podstrony. Do tego posłużył mi react-router. Po wejściu na stronę użytkownik ma automatycznie zostać przekierowany do strony powitalnej, jeżeli jednak już się zaloguje i jego dashbaord będzie miał konkretny id, wtedy ma się pojawić właśnie ten dashboard. Przygotowałam także stronkę “Not found”, która pojawia się, gdy żaden z adresów nie pasuje do tych wskazanych przeze mnie.
Przygotuj się merytorycznie
Wspominałam, iż w projekcie przy layoutach chcę użyć CSS Grida. Nigdy w nim nie pracowałam, także najpierw postanowiłam zdobyć wiedzę, aby móc użyć jej w moim kodzie. Po pierwsze, przypomniałam sobie główne założenia grida grając w grę Grid Garden. Potem z kolei zrobiłam darmowy kurs CSS Grid od Wesa Bosa, który zapoznał mnie z podstawami, pokazał, jak używać grida, co można za jego pomocą zbudować. Teraz czuję się lepiej przygotowana do dalszej drogi. Wcześniej też zrobiłam ten kurs z Reacta, aby ugruntować sobie wiedzę przed przystąpieniem do pracy nad aplikacją i poczytałam trochę oficjalną dokumentację.
Ja lubię taką metodę, tj. najpierw poświęcenie czasu w zapoznanie się z jakimś zagadnieniem teoretycznie czy przez krótkie ćwiczenia, a potem użycie ich w projekcie. Wiem, iż wiele osób lubi działać od razu, czytają o danym rozwiązaniu i w tej samej chwili używają go w projekcie. Musicie wybrać opcję, która Was bardziej przekonuje i z którą pracuje Wam się wygodniej, tutaj nie ma jednej recepty.
To moim zdaniem kolejne kroki, które należy wykonać na drodze do własnej aplikacji. Jak widzicie, jest tego całkiem sporo. Ja zupełnie nie doszacowałam, ile czasu może mi zająć przejście przez powyższe zadania. Stwierdziłam, iż usiądę na jedno popołudnie i będzie ok. I pewnie by było, gdybym to popołudnie miała w całości. Musiałam jednak trochę wyrywać czas na ten projekt. Zadania się trochę rozwlekły i nie doszłam do kodowania strony powitalnej, co początkowo było moim założeniem. Uważam jednak, iż dobrze jest umieć się przystosować do zmieniających się warunków i zmienić plany, gdy zachodzi taka potrzeba. Jestem zadowolona z tego, co udało mi się zrobić, biorąc pod uwagę ilość czasu, jaką dysponowałam.
Jak macie ochotę zobaczyć, co takiego udało mi się zbudować, zajrzyjcie do repozytorium na GitHubie. Uprzedzam, iż to dopiero początki, więc za wiele tam nie ma. Ale zachęcam do spojrzenia I podzielcie się koniecznie, jak idą prace nad Waszymi projektami!
