Clojurians Log v2

I totally agree. Since I didn't have a lot of time on my hands and I couldn't find a reference large-ish hoplon codebase, I went with the same layout as the Re-frame implementation.

https://github.com/jacekschae/conduit

makes sense

at adzerk, we have a huge hoplon application and we organize the cljs files partly around views. like each conceptual "page" gets its own file

some of those individual pages can be huge (like if there's a big complicated form with lots of logic)

and there are also a lot of them

Interesting, that's what I was aiming at initially. But then I started factoring out the common parts and figured it wasn't worth the trouble for such a small app.

BTW, I'd love your opinion on how idiomatic that codebase is 😃

i'm taking a closer look now. one thing that sticks out to me is that your views have a lot of "markup," e.g. many layers of nested divs i think that's a good way to start out, but as you build more and more views, you typically end up coming up with abstractions and composing together elements a lot more

i still don't really know what approach to CSS i would recommend

my frontend skills are comparatively weak, especially when it comes to CSS

what we do in our app is we have most of our styling in a bunch of sass files, and our build pipeline includes compiling the sass to css

but we also end up doing some dynamic CSS stuff depending on the state of cells, because that's a superpower that hoplon enables

so in light of that, i'm not really sure if keeping your styling in CSS files is even the best approach anymore

anyway, what i'm getting at is that i don't think there's necessarily anything wrong with how you're doing styling

at any rate, i do think it's a good idea to define a lot of little "helper elements," in the same way that we compose together -small functions when doing FP

the way you're using cells looks good. it pretty much looks like something i would write, for whatever that's worth 😄

i like your "state" namespace where you define a bunch of cells at the bottom. we have something similar in our app

it really helps to have those cells in a single, really simple namespace, so that you can refer to it from a lot of other namespaces and avoid running into circular namespace dependency issues

Thanks for the feedback, much appreciated!

About the nested html/css, I had to follow the spec here: https://github.com/gothinkster/realworld-starter-kit/blob/master/FRONTEND_INSTRUCTIONS.md

It's out of my control but I agree with you, I wouldn't nest html this way either.

Do you have any public link with this kind of dynamic CSS implemented?

I didn't use any global scoped state within components but I was on the fence about using in pages. Ideally every view would be a product of the parameters, but in the end I wasn't able to find a nice way to preload each route's state so I just left at that.

I think it does make sense to have some global state. A "current errors" cell is a good example, or a global route cell

It's always good when you can encapsulate it when the state is an implementation detail of a particular element

I don't have a good example of dynamic CSS handy, sorry