This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-03-02
Channels
- # aleph (1)
- # announcements (1)
- # babashka (4)
- # beginners (89)
- # calva (3)
- # chlorine-clover (18)
- # cider (33)
- # clj-kondo (27)
- # cljdoc (4)
- # cljsrn (2)
- # clojure (248)
- # clojure-europe (7)
- # clojure-italy (15)
- # clojure-nl (7)
- # clojure-norway (10)
- # clojure-poland (1)
- # clojure-spec (12)
- # clojure-sweden (5)
- # clojure-uk (57)
- # clojured (4)
- # clojuredesign-podcast (1)
- # clojurescript (55)
- # core-async (14)
- # core-logic (3)
- # cursive (10)
- # datomic (38)
- # figwheel-main (8)
- # fulcro (23)
- # graalvm (126)
- # hoplon (59)
- # jobs (1)
- # kaocha (3)
- # malli (30)
- # meander (17)
- # off-topic (32)
- # pathom (19)
- # pedestal (4)
- # re-frame (12)
- # reagent (2)
- # reitit (3)
- # shadow-cljs (81)
- # sql (9)
- # tools-deps (34)
- # vim (20)
- # vscode (7)
- # xtdb (5)
Hey guys! I just published the finished Hoplon + shadow-cljs realworld
app: https://github.com/rlander/conduit
BTW, I tried using only hoplon.goog
to get rid of the jquery dependency but the app did not compile.
nice, congrats!
does it compare favorably size-wise to the othre frameworks? in terms of delivery
I'd say it's average with jquery but we could do much better. Personally, I don't mind jquery at all. But I know it might be a major turn off for some people.
wow i wonder why that was in there
oops that might have been me
200k is nothing to sneeze at, probably worth removing
It doesn't really matter for this app because, since I added a compiler directive, it won't get bundled
i just took a brief glance, but if i were to have to co-maintain that codebase, i would want each view to be in its own namespace. that's really personal preference, speaking, of course. i realize that some people prefer to have everything in one namespace for reasons(?)
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.
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)
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.
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
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
About the nested html/css, I had to follow the spec here: https://github.com/gothinkster/realworld-starter-kit/blob/master/FRONTEND_INSTRUCTIONS.md
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
The current bundle (compressed) is at 153Kb
which is not the worst https://cdn-media-1.freecodecamp.org/images/DRmH8Fz15DLxXguz9d8NR0eVanX0U9xW9jom
makes me wonder about having our own provider, i wonder if there is a runtime way to see code liveness
i would bet there's a lot of junk even in goog that doesn't get shaken out
oh, that the code delivered is actually exercised at runtime
live code as the opposite of dead code
Shadow-cljs does a great job at detailing the dependencies https://gist.github.com/rlander/ed45bd67ab1193d8bedb559eaa553b80
oh interesting, it would be cool to instrument jquery maybe to see which methods actually get called by hoplon
to inform our own bare-bones provider
App deployed: https://hoplon-realworld.netlify.com/