This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # aws-lambda (21)
- # beginners (8)
- # boot (67)
- # braveandtrue (2)
- # cider (12)
- # cljs-dev (38)
- # cljsjs (87)
- # cljsrn (11)
- # clojure (307)
- # clojure-austin (29)
- # clojure-finland (1)
- # clojure-italy (9)
- # clojure-russia (19)
- # clojure-spec (71)
- # clojure-uk (33)
- # clojurescript (109)
- # clojutre (1)
- # core-async (2)
- # cursive (24)
- # datomic (11)
- # devops (5)
- # ethereum (5)
- # figwheel (2)
- # hoplon (25)
- # ipfs (1)
- # jobs (1)
- # luminus (17)
- # off-topic (1)
- # om (38)
- # om-next (3)
- # onyx (166)
- # other-lisps (1)
- # proton (5)
- # re-frame (15)
- # reagent (45)
- # ring (2)
- # spacemacs (6)
- # specter (12)
- # untangled (58)
- # yada (23)
has anyone used zxcvbn (https://github.com/dropbox/zxcvbn) with CLJS ? Does not appear to be packaged on CLJSJS ?
@superstructor Haven't used it but PRs are welcome for cljsjs. You only need externs when you use advanced compilation.
@superstructor yeah, like @kenny said, you only need externs if you’re going to do advanced compilation. another idea would be to include the
If I refer to a record in a different namespace, I seem to not to be able to use
map->MyRecord directly unless I namespace it like
other-namespace/map->MyRecord. Is that correct?
import is just for Google Closure constructors - using it to bring in JS types is not really idiomatic in CLJS
@nidu: if you just need it under debug and elide it otherwise, you can use
if you need general solution also for advanced mode, look into
:modules isn’t really about loading modules though, we should be clear about that
(you can use
:main in your build to control which namespace you get as your entry point)
ohh, this way. I wanted to argue that this dev namespace should also be required conditionally, but i should just change an entry point. Thanks!
The files that optimization none creates seems to split into "needs serving" (goog.base.js or something) and "needed for compilation" (e.g. cljc files) is there any way to separate the two with a config?
@nidu, as a side note, I prefer to use macros for conditional code,
js/goog.DEBUG sounds like a good idea at first, but it needs careful treatment:
to know if you are under :advanced mode, your macro could do something like this: https://github.com/binaryage/cljs-oops/blob/4e78df2b41254f3d669b86cc12cdfedad1f2ec74/src/lib/oops/config.clj#L28-L30
@darwin my case is about devtools as well but i've got compiler error that
devtools.core is not found because it's only in dev dependencies.
So it's not even about dead code elimination (though that would be the next case anyway)
This option actually looks pretty. I'll prefer its simplicity to build configuration. At least this time. Thanks!
Suddenly this gives another fancy error message:
required "devtools.core" namespace never provided goog.require("devtools.core");
@nidu: Have you looked at how the devcards template works? It seems like a problem that shouldn't be happening unless there's something weird with your config.
wow, i didn't know i can omit :main. But the point here is that i don't want devtools.core to be bundled
@nidu devtools code will be removed by closure compiler under advanced builds via dead-code-elimination
the drawback of this approach is that you must not specify :main, which you probably want to do, to give your app an entry point and tell closure compiler which namespace is the starting point for DCE
why don’t you want to use
:preloads? and configure your advanced and none builds differently
@nidu: Maybe ignore me, I read
devcards - repeatedly. No devtools in the devcards template. Going to step away from the computer before I screw up something important 🙂
@darwin quick search for :preloads at sample.project.clj of lein-cljsbuild didn't give results, but i guess i should search in some other places. I have different builds for dev and prod. Pretty sure the problem is incorrect config. Currently i'm poking around with approach with different entry points.
and cljs-devtools-sample uses preloads to give a real example: https://github.com/binaryage/cljs-devtools-sample/blob/master/project.clj#L43
@dnolen: the cljc files created during compilation are put into a directory next to the js files that I need to serve. I need to keep them separate
it’s not important for production that this happens, since you’ll generally be producing only a single JS file then
@dnolen: I think it was done for uberjars. I'm not sure what the other methods to serve are though.
@dnolen: how would you suggest I serve in dev? That's the part I don't really get I think.
but generally when you serve resources - you just put
resources/public on the classpath
@dominicm What was this in relation to? Cljc files written by Cljs breaking tools.namespace?
@darwin thanks for helping with configuration, unfortunately i have to postpone solution of this subtle problem
it’s now Russian Roulette as to what you will get when ClojureScript tries to load something
Right, Cljs compiler has problems if the output-dir is directly part of classpath, but Cljs compiler doesn't have problem if the files are under a prefix in classpath? Do I still follow?
Okay, tools.namespace has a different problem. It will try to load the files even from prefix (e.g. public/js/out/foo.cljc under classpath, even if the ns is just
Is this just a tools.namespace bug? I've been trying to think about configuration that would prevent this but thus far only solution has been to manually tell tools.namespace to ignore the specific dir or namespaces.
I believe there was a conversation here a while back about how people are testing clojurescript applications, I wrote a blog post about how we're doing it on our project if anybody is interested: http://tech.adstage.io/2016/09/12/how-we-test-full-stack-clojure.html
C.t.n now does find all modified files in directories that are part of classpath, then it will read ns forms from all those files and will reload all those ns
@juhoteperi: yeah, that's my underlying problem here. Figured I'd try a new angle on the solution.
@dnolen: I think I understand your recommendations now, and why they don't work for me here. Miscommunication!
Another question is that why reloading these library ns breaks the Clojure env. IIRC Sente is one of the problematic libraries.
@juhoteperi: bidi breaks, component is reported to. Its because they don't get reloaded as part of the namespace dependency hierarchy, but as a new top level, and then their protocols, or one of the other parts of the clojure global state, is blown away.