Hi. I'm trying to create a simple react dashboard component and use it in a react app. I've managed to get everything running using re-frame. I'm using shadow-cljs and releasing it as a node-library. I've created a simple react app using create-react-app and there goes my nightmares. I can't find any good example where this has been done. Most of the articles do the reverse (using node modules in clojurescript). I'm also using material-ui via npm (was just experimenting). What is the right way of exporting and then importing this library. Any reference to a good example can also do.

Anyone know how to use apply for all constructors? Ok:

(apply js/Error ["msg here"] )

(apply js/EventSource ["/path-here"] )
;=>
Uncaught TypeError: Failed to construct 'EventSource': Please use the 'new' operator, this DOM object constructor cannot be called as a function.

;; Ok
(let [sse (js/Function.prototype.bind.apply js/EventSource)]
  (println "works" (new sse "/path-here")))
;; Not ok
(let [sse (js/Function.prototype.bind.apply js/EventSource)]
  (println "__" (apply new sse ["/path-here"])))

create dedicated function (e.g. (defn error [& messages] (js/Error. (apply str messages))) ) and then call apply for that function: (apply error ["str1" "str2"])

has there been any plan/debate/consideration for implementing a clojurescript parser+compiler independent of googles closure compiler? My experience with cljs so far is that the tooling is far less mature then I've become accustomed to in js development over the past few years. While I like the clj(s) language, I'd feel much more comfortable with using js tooling, making use of tried-and-tested treeshaking/minification/... as offered by webpack, rollup and the like; getting easy access to the full js ecosystem rather than having to work around the (imho) clunky behemoth that is the closure compiler and library. My instinct is that a cljs compiler that worked as eg a webpack loader or babel plugin and emitted (as much as possible) dependency-free es6 code could integrate far better in the js ecosystem. Did anyone consider this in the past and was it deemed a bad idea? Probably I'm overlooking aspects of the cljs->js conversion that are prohibitive of doing this?

> making use of tried-and-tested treeshaking/minification/... as offered by webpack

I'd argue that the closure-compiler is much more tried-and-tested in that area and has been for years 😛

also try shadow-cljs 😉

Any feedback on the following approach to use apply on constructors:

(defn constructor-fn [class]
  (let [constructor (js/Function.prototype.bind.apply class)]
    (fn
      ([a] (new constructor a))
      ([a b] (new constructor a b c))
      ([a b c] (new constructor a b c d))
      ([a b c d] (new constructor a b c d e))
      ([a b c d e] (new constructor a b c d e))
      ([a b c d e f] (new constructor a b c d e f))
      ([a b c d e f g] (new constructor a b c d e f g))
      ([a b c d e f g & more]
       (throw (ex-info "Constructors with more than 7 arguments are not supported" {:class class}))))))

(apply (constructor-fn js/EventSource) ["/yeah"])

what are you doing that you need apply for new? 😛

haha good question

I’m trying to (js/EventSource "/foo") from the sci interpreter…. https://github.com/jeroenvandijk/sci/blob/51ad3e653e8759717bf7806b6cf51bf658d8a134/src/sci/impl/interop.cljc#L67

If you have ideas please let me know 🙂

normal constructors work, but (js/EventSource. "asdfsa") doesn’t work with apply

I just checked and this solution doesn’t work in advanced compilation (not sure why)

WARNING: Use of undeclared Var sci.impl.interop/c at line 47 /Users/jeroen/Projects/Github/sci/src/sci/impl/interop.cljc
WARNING: Use of undeclared Var sci.impl.interop/d at line 48 /Users/jeroen/Projects/Github/sci/src/sci/impl/interop.cljc
WARNING: Use of undeclared Var sci.impl.interop/e at line 49 /Users/jeroen/Projects/Github/sci/src/sci/impl/interop.cljc

ah this is for sci

so rather "reflection" heavy

In the JVM it’s all reflection, but js doesn’t have that right?

not in the JVM sense no

but you don't really need apply in this case?

you know how many args you have and could just write a bit of boilerplate 😉

hmm you mean I could call new myself. True probably, but I would like to get the cljs experience in sci. So no context switching

pretend it’s the same

I already have this boilerplate in sci to avoid going through apply: https://github.com/borkdude/sci/blob/d768910b6c4f51fc9b3331f5d8ddefc59c1f4f36/src/sci/impl/interpreter.cljc#L395

it was only done for perf optimization

I can remove the boilerplate, but it doesn’t seem to work in advanced mode yet. compiler doesn’t like c, d, and e for some reason

and trying with one arity gives a weird error still. Ok back to the drawing board

Ah wait you mean not using apply at all. I can try that 🙂

(let [ctor (get-static-field [class field])]
  (case (count args)
    0 (new ctor)
    1 (new ctor (nth args 0))
    ...))

something like that .. assuming get-static-field just returns the actual type

awesome!

I think it does… but I am not entirely sure what I’m doing either

@thheller your suggestion works, sci.evalString("(js/EventSource. \"/aaa\")", {"classes": {"allow": "all", "js": window}}) works now

When I want to use addEventListener there is a new problem waiting 🙂

Does anyone know if the metadata reader macro is supposed to work within go blocks? If I run (go (println (meta ^:foo {}))) it prints nil to the console (whereas (go (println (meta (with-meta {} {:foo true})))) and (println (meta ^:foo {})) both print {:foo true})