Wpis z mikrobloga

@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. ( ͡° ͜ʖ ͡°)
  • Odpowiedz
@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 podejscie
  • Odpowiedz
zeby uniknac re-renderow.


@workwork: ale ty ich nie unikasz bo robisz zmianę countera odrazu po zmianie w refie

setCounter(counter + 1) w tym tez nie widzisz problemu? ( ͡° ͜ʖ ͡°)


@workwork: a jaki tu jest problem ? jak wywołujesz to w event handlerze to zawsze można callback przekazać zamiast poprostu wartości
  • Odpowiedz
@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...
  • Odpowiedz
Wartość, mogą być stare jeżeli będę probowal je odczytac jezeli bylby w state trzymane.


@workwork: nie będą bo w następnym renderze masz aktualne wartości i w callbacku przekazanym do setX też będziesz mieć w parametrze aktualną wartość, ot poprostu setState jest asynchroniczny i trzeba o tym wiedzieć a nie hackować to bo mimo że jest asynchroniczny to masz gwarancję że po renderze wartość będzie aktualna (poza event handlerem bo tam
  • Odpowiedz
@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?
  • Odpowiedz
@workwork: no to przecież tlumacze ci że aktualne wartości zawsze masz zwrócone przez useState
function Test() {
const [x, setX] = useState(1);

console.log('x', x) // <-- tutaj zawsze x ma aktualną wartość
}

nie wiem gdzie jakas inna funkcja miała by tego użyć? jak chcesz wywołać np walidację na state to zawsze możesz zrobić setX(validate(x)) a jak jesteś w event handlerze to setX(x => validate(x))
  • Odpowiedz
@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
  • Odpowiedz
@workwork: ale z czym się tu zapoznawac? przecież ten przyklad co podesłałeś jest bez sensu, wiadomo że console.log nie zadziala po setState jak chcesz wypisać aktualną wartość to robisz to albo w useEffect albo poprostu w funkcji komponentu używając wartości zwróconej z useState. Ty chyba nie do końca rozumiesz o czym mówisz, znalazłeś jakiś wzorzec wrzuciłeś go na siłę i próbujesz go bronić słabymi przykładami bo nie ogarniasz asynchroniczności
  • Odpowiedz
@workwork: ale po co mam robić console.log tego co zmieniłem ? przecież tam będzie stara wartość jak chce operować na nowej to robi się to w innym miejscu. Już nie mówie o tym że u ciebie nie ma żadnej operacji po setCounter a ciągle piszesz o tym że jakas jest a jest poprostu

ref.current = X;
setCounter(counter+1);

Nie widze tam w kodzie zadnej operacji po tym więc czemu ciągle powtarzasz
  • Odpowiedz