God morgen!

Morn!

Morn, ja

Mornings! ❄️

Sa på jobben så har vi sånn sikkerhetsgreie som gjør at man må oppdatere maskinen sin (mac) når det kommer nye sikkerhetsoppdateringer. Det er vel og bra, men jeg må si jeg er litt skuffet over hvor ofte det kommer sikkerhetsoppdateringer. Jeg tror det er minst to siden Sonoma kom? Og det er jo ikke så lenge siden?

Jeg følger ikke helt med, men det er vel ikke så uvanlig at det kommer noen sikkerhetsfikser i kjølvannet av større oppgraderinger?

Joa, men det er litt irr.

egentlig burde jo OS-et få 15 sikkerhetsoppdateringer hver dag, usynlig i bakgrunnen

Jepp ,det er liksom litt veldig irr at det tar 30 minutter for å gjøre en sikkerhetsoppdatering.

Ja, det suger

etter vi fikk flex og grid så får jeg gjort det meste jeg trenger å få gjort ihvertfall 🙂

Morn!

Ang CSS, så merker jeg meg a som en n00b som bare forventer at ting skal virke, så er det utrolig mye rart man må gjennom for å få ting til å se ut som de jeg vil at de skal. Sagt på en annen måte, CSS og jeg har ulike måter å betrakte verden på. Jeg sier ikke at min er den riktige.

Helt klart. Og jeg lider sikkert av en viss porsjon Stockholm-syndrom etter 20 år

Eksempelvis, hvorfor må det være en div her og ikke en span (eller var det jeg som tok feil) https://github.com/slipset/www.bonzai-hvaler.no/blob/main/index.html#L52

Det skal egentlig være en span 😅

Og det har egentlig ingenting med CSS å gjøre

Og kanskje et av problemene mine er at jeg gjerne begynner med noe naivt, og så plutselig må jeg scrap’e alt jeg har gjort og begynne med flexbox eller grid eller noe. Sånt gjør at jeg kvier meg for å begynne.

Mulig det ikke har noe med css å gjøre, men i min verden brukte jeg css til å “fixe” det?

span er et inline-element og div er et blokk-element. Inline vs blokk er fundamentale konsepter i både HTML og CSS. Visuelt så vil et inline element flyte "i linja", og kunne delta som en del av en linje innhold osv. Blokkelementer får en hel blokk - altså, i utgangspunktet står ikke blokkelementer ved siden av hverandre. I HTML har disse elementene (veldig tynn) semantisk betydning - inline og blokk. I tillegg har de default CSS: inline- og blokk-layout. Du har kanskje valgt en div fordi du ønsket blokk-utseende. Men h4 kan ikke inneholde blokk-elementer (HTML-regel). Dermed skulle det vært en span . Og hadde du gitt den display: block så ville den sett lik ut som den gjør nå.

Jeg er litt overrasket over å lære at spacene du har rundt = faktisk er tillatt 😄 <h4>Basilikumsaus med grønnsaker og ris <div class = "price">169,-</div></h4>

Det er helt klart mulig å ha en diskusjon om hvor intuitivt dette er, men det som er sikkert er at å levle opp litt på fundamentale konsepter gjør hele øvelsen mye hyggeligere 🙂

semantikk er en faktor og, idéelt sett burde det kanskje vært en h4, og så en p, hvor det står “Pris: 169” og så eventuelt skjule “Pris:” visuelt. Den h4 med div inni seg leses vel som “Basilikumsaus med grønnsaker og ris 169” av en skjermleser

en tråd med mange varianter av svar på spørsmålet “hvorfor liker du ikke Clojure” https://news.ycombinator.com/item?id=38540761

Så gærnt har det blitt: > By default, when a component re-renders, React re-renders all of its children recursively. This is why, when ProductPage re-renders with a different theme, the ShippingForm component also re-renders. This is fine for components that don’t require much calculation to re-render. But if you verified a re-render is slow, you can tell ShippingForm to skip re-rendering when its props are the same as on last render by wrapping it in memohttps://react.dev/reference/react/memo

Driver og lurer på hvorfor vi trenger https://react.dev/reference/react/useCallback , og det viser seg at det er fordi man ikke bruker data.

hvordan løser egentlig reagent og disse cljs-react-wrapperene det? (= #(+ 1 2) #(+ 1 2)) er jo false i cljs og

altså, old-props og new-props blir jo aldri = ved re-render om man sender inn funksjoner: (= {:title "zing" :on-click #(+ 1 2)} {:title "zing" :on-click #(+ 1 2)}). Jeg lurer på om reagent ikke løser det, og at det er “feil” å sende inn funksjoner med props på den måten. Synes å huske at det er noe med at første argument skal være immutable props, og etterfølgende argumenter skal være funksjoner og annet?

Det kommer fra quiescent

Lurer på om Ohm også hadde noe sånt

dumdom er sånn sett den store vinneren her, som ikke har event handlers (eller støtter å ikke ha det ihvertfall, data ftw)

Svaret er at funksjoner søpler til dataene dine, og fører til over-rendering

Det er delvis bakgrunnen for event-handlers som data i dumdom. Den andre er at det hjelper deg å frikoble komponentene fra mekanikken som dispatcher events

makes sense. React “måtte” vel lage useCallback i og med at det ikke er noen måte der å skille på “props” og “andre ting” - du kan bare sende inn props

er jo egentlig en ganske bananas default å sende inn masse “live” kode sammen med rendringen

En praksis tilnærmet hele bransjen bedriver. 😅

ser at reagent sin egen doc gjør “angular-tingen” (har det et navn?), altså at dokumentasjonen tar noen snarveier for å slippe å adressere problemer som dukker opp “in the real world. F.eks er diverse handlers som sendes inn defns, og da blir den jo = på tvers av renders

man kan si at det med state på toppen vs spredd i komponentene en smakssak…. Hear me out…. Sier ikke det, men la oss si at man kan si det, og at det argumentet for en “cljs-arkitektur” sånn sett faller flatt. Men det å ha all event-håndtering på toppen, og at alle on-ditt-datt i rendringa bare er data, der snakker vi en 100% objektiv fordel som har en direkte effekt på koden. Kunne vært et interessant tema for en talk eller bloggpost for å selge inn den arkitekturen. (Har ikke sett Christian sitt javazone-foredrag enda 😬, kanskje han er innom det der?)

som @slipset er inne på, så er det ikke akkurat supergøy å wrappe alle handlerene dine i useCallback med deps-array og i det hele tatt

Høres igjen ut som en dårlig løsning på noe som muligens er riktig problem

og i React så må man det jo, særlig om du sender en handler inn til en useEffect (som man ofte gjør), sånn at ikke effekten kjører på hver render siden callback blir ny på hver render

det Clojure løser ved å …. løse det, løser JS-land med linting da, om ikke annet. Ut av boksen får du grei beskjed i vscode om at du har dumma deg ut om du ikke gjør det riktig med useCallback/useEffect

noen må få bundla med en cljs-not-a-real-problem linting-regel i vscode, som gir deg en advarsel hver gang du gjør noe i JS/react som ikke egentlig trenger å være et problem

relatert? https://twitter.com/adamwathan/status/1732439683014017217