This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-02-27
Channels
- # aleph (7)
- # beginners (80)
- # boot (1)
- # cider (3)
- # cljs-dev (277)
- # cljsjs (52)
- # cljsrn (1)
- # clojure (69)
- # clojure-gamedev (4)
- # clojure-italy (1)
- # clojure-losangeles (2)
- # clojure-russia (89)
- # clojure-spec (92)
- # clojure-uk (196)
- # clojured (1)
- # clojurescript (70)
- # cursive (5)
- # data-science (1)
- # datascript (84)
- # datomic (9)
- # defnpodcast (12)
- # docker (1)
- # emacs (4)
- # events (1)
- # fulcro (112)
- # graphql (1)
- # jobs (1)
- # lumo (1)
- # nrepl (21)
- # off-topic (2)
- # onyx (3)
- # protorepl (10)
- # re-frame (23)
- # reagent (66)
- # reitit (2)
- # rum (13)
- # shadow-cljs (144)
- # spacemacs (14)
- # sql (4)
- # unrepl (29)
- # vim (16)
Hello, I am looking for ways to compile my cljs as a node package. As reference, following the datascript
approach https://github.com/tonsky/datascript/tree/master/release-js , which builds the bare js version and then add the prefix and suffix, and append them at the top and bottom of the the bare js content. Just curious is any other aprroach which may be more straightforward?
I’m hoping that you folks can help me …. is there an idiomatic approach to integrate with JS libs that use ES7 async/await from CLJS?
@raymcdermott async/await is just syntax sugar around promises so you either .then
something you get from JS or hand it a promise
Hi all. I’m working on the first cljs app for our company, and I’ve run into a roadblock. I need to use 2 react components from npm. They currently do not have wrappers in cljsjs, and both online extern-generating tools have errored out saying ‘namespace not found’. I only know enough about external js libraries to have imported a few before that didn’t need any extra work. But I’m stuck now. Any suggestions?
@thheller true that it’s sugar over promise, so is your point that we can just ignore the fact that the libs use async/await?
@raymcdermott you can write a macro that solves that, I was trying to find here, but once I wrote a <!p
that works just like <!
but on JS promises (still need to be inside go
blocks)
(ns common-js.async
(:require [clojure.core.async :as async]))
(defmacro go-catch [& body]
`(cljs.core.async.macros/go
(try
~@body
(catch :default e e))))
#?(:cljs
(defn promise->chan [p]
(let [c (async/promise-chan)]
(.then p
#(async/put! c {:success %})
#(async/put! c {:error %}))
c)))
#?(:cljs
(defn consumer-pair [resp]
(if (contains? resp :error)
(throw (:error resp))
(:success resp))))
(defmacro <!p [promise]
`(consumer-pair (cljs.core.async/<! (promise->chan ~promise))))
@wilkerlucio remember everything is throwable in javascript, even undefined
, so your either implementation is brittle
@leonoel not sure what you mean, if you look at promise->chan
, the err
will only be present when the promise fails, otherwise will be nil, so the if
on consume-pair
will not throw, did you see something else I'm missing?
if an evil library returns a failed promise with a falsey value as error, your code will not propagate failure
then the library is doing it wrong doesn't it? I never had a case where a promisse error is not an actual error object, that seems a wrong implementation to me
I agree it would be unexpected, but it's allowed by both the language and the promise semantics, so nothing says it would be wrong
@leonoel ok, I can agree with that, updated it, what you think?
thanks for pointing it out
@jmckitrick make a foreign dep of those and try externs inference - also shadow-cljs appears to have a smoother story for integrating NPM stuff (`:npm-deps` is cool but requires a certain level of NPM semantics understanding / Closure Compiler expertise)
I place all my code in src
dir, some like this src/app/
(cljc), src/client/
(cljs), src/server/
(clj)
My cljs build is really slow, due it load all (not required's) namespaces from src/server
. There is how cljs build load just the required clojure or i will need to split in src-clj
/`src-cljs`/`src-cljc`?
shadow-cljs does a good there, it only loads things your code actually needs
I'm actually with figwhell for dev and cljsbuild to production shadow-cljs will replace just cljsbuild, right?
no, shadow-cljs is for dev too, so no figwheel or cljsbuild
I read in the ClojureScript cljs.test code:
A fixture is a map of one or two functions that run code before and
after tests. It looks like this:
{:before (fn []
Perform setup, establish bindings, whatever.
)
:after (fn []
Tear-down / clean-up code here.
)}
How can we add bindings
?
E.g., is it possible to add bindings around an fn?
(defn my-fixture [f]
(binding [*my-binding* 1]
(f)))
What would be the equivalant using the map with :before
and :after
?I see 🙂
Thanks
I am indeed trying to run an async test
I'm struggling quite a bit with getting the cljs compiler, DCE, and node modules ... I'm hoping someone can straighten me out, because I suspect my expectations are completely wrong... here's a minimal lein-cljsbuild test I'm trying https://gist.github.com/rgm/da7c0e814fb7482f3aa9741076eab34b ...
I put in the commented-out react-router bits just to see what happens to code I don't use ... I'd expect the size of app.min.js
not to change at all. (BTW node app.min.js
will spit out a hello-world div as expected).
(btw is there a canonical doc somewhere for doing this with lein? The feature sounds exciting but with so much of the knowledge about it being folkloric it's a bit discouraging).
but DCE isn’t magic - if the JS library does something overly dynamic, it’s not going to work
so philosophically it seems like I'm good on my build plumbing, and I'm best to move my exploration/experimentation to understanding the patterns around JS packaging?
another thing (of the many, sadly) that I'm fuzzy on: removing cljsjs/react etc. from the project :dependencies
doesn't seem to cause grief around externs ... is this being inferred?
@rgm React uses some dynamic properties, so externs are required (but it has been a few months since I last tested this, don't know about latest React)
But you can require the cljsjs packages in the project, node_modules will have precedence over cljsjs foreign-libs so the cljsjs JS shouldn't be included in the build
This requires that cljs namespaces only require react
react-dom
, not old cljsjs.*
names
IIRC the dynamic properties are related to DOM event props, so if you don't need to access those, everything might work
Is there anything special required to use JS libraries in ES6 syntax? I’m seeing errors when loading JS files that are fine outside of cljs
I’m trying a few approaches. Linking them in the html page right now.
But I’m also trying to generate externs and treat them as foreign libraries in src.
I’m not sure if my method is broken or if there’s something unusual about the libraries, since both fail to generate externs when using the 2 online tools for cljsjs
aside from using shadow-cljs, the way i had the most luck with was to find the UMD build of the library and include it via foreign-libs, then use cljs-oops to access objects and properties and forget about externs
@jmckitrick often you need to access libraries like this: (.-default libFromNPM)