Fork me on GitHub

I just started looking into core.async for clojurescript. Under which conditions would one opt for core.async over js async/await or promises? A use case I am thinking about is a basic http request. Most articles I am reading are written before the mechanisms were part of JS, so I am curious when core.async is the right tool.


@tkjone core.async brings a whole world of complexity that you almost certainly don’t need. I’d strongly recommend you stick with promises unless you have a clear need otherwise. Promises are reasonably ergonomic to work with in cljs, particularly with the alet macro from the promesa library


This is my understanding as well. Thank you for confirming. I am looking at both and just couldn't seem to see, for basic front end server requests, why go blocks would be needed


Yes exactly. And they are actually worse, because they don’t deal with exceptions well and they produce a massive stack trace of generated code. For this reason, I avoid core.async-based libraries like cljs-http in favor of promise based libraries


I think I would suggest pretty much exactly the opposite. core.async in most use cases is trivial to set up and use and extremely transparent. And it pretty much just works without having to think about it. The model is higher level than promises and callbacks.


So, if you aren't already using promises and such (you aren't going into some legacy code), I would (and do) opt for core.async


If you are curious, it is stuff like this that makes me shy away from core.async:


The exception handling on the producer side just isn’t well thought through.


Thanks. Never had an issue with this - but then I don't do that sort of thing in go blocks. Even if that worked (could be made to work) I still wouldn't use that idiom. Much better to use error channel(s) and/or <?. And as a general rule, it is always a good idea to avoid exception style code as much as reasonable (or at least hide it as in the mentioned idioms)


can’t fix it if it’s in a library. hard to control what might throw in javascript. all kinds of crap can throw unexpectedly. again, i’m just not sure what you get given how much work it is

João Lucas11:08:02

Hi there, I've got a reagent/re-frame app in which I get React from cljsjs. Now I want to use a npm package that depends on React and when try to compile I get the error "Error: Can't resolve 'react' in '<PROJEC_HOME>/node_modules/react-select/dist'" Should I also include react as a npm dep?

Logan Powell11:08:51

Also, you may want to ask your question on the #reagent channel

João Lucas14:08:20

Thank you for your help. I posted the question here because I thought it was a npm-deps related issue.

Logan Powell11:08:06

Is anyone in here running their ClojureScript on ChakraCore (instead of V8)?


On startup, does cljs ignore files that are already compiled, or does it compile everything from scratch each time?


On startup, does cljs ignore files that are already compiled, or does it compile everything from scratch each time? [2]


@loganpowell FWIW, ClojureScript’s unit test suite includes ChakraCore.

Logan Powell13:08:15

@mfikes! I saw your YouTube video testing ChakraCore. Thanks for responding. Is it safe for me to replace my Node VM with CC?

Logan Powell13:08:37

I'm running into a v8 limit with JSON.stringify atm 😄


At least as far as ClojureScript’s behavior on ChakraCore, we’ve been (successfully) testing with it for quite a while now.

Logan Powell13:08:00

Is there a specific set of Node and CC versions I should pair together?


FWIW, when ClojureScript is tested with ChakraCore, it is not done with Node-ChackaCore. We instead use Microsoft binaries from

Logan Powell13:08:37

Ah, so not ready for Node replacement yet


I wouldn’t conclude that. Node-ChakraCore’s quality likely surrounds how well they integrate the two.


(Even if you ran ClojureScript’s unit tests on Node-ChakraCore, ClojureScript’s unit tests focus on the JavaScript implementation. It never invokes anything that would be in Node.)

Logan Powell13:08:17

Have you tried the node-chakracore setup?


If I have, I don’t recall. 🙂

Logan Powell13:08:08

No worries. If I can't figure out another (potentially hackier) solution, I'll give it a go and let you know


There is also the Node implementation that sits atop Graal.js

Logan Powell13:08:26

Let me check that out

Logan Powell13:08:07

btw, thank you for the apropos channel!

👍 4

Has anyone run into an issue with the warning-handlers compiler option as passed in thru project.clj via lein cljsbuild? It looks like with the current version of cljsbuild, the custom warning handler feature always throws an exception:

Julien Fleury14:08:27

Hi ! Is someone familiar with this doc ? I’m trying to follow “Using Your Foreign Library” with lein and figwheel and I think I understood a lot.. But my browser still displays lot of errors like: goog.require could not find: module$Users$<my_absolute_path_to_my_project>$node_modules$create_react_class$index . I’m trying to include npm modules since yersterday and had so much problems doing it... 😕


Hi! Need help to use js libs! how to? shadow-cljs is worth to look?

Julien Fleury14:08:39

Same problem here... From what I understand, this solution seems to be the simplest one: . Please tell me if it works for you 😉

🔥 4
😎 4
Julien Fleury14:08:11

Yep, that was one of my first shots, but after testing it, it seems to be outdated 😕


hey everyone. i’m looking for some great projects using cljs / figwheel for node applications to read through and learn from. any recommendations? the larger the better.

Julien Fleury14:08:21

Mmm, just solved the problem I had with it, it doesn’t seem to come from the versions of the libs, as I first thought. I had to add ” :jvm-opts [“--add-modules” “java.xml.bind”] ” to project.clj . I will send that in an issue. But I think there are other problems after that, when updating to newer versions of reagent, clojure etc. I will check now that I have solved this first step.

Julien Fleury15:08:15

Well, I confirm that another problem pops when you pass from reagent 0.6.0 to 0.8.1 / update React from 15 to 16. Apparently, people at Reagent seems to be aware of it, from this comment in the code: 😕


you can make it work with reagent 0.8.1 as well I think

Julien Fleury15:08:12

I would definitely love to know how 😕 Taking the double bundle, updating clojure/clojurescript and reagent from 0.6.0 to 0.8.1 and then js dependencies to last ones ( “@cljs-oss/module-deps”: “^1.1.1", “moment”: “^2.22.2", “react”: “16.4.2", “react-dom”: “16.4.2", “react-datetime”: “^2.15.0" ) I get only this message in my browser: Error: Undefined nameToPath for react

Julien Fleury15:08:42

Figwheel doesn’t seem to have any problem on its side 😕 I have no clue where to go next

Julien Fleury15:08:37

From what I understand, it’s reagent searching for react via goog.require, but React & ReactDOM are well defined in my browser

Julien Fleury17:08:17

Finally found how to make it work with :foreign-libs ! 🙂


@julien.fleury glad you got it to work


I'm happy to incorporate your changes into the double-bundle repo


Re: the --add-modules flag, that sucks that lein hasn't learned to deal with that on its own yet


Re: foreign-libs, yes I use that technique now as well. Basically, include the webpack-built bundle as a foreign lib. It's necessary for unit testing using lein doo, for example


But they essentially queue up actions on the proxied dom object and I don't think it'll work with things that are supposed to return results synchronously.


If you want to retrieve a value from the DOM, it must be accessed asynchronously, since it requires a postMessage round-trip. Via.js provides a global get() function which returns a promise that resolves with the requested DOM property value, e.g.:


I wonder if WorkerDOM has the same limitation


With using SharedArrayBuffers though, and blocking, values retrieved from the dom could be converted back into synchronous operations.


just by waiting on the result


As long as the thing returned by the dom can be serialized


Or maybe not. You could possibly forward your mutation over to the main thread and work on the non-serializable object there. But that sorta defeats the purpose of moving stuff off the main thread.


I don't think it makes much sense in the context of react and such that already batch create dom nodes and can do so async (react v16)


but it could be useful for smaller non-vdom based dom interop


I've heard it can help performance in some situations to move the react renderer into a worker, for the reconciliation crunching


in theory you could do all react ops in a worker and just transfer its patch set over


but in practice thats just annoying to work with 😛


But the blog post you linked said the thing works with react. So maybe you'll get that all for free?


dunno didn't test it yet. it sounds interesting though.


bah. any javascript / react people here?


wondering how to open a new window in the browser, did not seem to work

thheller17:08:17 is typically blocked by browsers due to ads. you can only open them under specific conditions


basically only on link clicks


hm. i have a data url that I want to open automatically after it has been generated


it's not porn in this case, but yeah I get the issue with that approach


would there be a way to open the window on button click, then pipe the data url to it once it's done?


or do you lose control over the window once it's opened


@restenb you could do it asynchronously using postMessage and window.opener:


i've noticed a lot of cljs code uses native js code instead of their google closure equivalents for stuff like dom/js object manipulation etc. I have noticed the goog versions being slightly slower in some quick benchmarks, but presumably this is due to adding things that are usually justifiable ie browser compatibility. Is there a particular reason for this preference of native js? Is it perception of raw js being "simpler", or closure being unnecessary? non-awareness of the goog stuff? Anything else?


@jjttjj one of the priorities for the closure lib is maximum compatibility


so yeah lots of the stuff in there isn't really that relevant anymore since browser support is a little bit more sane these days (although still not good)


gotcha, makes sense


I guess if you care about old browsers use closure otherwise direct interop is fine


They never updated the UI stuff around the material design and some of it appears old now, like look at the editor:


my guess is that those are meant to play well with react, so there are mostly useless for clourescript


or said another way, horrible and painful to use in cljs 😉


But there's lots of great stuff in there not related to the UI


yes, was talking about the UI specifically since that is what you mentioned


It'd be cool to have a version updated with more modern look and feel


material components are being designed to be compatible with closure advanced compile:


its sometimes not clear what google does internally. sometimes it feels like half of their own developers never even heard of the closure compiler.


Yeah, I guess it was created by the gmail/maps/docs folks


> At Google, all Javascript is processed and minified by the Closure Compiler


yet some of their open source stuff isn't compatible at all 😛


but mdc looks nice on that front. the react binding just aren't that great yet.


that's a shame


anyone know of any reason i wouldn’t be able to require core.async in a .cljc file that defines macros?


i’ve used a reader conditional to pull in the cljs version


I personally have no idea. But I suspect your answer may be found in this direction:


looks interesting. i’ll dig around. thank you


Using :foreign-libs and the babel-standalone transformation, I'm compiling alongside from React JSX. This works, but not if there are any import statements within the JSX. Example:

import React from 'react'; // causes goog.require could not find: module$react

export default class Desktop extends React.Component {
  render() { return (<div>"Desktop!"</div>); }
Is there any way this can work, or should I have a custom transformation which removes imports?


> You may have noticed that our ES6 file does not declare its dependency on React, ReactDOM, or ReactDOMServer via import. Handling this correctly depends on a pending patch to Google Closure to support Node.js module resolution for ES6 source files. When this change lands this guide will updated. Does anyone have a link to this issue?


bidi leaves the user to handle fragments themselves, right?

cljs.user> (def my-routes ["#/" {"index.html" :index
                           "article.html" :article}])
cljs.user> (b/path-for my-routes :index)
cljs.user> (b/match-route my-routes "#/index.html")


On startup, does cljs ignore files that are already compiled, or does it compile everything from scratch each time? [2]