Fork me on GitHub

I'm attempting to call a macro with a #js {} object literal, and getting a ClassCastException in the compilation phase. Is this not supported?


@mattly is the #js reader used in CLJS code or CLJ code?


#js should expand at read time before it hits your macro code


But if your macro is outputting it, it might not work


It’s in the CLJS code invoking the macro


I’ll get a little example up after I get my kid to bed


bah, some kind of heisenbug


went away when I tried to isolate it, and now I can't reproduce


Hmm I confused myself: clj -A:fig:build

Syntax error compiling at (src/form_validator/core.cljs:9:7).
No such var: s/explain-data
(ns form-validator.core
  (:require [cljs.spec.alpha :as s]))

(def conf (atom {:atom atom}))

(defn ?spec-problems
  "Return nil if pass."
  [spec value]
  (-> (s/explain-data spec value)
Why I have this error? I am using fighweel-main. I am sure I didn’t have it a few months ago. But when and open the same running process ( clj -A:fig:build ) in web browser or clj -A:test:test-watch it works. But when I want to use REPL directly it doesn’t work. Is it ClojureScript / figwhee-main / Cursive issue?


to make it clear: I am running the REPL which work for web browser in Cursive. This is the same REPL where I am trying to load the namespace.


hmm I think it is Cursive issue with figwheel-main when use deps.edn


But it was working in the past hmm


ok I found it. I needed to switch REPL. I didn’t remember about it.


Folks, something very noob that I simply assumed would work. When consuming your clojurescript code from JS, it seems multimethods are not exported the same way that functions are (as in, they can't be called directly).


What's the best way to consume multimethods from JS?


mulitmethods are not regular JS functions. In JS you call use .call or create a regular function in CLJS that calls the multimethod


depends on what kind of "translation" of arguments you need to do


Does .call have the same signature as the original multimethod?


@luchini I would export a normal function that wraps the multimethod


.call takes one extra first arg


usually for JS functions thats the this the function will have


but the multi method will just ignore it


It's basically what we are preferring to do here @lilactown


yeah, I would also recommend using a regular wrapper fn

Mario C.19:10:41

I want to integrate re-frame into an existing project I have. I don't want to run the lein new re-frame command since that will build a new directory with a project.clj and other stuff. If I already have a project structure should I just emulate the project structure that the script builds and look at how the script creates the project.clj and incorporate that into my existing project.clj?


Thanks @thheller and nice work on shadow-cljs. It packs a lot of goodness.

👍 4
Mario C.19:10:49

Or is there a better way of going about it?


(About hot reload of cljc files in figwheel) Has anyone experienced this/has any idea? I'm stuck and this thing really slows my workflow 🙂

Mario C.22:10:10

when running shadow-cljs build I get Circular dependency detected: cljs.core -> cljs.core how can I figure out whats causing this? I tried building with the --verbose option but it doesn't give me much info other than

-> build target: :browser stage: :configure
<- build target: :browser stage: :configure (8 ms)


there was a time when CLJS didn't have "vars" as described here: when they were introduced, did this mean a drop in performance because of more indirection? and are vars compiled away in advanced compilation?


not sure what you mean. CLJS still doesn’t have vars, as described there :thinking_face:


@lilactown I mean this: > In ClojureScript def yields the value, unless the REPL option :def-emits-var is set (this defaults to true for REPLs). and this:

cljs.user=> (var assoc)


call it whatever you want to call it, but it's an indirection that resembles something like a var


I think it’s point is that, vars don’t get output in actual code. only at the REPL


(def foo 1) JS output is = (1);


if you explicitly call var in your code, it will create a special var object at the call site and yes, it does impact code size


ex: (var assoc)


but 99% of CLJS code contains no vars at all, because def does not actually return a var and it is not a part of the typical CLJS runtime


so vars are almost never output and advanced compilation does not deal with them at all