Morn!
Morn!
Morn!
Mrn
Morn!
Morn!
Morn!
Morn 🙂
Morn
Morn!
☕
Mornings
Haha! Footguns all the way!
You don't need an effect!!!
useEffect er vår tids strcopy 🥲
De må få på plass useEffectN
@augustl Hvofor gjør du sånn da? Du vet bedre?
er vanskelig å unngå useEffects. Holder meg unna domene-spesifikke greier, handler bare om ren UI-logikk. Det hjelper litt. Bruker det ikke til data-fetching f.eks, som er største kilden til mayhem
alle sammen gjør i bunn og grunn dom-manipulasjon som å lytte på events etc
Interessant at knappen din må lytte til dom events?
SBMainSaveButton har faktisk side-effekter. Den sørger for at mens den er “waiting for server” så er ikke bare selve knappen disabled, men det vises en global loading-indikator og hele siden blir inert (aka ikke-interaktiv) mens vi venter på svar fra serveren
Det er så mange ting å spørre om.
Det er vel ingen av de greiene der som krever at knappen har en useeffect?
det å skru av og på “loading mode” er et imperativt kall (via en useState sin setter)
Hvorfor useState? Har du ikke lest hva @christian767 og @magnars skriver?
det er en praktisk snarvei som ga mening i dette tilfellet, for å slippe så mye maskineri i “prepare”-biten av arkitekturen for å gjøre noe som vi gjør på veldig mange av sidene våre
Du begynner å høres ut som jeg begynte med hooks, og så ble det fler hooks og så ble det useCallbacks og så måtte hele frontende skrives om… til next.js
det er en React context som ligger i layouten som wrapper hver enkelt prepare-baserte side som gjør selve inert-biten, render progress bar, osv. Og da er en useState limet mellom de to universene
brukes med omhu og varsomhet 🙂 Og kun for små maskiner her og der, ikke businesslogikk
sånn sett føler jeg ikke det går direkte på akkord med prepare-arkitekturen. All businesslogikken ligger der. Er mere “integrasjons-maskineri”, som igjen brukes med omhu (maskiner som har maskiner i seg kan jo fort gå galt)
Jeg er så glad for å jobbe i en stack hvor sånne snarveier rett og slett ikke går an.