Clojurians
#cljs-dev
<
2017-06-09
>

This page is not created by, affiliated with, or supported by Slack Technologies, Inc.

dnolen05:06:46

@danielcompton it’s noted in 1.9.456 as a fix, I don’t have any strong opinions about this at all - if you have something you want to see done, describe it

danielcompton06:06:39

In versions prior to CLJS 1.9.456, seqable? tested only for the ISeqable protocol, i.e. collections. In CLJS-1875, released as part of 1.9.456 it now tests for anything that you can call seq on. This matches the behaviour of the seqable? function in Clojure that was recently added for 1.9, but was a breaking change in behaviour for ClojureScript. In concrete terms, this means that strings and arrays that previously tested false for seqable? will now test true. In 1.9.229 cljs.user=> (seqable? [:a :b :c]) true cljs.user=> (seqable? {:a :b :c :d}) true cljs.user=> (seqable? "abcd") false cljs.user=> (seqable? (into-array [:a :b :c])) false In 1.9.456 and beyond cljs.user=> (seqable? [:a :b :c]) true cljs.user=> (seqable? {:a :b :c :d}) true cljs.user=> (seqable? "abcd") true cljs.user=> (seqable? (into-array [:a :b :c])) true

dnolen06:06:49

@danielcompton yes you already explained that before :slightly_smiling_face:

dnolen06:06:42

my point is what do want the notes to say? submit a patch if all you want to add to do is move that line to changes instead of fixes with a note that’s breaking for code that depended on the old behavior

dnolen16:06:37

hrm I’m thinking :modules should support wildcards

dnolen16:06:02

also :module-loader option to auto-generate a global loader

thheller17:06:35

not sure about the wildcard

thheller17:06:59

currently exploring how webpack does the dynamic loading. totally different implementation but makes some things a little easier

dnolen17:06:39

@thheller I just walked somebody through a complicated module split - no good reason not to support wildcards

thheller17:06:29

yeah maybe .. thats why I mention webpack. they split async require.ensure calls so you do not need to configure them

thheller17:06:45

PITA in other situations though

thheller17:06:07

could maybe mess with (ns app.foo {:module/loader :lazy} ..) or so and extract module configuration from that

dnolen17:06:35

everytime I look at webpack I am not inspired

dnolen17:06:00

related to async module loading would like to call across module boundaries w/o affect splits

thheller17:06:31

yeah that is the issue with splits in closure

thheller17:06:45

if a loads b the a can’t call functions of b

dnolen17:06:49

so now ready for resolve

thheller17:06:51

since it doesn’t know about it

dnolen17:06:11

yes we can do this with a resolve macro easily

thheller17:06:37

webpack does require.ensure(["./b"], callback) so the callback can use b

rgdelato17:06:21

webpack has since switched to an import function that returns a promise: import("./b").then(...)

thheller17:06:35

@rgdelato same thing stilll

rgdelato17:06:42

yeah, it is, but slightly less yuck

thheller17:06:51

@dnolen you can’t actually resolve something though

thheller17:06:07

needs some kind of dynamic lookup even for :advanced

dnolen17:06:13

@thheller you do not

dnolen17:06:32

read the ticket

thheller17:06:37

if the closure compiler finds a call to app.b.thing() in app.a it will complain

dnolen17:06:46

it’s not a real resolve

dnolen17:06:56

it’s just macro which throws if not yet defined

dnolen17:06:00

but returns var if defined

dnolen17:06:04

advanced compilation safe

thheller17:06:46

doesn’t change what I’m saying

dnolen17:06:24

@thheller oh Closure complains about calls across module boundaries?

dnolen17:06:28

sorry that news to me

thheller17:06:59

well it might work if its a nested var

dnolen17:06:34

ok well worth trying but low priority

thheller17:06:39

yeah I might try the nested thing

dnolen17:06:22

@thheller well that was my point about returning a var, reference would be inside a method

thheller17:06:36

the thing I tested couldn’t call some.foo when some was defined in another module

thheller17:06:17

shouldn’t work either with nested things since closure will collapse it to some$foo anyways

dnolen17:06:41

well should check, can close ticket if discover can’t work

thheller17:06:30

the docs on the goog.module.ModuleManager are a bit light so its hard to tell how google intended the use

thheller17:06:44

loading code is easy but there is no mention of actually calling it

thheller17:06:54

I suppose they expect you are using the global and look it up by the full name + ^:export

thheller17:06:33

ok, quick test showed that it doesn’t complain. should be easy then

dnolen17:06:20

@thheller sweet

anmonteiro17:06:10

@dnolen that was my fault and was fixed in https://dev.clojure.org/jira/browse/CLJS-2071

anmonteiro17:06:16

which I guess can be closed now

mfikes17:06:57

Cool. I forget where the CI situation was. (Was it pending something that Alex was working through?)

mfikes17:06:09

(I'm willing to help set it up.)

thheller17:06:54

(-> (loader/load "c")
    (.then #(code-split.c/in-c "from-a")))

thheller17:06:13

this just works :slightly_smiling_face:

thheller18:06:31

don’t even need to export anything

dnolen18:06:11

fantastic, that’s what I was hoping for

mfikes18:06:58

I think I’ll work on an independent CI system for the compiler and it pans out and proves useful, the learnings / associated scripts can be considered for something more formal / official.

dnolen18:06:06

@mfikes that would rock