This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2017-06-09
Channels
- # beginners (121)
- # boot (28)
- # cider (106)
- # clara (57)
- # cljs-dev (70)
- # cljsrn (6)
- # clojure (145)
- # clojure-dev (7)
- # clojure-italy (36)
- # clojure-russia (42)
- # clojure-spec (26)
- # clojure-uk (127)
- # clojurescript (103)
- # core-async (10)
- # cursive (56)
- # datascript (66)
- # datomic (16)
- # defnpodcast (1)
- # emacs (18)
- # events (6)
- # figwheel (1)
- # jobs (1)
- # luminus (1)
- # lumo (44)
- # off-topic (58)
- # om (17)
- # onyx (2)
- # parinfer (75)
- # pedestal (4)
- # re-frame (18)
- # ring (4)
- # ring-swagger (8)
- # rum (7)
- # spacemacs (7)
- # specter (2)
- # sql (4)
- # unrepl (39)
- # untangled (17)
- # vim (3)
- # yada (21)
@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
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
@danielcompton yes you already explained that before 🙂
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
Will do
like that https://github.com/thheller/shadow-cljs/wiki/ClojureScript-for-the-browser#module-loader ?
currently exploring how webpack
does the dynamic loading. totally different implementation but makes some things a little easier
@thheller I just walked somebody through a complicated module split - no good reason not to support wildcards
yeah maybe .. thats why I mention webpack. they split async require.ensure
calls so you do not need to configure them
could maybe mess with (ns app.foo {:module/loader :lazy} ..)
or so and extract module configuration from that
related to async module loading would like to call across module boundaries w/o affect splits
webpack has since switched to an import function that returns a promise: import("./b").then(...)
@thheller well that was my point about returning a var, reference would be inside a method
shouldn’t work either with nested things since closure will collapse it to some$foo
anyways
the docs on the goog.module.ModuleManager are a bit light so its hard to tell how google intended the use
I suppose they expect you are using the global and look it up by the full name + ^:export
@mfikes not sure how I missed this but this is not working for me https://github.com/clojure/clojurescript/commit/4b68cf21f395f8ac2ba1a6425d7ed9fc8d9e4d1e
@dnolen that was my fault and was fixed in https://dev.clojure.org/jira/browse/CLJS-2071
which I guess can be closed now
Cool. I forget where the CI situation was. (Was it pending something that Alex was working through?)