This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-28
Channels
Det er kanskje ikke noe sql injection pr se, men dette betyr jo at det finnes et endepunkt på serveren som mottar sql og returnerer resultatet. Little Bobby Tables would have a field day.
Jeg skjønner ikke appellen med å blande ting som skjer på klienten og serveren på denne måten
Nesten så jeg ikke har sovet i natt (ikke helt sant). Men jeg har tenkt på sånn snabbdom greie.
Hvis man sier at komponentene er bivirkningsfrie funksjoner fra props til html (sånn litt forenklet), så burde man ikke helt trenge vdom?
Fordi, da skulle det jo holde å diffe props-treet, gitt at man visste 1) hvilke komponenter som er avhengige av hvilke props og 2) visste hvilken dom-node en komponent manipulerte?
Mhp perfomance og sånn. Jeg har tidligere referert til https://github.com/chriskr/uldu som “hiccup for JS”, men har ofte glemt å nevne at benchmark’ene viser at uldu er raskere enn React selvom jeg ikke tror uldu gjør noe som helst slags diffing. Jeg har dog ikke lest kildekoden til uldu.
https://github.com/chriskr/uldu/blob/master/src/index.js#L28 er jo hele greia, en rekursiv dings som bare lager dom elementer og banker dem inn i dokumentet.
så, hvis man snudde opp ned på rekkefølgen litt:
(->> props
(create-hiccup-for-changed-props root-component old-props)
(insert-into-dom))Uansett. Dette er ingenting jeg kan noe som helst om, så ta alt med en klype salt eller tre.
Det du beskriver er vel omtrent det jeg tenker at vdom + memoize på komponentnivå er.
Det er jo omtrent det, kanskje? Men jeg tenkte at det kanskje var raskere å diffe på props-treet enn på dom-nivå? Og hvis man differ på props-treet forbyr man liksom stateful components.
Ja, jeg har tenkt det samme. Idéen min er å ha en biblioteksspesifik memoize som merker resultatet med "denne er ikke fersk" (feks via metadata), som rendering-algoritmen kan bruke til å si seg ferdig med den gjeldende grenen
"Aha, siden dette er et tidligere beregnet resultat er den tilsvarende dom-en fortsatt oppdatert"
Hvis man generaliserer litt kunne man benyttet samme memoize for å gjøre domenedata -> uidata, og optimalisere det leddet også
Forresten, det får man til med vanlig memoize. Må bare ha en LRU eller lignende for å kontrollere minnebruken
Jeg sitter her ved kjøkkenbordet mens sønnen sover og ser på https://www.youtube.com/watch?v=BThkk5zv0DE, hvor han viste en fyr med Clojure (eller LISP) tatovering.
(iterate think self)
Men hvordan gir det mening egentlig? 😅
iterate er definitivt en funksjon pga. plasseringen, men hva med think og self? think høres ut som en funksjon, men self er kanskje en datastruktur? self høres litt objekt-aktig ut. Hmmm. En funksjon som tar en funksjon og en datastruktur? :thinking_face:
Hvis iterate er en funksjon som tar en funksjon og en datastruktur, så burde kanskje map eller reduce vært brukt istendenfor.
Dette er selvsagt bare tull og tøys på en lørdag ettermiddag av en sliten småbarnsfar :melting_face:
Det er kanskje ikke noe sql injection pr se, men dette betyr jo at det finnes et endepunkt på serveren som mottar sql og returnerer resultatet. Little Bobby Tables would have a field day.tror ikke det stemmer! Det blir såvidt jeg vet bare kjørende på serveren, og pakkes som et del av et byggesteg og kalles over http osv, altså erstattes funksjonen med et rpc-kall enten når man rendrer på serveren eller på klienten
"server components" betyr vel i praksis "du har et byggesteg som rendrer dem statisk", ikke "du har en live kjørende server som rendrer on-demand"
så man kan ikke ha "use server" uten et byggesteg som pre-pakker server-kode i byggesteget. Så på en måte kan man se på dette som å inline serverkode i stedet for å manuelt måtte wrappe det i et API. Så debatten her ser jeg fortsatt på som "bør man kalle API-er i rendring-koden", dette SQL-greiene er mere en slags svarvei enn en helt ny topologi
Dette er PHP, hverken mer eller mindre. Tradeoffene blir nøyaktig de samme. Ok, sql-en har ikke injection attacks, men det er der skoen trykker. Problemet er at du søler alt sammen på ett sted.
la oss si at man har all sin "use server"-kode som navngitte funksjoner, da blir spørsmålet "er URL-er eller funksjonsnavn fundamentalt forskjellige når man gjør RPC i render-kode"