This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # adventofcode (82)
- # bangalore-clj (1)
- # beginners (44)
- # boot (7)
- # boot-dev (25)
- # cider (1)
- # cljs-dev (3)
- # cljsrn (14)
- # clojars (11)
- # clojure (210)
- # clojure-dusseldorf (4)
- # clojure-gamedev (2)
- # clojure-greece (11)
- # clojure-italy (6)
- # clojure-norway (6)
- # clojure-russia (6)
- # clojure-serbia (2)
- # clojure-spec (43)
- # clojure-sweden (1)
- # clojure-uk (77)
- # clojurescript (43)
- # cursive (1)
- # data-science (3)
- # datomic (32)
- # duct (3)
- # figwheel (2)
- # fulcro (71)
- # graphql (3)
- # hoplon (14)
- # jobs-discuss (3)
- # lambdaisland (1)
- # leiningen (2)
- # luminus (2)
- # lumo (14)
- # off-topic (16)
- # om-next (1)
- # perun (5)
- # random (1)
- # re-frame (19)
- # reagent (37)
- # ring-swagger (3)
- # shadow-cljs (157)
- # specter (6)
- # sql (29)
- # unrepl (14)
So this might be a little crazy, but is there a way to do node module loading from a node_modules directory for a nashorn interpreter? i.e. if I ran
npm install with a package.json to get all of the dependencies, there would be some shim that I could load and pass it the node_modules File object
I want to run some code that doesn't do a ton of IO, so I suspect that it'll work on nashorn without too much effort, but for various reasons I'm not thrilled out shelling out to a node process to get what I want
actually, this looks like exactly what I want: https://github.com/coveo/nashorn-commonjs-modules
Could someone help me understands it’s only my problem or they are common. in short, I have a small project on cljs under the nodejs with cider + figwheel. After build js bundle and the application starts, the REPL becoms very slow. Just evaluating single-line may takes up to 10 seconds, and the REPL periods simply die. sometimes i get a message - Figwheel: message from client couldn’t be read! clj and cljs versions 1.9 and 1.9.946.
I'm not a cljs expert; but it seems like this is hard for others to debug unless you ca npost a repo with your complete config
cljs.test/run-all-tests, how do I access the summary/result? The macro
run-tests-block cleans the
*current-env* before I have a chance to access it. How do other people do this?
For now I found a very hacky way:
(def summary (volatile! nil)) (defmethod test/report [::test/default :summary] [m] (vreset! summary m) (println "\nRan" (:test m) "tests containing" (+ (:pass m) (:fail m) (:error m)) "assertions.") (println (:fail m) "failures," (:error m) "errors."))
hello everyone, using cljs (reframe) how do I register a handler to the
Hi @plins there’s a #re-frame channel you may be interested in. I think the answer to your question is that reagent/re-frame often does not need as many of the React lifecycle events, due to the way the re-frame subscription model works.
I would like to clean parts of my application state (`db` in re-frame) when an user leaves the page (hits the back button, or, whatever)
Ok, I’d suggest posting that question in the #re-frame channel, you’ll probably get better answers than I could give you
I have the 2nd option working, and now i’m trying to publish the package, but the npm deps aren’t being included (just doing a local install for now)
the project user has to specify
:install-deps true so the
:npm-deps are installed properly. did you try that?
gotcha. and it has it defined in compiler options. will it need to be done in
I think this hasn't been documented anywhere. And personally I'm not fan of letting Cljs libraries to install npm packages, but at least it doesn't do anything with
I wonder if I could just publish the bundled package so
install-deps would only need to be run from the library
Bundled package? The processed JS modules and then using those as Closure libs? Might be possible, but would be quite a hack. And one benefit on npm-deps is that user can update those without repackaging things to Clojars or such.
Currently my favorite solution is for a library to default to Cljsjs foreign-libs but also support npm-deps if user decides to use those in application. This is how Reagent 0.8 will work.
Ya, that’s what I was referring to. With that solution, would the user need to manually add the dependent libraries?
If processed JS modules were packaged, no. But the output would depend on Closure-compiler version, and it is possible the processed JS wouldn't work with other Closure versions.
cool. I will have to investigate that as well b/c the idea of being able to update the libraries independently of a new library release is appealing.
quick question, when you said
And one benefit on npm-deps is that user can update those without repackaging things to Clojars or such. user here refers to a library consumer, right?
:npm-deps in application compiler-options will overwrite deps from libraries, so updating those will be easy compared to packaging processed JS
thanks! i guess one downside would be that there’s no guarantee your library would work with the specified version but I definitely see its appeal
just noticed I have this PR pending since march https://github.com/kawasima/fressian-cljs/pull/7 does no one maintain fressian-cljs? 😮