So, it seems that the callback for cljs.loader/load does not get called unless you remember to require cljs.loader in the namespace that is getting loaded, even though that namespace doesn’t use it. Is this expected, and if so, I think this should be added to the docs.

expected, and I think it’s in the guide?

perhaps it’s not

@tony.kay feel free to PR the website https://github.com/clojure/clojurescript-site

Cool. It is in the code, but you could easily overlook it as cruft

people require things all the time that aren’t needed

@anmonteiro Do you not end up with the same singleton or something? It was very surprising to me, and I’m not exactly a beginner.

I don’t understand the question

can you clarify?

do you mean the moduleManager thing?

I don’t understand why it is necessary to require cljs.loader in a namespace that does not use it. Obviously it causes a dep graph to complete (though it would seem to me that the module config should be able to supply that needed fact)

if a namespace should be loaded as a module it needs to require the loader

otherwise you can not require it

Bad developer experience 🙂 Why can’t the compiler just figure that out from the module configs?

TBH I don’t recall the exact reason

but I remember David mentioning there’s one

I think in some advanced cases you may want to manage the loading yourself

and injecting the loader would prevent that

^ but I’m not sure about this

Well, I’ve spent several hours banging my head on module loading problems. I think I’ve finally got it, but subtle things like that are the kind of thing that lead people to try Clojurescript and just give up because the experience sucks.

The code looks simple enough. Nice and trivial. You read the docs and think: yeah! I want that. Then spend a day hitting problems.

I guess js-land sucks too 😜

glad you figured it out

there’s definitely space for improvement with regards to docs and developer experience

@tony.kay I would suggest starting a discussion about this on the website repo

I’ll send a PR with some additions to the guide

that too

thanks for the help

np

@anmonteiro Is the compiler supposed to walk the dep graph for a module, or are we always supposed to list all ns explicitly in the config?

I assume the former

the former

Yeah, I had to do the latter because of some dynamic resolution that the compiler couldn’t see

any suggestions on how to shim fs and path for node modules in the browser?

i have the same exact issue as here https://dev.clojure.org/jira/browse/CLJS-2290?focusedCommentId=46576&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-46576

only that in my case my target is not :nodejs

and for me it's not assert but fs and path that is required by the third party module

@ashnur if in your case target is not :nodejs why are you trying to require fs or path?

@anmonteiro it's not me who is trying, but an npm module.

so that module may not be suitable to work in a browser

@anmonteiro that's why i was asking how to shim these. like with browserify or something

I don’t know, maybe you need to bundle it with Webpack or browserify

or require only certain files that don’t need fs?

i've been using browserify for many many years now so i am not used to check if a module is written for node or browser, it just works:tm:

🙂

i am assuming - perhaps incorrectly - that pre bundling some js files and loading them will not give me the same optimizations that i might get now using only :npm-deps

correct

thanks for the help @anmonteiro!

Hi folks! I have the above code snippet which I use to log in via Facebook. As you can see this is async javascript code ported over to clojurescript. What would be the changes that would make the code more idiomatic?

I am looking into core.async channels, however I don’t quite understand how to use them here.

Honestly the snippet looks fine to me - hard to improve upon

Don't introduce core.async just because you can

IMO it should be used only when other alternatives have been shown to have real problems in your code, problems which require core.async's primitives, like channels

Thanks @pesterhazy!

Is this a bug? Wrong number of args (-1) passed to: macros/session*/fn--57416

And should the error not surface when the parameters of the function are (`[& args]`)?

oke am i doing something wrong? ajax.cljs post to server and when i use :body it's #object[java.io.ByteArrayInputStream 0x5aec0e6e java.io.ByteArrayInputStream@5aec0e6e] is that normal ? what do i do now?

@alex-dixon that means that you somehow got hand of a macro without the metadata indicating it's a macro, so that it got called like a function

this can happen when you use the var of a macro

what happens is that when a function has :macro true in it's metadata map the clojure compiler adds two args to the beginning of the arg list, &env and &form representing local bindings and the raw form of the macro invocation, then it captures the result of calling the macro, then compiles the output of the macro

Well. Apparently I just realized I don’t know how to use alter-meta!. And still don’t

so, if you call a macro that doesn't have that metadata on it, you end up with a "negative argument count"

Calling it from a cljs repl on an interned var free of macros doesn’t seem to be working how I expected

Oh

because a macro with two args is really called with 0 args, etc.

oh wow even with the deref I am getting the correct 0, hmm...

😕

I’ve passed the amount of time I told myself I would spend on this but…

(def ^{:cool true} foo "hey")
(var foo)
(alter-meta! (var foo) merge {:cool "yes"})
(println "Foo meta" (meta (var foo)))
=> Foo meta {:cool true, :ns precept.app-ns, :name foo, :file /Users/alexdixon/precept/test/macros/cljs/precept/app_ns.cljs, :end-column 23, :column 1, :line 61, :end-line 61, :arglists (), :doc nil, :test nil}

Would expect :cool to be “yes”…what am I missing?

@alex-dixon that code would work in jvm clojure...

(just tested it)

Yeah…

Just updated to 854 which should be the latest and getting the same behavior

well I believe merge takes the value of the left argument in the event of a keyword collision

no

woops nvm

like I said, that code works correctly in clj - merge goes with rightmost

@gcast the easy way to remember is that for many vararg clojure functions, (f a b c) is the same as (f (f a b) c) - thus it needs to prefer the rightmost arg (see for example str, *, -, /, or, and, conj)

ahh because they are reducers?

right - even if not written with reduce (which most of them are), they keep that semantic

cool. thanks

@tony.kay certainly nothing is final wrt. the behavior of cljs.loader, but my assumption was that people would commonly use the loader via routing, in that case you never know which thing will load which thing - so you would include the loader in every entry point anyway

@tony.kay also if that was a significant time sink (I’m also curious what else you hit), then we should talk about that more.

it would be pretty simple to warn on attempting to load a module that doesn’t require cljs.loader

there an equivalent to jquery’s document ready? I have some JS loaded with an async tag and I can’t depend on the script loading before the DOM so goog events DOMCONTENTLOADED is not an option

Is anyone here in the habit of clojure-spec-ing their app states? How thorough do you tend to go with the specs? Every bit of the structure or just the leafs?

Anyone here using mach? https://github.com/juxt/mach

I have this weird problem. Reagent is rendering"Hello World" -- yet that string appears no where in my html / clj / cljs files.

(set! (.-onload js/window)
        (fn [& rst]
          (. js/console log "onload window called")
          (init)))

resolved -- problem was elsewhere, above code worked fine for setting onload

@dnolen I would think you’d only include cljs.loader in those things that actually call it. Routing is exactly what I was building, and the “leaves” never need to load anything else. Thus, my callback not getting called when those were loaded just left me scratching my head and thinking I’d made some “silly” typo or mistake. The other thing I hit was related to using it in devcards or perhaps because I am building a reusable routing component. I am not sure exactly why I had to add so much to :entries. It could be that because I’m triggering the routing through an Om mutation that it could not figure out the dependency graph info? The namespace for routing was required, but the routing namespace wasn’t known when it tried to look up “loader”. My suspicion was that the compiler couldn’t analyze the dependency graph from the requires, but I didn’t understand how that works very well from the documentation. I expected to be able to add my “entry points” for the modules to the config and have the rest derived, but I had to add a lot more to :entries than I expected, and I had to essentially tinker until I figured that out. I still would have expected it to work. Perhaps that is a bug? The cljsbuild config that worked is: https://github.com/fulcrologic/fulcro/blob/develop/src/main/fulcro/client/routing.cljc#L297 :main in my case is the main route that is dynamically loaded. But I had to explicitly add the routing namespace to the :entries (which is where the call to load comes from…through an Om mutation). I was expecting that to get picked up through requires (the namespace that triggers the mutation requires the routing namespace). I’m gathering now that perhaps the analysis works by looking for just requires of cljs.loader? The documentation led me to believe that loader was just a utility component to triggering/tracking loads. It was not clear to me that it was more (e.g. something used by the analyzer?).

@tony.kay you also don’t seem aware how the undelrying thing works 🙂

I highly recommend picking up Closure: The Definitive Guide

anyways the point is fundamentally you must require cljs.loader if you going to be loaded by cljs.loader because you must call set-loaded!

whatever you may think is going on is not so relevant

it’s just how goog.module.ModuleLoader works period

I opened https://dev.clojure.org/jira/browse/CLJS-2320

When I’ve written module code before, you had to add something to the namespace to trigger the event that signaled completion.

yes

set-loaded!

but you can’t even call that

without requiring cljs.loader first

but is that automatic now?

so obviously you must require it

in anyplace that will be loaded

but I agree this isn’t intuitive

because people are not reading the docs first

and I agree that’s not unexpected

so a warning

set-loaded! is only called for you if you require cljs.loader

it’s added to the end of the file that required cljs.loader

Right, which is magic. I was complaining about the docs more than anything 🙂

docs will only help so much

I’d rather see an explicit requirement for set-loaded! than no docs on magic

I agree we should say something about it

but the simpler thing is to just warn and tell you what to do

wanrings end up in the console with lots of other messages .Certainly helpful. Clear comment in the docs that is needed are good too

but the docs will only make partial sense is what I’m saying

you must read Closure docs to actually understand

so I’m not sold on doing much in the docs

other than “RTFM” because it’s gonna take too long to repeat it all over again

The thing is code flow: I, as a developer, would understand an explicit call to set-loaded! as a requirement for the callback to trigger. It is a traceable code path. A require is for library loading. Overloading it to augment your code with a hidden action is not remotely expected.

or we could just remove the magic stuff

and then you go figure it out on your own

I would honestly prefer that

because then the docs would show it being called in an example

but everyone would spend even more time than you did

I disagree

all of this could have been avoided

by actually reading the original docs

@tony.kay you can disagree but this has already come up multiple times

it’s not your like the first person to bring this up

and I couldn’t even figure it out myself

without reading the Closure book

the source code is not forthcoming

which is to separate your personal frustration from something that should work for people that aren’t going to read docs

I’m disagreeing because had your guide set set-loaded! at the bottom of a source file I would have not hit an issue

but people can forget to do that

and then what?

I’m wanting something that works when you read the docs. I don’t give a rats ass if people cause themselves problems by not reading anything. I read your guide. One simple comment about set-loaded would have kept me from having any problems. And I’ve written module loading before with Closure.

anyways I’m not going to listen to (only one) personal anecdotes 🙂

your feedback has been heard

first step is adding the warning

and then collect more feedback

nothing is set in stone, it’s a new feature

That will probably do it. I understood there was “magic” going on somewhere. I just didn’t realize it was in the require.

some of this is because implementation details

a desire to make it easy w/o actually having to write a whole bunch of injection code

which I’m totally uninterested in

@tony.kay but thanks for trying it and wading through it, the feedback is in fact very welcome

And thank you for working on it. It’s a big improvement.

Fulcro now has a completely dynamic UI routing system with module loading integration…and it is about to have automatic i18n locale loading.

So your efforts are not lost on me 🙂

cool 😄

@dnolen So am I right in saying that, in order to call load a namespace must be explicitly listed in a module in the compiler config’s :entries ( it cannot just be derived by the require graph)?

@tony.kay I don’t know what you’re saying

you can’t load namespaces

just modules

I understand that.

Say I have namespace A, and it wants to load module :m

If I don’t put namespace A into an explicit module in compiler config, then loaded is unset when it calls the load for :m

and it crashes

even though an entry point that requires A is in a module

My understanding was that the compiler would derive all the stuff needed for a module through the require graph

you’re talking about too many different things for me to understand anything at all 🙂

😕

set the compiler stuff aside

just focus on the first statement

Concrete: namespace “router” is a namespace that loads various modules. The module name is given to it by parameter. Thus, it might load any number of modules. When you call the load macro, it tries to derive the module that you’re loading from. Right so far?

I don’t care about routing

and I don’t want to talk about it

all I care about is the semantics of loading

ok

I’m jsut trying to give you an example that makes it easy to talk about

it’s not making it any easier 🙂

ok

so hold on

you may be talking about a reason to get rid of the magic set-loaded! call is why

nope

unrelated

no

just listen

ok

and don’t jump to any conclusions

so first question - why would A need to load if it’s not an entry point?

it is a namespace within the namespaces of the entry point.

but what is rationale for not loading from one place

I am just asking a simple question

composition of libraries

one of the namespaces is a reusable library component whose task is to load things (e.g. routing)

another library element loads locales (i18n). Separate concern. Separate library even.

ok but then doesn’t it sound like appending set-loaded! for you when you require cljs.loader a problem? It does to me

generic thing doesn’t know the module is loaded, only you do

I assumed set-loaded was idempotent…once the thing is loaded it doesn’t hurt for it to be called

it is idempotent … but it might not be true the module is actually loaded (if there are multiple entries)

oh, I see

one namespace calls it, but some others aren’t there yet

yes

possible overlap

so this makes me feel like the magic set-loaded! thing is just broken

and really we should leave this to users

that could explain some of the strangeness I’m seeing

I was assuming it was in the derivation of what module things went with in the dependency graph.

but cljs_base is a likely place for things

without the the magic set-loaded! thing, cljs.loader becomes a fully generic useful programmable thing

it also means the other requirement goes away

no more unused cljs.loader for entries that are only going to be loaded

so, I have a question: what is required in :entries now? Just the entry point of a module, or everything you want to try to force to be in that module.

yeah different topic, but OK

I mean, it will move it up if needed by more than one.

:entries is just about pinning something to a module

related topic. I have an idea, but I need to be clear on intentions

it should not move

if it needs to move you made a mistake

and never should have put it there in the first place

:entries should only be exactly what you want where

ok, so what can’t you use that to add the magic?

everything else should be left to the compiler

@tony.kay cannot

there is no required dep order for :entries

they may all be leaves

so only the user knows which one should call set-loaded!

but if it is idempotent, can’t they all?

no

because don’t know which one matters

no idea what your app is doing

problem with leaf nodes is they often have side effects at the top level

no way to understand that stuff

ok, I trust you on that. My naive understanding.

so I’m leaning towards just removing the magic

then cljs.loader becomes a normal tool

That’s too bad. The magic would be nice 😉

Could also add an additional compiler config entry to indicate exactly which namespace is the rep for the module

I just don’t see how to reconcile it programmability

customizing loading seems too valuable

@tony.kay more compiler config for this is not desirable

yeah, I tend to agree

just brainstorming

yeah I just think the ease stuff actually gets in the way of composability

and writing useful stuff on top of cljs.loader is impossible with current design

that seems like a huge flaw

It has felt a little “eye of toad, blood of goat” so far 😜

yeah

So, one more possible problem: pinning to a module. Is it true you must pin something to a module if it is going to call load? I.e. that ns cannot end up in cljs_base?

or rather, it must at least have a known named module

if it ends up in base, that is a separate matter I guess

https://dev.clojure.org/jira/browse/CLJS-2321

@tony.kay no, if we fix 2321, you can call load whenever you want

as long as that calling module has called set-loaded! itself of course

ok. I was seeing an issue where I was having to pin my router to a module, even though it was acceptable to be in base

oh so there is a related problem here

oh, I see. So the router is going to have to be in an explicit module in the compiler config

which is that we never actually call set-loaded! on :cljs-base

yep

instead what we do is that when you call set-loaded! on your own module

then we ensure all parent modules have set-loaded! called on them

but we need to be very careful here

code splitting, and cljs.loader are two completely independent features

you can use the former w/o the later

and having the later bleed into the former is undesirable

That was the root of my confusion. I didn’t see how you could implement the latter well without it bleeding into the former…so I was assuming it was part of it.

it’s just not going to happen

so take that as a base assumption

ok, then magic is out 🙂

exactly

that was part of the reason I didn’t dig into the source…I assumed it was a mountain of madness of dep resolution 🙂

no not at all

module loading is really dumb

nothing happens at runtime

we compute the module graph at compile time

IIRC the magic wasn't there to start with, right? It was only added after some discussion

yeah, shadow-cljs does some stuff here, but perhaps it can work around these issues w/ injection

but I don’t want to do that, and the ease stuff just is getting in the way

The entries form the root set of a DAG, though, right?

nvm. still thinking about the magic, and I agree it is better just to have explicit calls to set-loaded!

yeah

the problems and complications just disappear

once again Hickey was right

I added a comment in CLJS-2321

not sure about the cljs_base issues, but it might be as easy as reverting CLJS-2157

@anmonteiro yeah that’s what I was looking at - thanks for adding the comment

@tony.kay the magic that remains which is probably what you’re getting at is that cljs.loader will remain a magic ns

we insert the module graph into that ns when we compile that ns

and that ns is marked dirty whenever the module graph changes

Cool. And you see a resolution for the cljs_base library problem?

@tony.kay I don’t really see the problem anymore

https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/loader.clj#L19

it’s not a entry point, it should not load at the top level

loader will be nil

library code that ends up in cljs_base will have a problem

that stuff will probably be removed

oh, ok

basically walking backwards from all this easy stuff

and simply just thin layer over moduleloader + module graph injection

people must read the docs

And a library author will have to tell ppl to explicitly place certain namespaces into a module (those that call load)

I don’t see why

I thought those ns’s that call load have to call set-loaded

they do not

cljs.loader has the module graph

they’ve already called set-loaded!

oh right

got it

yeah once everybody reads the docs

then writing composable stuff on the base assumptions just falls out

well, I’ll be glad to test it when you’re ready 🙂

happy to do so against master before release

great thanks

yeah this was super helpful

definitely needs to be in the next release

@tony.kay removed automatic set-loaded! calls from master

if you have time to test that would be great

I’ve left the module loader assertion alone, seems to me that should be fine - but maybe you’ll demonstrate otherwise

I’d like to cut a release tomorrow, gotta head out for now but I will check back in later

@dnolen that was fast. I’ll take a look.

@dnolen OK, I tested it out. The explicit calls to set-loaded! work fine, as I’d expect. When I use figwheel, it does throw an exception, but even then it does work. I suspect figwheel is going to need a little tweak. The exception, for general interest was:

ioc_helpers.cljs?rel=1502666299392:42 Uncaught TypeError: goog.net.jsloader.load is not a function
  4     at figwheel$client$file_reloading$reload_file_in_html_env (file_reloading.cljs?rel=1502666284269:208)
  5     at figwheel$client$file_reloading$reload_file (file_reloading.cljs?rel=1502666284269:250)
  6     at figwheel$client$file_reloading$blocking_load (file_reloading.cljs?rel=1502666284269:269)
  7     at file_reloading.cljs?rel=1502666284269:279
  8     at file_reloading.cljs?rel=1502666284269:277
  9     at figwheel$client$file_reloading$state_machine__54034__auto____1 (file_reloading.cljs?rel=1502666284269:277)
 10     at figwheel$client$file_reloading$state_machine__54034__auto__ (file_reloading.cljs?rel=1502666284269:277)
 11     at cljs$core$async$impl$ioc_helpers$run_state_machine (ioc_helpers.cljs?rel=1502666299392:35)
 12     at cljs$core$async$impl$ioc_helpers$run_state_machine_wrapped (ioc_helpers.cljs?rel=1502666299392:39)
 13     at ioc_helpers.cljs?rel=1502666299392:48

^ this error message also looks a little strange

because the module name looks null

in Module does not exist

2 spaces where a name should be

I know. It should be the name of the loader namespace

or :cljs_base no?

https://github.com/clojure/clojurescript/blob/master/src/main/cljs/cljs/loader.clj#L19

ah

that tries to look up which module the ns is in, but L isn’t pinned, so it isn’t in one as far as the data structure is concerned

that’s why pinning it fixes the problem

that’s why I was referring to there being the need for some kind of “default” module that we know is loaded

oh yeah that totally makes sense

I don’t know if that’s supposed to work, but makes sense to me that it should

however, it does seem a little odd to me that library code would dictate split points

what do you mean?

the library isn’t dictating anything…it’s just ending up in base because it is used by things

but the library is calling cljs.loader/load!, no?

yes, it is.

right. that’s what I find might not be idiomatic, if there’s a word for it

shouldn’t it be up to application code to take care of loading?

It depends on who knows that is in cljs_base. If only Google Closure knows whats in base, then there’s nothing to be done. But if cljs builds that, then it does know what is in the base module.

and that could just be placed in the deps thing that is being generated for cljs.loader

it has to be cljs, though, because it works with opt none, right?

I guess there’s some distinction here of splitting vs loading that David was speaking of earlier that I’m not really getting yet

I think CLJS knows what’s in base

loading is standalone. It just loads things that are defined. It does, however, tried to load things in dependency order.

which is why there is an injected module info

it seems to me the lack of cljs_base being part of that story is a hole

it isn’t a module, but it sure is split code

right. In case it is supposed to work, there might be a bug here wrt cljs-base

there is the possibility that I’m msising something. What if L was placed into a module explicitly. In that case, it will work because that is the design (and you better do the proper calls to set-loaded!. But the assumption is that a caller of load should be in something that was already properly loaded…e.g. a module with an invocation of set-loaded!. But your 3rd party is the app writer using cljs AND a library L. For them, L is just going to end up in cljs_base. It would be nice if they can just use it, and an implicit set-loaded! has already happened for the cljs_base “preload”

otherwise your library author has to document what namespaces need to be pinned, and we then have a huge library dependency nightmare…I use a lib that uses a lib that uses a lib that needs to be pinned into a module to work

bleh

composition collapses into compiling things for 1990's Linux