This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # announcements (18)
- # aws (17)
- # babashka (19)
- # beginners (141)
- # calva (73)
- # cider (4)
- # clj-kondo (13)
- # cljs-dev (2)
- # clojure (97)
- # clojure-europe (6)
- # clojure-italy (5)
- # clojure-nl (1)
- # clojure-spec (25)
- # clojure-sweden (2)
- # clojure-uk (25)
- # clojured (3)
- # clojurescript (63)
- # core-typed (6)
- # cursive (23)
- # data-science (4)
- # datomic (74)
- # fulcro (19)
- # graalvm (18)
- # graphql (3)
- # hoplon (63)
- # jackdaw (1)
- # juxt (23)
- # london-clojurians (3)
- # meander (7)
- # off-topic (23)
- # om (1)
- # pathom (13)
- # pedestal (2)
- # perun (2)
- # re-frame (38)
- # reagent (3)
- # reitit (24)
- # shadow-cljs (91)
- # spacemacs (14)
- # sql (4)
- # tools-deps (8)
- # vim (3)
So what's the idiomatic way of breaking a non-toy Hoplon app into namespaces? Most of the examples I found involved a single namespace.
I just ported the realworld app (https://github.com/gothinkster/realworld) to both learn how Hoplon works and to contribute back with a "reference". Anyone willing to take a look at the code?
i think usually there's an entrypoint element that's basically a tabset, and namespaces follow from how that top level element is structured
this is one area where hoplon offers a lot of flexibility so i'm not sure there's one true approach
how about top level cells (state)? Should they live in a separate ns, like
myapp.state or within the
since the linkages between cells are usually automatic, explicit structure isn't required
I ended up doing everything in one single file, the entire 900 lines. haha. Doesn't look as bad as it sounds.
there can be a top-level state, usually it contains the route and info related to the URI
i'm sure it's awesome, maybe one of the greatest things about hoplon compared to other frameworks is you can do it all in a single file
Yeah, I tried to used scoped cells as much as I could so that most elements could be re-usable.
I only use global state for things that should be global, ideally state is scoped to a page or element
with element state you have the option of a local let scoped cell or passing one in via an attribute
I'm still going to clean this up, but here it is: https://gist.github.com/rlander/e971880d86ad8ccb665ab69a0eb731aa
this pattern lets you have local default state while also accepting external state for reusability
Are you guys interested in adding this to the canonical realworld repo? It's fully working (based on shadow-cljs and retiit router though).
I'm coming from many years of reagent and re-frame apps so maybe some of the code looks reagent-ish.
makes me wonder about a helper for nested divs like
(divs [["outer-class"] ["inner-class"]] ...inner-children) to compete for line count better
@alandipert hmm yeah, I didn't even try to reduce repetition and it's already besting the
re-frame implementation by ~150 lines. But yeah, that kind of helper would be useful!
Yesm with advanced on. Shadow-cljs has a report command that shows all dependencies by size.
not to suggest hoplon PR work for you 😉 , but i don't think anyone's ever written an experience report about that combo
something like this: https://gist.github.com/rlander/3081f3703ea9cfed3129e8afcc94bedb
They go really well together since through shadow-cljs I am free to use any JS lib that's in npm.
BTW, I only used shadow-cljs because I could not find recently updated boot template.
It's nice to know that it is flexible enough to work well with a build tool that didn't even exist when Hoplon was created, though.
As someone who's coming from years of React/Redux/reagent/re-frame, I really enjoyed working with Hoplon.
modern editors can split files into conceptually separate files with window-splitting technology
no concerns here. if it works for you, then it's idiomatic as far as we're concerned
i feel like this is maybe why people were always a little weary of hoplon, we never described (or prescribed...) any particular high level architecture in concrete terms
but that was supposed to be a feature, that the implementor would have full control there still