@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

@onetom: Would you want to open a ticket since you can better articulate the issue?

@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

alandipert: have you checked your app without the when-dom? ours seems fine so far.

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.

@alandipert, @micha: guys, please remind your pure-javascript lib similar to javelin

@ul: perhaps you are thinking of https://github.com/adzerk-oss/splint.js

I am looking at splint right now. Would you mind explaining how splint-export differs from doing (def ^:export ...) ?

@nha: it has something to do with meeting the requirements of the javascript module formats, but i don't know more. it comes from mori, https://github.com/swannodette/mori/blob/master/src/mori/macros.clj#L19 on which splint is based

hm, ok i think it exports every arity of a cljs function

It looks like it has something to do with arity yes, but I am quite sure def ^:export works as well with different arities when called from javascript.

i am open to a PR if you're interested in simplifying it

the splint-export thing looks brittle and scary

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.

I'll keep it in the back of my mind

That could even be useful to export cljs.core to javascript (!)

But I'll ask on #C03S1L9DN what it does first. Thanks !

my pleasure!

everything works so nicely until you introduce mutation -_-

@alandipert: wouldn't javelin be a nice FRP library for clojure as well?

@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

@alandipert: are you saying it takes 100 lines to define the whole thing?

the runtime component, yes. iirc it uses the same macro as the cljs one for cell=

javelin cljs runtime is also very short

oh wait, it does have its own cell=

yeah i think the cljs version has acquired optimizations over the years that we never backported

like i know the latest cljs cell= is very conservative about creating new cells

@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

@nha: ah. we should remove it then

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

@martinklepsch: that's cool, thanks for sharing

@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

thanks for looking into it though

Well thanks for helping me satisfy my curiosity

my pleasure!

@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

@mynomoto: ping?

How do I access the cljs repl using boot on the hoplon demo projects?

@mangr3n: boot dev

this will show you a repl url

nREPL server started on port XXXXX on host 127.0.0.1 - <nrepl://127.0.0.1:XXXXX>

i personally use lighttable to then connect to the nrepl server

however i believe there are additional commands; cljs-repl start-repl

https://github.com/adzerk-oss/boot-cljs-repl

thanks, I'll do some more hacking around

@raywillig: pong

Hi. Is there a way to require hoplon.core in index.hl.cljs?

@andrewboltachev: all functions from hoplon.core are available on hl.cljs files by :refer. Is that what you want?

alandipert: nha: i find these kind of explanations very valuable when trying to understand others' code i've captured your conversation about splint-export here: https://github.com/adzerk-oss/splint.js/wiki/About-%60splint-export%60 just mentioning in case you want to anonymize it or something.

@andrewboltachev: u mean index.cljs.hl?

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 required in

@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

@mynomoto: anyway I did find it

@raywillig: the territory builder should be almost working 😉

Well I got it to compile but it blows up with max call stack error

The main problem is that it uses lots of things from the google-maps lib that I'm not familiar with.

Wow. I will check later but it was compiling the last time I tried.

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've been keeping them up with the alphas in my own space but .....

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.

mynomoto: wait a sec, u were also saying index.hl.cljs instead of index.cljs.hl is this some new convention i missed?