Clojurians Log v2

Nice!

Har dere timing på ytelsesforbedringen?

Ligger på Jira issues. Interessante diskusjoner over i #announcements

Nice, https://clojure.atlassian.net/browse/CLJ-1789

(bench (clojure.core/select-keys {:a "b" :c "d"} [:a]))
Evaluation count : 246382440 in 60 samples of 4106374 calls.
             Execution time mean : 243.245536 ns
    Execution time std-deviation : 2.714803 ns
   Execution time lower quantile : 238.473675 ns ( 2.5%)
   Execution time upper quantile : 248.544255 ns (97.5%)
                   Overhead used : 1.845047 ns

Artig å få med kode i core! Men hvorfor vente seks dag? 🤔

Og hvorfor er hele funksjonen flytta for så å ende opp i en declare? 🤔

Du kommer snart til å være forfatteren av kode jeg bruker stadig vekk @slipset 😄

Så Frankrikes nasjonaldag er 14. juli, etter stormingen av Bastillien samme dag i 1789. Funksjonen måtte flyttes fordi den tidligere brukte idiot versjonen av reduce, fordi den raske reduce’n ennå ikke var definert. Når jeg skriver det, så er det litt rart. Eller om den gamle versjonen brukte reduce1? Det er noen år siden nå…

Aha

Jeg synes det er tøft at dette er en ekte test:

(testing "Viser skillelinje mellom hver hovedbolk"
  (is (= (->> (mitt-serveringssted-ui/vis-serveringssted {} testdata)
              (lookup/select-one "[data-center=lg]")                 
              lookup/children                                       
              (map first))                                          
         [::mitt-serveringssted-ui/nøkkelinfo
          :hr
          ::mitt-serveringssted-ui/besøksadresse
          :hr
          ::mitt-serveringssted-ui/åpningstider
          :hr
          ::mitt-serveringssted-ui/kontaktpersoner
          :hr
          ::mitt-serveringssted-ui/detaljer
          :hr
          ::mitt-serveringssted-ui/drift])))

Veldig elegant!

Ja, veldig stilig! Å representere UI med en innebygd datastruktur tror jeg kanskje er det jeg savner aller mest i andre språk etter at jeg først så det i Clojure.

Jeg setter også pris på maktdemonstrasjonen det er å inkludere lenker til tre open-source biblioteker dere bruker uten å nevne at det er forfatteren som står bak alle sammen 😄

Haha! Jeg syns egentlig det er mer pinlig enn noe annet. "Denne fyren bruker bare sine egne greier" har en litt negativ klang til seg 😅

🤷

Blir ikke morsommere enn man gjør det til sjæl, som vi pleier å si 😄

Hvis man prøver å gjøre det samme med React, så møter man raskt veggen fordi en hierarkiet ikke blit materialisert før man sender avgårde til rendering:

const MySection = (props: { x: { val?: string } }) => 
{props.x.val}
;

const MyComponent = (props: { state: { xs: { val?: string }[] } }) => (
  

    {props.state.xs.map((x, i, xs) => (
      <>
        {!x.val && xs[i - 1] && !xs[i - 1].val && 
}
        
      
    ))}
  
);

const result = ;
console.log(result);

---

==> {
  '$$typeof': Symbol(react.element),
  type: [Function: MyComponent],
  key: null,
  ref: null,
  props: { state: { xs: [Array] } },
  _owner: null,
  _store: {}
}

Problem, eller feature, alt etter som hvordan du ser det. Det kommer ikke så godt frem av eksempelet Teodor posta over, men det samme skjer der. Og jeg mener det er en fordel, for det lar meg snakke om strukturen uten å gå inn i detaljene. Hvis jeg fjerner (map first) så ser du hele hiccupen:

([::mitt-serveringssted-ui/nøkkelinfo {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}]
 [:hr]
 [::mitt-serveringssted-ui/besøksadresse {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}]
 [:hr]
 [::mitt-serveringssted-ui/åpningstider {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}]
 [:hr]
 [::mitt-serveringssted-ui/kontaktpersoner {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}]
 [:hr]
 [::mitt-serveringssted-ui/detaljer {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}]
 [:hr]
 [::mitt-serveringssted-ui/drift {}
  {:db/id 4
   :serveringssted/id "serveringssted-10180"}])

MEN! Replicant har replicant.alias/expand-1 for å ekspandere ett nivå med aliaser, og replicant.alias/expand for å ekspandere alle aliaser. Så du kan velge detaljnivået som det passer seg, uten å vite så mye om hver enkelt konkrete instans.

Normalt sett ville jeg tenkt at en test som trenger å se på hva ::mitt-serveringssted-ui/detaljer gjør, gitt en serveringsstedsentitet, burde formuleres som en test rett på det aliaset i stedet.

Aliaser er for hiccup omtrent som makroer er for Clojure-kode 😅

expand blir jo kjempenyttig, f.eks. ved smoke-tester e.l. Nice! Den store store forskjellen tenker jeg ligger i hvordan vi bruker React. Hadde vi brukt rene funksjoner som produserte ui istedenfor komponenter, og komponenter unntaksvis for abstraksjoner, så kunne vi hatt en lignende opplevelse også der. Men dessverre så er det ingen som er interessert i å skrive på den måten (som ble tydelig omtrent samme dag som JSX ble lansert).

Ja, det er et mysterium for meg at man heller ønsker seg en levende objektgraf 🤷

Men det er så praktisk å kunne gjøre HTTP-kall fra DetailsCard! (😢)

Så lenge det er uttrykt som data, er jeg med ☺️

gir ro i sjela ☺️

ja, det er fint at man uttrykker dette i page-lifecycle metoder. men jo mer jeg tenker på at ui'et er rene data, så kan det også behandles som domenelogikk som uttrykker effekter som må utføres. Imperativt skall / funksjonell kjerne, hvor kjernen er ui'et. Det vil medføre mindre grad av mapping (ingen prep) og potensielt et mer konsist og kompakt kodetre, hvor aliaser representerer rent gui, mens resten er funksjoner som deklarerer ui + effekter.

Yes, det er mer eller mindre nøyaktig det vi har bygget 🙂

@christian767 har ikke du skrevet om "hva er domenespråket til UI-et" eller noe sånt før? Jeg tittet over på Parenteser, men fant den ikke, så kanskje den ligger hos Kodemaker?

Kodemaker, ja

Jeg fant den! https://www.kodemaker.no/blogg/2023-01-domenemodell-frontend/

@gar da du sa "så kan det også behandles som domenelogikk som uttrykker effekter som må utføres", fikk du meg til å tenke på denne.