This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (25)
- # boot (14)
- # business (1)
- # cljsrn (2)
- # clojure (180)
- # clojure-korea (14)
- # clojure-russia (8)
- # clojure-spec (9)
- # clojure-uk (17)
- # clojurescript (110)
- # cursive (14)
- # datomic (18)
- # emacs (23)
- # events (4)
- # garden (7)
- # hoplon (44)
- # lein-figwheel (1)
- # liberator (4)
- # london-clojurians (1)
- # om (10)
- # om-next (2)
- # onyx (22)
- # protorepl (60)
- # re-frame (36)
- # reagent (11)
- # ring (10)
- # yada (5)
@flyboarder what did u use to generate that dependency graph? (imean the graph data itself; otherwise i see it's rendered by graphviz) i was just sniffing around the other day for a similar tool. there are not a lot...
@micha it occurred to me that it might be worthwhile to adopt Elm's Architectural terminology of Model, Update, and View in Hoplon documentation, since that's (to me) what a Hoplon app looks like. The Model is state (cells and atoms). The Update are state transition functions. The View is the HLisp. If you look at https://github.com/hoplon/demos/blob/master/todoFRP/src/index.cljs.hl, I think it would be conceptually better to lump persisted state, local state, and computed state under Model; state transition functions under Update; and page under View. What do you think? I think it helps make things easier to reason about if this pattern is made explicit.
@mhr Micha has avoided in the past telling people how to use Hoplon and what is "idiomatic" by saying everything is idiomatic. Not sure if this will change. I'm working on some version of what I think a good architecture for bigger Hoplon apps, but this is of course not official. There are lots of ways of using Hoplon specially for small apps where too much architecture is unnecessary and even harmful.
I guess just for me, then, I struggled with how to think about Hoplon apps until I looked at Elm. I just found it hard to think about; it seemed too easy to write spaghetti code without some sort of discipline. Being able to ask myself "What is the Model, Update, and View for this application?" helped a lot.
@mhr a lot like redux I guess, which is like elm 😃 Views updated from a datascript db or a big atom in a cell (storage), a mechanism to receive events and update the storage (reducer).
There is another version that is nice too, where there is no central storage, but some smaller ones. Trade offs.
But for small apps, is put your data in cells, your views will update when you update cells 😉
It would also be cool if I could specify a namespace as an entry point for it to scan
hoplon itself is pretty low-level library, there isn't any specific architecture it is really tied to
once you start building your application you will end up making decisions that will guide you toward some more specific set of patterns etc
@micha I would certainly like to see the things that worked for you. A complaint that I heard about Hoplon in different occasions is that is has less structure than people feel comfortable with.
@mynomoto: this was also a thing I was thinking about, structure is a huge thing, but with hoplon it's actually so much easier
@flyboarder yeah, I find Hoplon pretty straight forward, even large apps still fit in my head, but I'm not sure how to convince people of that 😉
It seems to me, I generally end up with ~50-60% of the code I would normally write for equivalent functionality, but I haven't actually been using it all that long, so I can't tell if this is how it generally works out.
Cool, I was listening to the cognitcast episode about hoplon and wondered if you were aware of Tilton's work
as micha says, most of these people weren't builidng on a browser or an existing event system, so their things do way more