Fork me on GitHub
#hoplon
<
2020-03-02
>
rlander17:03:01

Hey guys! I just published the finished Hoplon + shadow-cljs realworld app: https://github.com/rlander/conduit

bananadance 4
rlander17:03:09

Would love to get your feedback

rlander17:03:39

BTW, I tried using only hoplon.goog to get rid of the jquery dependency but the app did not compile.

alandipert17:03:09

nice, congrats!

alandipert17:03:29

does it compare favorably size-wise to the othre frameworks? in terms of delivery

rlander17:03:32

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.

rlander17:03:56

Uncompressed ~600K

rlander17:03:41

I got rid of ~200K by stripping "cljs.pprint"

alandipert17:03:19

wow i wonder why that was in there

rlander17:03:55

I found a few pprint imports in hoplon.

alandipert17:03:16

oops that might have been me

rlander17:03:18

(or maybe javelin, not sure)

alandipert17:03:10

200k is nothing to sneeze at, probably worth removing

rlander17:03:11

It doesn't really matter for this app because, since I added a compiler directive, it won't get bundled

dave17:03:07

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(?)

rlander17:03:58

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.

dave17:03:49

makes sense

dave17:03:21

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

dave17:03:49

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

dave17:03:57

and there are also a lot of them

rlander21:03:54

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.

rlander21:03:30

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

dave22:03:55

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

dave22:03:14

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

dave22:03:27

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

dave22:03:48

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

dave22:03:28

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

dave22:03:44

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

dave22:03:52

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

dave22:03:20

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

dave22:03:48

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

dave22:03:22

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

dave22:03:55

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

rlander00:03:24

Thanks for the feedback, much appreciated!

rlander00:03:15

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

rlander00:03:10

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

rlander00:03:08

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.

dave04:03:16

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

dave04:03:03

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

dave04:03:20

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

rlander17:03:05

The current bundle (compressed) is at 153Kb which is not the worst https://cdn-media-1.freecodecamp.org/images/DRmH8Fz15DLxXguz9d8NR0eVanX0U9xW9jom

rlander17:03:21

I guess without Jquery I can get to ~120KB which just about ties with Aurelia.

alandipert17:03:51

makes me wonder about having our own provider, i wonder if there is a runtime way to see code liveness

rlander17:03:26

wdym "liveness"?

alandipert17:03:26

i would bet there's a lot of junk even in goog that doesn't get shaken out

alandipert17:03:35

oh, that the code delivered is actually exercised at runtime

alandipert17:03:54

live code as the opposite of dead code

rlander17:03:43

Shadow-cljs does a great job at detailing the dependencies https://gist.github.com/rlander/ed45bd67ab1193d8bedb559eaa553b80

rlander17:03:52

But there's no way to know what's actually being used

rlander17:03:17

I think the lowest hanging fruit there is jquery

rlander17:03:36

spec also gets bundled for some reason

rlander17:03:16

The actual app code corresponds to less than 10% of the final bundle size.

alandipert18:03:46

oh interesting, it would be cool to instrument jquery maybe to see which methods actually get called by hoplon

alandipert18:03:51

to inform our own bare-bones provider