@dpsutton I've run into some issues with #[email protected] in a require section, I solved them by always having one top level form in the :require , i.e. (:require [clojure.string :as string] #[email protected](:cljs [...])

I think this ended up cljsjs/big is not compatible with nashorn

But I appreciate the thought

@john 🙂 I just came on here to ask about a library for using Fetch API and promises without js interop - in the context of service workers and PWAs

Pretty convenient time to drop into the channel and just scroll up 👍

Well, I don't have a non js interop solution 🙂 It could probably be done with core.async

For my purposes, I was just trying to simulate blocking operations using xhrs on the service worker

So I just went with a quick and dirty (defn async [evt uid] (js* "(async function() { await foo.sws.await_val(evt, uid); return foo.sws.getResponse(uid);})();"))

And then handled the promise stuff in cljs

Cool

If you want to block on the xhr though, you have to do it from another webworker. The blocking is cool, but you still have separate execution contexts, without memory shared between them. I ended up stringifying cljs fns "across the wire" and a surprising amount of functionality still works, even in advanced compilation. Not sure if it'll ever be a practical solution for anything but it's an interesting hack.

I'm hoping to clean it up enough to put the bits up on github this weekend

There's some experimental work with SharedArrayBuffers in there too, that some folks might be interested in looking at

Trying to test some scenarios with shared memory across contexts

you can always covert a promise into a channel

(defn p->c [p] (let [c (chan)] (.then p #(put! c %)) c))

I'm trying to create a very simple reagent problem and keep finding that calling the basic reagent render functions is failing from a ReferenceError:

dom.cljs?rel=1528574176684:20 Uncaught ReferenceError: react_dom is not defined
    at reagent$dom$render_comp (dom.cljs?rel=1528574176684:20)
    at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$3 (dom.cljs?rel=1528574176684:44)
    at reagent$dom$render (dom.cljs?rel=1528574176684:31)
    at Function.reagent.dom.render.cljs$core$IFn$_invoke$arity$2 (dom.cljs?rel=1528574176684:39)
    at reagent$dom$render (dom.cljs?rel=1528574176684:31)
    at Function.reagent.core.render.cljs$core$IFn$_invoke$arity$2 (core.cljs?rel=1528574177067:74)
    at reagent$core$render (core.cljs?rel=1528574177067:65)

:dependencies [[org.clojure/clojure "1.8.0"
                   org.clojure/clojurescript "1.9.908"
                   org.clojure/core.async "0.4.474"]
                  [cljsjs/react "16.3.2-0"]
                  [cljsjs/react-dom "16.3.2-0"]
                  [reagent "0.8.1"]
                  [quil "2.6.0"]]

@awerner32 is that an accurate representation of your clojure dependencies? bc that is missformatted

@awerner32 you also shouldn't have to require react explicitly if you ar using reagent

how does reagent handle if React is included via npm-deps vs. cljsjs?

i’m trying to read the code and I see them just use (:require [react :as react])

I see there’s this file: https://github.com/reagent-project/reagent/blob/master/lib/modules.js but I have no idea what it’s doing

@lilactown That file is not used; I have no idea either what it does

It was probably for the webpack example but I probably removed that while ago

Re cljsjs vs. npm-deps: If lib exists in node_modules it has precedence (unless :npm-deps false option is set), else Cljsjs is used. React Cljsjs package provides react name to match the npm package.

okay. so if I’m writing a library that uses react, where a consumer might use npm-deps or cljsjs, I should just require [react :as react] and it will use whichever is available?

Yes, that is the idea.