@facefear: Dzięki za feedback. To prawda, narzut libki + TS robi swoje, ale to typical stuff jezeli chcesz robic cos na wieksza skale, takie to programowanie jest niestety, albo abstrakcja, albo jedziesz recznie. ( ͡° ͜ʖ ͡°)

@mirasKo-Kalwario: xd przeczytaj dokladnie i uzyj set state oraz use ref zobacz pozniej jaka jest roznica

@mirasKo-Kalwario: Daj sobie console.loga po setState i daj sobie console loga po przypisaniu wartosci za pomoca useRef. Jest dokladnie napisane, pokazane - po prostu sie wczytaj - useState ma zawsze wartosc stara z perspektywy event handlera - poniewaz zmiana jest asynchroniczna, useRef nie bo zmiana jest synchroniczna.

To podejscie jest wykorzystywane w wielu bibliotekach, np react-redux do obslugi zmian w storze, za pomoca subscribe, zeby uniknac re-renderow.

Dodatkowo to podejsciePokaż całość

@mirasKo-Kalwario: setCounter(counter + 1) w tym tez nie widzisz problemu? ( ͡° ͜ʖ ͡°). Podsylam w takim razie nitke do gita, ktora to wyjasnia:

https://stackoverflow.com/questions/50837670/reactjs-setstate-previous-state-is-the-first-argument-props-as-the-second-argum#:~:text=If%20you%20are%20going%20to,state%2C%20like%20the%20example%20below.

@mirasKo-Kalwario: Ehhh, dalej nie rozumiesz. Wartość, mogą być stare jeżeli będę probowal je odczytac jezeli bylby w state trzymane...

Dlatego sa w useRef zeby byly zawsze "aktualne", a re-render bedzie odbywal sie po zmianie innej wartosci niz duzego obiektu...

Dodatkowo jezeli zmienie typ prosty -> jak liczbe latwiej mi jest porownac w useMemo czy zmienil sie duzy obiekt czy tylko wartosc liczby...

@mirasKo-Kalwario: Przesledz artykul, masz code sandboxa - zmien po swojemu i dodaj strzaly do API. Napisz pozniej czy miales jakis problem ( ͡° ͜ʖ ͡°)

@mirasKo-Kalwario: Jeszcze raz, na spokojnie.

1. Tak useState - ma callback, ktory pozwala Ci dostać sie do "zawsze aktualnej wartosci"
2. Jezeli jest jakas inna funkcja, ktora chce korzystac z tych wartosci i miec je aktualne -> ja to zrobisz? Uzyjesz setCounter z callbackiem? Teraz git?

@mirasKo-Kalwario: Tu masz drugi przyklad, o ktorym mowie. Razem masz az 3. Po prostu sie z nimi zapoznaj na spokojnie.

https://stackoverflow.com/questions/54867616/console-log-the-state-after-using-usestate-doesnt-return-the-current-value

@mirasKo-Kalwario: Napisalem Ci 3 przyklady, albo trollujesz i tego nie czytasz, albo nie wiem ^^. Uzyj event handlera, a po setState daj console loga tego co zmieniles. Moge sie z Toba zdzwonic i Ci wytlumaczyc jak chcesz

@mirasKo-Kalwario: XD

@mirasKo-Kalwario: Jak tak piszesz to pewnie tak jest ( ͡° ͜ʖ ͡°)

@mirasKo-Kalwario: Dobra ziomek chodz call bo ciezko. Moze jakis google met? Chce Ci to wytlumaczyc bo moze nie wiesz, a Ci sie przyda

Ten valid, status jest wlasnie z useRef
Jakby to byl setState to bys mial stara wartosc -> 1 re-render do tylu

Uzycie useRef w takim przypadku - gwarantuje mi dostep zawsze do aktualnych danych bez koniecznosci uzycia useEffect i czekania na re-render. Tu nie chodzi o to, ze ja go unikam - oczywiscie, ze nie, ale dzieki temu zabiegowi re-render i tak mam, ale w event handlerach jest "swiezy" stan.

Tu masz prezke, ktora moze Ci pomoc: https://www.youtube.com/watch?v=HPoC-k7Rxwo

@mirasKo-Kalwario Ale po co mam to robic w callbacku i to jeszcze funkcji, ktora jest zaprojektowana do zwracania nowego stanu i ma byc czysta? Dodajesz do niej efekt uboczny w postaci strzalu do API...

Dalej nie rozumiesz i chyba nie chcesz. Niech bedzie, ze "tak powinno byc" - znajdz mi prosze przyklad w necie gdzie ktos robi takie fikolki
.

@mirasKo-Kalwario: Dobrze, powinien to slaby argument

@RussellSuperFan: zazdro mirek

@RussellSuperFan: to pierwsze, ale ciezko zyc dalej ze świadomością, ze my tu smieszkujem, a ludzie tam traca dorobek zycia, zycie.