Clojurians Log v2

de greiene her, altså https://www.kodemaker.no/blogg/2020-01-enkel-arkitektur/

Er det litt som Elm-arkitekturen?

(Eg las berre første avsnitt...)

ganske likt ja, men det er overraskende mye dybde i den artikkelen 🙂

f.eks det med at GUI-et ikke skal vite noe om domenet

@msolli Feil kanal? 🙂

Siden jeg ikke husker noenting av den artikkelen som jeg leste da den ble publisert, fyrer jeg av en bredside (som jeg tror jeg har tatt opp her tidligere)

Fikk en melding av en rekrutterer på Linkedin her forleden:

I have a Senior opportunity in the heart of Oslo. My client prides itself on working with the very latest technologies (Clojure, Kotlin & Node), and are developing products that make the world a safer place.

The budget for this role is 600K - 900K NOK. 

@johsgrd Neida, trykket bare enter for fort! 🙂

1. Jeg savner en diskusjon rundt hvordan domene-data behandles sammenlignet med app-state, dvs hvilke faner dialoger etc som er oppe. 2. Jeg er uenig i at det er bra at GUI'et ikke vet noe om domenet. Jeg mener vi må bygge opp et komponentbibliotek som kan brukes til å representere domenet, gjerne basert på enkeltkomponenter (som ikke vet noe om det)

@msolli jeg fikk også den, valgte å ikke connecte.

Men aner ikke hvem det er .

(jeg vet at vi har tatt i bruk en rekrutterer, men vi bruker ikke Kotlin)

1 - jeg har samme problem, planlegger å ha 100% domene-data i datascript, og GUI-data (drag & drop mm) i et atom ved siden av

2 - også usikker på den. Virker digg å ende opp der, men er jo en kostnad ved å måtte "naming things" to ganger

men det litt større bildet med 2 er vel at rendering-koden skal være litt som css er til html. Rent visuelt, ikke noe logikk

Hmm, jeg ble plutselig litt uenig med meg selv mhp 2)

Det er jo absolutt på sin plass med en ModalDialog (hvis man nå trenger det). Og den er jo ikke nødvendigvis en del av domenet.

sant - det er jo uungåelig med deler av GUI-et som ikke har noe med domenet å gjøre ja

Men vi lager nå et MergeTable. Det er jo helt klart en del av domenet vårt.

jau, det frister jo å kalle det "pages" og "page drafts", ikke "sidebar draft items" og "sidebar items" eller noe sånt

Noen komponenter er jo generiske (og ting som alle må mekke fordi vi ikke har et solid komponent bibliotek for web) dialoger, tables, trees er jo lette å trekke fram.