yes, I think so.

in that specific case, re-frame.core/subscribe which maps to re_frame.core.subscribe in javascript

fwiw, if you are set! -ing at the REPL it should work, if you're talking about optimized fns builds (which include :advanced) this was never something that was supposed to work, and if it did work that was accident and not going to change anything here.

I have a strange problem with citrus/rum where the args to the defc components aren't "delivered " correctly.

When I downgrade to cljs 1.11.4 everything works as expected.

The smallest example would be: (ns frontlyft.repro (:require [citrus.core :as citrus] [goog.dom :as dom] [rum.core :as rum])) (defn control [event args state] {:state (update state :number (fnil 0 inc))}) (defonce reconciler (citrus/reconciler {:state (atom {}) :controllers {:repro control} :effect-handlers {}})) (rum/defc smol-component < rum/reactive [r] [:div [:h1 "smoll life"] [:p (str (rum/react (citrus/subscription r [:repro :number])) )]]) (defn ^:export run [m] ;; (let [r reconciler]) (rum/hydrate (smol-component reconciler) (dom/getElement "app"))) where there obv is a webserver responing with a html page with an "app" tag, and running a frontlyft.repro.run({}) stacktrace Uncaught Error: Assert failed: (instance? r/Reconciler reconciler) cljs$core$IFn$_invoke$arity$3 core.cljs:117 citrus$core$subscription core.cljs:117 cljs$core$IFn$_invoke$arity$2 core.cljs:128 citrus$core$subscription core.cljs:117 smol_component repro.cljs:17 cljs$core$IFn$_invoke$arity$3 core.cljs:3941 cljs$core$IFn$_invoke$arity$2 core.cljs:3936 cljs$core$IFn$_invoke$arity$2 core.cljs:3971 cljs$core$apply core.cljs:3962 render core.cljs:208 reactive core.cljs:424 build_class core.cljs:112 React 17 rum$core$hydrate core.cljs:287 frontlyft$repro$run repro.cljs:26 <anonymous> (index):6 core.cljs:117 The assertation is: https://github.com/clj-commons/citrus/blob/master/src/citrus/core.cljs#L130 Buildscript: {:main frontlyft.repro :asset-path "/js/frontlyft/compiled/out" :output-to "cljs-resources/public/js/frontlyft/compiled/frontlyft.js" :output-dir "cljs-resources/public/js/frontlyft/compiled/out" :language-in :ecmascript-next :warnings true :language-out :no-transpile} The app starts when i replace r with reconciler (ie don't care about about the argument passed to smol-component, I assume some part of cljs has changed so that citrus (or rum) get broken. Make this could happen orthers as well..

I can send a whole project.clj file but not here.

I would report this to rum project first

If you want to pinpoint the commit that breaks for you that would be a good first step

There are not that many commits so a git bisect should be pretty quick

I’m getting Could not locate vendor/bridge__init.class, vendor/bridge.clj or vendor/bridge.cljc on classpath

when starting a project from figwheel

That one seems a bit odd since no one reported that and I did some basic checking, can you look inside the jar and confirm it is missing?

But will double check later

yeah I see the cljs/vendor/bridge.clj file

I’m using lein let me try with deps

Huh I didn't test with lein - but that would be odd

Damn same problem

Now I’ll look at the deps tree for strange stuff

Hold on I think I may be onto it. It’s probably not a problem on your end

Ok

Actually I’m wrong. The problem is still happening. So I guess I’ll just explore some more

happy to fix it up - not a surprise is something snuck through, might be cool to just dummy check w/ ClojureScript by itself too

clj -M -m cljs.main -co build.edn -r etc.

Yeah its the loading of figwheel that’s the problem.

ugh

Cool, I’ll look into this more in the morning.

{:clojure.main/message
 "Execution error (FileNotFoundException) at cljs.repl/repl* (repl.cljc:1060).\nCould not locate vendor/bridge__init.class, vendor/bridge.clj or vendor/bridge.cljc on
 classpath.\n",
 :clojure.main/triage
 {:clojure.error/class java.io.FileNotFoundException,
  :clojure.error/line 1060,
  :clojure.error/cause
  "Could not locate vendor/bridge__init.class, vendor/bridge.clj or vendor/bridge.cljc on classpath.",
  :clojure.error/symbol cljs.repl/repl*,
  :clojure.error/source "repl.cljc",
  :clojure.error/phase :execution},

anyway, tomorrow will be a better time for me to look at this

I’m thinking now that the relative path loading is failing for some reason and that an absolute classpath relative path may fix it

(clojure.core/load "vendor/bridge")

I just couldn’t stop working on it. I know I should but …

do you have a fix feel free to propose