This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # admin-announcements (19)
- # alda (73)
- # announcements (1)
- # aws (16)
- # beginners (22)
- # boot (109)
- # cljs-dev (1)
- # clojure (79)
- # clojure-art (3)
- # clojure-czech (2)
- # clojure-russia (233)
- # clojure-sweden (2)
- # clojurescript (161)
- # clojurex (25)
- # core-async (2)
- # cursive (4)
- # datomic (11)
- # editors (17)
- # emacs (3)
- # funcool (4)
- # hoplon (72)
- # ldnclj (29)
- # off-topic (1)
- # om (9)
- # onyx (13)
- # reactive (10)
- # reagent (13)
- # yada (4)
@onetom: Just saw your messages, super valuable to know about. Thanks for sharing! Sorry to hear Hoplon's so tricky to use for multipage apps, but really glad to hear this may not always be the case: > i wouldn't recommend it just yet until we have a better model to handle the multipage app case Do you know if that's actually a priority for the 6.0.0 release? I looked in the tracker for a corresponding issue and couldn't find one, but maybe I missed it. If it's not there, I'd be happy to make a ticket if that'd help?
@jab: i don't think it's a priority, but since we are using it in production it might get better if i get frustrated enough with it
@onetom: however much it's worth that being able to prerender multipage sites was a main draw for me (some random guy looking for a better way to build web sites), it must be worth so much more that you're relying on this for your work
@jab: the current workaround is acceptable for 10-20pages so we are focusing on our webapp instead. Regarding the early initialization of GA u have a good point; it might distort our visitor stats. We have indeed experienced a significant drop in visitor numbers since we deployed this solution, but some of it might just be because of this measurement inaccuracy.
I might file an issue once I narrowed the scope. I the meantime I think your description is quite accurate.
I the meantime here is something completely different : https://github.com/exicon/hoplon-chart-examples
as i see it got into the code base with this commit: https://github.com/hoplon/hoplon/commit/99a99b523f72abc2af544515d233391ce7cb917f but i couldn't notice anything in the commit which would explain why was this funkier way of waiting for the element to be present in the dom being introduced.
I am looking at splint right now. Would you mind explaining how
splint-export differs from doing
(def ^:export ...) ?
It looks like it has something to do with arity yes, but I am quite sure
an even cooler but more ambitious project idea would be a boot task that packages the mori export machinery and lets one export any cljs namespace as a passable js module
Well I won't touch it before understanding it. But I kinda like the idea of a boot task that (selectively) exports a cljs namespace.
@xifi: could be, we have an experimental port at https://github.com/hoplon/javelin/blob/master/src/javelin/core_clj.clj
i've found cells most useful for ui programming, but neither micha nor i have done that in clj, so we never used it for anything
yeah i think the cljs version has acquired optimizations over the years that we never backported
@alandipert: after asking about that macro on #C03S1L9DN, it appears it creates functions with different arities for performance reasons : https://github.com/swannodette/mori/wiki/Benchmarking
at least in splint, it's much more important for it to be stable and to keep working with cljs that to be "performant" in some contrived sense
@alandipert: Well it shouldn’t break anything, it is kind of “opt-in” since you have to specify the arity (`method.f1`,
method.f2…). Your call of course.
a few bad experiences with cljs regressions brought on by premature optimization color my thinking
but i'm also loathe to change it because we use splint in our flagship UI which we're trying not to change much while we work on UI 2.0
so, i probably won't ever update the cljs version in splint anyway because it will never be used together with another cljs library... so i suppose we should probably just leave it
@alandipert: i like the sound of "main" as it's historic but usually i find that may cause false assumptions, main suggests a single primary entry, i suggest we use something which suggests less of a hierarchy
entry may be a bit more future proof as the landscape for multiple page apps in hoplon opens
@andrewboltachev: all functions from
hoplon.core are available on
hl.cljs files by
:refer. Is that what you want?
i find these kind of explanations very valuable when trying to understand others' code
i've captured your conversation about
just mentioning in case you want to anonymize it or something.
one major point of the
boot-hoplon task is to make hoplon inclusion painless, because in clojurescript you can not do :refer :all
(at least in the past you couldnt)
so if you want to use hoplon but don't want to create a "page", then you can just create a regular namespace within a
.cljs.hl file and hoplon will be
@mynomoto: hey was trying to figure out where the demos were so I could get territory builder up to date. It's really fubar lol. Might be a while
The main problem is that it uses lots of things from the google-maps lib that I'm not familiar with.
Yeah the google maps things need to be updated. I think I'm going to wait until hoplon 6 is release or at least rc
I did update the lib to get it working on alpha 10 and did a release, but not sure if it does everything it should.