thank you!!

as a side note… getting set up with clj and deps.edn is way easier than lein with cljsbuild was a few years ago. such awesome progress!

FYI, I resolved my issue with d3, and getting the error:

ERROR: JSC_PARSE_ERROR. Parse error. 'as' expected at /Users/thomas/ustudio/stats-ingest/stats-dashboard-ui/node_modules/d3-transition/src/transition/attr.js line 2 : 17
ERROR: JSC_PARSE_ERROR. Parse error. 'as' expected at /Users/thomas/ustudio/stats-ingest/stats-dashboard-ui/node_modules/d3-transition/src/transition/attrTween.js line 1 : 17

[org.clojure/clojurescript "1.10.238"
                  :exclusions [com.google.javascript/closure-compiler-unshaded]]
                 [com.google.javascript/closure-compiler-unshaded "v20180610"]

at least, it got me past that error; i’m getting a lot of errors like module$Users$thomas$ustudio$stats_ingest$stats_dashboard_ui$node_modules$pondjs$lib$lib$pipeline is not defined

Has anyone done anything with web components and cljs? Would be nice to have a cljs approach to something like https://stenciljs.com/

@smnplk if you like core.async, feel free to use it, but you don’t need to use it. I’ve ended up ripping it out and I just use promises. When I have more complex promise code, I use the alet macro from the promesa library. You can get most things done that way and you’ll get good predictable, debuggable behavior.

So in your upload-files, instead of returning a channel, just return a promise.

@lee.justin.m Hm, good idea about returning those two channels, I could do that so i don't have to pass them in at the call site. I will aslo checkout promesa. Thanks!

@smnplk agree with @lee.justin.m core.async is a power tool for very complex requirements, but many (most?) cljs projects don't have those. The costs of core.async are real: core.async is macros vs promises, which are just anon fns wrapped; core.async's main abstraction, channels, need to be closed, whereas promises are one-offs (conceptually simpler); exception handling in promises is easier to grok; and compared to core.async the API surface area of promises is tiny (essentially only the constructor, .then and .catch), so less cognitive load

also the thread-first macro is ideally suited for promise chains 🙂 (-> (js/fetch "url") (.then (fn []...]) (.then (fn [] ...))

finally you ultimately want to understand the implementation. Easy for promises: https://github.com/medikoo/plain-promise/blob/master/index.js. For core.async... good luck 🙂

@pesterhazy Yeah, I can see using core.async here is an overkill, I will probbaly just embrace promises as a simpler abstraction for async stuff.

@pesterhazy hrm, channels don’t need to be closed

core.async is fine for simple async tasks or complex ones

people seem to forget that channels & go blocks are a la carte

@smnplk re: your snippet (go (>! ...)) is not necessary, put!

whether you decide to use core.async or not is up to you - but I don’t find the backlog arguments particularly compelling

As a matter of taste I have worked on a project with promesa + alet for a year and I can’t really say I much care for it.

@tstephens re your :npm-deps issue have you looked at just doing this via WebPack, latest releases of ClojureScript make that path relatively smooth

@dnolen thanks; yeah, i did go down that path, briefly, but was running into other issues. i gave up on it relatively quickly, though; if I can’t get it working via npm-deps, i’ll probably go back to webpack. right now, I think the problem is closure is getting confused by some “meta module” code in some of the libraries (like, underscore trying to guess what module system is being used at runtime), which closure compiles out to something invalid. not sure if just telling closure a different module format would resolve that or not, though

it would be nice to be able to override the :foreign-libs options being passed for the node modules via :npm-deps, if 90% of them work, and just a few need custom options

@tstephens WebPack route is just fundamentally way simpler and you will run into fewer issues

way more moving parts with :npm-deps

thanks; maybe i’ll try that in more earnest tonight

is that just a consequence of npm-deps being “alpha”? or is there an expectation that it’ll never work as well as webpack, due to the crazyness of the npm ecosystem?

it works for a lot of simple libraries already

however for more complicated things more work needs to be done both in ClojureScript as well as Google Closure Compiler

so it’s a non-trivial effort to cover a lot of cases

when you go down the Webpack route you’re letting JS tools manage all that - so you’re less likely to hit trouble

:npm-deps is being actively developed - but it’s going to be for the adventurous for some time yet

@tstephens in the past the Webpack bundling route didn’t support idiomatic usage - but that’s not true any more

you can treat the libs in the bundle as normal requires etc. and externs inference eliminates the tedious parts of using a foreign lib

so, what I tried yesterday was to write a simple JS file that imported the modules I needed, and exported them as attributes on window, then ran that through webpack, then pointed a :foreign-lib at that output. is that the gist of the webpack route? or is there a different way to do it (i had trouble finding examples that fully integrated webpack with the foreign-libs part of the build process)

Can a data literal defined in data_readers.cljc point to a function that lives in a .cljs file? I'd like my data-literal's function to depend on compile time :clojure-defines value.

@dnolen point taken re: core.async

even if it's just a matter of taste, what didn't you like about promises/alet?

Using Luno 1.8, how come (set! js/foo 42) gives me back foo is not defined? Is it a self-hosted-cljs thing?

@grav what is foo? How do you define it? if it is with def you don't need js/

@richiardiandrea foo is a new global js var that I want to create. My scenario is for creating a polyfill.

It seems to work in Klipse which is also self-hosted Cljs. And it works fine in a shadow-cljs repl (non-self hosted), so it’s probably a lumo issue

@grav (set! (. js/global -foo) 1)

I have always done it this way

A, very nice! That works perfectly. Couldn’t find it documented anywhere

but it might be wrong 🙂

@tstephens I’m assuming you followed the guide? that’s how it works - I’m not sure what more you were looking for?

@richiardiandrea It’s not wrong enough for this hack 😉

kind of hope that David will write something so that we all learn 😄

haha, me too 🙂

@pesterhazy inevitably you need to do something more complex and I just find core.async more natural - other than that I didn’t find promises in real code bases any easier to debug (somebody unwisely catches errors upstream)

@richiardiandrea @grav also goog.global, however you definitely want to use goog.object/set if advanced compilation is under consideration

goog.global should be bound to the right thing regardless of JS environment

riiiight nice

@dnolen i was, but perhaps wasn’t require’ing the foreign lib, or defining the exports correctly; i’ll play with it again; i’m sure I was just configuring something or other wrong. thanks for your help

@tstephens did you get through the guide? I would make sure you can make that work first

it doesn’t take more than 10 minutes to get through those exact instructions

@john not sure if I would use data literals that way. but the reader would only be able to use functions available in the clj world. You can get at the :clojure-defines in the clojure environment. (-> cljs.env/*compiler* deref :options :clojure-defines)

@bhauman that's what I was looking for!

Thanks Bruce