This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-06
Channels
- # beginners (137)
- # cider (60)
- # cljs-dev (52)
- # cljsrn (5)
- # clojars (15)
- # clojure (156)
- # clojure-brasil (1)
- # clojure-dev (7)
- # clojure-italy (13)
- # clojure-serbia (2)
- # clojure-spec (12)
- # clojure-uk (76)
- # clojurescript (129)
- # core-async (27)
- # core-typed (1)
- # cursive (3)
- # datomic (105)
- # devcards (39)
- # emacs (10)
- # figwheel (1)
- # fulcro (68)
- # graphql (6)
- # juxt (3)
- # klipse (85)
- # lein-figwheel (47)
- # leiningen (3)
- # midje (1)
- # mount (26)
- # off-topic (71)
- # om (4)
- # overtone (4)
- # parinfer (3)
- # pedestal (4)
- # portkey (37)
- # re-frame (37)
- # reagent (13)
- # reitit (3)
- # ring (1)
- # rum (5)
- # shadow-cljs (191)
- # spacemacs (35)
- # specter (26)
- # tools-deps (45)
- # vim (20)
Unusual cases but might be worth considering regardless: using str
in an :advanced
build adds around 90K to the build over using goog/buildString
. I’m not sure these are API compatible but for people authoring JS libs in CLJS this is a high price and they are usually better of avoiding str
due to this.
Just using goog.string/buildString
in str
doesn’t change anything. (Tried with apply
and with a wrong impl that ignores varargs.)
Does this help? https://dev.clojure.org/jira/browse/CLJS-801
Str is a bit of a minefield https://dev.clojure.org/jira/browse/CLJS-890
oh wow, that’s a huge list of comments 😄
@martinklepsch that’s known problem but there’s really no way around it
@lee.justin.m ah JavaScript
the reason (I think) is because (1) strict javascript and non-strict javascript have mutually exclusive semantics, (2) es6 modules are, by definition, strict, so babel adds the strict mode to the top of the file during transpile
what don’t you buy? it’s absolutely possible to write strict-mode javascript that will not run correctly in non-strict mode
@lee.justin.m hrm that’s news to me, I haven’t followed changes to strict-mode
take a look at the section “Strict mode for scripts” here https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Strict_mode
let me see if i can think of an example. given that nonstrict mode hoists variables and doesn’t have lexical scope in some places, i’d think that would break it.
it’s crazy that I can’t find anything that says that definitively. js is so annoying sometimes
you won’t be able to find anything (I’m pretty sure) - I looked into this years ago and I came up empty
@juhoteperi I thought you were testing with React 16 though, you never ran into @symfrog’s issues?
@dnolen No, never seen it
well in anycase, I suspect it can’t be safe anyhow (to not do anything about it as we are currently) - and other build tools have reacted
the strongest argument that it is safe to remove “use strict” is the fact that it is written as a string: it is designed to be ignored by older browsers.
Does the problem only happen with :modules
? I don't use that
okay just to be pendantic: it is clear that you can write code that operates differently under non-strict mode by specifically catching an error strict mode is designed to catch. e.g.
try {
bar = 345;
} catch (e) {
console.log("error");
}
But the question is whether anybody could reasonably expect this behavior. I think @dnolen you’re probably right because stripping seems to be commonNumber.prototype.thisType = function () {return typeof this;}
ƒ () {return typeof this;}
Number.prototype.thisTypeStrict = function () {'use strict'; return typeof this;}
ƒ () {'use strict'; return typeof this;}
(1).thisType()
"object"
(1).thisTypeStrict()
"number"
that's the only diff I am aware of where strict to non-strict weakening could create exceptions that wouldn't exist otherwise
@dnolen The Closure ModuleLoader fetches a module and passes the module's js to eval
. Strict mode changes the behavior of eval
with regard to variable and function definitions:
Strict mode eval code cannot instantiate variables or functions in the variable environment of the caller to eval. Instead, a new variable environment is created and that environment is used for declaration binding instantiation for the eval code
https://tc39.github.io/ecma262@dnolen It matters because a global "use strict" directive applies also to the js generated from the definitions in the ClojureScript namespaces in the module. Since strict mode modifies the behavior of eval
the ClojureScript definitions are also not available to the module that triggered the load of the target module, making it impossible to resolve a definition in the target module and leading to my error Uncaught TypeError: Cannot read property '$cljs$core$IFn$_invoke$arity$0$' of null
when attempting to invoke the target function.
hmmm, when a directory is supplied to cljs.build.api/inputs
is as empty directory it fails with a Could not write JavaScript nil
error message.
@symfrog https://dev.clojure.org/jira/browse/CLJS-2768, I’ve closed the other issue