Polecam poczytać o webpacku i npm, pozwoli to stworzyć nieco lepszą strukturę w projekcie, a to co ostatecznie zostanie wyplute jako build to już w sumie nas mniej interesuje, to ma być odpowiednio przetranspilowane, zminifikowane itp. A co do kodu to wg mnie jest on zły, i nie chodzi mi o samego reacta, to nie ma tu nic do rzeczy, mam kilka uwag:
- brak jakiegokolwiek formatowania - wg mnie to oznaka braku myślenia o innych osobach czytających kod, o jego utrzymaniu itd.
- nazwa metody getApi jest błędna, co to znaczy, pobierasz całe API, czyli co? raczej widziałbym getUsersDetails czy coś w tym stylu, kod musi sam się opisywać.
- dlaczego użyłeś fetch, a nie bezpośrednio XHR czy np. axios itp? nie jest to zarzut, w żadnym razie, ale takie pytanko może się pojawić na rozmowie gdybyś np. w jakimś zadaniu testowym tak zrobił. Jak mówiłem, fetch jest oki, tylko warto umieć uzasadnić wybory danego rozwiązania (oczywiście nie chodzi o żadne komentarze, nigdy w życiu, to tylko po prostu luźne pytanie na rozmowę)
-
then(response => response.json())
a skad wiesz, że otrzymane dane są poprawnym JSONem, możliwym do sparsowania?
-
const title = data.results[9].name.title
a skąd wiesz, że obiekt data jest w ogóle tablicą i zawiera 10 elementów? Nigdzie nie ma analizy tego, co przychodzi z zewnętrznego źródła, brak jakiejkolwiek obsługi błędów. Dla mnie takie podejście jest skrajnie nieodpowiedzialne i totalnie błędne. Zawsze należy obsługiwać sytuacje błędów, a co jak Twój serwer będzie niedostępny i dostaniesz 500 czy gdy wyślesz request bez autoryzacji gdyby tego wymagał i przyjdzie np. 401?
- dlaczego zawsze renderujesz dane o użytkowniku nawet, jeśli ich nie masz? Dlaczego nie użyłeś renderowania warunkowego?
- dlaczego jedna klasa jest odpowiedzialna za wiele różnych rzeczy - pobranie danych z jakiegoś api, wyświetlenie ich? Pobranie danych z API to jedno zadanie, ewentualne zmapowanie response na obiekt domenowy to drugie, i trzecie to wyświetlenie tego. Akurat w React jest dość duża swoboda w stworzeniu sobie struktury odpowiedzialności, np. w angular jest to by default nieco lepiej wg mnie ograne serwisami, DI itp. ale to nie ma znaczenia, chodzi o to, aby rozdzielić odpowiedzialności.
- brak jakiegokolwiek testu, w mojej ocenie apka bez żadnych testów nigdy ale to przenigdy nie powinna wyjść na produkcję czy do oceny jeśli to byłoby np. zadanie rekrutacyjne. Rozumiem, że pewnie po prostu nie uczyłeś się jeszcze testów - spoko, tylko gdybyś wysłał takie zadanie bez testów w rekrutacji to możesz sporo stracić. A szkoda, bo tak naprawdę podstawowe testy są proste do napisania - jeśli idziesz w reacta to zainteresuj się np. jest/enzyme - wystarczy że napisałbyś nawet 2-3 mega proste testy i masz wielkiego plusa jako przyszły junior.
Generalnie spoko, ucz się spokojnie ale wg mnie jeszcze daleko aby zacząć wysylać CV na juniora, szkoda abyś odpadł na prostych pytaniach czy analizie kodu, co jak przysiądziesz uczciwie to za kilka miesięcy poznasz bardzo dobrze.
I takie luźne pytanko sprawdzające na ile zgłębiłeś dokumentację reacta - dlaczego używasz klas a nie podejścia funkcyjnego? Od razu mówię - to żaden minus czy coś, w żadnym razie, sam pracuję na codzień z projektami w obu rozwiązaniach i w sumie oba mają wg mnie swoje plusy i minusy, chodzi tylko o to, czy umiałbyś podjąć jakąś dyskusję.
Pamiętaj, że w zadaniach rekrutacyjnych i na rozmowach wcale nie chodzi o to, abyś odpowiedział na 100% pytań czy zrobił idealnie zadanie - chodzi o poznanie człowieka, podejścia do kodu, ogólnie do programowania itp.
- masz ładnie sformatowany kod - super, widać, że dba o wygląd kodu, wie, że to ułatwi czytanie itp. czy używał do tego narzędzi np. prettier itp. czy nie to już nie ważne, myśli o formatowaniu - to jest ważne,
- nazywa sensownie funkcje i zmienne - mega duży plus, dobry kod nie musi mieć tak naprawdę żadnych komentarzy, zawsze zastanów się co inny programista zrozumie widząc funkcję o nazwie X, czy będzie ona czytelna? Staraj się myśleć przy tym trochę "jak biznes", czyli nie jak programista. Możesz zrobić funkcję price(). ale co ona robi? oblicza cenę, ustawia ją czy co? Może lepsza będzie nazwa getPriceWithDelivery czy getTotalPriceForAllOrders?
- rozdzieliłeś kod odpowiedzialny za wyświetlanie danych od tego, który pobiera dane z API - super, nie ważne czy wyszło Ci to idealnie czy nie, ważne, że myślisz o tym, aby pisać kod możliwie prosty i czytelny, aby dzielić odpowiedzialności na osobne pliki, klasy itp. Jak ostatecznie to wyszło? To naprawdę drugorzędna sprawa, tego nauczysz się w praktyce.
Także reasumując, moja wskazówka to spróbowanie najpierw poczytać o webpack i nawet jakiś gotowych generatorach dla reacta i próba stworzenia większej apki - powiedzmy z 10-20 komponentów, jakiś formularz, z 1-2 endpointy na jakieś API, jakaś walidacja danych, poczytaj o react context co jest dzisiaj coraz częściej spotykane w apkach, wg mnie w wielu przypadkach pozwala w ogóle zrezygnować z reduxa itp.
Ogólnie jest spoko, na początku napisałem, że kod jest zły ponieważ często w rekrutacji ważna jest pierwsza ocena, pierwsze wrażenie - pamiętaj o tym :) Chociażby takie głupie formatowanie kodu mocno bije po oczach... a szkoda, bo to kilka minut roobty aby to poprawic :)