Strona do zadań (ocena?)

Question

Siemacie,
Zrobiłem stronkę już klasyczną do poćwiczenia "todo lista" i czy mogę Was prosić o ocenę wszystkiego co się da i powytykania błędów (jestem gotowy na największe zjeby, ale z kulturą)? Wiem, że jest ich sporo, ale może dostanę od Was jakieś wskazówki na przyszłość, bo od kogo mam się uczyć jak nie od lepszych. Z resztą to pierwsza strona napisana w React czyli wszyscy są lepsi ode mnie.

strona: https://krzaczor.github.io/todo_app/

kod strony: https://github.com/Krzaczor/todo_app

uprzedzając Comandeera: Wiem, że nie jest dostępna prawie w ogóle. Nie znam się na tym jeszcze

Z góry dzięki.

Answer 1

1. po co ten komponent App skoro nie robi nic, tylko wyświetla komponent Page? Miałby on sens np. gdybyś dodawał tam jakieś ContextProviders itp. ale tak to moim zdaniem jest zbędny.
2. dlaczego używasz reduxa a nie react context? Nie mówię, że to błąd, ale czy wiesz jak działa context? Osobiście bardziej składaniam się właśnie ku contextom podzielonym odpowiednio logicznie, wtedy w App można zrobić ładnie odpowiednie provicery i potem używać gdziue potrzeba, albo providery robić gdzieś dalej, zależy od potrzeb. W ostatnim czasie robiłem parę apek reactowych i przyznam, że w żadnej nie potrzebowałem zaciągać reduxa, context w zupełności wystarczy, nawet przy bardziej rozbudowanych formach itp.
3. osobiście jestem zwolennikiem tworzenia folderu per component, pozwala to lepiej zamykać w nim np. ewentualne style css czy testy jednostkowe ktorych tu brakuje... osobiście nie wyobrażam sobie tworzenia apki bez testów UT oraz choćby podstawowych e2e.
4. <ItemButton onClick={() => { openModalEvent(); showTaskEvent() }}>
   przyznam, że nie lubię takich zapisów i ładowania zbyt dużo w templatkę... ja bym tu zrobić osobną funkcję np. buttonClickHandler i w nim zapiął odpowiednie wywołania innych funkcji i wtedy masz onClick={buttonClickHandler}. Ale to kwestia gustu, dla mnie takie cos byloby czytelniejsze.
5. dlaczego piszesz w JS a nie w TS? Szcerze to nie wyobrażam sobie kompletnie pisania większej apki bez TS, albo chociażby reactowego flow, ale wolę TS. Naprawdę mega ułatwia to pracę, szczególnie z większą liczbą danych. Polecam w ramach ćwiczeń przewalić to na TS.
6. tak na marginesie polecam zapiąć sobie w babelu resolver do preact/compact, piszesz w react a pod spodem przewali Ci na preacta... z moich doświadczen wynika, że można zyskać dobre 30-40% na wielkości builda, a na razie wszystko mi śmiga ok, zarówno podejście klasowe jak i funkcyjne z hookami, libki do formularzy np. react-final-form itp.
7. dlaczego raz uzywasz class, a raz funkcji? Niezbyt widzę sens mieszania dwóch podejść w jednym projekcie. Pracyuję z obiema formami i w sumie jest to dla mnie znaczenia, ale w jednym projekcie moim zdaniem może być tylko jedna forma.

to tak na szybko, nie wgłębiałem się dokładnie w kod.

Comments

Dobry wpis!

---

1. Wcześniej było tam coś jeszcze i przy robieniu porządków przeoczyłem. Oczywiście to nie było zamierzone

2. Miałem wcześniej Context API zaimplementowane, ale tak myślę, myślę... a co tam, nauczę się Reduxa. Ileś tam komitów wcześniej jest pozostałość po Context API. Jakbyś nie miał nic przeciwko to zajrzyłbyś tam czy w ogóle dobrze się za to brałem? Działać działało

3. To moja jedna z wielu słabych stron niestety. Za nic nie potrafię rozplanować z sensem sktuktury folderów i plików

4. Szczerze, to już z lenistwa. Nie chciało mi się tworzyć osobnej funkcji

5. Nie umiem TS :( Jedyne co umiem z TS to twarde typowanie

6. Niestety nie mam pojęcia o czym piszesz, ale się dowiem

7. Hmmm. Komponenty stanowe i bezstanowe (prezentacyjne).. czy nie? Hooki znam z widzenia i tyle co używałem useState i useRef. Nie są trudne, ale chciałem napisać apkę "po staremu", a za hooki wziąć się w następnym projekcie

---

Szcerze to nie wyobrażam sobie kompletnie pisania większej apki bez TS

Nie widzę w pomijaniu TS-a nic zdrożnego. Osobiście nigdy nie miałem sytuacji, w której stwierdziłbym "ok, spartoliłem, tutaj TS byłby idealny". Jasne, czasami mi brakuje gdzieś interfejsów czy typy uprościłyby kilka rzeczy, niemniej bez tego i tak bez problemu tworzę aplikacje.

---

Comandeer oki spoko, tylko w sumie pytanie tak naprawdę po co trochę, moim zdaniem, utrudniać sobie życie? TS jest tylko developersko, i tak wszystko jest docelowo w czystym JS.

Powiem Ci, że mamy w firmie parę apek w czystym JS i naprawdę ciężko się z nimi pracuje... chociażby właśnie brak interfejsów... jak masz proste obiekty to spoko, ale jak masz rozbudowaną strukturę, różne mappery itp. to TS wg mnie bardzo ulatwia sprawę.

---

Nie powiedziałbym, że używanie JS-a to utrudnianie sobie życia. To po prostu inny język. A TS też potrafi utrudnić życie (np. jak generować definicje typów dla bundle'i?).

Answer 2

To co masz w komponencie Page mogło by być w App ;) App obecnie jest zupełnie nie potrzebny :/

Jeśli jeszcze nie znasz zapoznaj się z react hooks. W mojej ocenie wyglądają lepiej przy używanie reduxa niż funkcja connect.

Fajnie wyszło jednak gdzieniegdzie brakuje paddingów ale nie przejmowałbym się tym. W końcu nie chcesz być grafikiem tylko frontendowcem :) Jeśli chcesz rozwijać się w stylowaniu poszukaj zawsze na necie gotowca z projektem. Wyrobisz sobie nawyk zwracania na szczegóły ;)

Super że działa! W pracy i tak trzeba zrobić tylko tyle - działającą aplikacje. Reszta to zazwyczaj zbędne dodatki. Czystego kodu klient nie widzi :)

Comments

Super że działa! W pracy i tak trzeba zrobić tylko tyle - działającą aplikacje. Reszta to zazwyczaj zbędne dodatki. Czystego kodu klient nie widzi

o Panie.. serio takie masz podejście czy to mamy odczytywać jako żart?

Powiem Ci szczerze, że bardzo, ale to naprawdę bardzo nie lubię osób, ktore w ten sposób podchodzą do zrobienia jakiś ficzerów. Niestety czasami naciski z góry prowadzą do wrzucania do mastera jakiś kodów średniej jakości ale należy to ograniczać do minimum.

Osobiście wolę posiedzieć np. z 3-4 h dłużej i zrobić kod porządnie, niż wrzucać na produkcję śmieci i potem dziwić się, czemu nagle alerty dzwonią i apka się wywala... I uwierz mi, biznes też często to rozumie tylko trzeba odpowiednio rozmawiać... To tak samo jak np. pisanie testów... na szczęście mam przyjemnosć pracować w zespole, który nie dopuszca wrzucania zmian bez przynajmniej pokrycia zmian testami UT, a w niektórych projektach wymagamy również e2e i to jest dobre, bo pozwala czasami wykryć jakieś corner casy...

Ja nie wiem skąd u ludzi takie podejście robienia na odpierdol... mnie już parę razy budziły alerty w środku nocy i na prawdę wierzę w potęgę dobrego CR, testow (i to zarowno developerskich jak i manualnych) i w myślenie o tym, że piszesz kod, który będziesz za chwilę utrzymywał... Polecam Ci książkę Czysty kod... jest tam sporo fajnych, cennych uwag, które mogą zmienić Twoje podejście do programowania.

---

Pisze testy. Dbam o bezpieczeństwo typów przez TS. I pomagają mi koncepcje z programowania funkcyjnego ;-) (Ja jestem za używaniem reduxa wszedzie. Właśnie ze względu na dobre paterny z programowania funkcyjnego.)

Czysty kod mam, przeczytałem i szanuje jednak wproeadził u mnie zbyt dużo perfekcjonizmu z którym obecnie staram sie walczyć

Napisałem tak dlatego ponieważ przedstawiona apka w temacie w mojej ocenie jest wystarczająco dobra. Nie ma sensu cos poprawiać,m sie uczyć dalej ;)

---

Ja jestem za używaniem reduxa wszedzie. Właśnie ze względu na dobre paterny z programowania funkcyjnego.

Jakie dobre wzorce z programowania funkcyjnego wprowadza Redux? 

---

Czyli czego lepiej używać? Redux, React.createContext czy useContext?

Faktycznie przyjemniej używa się hooków niż klas?

---

Faktycznie przyjemniej używa się hooków niż klas?

pracuję z jednym i drugim i powiem Ci że to w sumie obojętne, wybierz sobie co jest dla Ciebie wygodniejsze.

Czyli czego lepiej używać? Redux, React.createContext czy useContext?
 

niezbyt rozumiem pytanie... powinno raczej brzmiec redux vs context... osobiuście już tylko w nielicznych apkach reacotych mam reduxa i są to jakieś starsze tematy. W nowych przyjęliśmy zasadę stosowania raczej contextów podzielonych odpowiednio logicznie i wystawiamy ContextProvicery, które sobie ładnie zapinasz tam, gdzie potrzebujesz.

---

Wcześniej już pisałem w odpowiedzi, że miałem Context API, ale chciałem się nauczyć Reduxa. Samemu zobaczyć jak to działa.

Jeden z ostatnich comitów przed usunięciem context:

https://github.com/Krzaczor/todo_app/tree/04a1a23aea9625aa47652a2987656a4d5320ec1f/src

Dobrze to robiłęm w Twojej ocenie? Na moje to brakowało mi Provider/Consumer wspólnego dla wszystkich contextów, żebysię je przyjemniej obsługiwało, a nie każdy Consumer ładować osobno co generowało mi 3 wywołania consumerów i 3 funkcje chwytania ich state.

<Tasks.Consumer>
        {({tasks}) => (
            <TasksEdit.Consumer>
            {({resetTaskEdit}) => (
                <Actions.Consumer>
                {({edit, toggleAdd, toggleEdit}) => (
                    <Navbar>
                        { tasks.length > 0 ?
                            <Button onClick={() => {toggleEdit(); resetTaskEdit() }}>
                                { edit ? 'anuluj' : 'zarządzaj' }
                            </Button> :
                            null
                        }
                        <Button once={tasks.length === 0} onClick={toggleAdd}>dodaj</Button>
                    </Navbar>
                )}
            </Actions.Consumer>
            )}
            </TasksEdit.Consumer>
        )}
        </Tasks.Consumer>

Koszmarnie to wygląda, a chciałem +- coś takiego i nie wiedziałem jak:

<Store.Consumer>
    {({tasks, tasksEdit, actions}) => (
        <Navbar>
            { tasks.length > 0 ?
                <Button onClick={() => {actions.toggleEdit(); actions.resetTaskEdit() }}>
                    { actions.edit ? 'anuluj' : 'zarządzaj' }
                </Button> :
                null
            }
            <Button once={tasks.length === 0} onClick={actions.toggleAdd}>dodaj</Button>
        </Navbar>
    )}
</Store.Consumer>

I przy okazji widać co wcześniej było w App.js :)