Daj Się Poznać 2017 – raport z działań. Część 3

Minął właśnie kolejny tydzień akcji DSP2017. W minionym tygodniu napotkałem kilka problemów, które udało się rozwiązać bądź obejść.

Co udało się zrobić?

Jednym z założeń nad którym pracuję jest możliwość tworzenia nowych rozgrywek ligowych, sezonów i meczy. W minionym tygodniu udało mi się zaimplementować tworzenie nowych rozgrywek w określonej hierarchii. Stworzyłem komponenty, które mają odwzorować elementy formularzy. Jednym z ciekawszych rozwiązań jest przyjęcie założenia, że elementy takie jakie radio buttony, checkboksy czy pola typu select to właściwie to samo. Jedyna różnica to wygląd. Postanowiłem stworzyć jeden element, który jest odpowiedzialny za obsługę tego elementu jako jeden komponent, który będzie mógł przyjąć różny wygląd po stronie interfejsu użytkownika w zależności od przekazanego parametr w props komponentu React.

Przygotowałem też ekran konfiguracji, gdzie będzie można określić domyślne rozgrywki i sezon rozgrywek. Ma to na celu ułatwić użytkownikowi tworzenie kolejnych meczów w wybranych rozgrywkach. Dzięki temu, w procesie tworzenia meczu można będzie pominąć dwa kroki. To całkiem sporo.

Problemy jakie napotkałem

W raporcie poprzedniego tygodnia wspomniałem o tym, że korzystam z WordPress REST API. Problem, który napotkałem to wydajność tego API. Niestety, nie udało mi się spotkać żadnych rozszerzeń ani sposobów, które by w sposób zintegrowany z WordPress sprawiły, że odpowiedzi na zapytania byłyby szybko zwracane. Niestety, decyzja którą podjąłem odnośnie korzystania ze współdzielonego hostingu wydawała się być czymś co mogłoby mnie spowolnić w rozwoju aplikacji. Przy 10 meczach, gdy trzeba było pobrać informacje o nich, to pobieranie danych trwało zbyt długo. Nawet 20 sekund.

Próbowałem skorzystać z Transient API z WordPress'a, ale nie dawało to oczekiwanych rezultatów. Już zaczynałem rozważać przejście na serwer dedykowany, gdzie miałbym dostęp do tzw. roota, aby móc zaimplementować rozwiązania oparte na cache'owaniu, ale problem udało się obejść poprzez modyfikowanie odpowiedzi zwracanych przez REST API. Opiszę to w kolejnym wpisie.

Kolejny problem, który zaczął mnie dręczyć to systematyzacja wymagań aplikacji. By nie pogubić się w implementacji kolejnych ficzerów aplikacji będę musiał wykorzystać funkcjonalność dostarczoną przez Github, czyli Issues. Tam przygotuję listę ficzerów, a kolejne commity będą nawiązywały do nich. Postanowiłem, że listę przygotuję tak, aby ficzery można było szybko zbudować, a kod w commicie nie był zbyt rozległy.

Ostatnią rzeczą, której brak mi doskwierał jest separacja widoków od źródła danych. W nadchodzących tygodniach przejdę na Redux, dzięki czemu widoki będą zajmowały się tylko i wyłącznie wyświetlaniem danych a nie również ich obsługą.

Plan na tydzień 4?

Będę chciał się pozbyć kilku problemów, które wymieniłem powyżej. Będą to między innymi:

1. Usystematyzowana lista ficzerów wraz z wymaganiami,
2. Dokończenie funkcjonalności tworzenia meczów poprzez dodanie interfejsu tworzenia kolejek w danych rozgrywkach oraz poprzez dodanie kalendarza,
3. Zbudowanie interfejsu do dodawania zawodników.

Nie wiem czy znajdę czas na implementację Redux, ale to będzie kolejna rzecz do zrobienia w dalszej części realizacji projektu. Plan jest taki, aby najpóźniej w 7. tygodniu zacząć budować aplikację mobilną opartą na React Native (czego jeszcze do tej pory nie robiłem).