Fork me on GitHub
#clojure-norway
<
2023-12-28
>
magnars09:12:15

God mørning!

🐄 1
🐑 1
🐖 1
cjohansen10:12:36

DOM-rendering. React / Reagent / Min kode. Benchmarken snubla på et tidspunkt i en bug, må finne ut hva det var - derav noen NaNs. Men, foreløpig er det ingen memoisering, og allerede tar jeg reagent på to punkter, og er rett i nabolaget på 4 til. Dette kan bli noe 😄

magnars10:12:51

Ja, unntatt "replace all rows" så ser jo dette slettes ikke ille ut!

cjohansen10:12:39

Den er ikke så stillig nei 😅 Den treffer worst case i "oppdater barn"-algoritmen min. Mulig den blir raskere av å lage flere nye noder.

cjohansen10:12:51

Dette er forøvrig et dev-bygg

magnars10:12:59

veldig kult, altså

magnars10:12:08

da har du jo noe helt konkret å jobbe med også

cjohansen10:12:09

Altså optimizations none

magnars10:12:12

stilig verktøy!

cjohansen10:12:15

Ja, absolutt

cjohansen10:12:27

"A few popular javascript frameworks" 😂

cjohansen10:12:58

Men om jeg ender opp med akseptable tall overalt ellers enn "bytt ut 1000 noder med 1000 nye noder" så tror jeg at jeg kan leve med det. Putt en key på parenten hvis du driver med det, liksom 😄

magnars10:12:32

ja, det ville være et typisk case i en paginert liste, for eksempel

magnars10:12:59

men kanskje også hvis man bytter side i en SPA?

cjohansen10:12:50

Det skal mye til. Du må ha 1000 noder av samme type i samme posisjon

cjohansen10:12:37

Men altså, jeg skal ikke slå meg til ro med 20x verre performance 😅

magnars10:12:40

ja, det stemmer nok. Jeg tenkte for eksempel på at system hvor sidene er bygget opp av "sections" som alle er div's på toppnivå. At det skal bli 1000 av dem er usannsynlig da, men treffer vel samme worst case.

cjohansen10:12:00

må finne ut av hva som tar tid osv

magnars10:12:12

ja, ser veldig lovende ut! 😊 👌

cjohansen10:12:33

Først og fremst må jeg finne ut av hva det var som gjorde at den fant 11 noder når den forventet 10. Den bød ikke på så mye info om hva den gjorde for å havne i den situasjonen 😞

magnars10:12:59

Ja, den er verre. 😬 Gratis testing på toppen av ytelsesmålinger, fra det verktøyet, da. Gode greier.

cjohansen10:12:15

Ja, det er bra

cjohansen10:12:39

Det er antageligvis ikke meninga at den øverste raden skal forsvinne uansett hvilket kryss du trykker på 😂

🙈 1
cjohansen10:12:37

> ==== Results of PlausibilityCheck: > successful run

👌 1
leifericf10:12:34

Forresten! Jeg har en tidligere kollega (fra det gamle grafikkmotorteamet til Funcom) og god venn som nå jobber på React i Meta/Facebook. Han er også en Clojure fan, og holder foredrag på London Clojurians i ny og né. Han er Ukrainsk, men har bodd i Norge i mange år og snakker norsk. Jeg har invitert ham inn hit til Slack, men han er ikke helt typen til det. Hvis dere har noen mer dyptgående tekniske spørsmål om React eller DOM-rendering generelt, så kan jeg prøve å sende dem til han også.

👍 1
cjohansen10:12:10

Raskere enn React på ett punkt!

👏 2
🔥 1
cjohansen11:12:30

Raskere enn dumdom på alle punkter unntatt ett

magnars11:12:44

fy søren, så rått! :star-struck:

cjohansen11:12:03

Skal sies at Dumdom ikke får spesielt imponerende tall 😅

cjohansen11:12:15

Men da er vi plutselig inne på "hva er raskt nok"-diskusjonen til @slipset 😄

1
magnars11:12:04

bedre å være rik og frisk enn fattig og syk 😁

😂 1
leifericf11:12:00

Det hadde vært ganske fett (pun, hehe) om Mattilsynet av alle steder hadde kommet ut med neste generasjon DOM-rendering, lol

cjohansen11:12:22

Det er vel i aller høyeste grad "forrige generasjon" 😅

😅 1
magnars11:12:16

"neste generasjon" impliserer en lineær forbedring over tid i bransjen, noe jeg vil si er ganske tydelig motbevist 😅

leifericf11:12:32

Godt poeng, ja!

cjohansen11:12:03

Noen ting blir umulig å slå React på. Den bruker feks lokal state til å velge rad, mens min løsning er "full re-render" topp-ned.

magnars11:12:52

Ja, så lenge det slår dumdom på alle punkter, så er det jo allerede en massiv oppgradering for oss. 🙂

cjohansen11:12:30

ikke på "replace all rows" da, så det må jeg grunne litt på

augustl11:12:06

det er en av tankene bak å eksponere hooks som public API - React har allerede sånne ting under panseret, så det er på en måte “bare” å gjøre API-er som allerede er der public

augustl11:12:09

siden React blander state med rendring for å få til alt under panseret, så skal også apputviklere gjøre det? :thinking_face:

cjohansen11:12:33

Raskere uten keys :thinking_face: Antar at det er fordi den da bare modder alle nodene, mens om du har key så vil den forsøke å finne hver enkelt node før den innser at den skal slettes.

cjohansen12:12:19

Beklager spam. Fikk advanced compilation til å kjøre. Raskere enn reagent på nesten samtlige punkter :star-struck:

3
cjohansen12:12:22

Det er fortsatt ikke en eneste memoize noe sted

cjohansen12:12:13

Komprimert størrelse: Mindre enn React Minnebruk: Sammenlignbart med React, merkbart bedre enn reagent "Startup metrics": Klart best av cljs-variantene

augustl12:12:05

likandes! Reagent er litt utdatert, det har funnet opp en del egne konsepter som bare kunne piggybacket på React hooks. Fint med et alternativ 💯

cjohansen12:12:34

Dette blir nok ikke et direkte alternativ, for det kommer by design ikke til å støtte mange ting som reagent driver med

cjohansen12:12:07

Altså, det blir jo et alternativ, men usikker på om det umiddelbart appellerer til de som bruker reagent

magnars12:12:17

det kommer til å ha en deilig, deilig minimal overflate med akkurat de tingene du trenger for å lage datadrevne UI

💯 3
augustl12:12:41

dogfooding på mattilsynet?

cjohansen12:12:56

Enn så lenge: to public funksjoner, hiccup, én life-cycle hook

magnars12:12:57

det kan jeg love deg

🐶 2
cjohansen12:12:27

Life-cycle hooks og events som data

augustl12:12:09

det som er morsomt med det, er vel at i praksis så skjer vel all event handling på toppnivå i react og (de lytter på events som bobler opp til rot)

cjohansen12:12:36

det var ihvertfall sånn før - på de eventene som støtter det

cjohansen12:12:46

tror feks ikke input-events propagerer

augustl12:12:02

hmm, kanskje det er en sånn 2000-talls optimalisering som ikke gjelder lengere, litt som hvor viktig det var å cache .length på lister i for-loops 😄

cjohansen12:12:27

det tror jeg fortsatt gjelder, fordi dom-en er mutable

augustl12:12:29

var i = 0, il = xs.length :face_holding_back_tears:

magnars12:12:53

viktig å iterere over dom-elementene backlengs 😅

laughcry 2
augustl12:12:20

dra meg baklengs inn i fuglekassa! Den har jeg ikke hørt om

magnars12:12:55

la oss si at du skal fjerne enkelte dom-elementer, så beholder alle indeksen sin underveis mens du muterer DOM'en hvis du tar den siste først.

augustl12:12:43

btw, har noen laget en faktisk immutable GUI-stack enda? GPU-en rendrer jo hver frame fra scratch hver gang, det jo være noe å hente her

augustl12:12:21

(bare sånn helt esoterisk sett, uavhengig av DOM og praktiske hensyn og sånt)

leifericf12:12:09

Jeg gjorde noe som føltes veldig smart, og som derfor kanskje er dumt (?): https://gist.github.com/leifericf/242fb222966c8cfc8beb04539aaf8fab?permalink_comment_id=4809951#gistcomment-4809951 Ref. stacks hvor jeg har lagt inn dette:

:page {:values :stacks
       :next :continuationToken}
:stacks er navnet på nøkkelen (og dermed funksjonen) som henter ut verdiene i responsen fra Pulumi sitt API, som jeg ønsker å samle opp. :continuationToken sier seg vel selv. Det er token i responsen fra Pulumi sitt API, som jeg trenger for å hente neste batch/side. På den måten trenger ikke fetch funksjonen å "vite" noe om responsen fra Pulumi sitt API. fetch-all kan bruke samme nøkler (færre parametere).

augustl12:12:16

Helt innafor! Ville kanskje kalt den :get-value-f (elendig navn)… Men altså, et eller annet som indikerer at “her kan du putte en hvilken som helst funksjon”. Mulig jeg overtenker

👍 1
leifericf12:12:58

iteration kaller disse for :vf og :kf, som antagelig er forkortelser for "value function" og "key function." Jeg kan kanskje gjenbruke de navnene. Men da liker jeg kanskje :val-fn og :key-fn bedre.

👌 2
leifericf12:12:20

Nå må jeg snart gi meg 😅 Det er utrolig hvor mye man kan flikke på ting for å gjøre det bedre. Man lærer mye av sånt, da!

1