Fork me on GitHub
#clojurescript
<
2018-08-22
>
athomasoriginal02:08:08

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.

justinlee16:08:11

@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

athomasoriginal16:08:54

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

justinlee16:08:38

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

jsa-aerial18:08:49

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.

jsa-aerial18:08:34

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

justinlee19:08:33

If you are curious, it is stuff like this that makes me shy away from core.async: https://github.com/r0man/cljs-http/issues/110

justinlee19:08:24

The exception handling on the producer side just isn’t well thought through. https://dev.clojure.org/jira/browse/ASYNC-73

jsa-aerial21:08:36

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)

justinlee01:08:40

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)?

weavejester13:08:30

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

aisamu13:08:40

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

mfikes13:08:31

@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 😄

mfikes13:08:03

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?

mfikes13:08:41

FWIW, when ClojureScript is tested with ChakraCore, it is not done with Node-ChackaCore. https://github.com/nodejs/node-chakracore We instead use Microsoft binaries from https://github.com/microsoft/chakracore

Logan Powell13:08:37

Ah, so not ready for Node replacement yet

mfikes13:08:19

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

mfikes13:08:16

(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?

mfikes13:08:37

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

mfikes13:08:01

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!

👍 1
pesterhazy13:08:44

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: https://github.com/emezeske/lein-cljsbuild/issues/494

Julien Fleury14:08:27

Hi ! Is someone familiar with this doc ? https://clojurescript.org/guides/webpack 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... 😕

neural14:08:33

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: https://clojurescript.org/news/2017-07-12-clojurescript-is-not-an-island-integrating-node-modules . Please tell me if it works for you 😉

🔥 1
😎 1
Julien Fleury14:08:11

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

g14:08:37

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: https://github.com/reagent-project/reagent/blob/master/examples/material-ui/project.clj 😕

pesterhazy15:08:45

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 ! 🙂

pesterhazy17:08:36

@julien.fleury glad you got it to work

pesterhazy17:08:48

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

pesterhazy17:08:24

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

pesterhazy17:08:29

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

john15:08:40

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.

john15:08:29

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.:

john15:08:53

I wonder if WorkerDOM has the same limitation

john16:08:47

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

john16:08:08

just by waiting on the result

john16:08:49

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

john16:08:06

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.

thheller16:08:43

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)

thheller16:08:03

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

john16:08:40

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

thheller16:08:40

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

thheller16:08:52

but in practice thats just annoying to work with 😛

john16:08:55

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

thheller16:08:15

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

restenb17:08:40

bah. any javascript / react people here?

restenb17:08:14

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

thheller17:08:17

window.open is typically blocked by browsers due to ads. you can only open them under specific conditions

thheller17:08:27

basically only on link clicks

restenb17:08:13

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

restenb17:08:31

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

restenb17:08:57

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

restenb17:08:07

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

isak17:08:39

@restenb you could do it asynchronously using postMessage and window.opener: https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage

jjttjj19:08:13

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?

thheller19:08:22

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

thheller19:08:51

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)

jjttjj19:08:17

gotcha, makes sense

thheller19:08:23

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

john19:08:08

They never updated the UI stuff around the material design and some of it appears old now, like look at the editor: https://google.github.io/closure-library/source/closure/goog/demos/editor/editor.html

johnj19:08:52

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

johnj19:08:26

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

john19:08:31

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

johnj19:08:27

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

john19:08:09

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

john19:08:48

material components are being designed to be compatible with closure advanced compile: https://github.com/material-components/material-components-web/blob/master/docs/closure-compiler.md

thheller19:08:39

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

john19:08:03

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

thheller19:08:26

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

thheller19:08:34

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

thheller20:08:26

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

john20:08:06

that's a shame

g20:08:37

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

g20:08:09

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

john20:08:04

I personally have no idea. But I suspect your answer may be found in this direction: https://github.com/cgrand/macrovich

g20:08:39

looks interesting. i’ll dig around. thank you

jeaye22:08:28

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?

jeaye00:08:29

> 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. https://clojurescript.org/guides/javascript-modules Does anyone have a link to this issue?

urbanslug23:08:08

bidi leaves the user to handle fragments themselves, right?

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