@micha thanks, I was hoping someone had already solved this problem 🙂

@micha https://github.com/simeji/jid

@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.

*Update is

@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.

@mynomoto: can you describe what you think "good" Hoplon architecture looks like?

@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 😉

@onetom: I used ns-graph which has a boot task https://github.com/alexander-yakushev/ns-graph

I like it, but doesn't yet have cljs support

I opened a ticket for that

It would also be cool if I could specify a namespace as an entry point for it to scan

^^ that's exciting, i'll take a look

@mhr i can show you some things i think came out well if you like

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 i'll make a demo with some things that i think worked out well

some of them are not easy to make into a library

because the library code ends up being redundant

@micha cool! I'm eager for it

@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.

when i try to make a philosophy of it it all ends up being redundant and obvious

http://smuglispweeny.blogspot.com/2008/02/cells-manifesto.html

Some "prior art" for the cells model.

https://github.com/hoplon/javelin/blob/master/test/javelin/core_test.cljs#L765-L829

^^ re: kenny tilton cells manifesto

Cool, I was listening to the cognitcast episode about hoplon and wondered if you were aware of Tilton's work

javelin does a lot less, basically

i hadn't seen it till we had already made the initial javelin

we got most of the ideas from this microsoft thing called flapjax

which was more of a classical FRP type thing

so most of our original research was into the various FRP things

Cool, while thanks for making it.

there's a lot of pre-Tilton art also, also discovered post facto

http://repository.cmu.edu/cgi/viewcontent.cgi?article=1761&context=isr is a good entree

as micha says, most of these people weren't builidng on a browser or an existing event system, so their things do way more

but usually the part that's like javelin... is like javelin

Yeah, I've actually compiled and played with Garnet recently.