clojure-norway 2025-09-16

føler denne hører hjemme her

7

Haha! Footguns all the way!

You don't need an effect!!!

Hoi, Problematic Object er jo mellomnavnet mitt

😂 5

useEffect er vår tids strcopy 🥲

De må få på plass useEffectN

krisen er rett rundt hjørnet for kodebasen vår ihvertfall

😂 2
😱 2

@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

React context. Global hidden state.

🎯 1

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.

kanskje jeg egentlig burde kode C :)

😁 1