@dpsutton You can convert from a transit UUID to a core UUID by first converting to string:

cljs.user=> (require '[cognitect.transit :as t])
nil
cljs.user=> (uuid (str (t/uuid "123e4567-e89b-12d3-a456-426655440000")))
#uuid "123e4567-e89b-12d3-a456-426655440000"

Interestingly, there is code in Transit supporting the intent that Transit UUIDs and core UUIDs be transparently exchangeable, but the new core uuid? function was written after all of that and doesn't address that aspect.

@dpsutton Looks like you can fix uuid? failing on Transit UUIDs by revising them to implement IUUID. Hrm.

cljs.user=> (require '[com.cognitect.transit.types :as ty])
nil
cljs.user=> (extend-type ty/UUID IUUID)
#js {}
cljs.user=> (uuid? (t/uuid "123e4567-e89b-12d3-a456-426655440000"))
true

I’m getting an error I haven’t seen before while attempting to use a cljsjs dependency to a new project: java.io.FileNotFoundException: Could not locate cljsjs/aws_sdk_js__init.class or cljsjs/aws_sdk_js.clj on classpath. Please check that namespaces with dashes use underscores in the Clojure file name.

the js files from cljsjs are in the right place, but it seems the cljs compiler is trying to load these as a java class for whatever reason

@mattly You would get that if you are requiring them as macros. In other words (require-macros 'cljsjs.aws-sdk-js) repros that error.

odd

I’m on clojurescript 1.9.946

I figured there was something like that out there. Thanks @mfikes

@dpsutton No problem. Perhaps transit-cljs should automatically (extend-type ty/UUID IUUID) in its core namespace.

Yeah I'm a little surprised it didn't hide itself a little better

@mattly Is myapp.states.login perhaps a .cljc file that requires macros from itself?

@dpsutton I think the intent is to hide the difference, but that was coded up 3 years ago, with uuid? being relatively new.

@mfikes it uses re-frame, but that’s the only other entry in :require and there’s no macros at all

@mattly Is there a stack trace associated with the error? Perhaps it has a hint as to where things go into Clojure-land.

hm… the error is coming from Figwheel in the browser, not anywhere else afaict

lemme try lein cljsbuild

I’m also unfamiliar with lein, I’ve used mostly boot in the past

Ahh, Figwheel is only showing the error message, without the stacktrace? Dang.

yeah

ok here’s the error from cljsbuild:

@dpsutton I've logged https://github.com/cognitect/transit-cljs/issues/41

@mattly Yeah, it definitely looks like you have a *.cljc file that is being loaded by Clojure instead of by ClojureScript

hm, perhaps I should double-check my source paths

@mattly On the surface, I don't think paths would be the root cause (all source files need to be "on the classpath" somewhere but that doesn't control how they are treated / loaded)

The fact that the error starts off with Reloading Clojure file is interesting...

@mattly Perhaps you are onto something though, especially if it is in the "env/dev/myapp" directory

(`dev` would be treated specially, I think)

Need, to run, but my guess above, with dev is that stuff in that directory might be loaded like user.clj would be loaded. In other words, it may have special meaning to lein.

hm

there’s actually nothing in the /env/dev directory I’m using yet, I’m going to try removing that

cljsbuild works, but figwheel still fails

this seems to be specifically a figwheel problem now, I can cause a similar error with a (js/console.log :foo) call

it’s fine until I reload something

Yeah, that code is evidently being compiled as Clojure, not ClojureScript.

oh derp

it should have been a .cljs file, not .cljc

definitely time to go home

Is it possible to pass feature flags to the reader used by the cljs compiler? Motivating use case described here: https://gist.github.com/lynaghk/0608a43f173558b6fcf30c3be53d77dd

@kevin.lynagh nice timing. I was going to open a ticket about that very thing. My current plan was to add :reader-features #{:kw1 kw2} to the build config and use that when reading .cljc files. My goal however was to enable reading based on the target platform, eg. node, browser, react-native, etc.

but splitting dev code from release code is also a good use-case I guess

opened https://dev.clojure.org/jira/browse/CLJS-2396

has anyone done some debouncing with react? (do something only after event stopped occuring, like trigger the search when the user stopped typing)

@roti use [goog.async Debouncer] and then set it up in will-mount and tear down in did-unmount

@rauh thanks. what should happen on unmount?

@roti (.dispose db)

@roti Example: https://github.com/tonsky/rum/wiki/Mixins#debouncer

@kevin.lynagh I think you could use :external-config and some helper macros to exclude values on dev builds. Here's the example: https://gist.github.com/metametadata/bb00917e09463f6ce04f0e50ccc0740a cc @thheller

@kevin.lynagh If you can use 1.9.854 or later, you can rely on aggressive branch elision that occurs at the ClojureScript level for ^:const Boolean Vars. This can remove stuff that even goog.DEBUG fails to ferret out. Details here https://gist.github.com/mfikes/93cb77921ee35c2328b92af441ee5393

@mfikes I guess your solution (as well as :external-config one) also won't help with eliminating the require of core.spec as @thheller pointed out in the above thread, due to https://dev.clojure.org/jira/browse/CLJS-1701?

@metametadata In the test I was doing, simply requiring clojure.spec.alpha results in no increase in generated code size under :advanced.

Perhaps thing have improved—I was using the latest ClojureScript release.

hmm maybe something changed since I tested it, it has been a while. just a single spec will probably keep everything alive though.

I went back and checked, and was incorrect. Simply requiring cljs.spec.alpha increases my :advanced uncompressed output by 8 kB.