Når man snakker om elsk rundt cond. Husker en gang Slipset sa så fint at man ikke burde skrive, som jeg hadde skrevet

(if condition
   (do-stuff thing)
   thing)

(cond-> thing 
        condition do-stuff)

God morgen.

Eskimoene har mange ord for snø, Clojure har mange ord for if 😄

Veldig fint med mer spissede verktøy, da kommuniserer også koden bedre. if => when, cond, case, cond->, if +++, for ikke å snakke om for/`while` => map, filter, keep, remove , doseq, for, loop +++

find src -name "*.clj" | xargs grep "cond-" | wc -l
     132

Jeg liker’n godt 😄

@slipset some-fn har jeg aldri brukt :thinking_face:

Jøss, some-fn er ganske fancy da. Spesielt når keywords er funksjoner i Clojure. Funker nesten som "short-circuit OR" med predikater. Eh, nei, kanskje ikke… Fant dette eksempelet:

((some-fn :a :b :c :d) {:c 3 :d 4})
;=> 3

en tanke som datt ned i hodet nå: når man har tilstand “globalt”, altså på toppen, og ikke noe tilstand i komponent-hierarkiet, får man et problem: man må rydde opp i tilstanden. Typ, du åpner GUI X, som putter en haug ting i databasen. Så åpner du GUI Y, som ikke trenger noe av den tilstanden. Pleier dere å løse sånne ting og fjerne unødvendige ting fra global state, eller er det et ikke-problem og premature optimization osv? Hilsen August “Premature Optimizer” Lilleaas

og har det noen gang skjedd på ekte i prod at tilstand som “lekker” mellom skjermer fører til bugs? La oss si gui X skriver til state :foo, og gui Y gjør også det, og antar at den er null ved første visning, men så er den ikke null fordi den lekker?

Vi har operert med et spesielt lager for "transient" state (bare en egen key i global store) som ryddes når du navigerer mellom sider. Den brukes til å unngå at helt midlertidig tilstand ikke blir persistent på tvers av sider.

har gjort noe lignende selv ja, har en :current-route eller noe sånt hvor alle sånne ting ligger. Stort sett har det fungert greit tror jeg, selv om den ene gangen jeg har laget GUI på denne måten (CMS-en) ikke rakk å vokse seg så veldig svært osv

På Fortum hadde vi ikke noe mer rydding enn det. Vi hentet data via specs per side ("gitt denne staten og disse parameterne fra URL-en, hvilke data trenger du?"). Et problem som kan oppstå, som du var inne på, er at en side kan ende opp med å være avhengig av data den har glemt å spesifisere. Da vil den bare fungere dersom du først har vært innom en annen side som ber om de dataene.

Dette kan lett løses ved å filtrere staten som siden ser ved rendering

høres ut som et klassisk tilfelle av “ingen patterns gjør deg immun mot bugs” 😄

Altså, i stedet for å "rydde opp" så plukker du kun ut de tingene som siden ber om når den skal rendre

Er det slutt på CMS-prosjektet?

er lagt litt på is ihvertfall. Det viser seg at én utvikler som forvalter et prosjekt med et scope på en håndfull utviklere i en håndfull år for å komme til beta-stadiet ikke er så kjempelurt 😄

men det var en fin erfaring å ta med seg. Nå har jeg implementert et nytt system: sideprosjekter får 100 timer på seg, om jeg har 0 fornøyde brukere av tingen på 100 timer, kast prosjektet og finn noe annet 😎 Mulig jeg tar opp igjen CMS-en med de brillene på, har fortsatt trua på konseptet! Må bare scopes litt bedre

“hva om Google Docs hadde Sanity-aktige utviklerdefinerte forms du kunne dra inn hvor du vil i dokumentet, som representerte React-komponenter”

(hva er et bra universelt ord på “React-komponenter” som også treffer andre komponent-baserte biblioteker? Bare “komponent” i seg selv føles for fuzzy og tunglest)

Ser på London Clojurians-presentasjonen av electric. Det er en fascinerende ting de har fått til, men jeg tror egentlig ikke jeg ønsker meg dette...

har ikke blitt bitt av noen basill enda selv heller, selv om jeg ikke er uenig i noe av det han sier

Jeg er uenig i at det er et fint mål å ha en funksjon som blander kall til serveren og klienten. På samme måte som at jeg ikke syns det er noe ålreit å putte html OG sql-spørringer i en php-fil.

For ikke å snakke om at det ser ut som om all koden min blir pakket i noen makroer. Hvis du har feilsøkt core.async-kode så vet du hvorfor det ikke frister.

Imponerende eksempler med streaming i uendelig scrolls.