This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-12-28
Channels
- # beginners (2)
- # calva (8)
- # capetown (1)
- # clojure (28)
- # clojure-europe (6)
- # clojure-norway (82)
- # clojure-sweden (1)
- # clojuredesign-podcast (5)
- # clojurescript (26)
- # core-async (3)
- # cryogen (7)
- # datahike (30)
- # datomic (10)
- # figwheel-main (8)
- # honeysql (8)
- # hyperfiddle (15)
- # jobs-discuss (6)
- # lsp (6)
- # matrix (6)
- # off-topic (12)
- # overtone (1)
- # polylith (6)
- # portal (6)
- # releases (1)
- # shadow-cljs (9)
- # sql (1)
- # xtdb (5)
Mornings!
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 😄
Den er ikke så stillig nei 😅 Den treffer worst case i "oppdater barn"-algoritmen min. Mulig den blir raskere av å lage flere nye noder.
Ja, her har noen jobbet hardt 😅 https://github.com/krausest/js-framework-benchmark
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 😄
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.
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 😞
Ja, den er verre. 😬 Gratis testing på toppen av ytelsesmålinger, fra det verktøyet, da. Gode greier.
Det er antageligvis ikke meninga at den øverste raden skal forsvinne uansett hvilket kryss du trykker på 😂
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å.
Det hadde vært ganske fett (pun, hehe) om Mattilsynet av alle steder hadde kommet ut med neste generasjon DOM-rendering, lol
"neste generasjon" impliserer en lineær forbedring over tid i bransjen, noe jeg vil si er ganske tydelig motbevist 😅
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.
Ja, så lenge det slår dumdom på alle punkter, så er det jo allerede en massiv oppgradering for oss. 🙂
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
siden React blander state med rendring for å få til alt under panseret, så skal også apputviklere gjøre det? :thinking_face:
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.
Beklager spam. Fikk advanced compilation til å kjøre. Raskere enn reagent på nesten samtlige punkter :star-struck:
Komprimert størrelse: Mindre enn React Minnebruk: Sammenlignbart med React, merkbart bedre enn reagent "Startup metrics": Klart best av cljs-variantene
likandes! Reagent er litt utdatert, det har funnet opp en del egne konsepter som bare kunne piggybacket på React hooks. Fint med et alternativ 💯
Dette blir nok ikke et direkte alternativ, for det kommer by design ikke til å støtte mange ting som reagent driver med
Altså, det blir jo et alternativ, men usikker på om det umiddelbart appellerer til de som bruker reagent
det kommer til å ha en deilig, deilig minimal overflate med akkurat de tingene du trenger for å lage datadrevne UI
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)
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 😄
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.
btw, har noen laget en faktisk immutable GUI-stack enda? GPU-en rendrer jo hver frame fra scratch hver gang, det må jo være noe å hente her
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).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