Clojurians Log v2

Does anyone know what this might mean (React Native)?

(shadow/repl :dev-android)
To quit, type: :cljs/quit
=> [:selected :dev-android]
(def one 1)
=> #object[TypeError TypeError: undefined is not an object (evaluating 'cljs.user.one = (1)')]

just a hunch but looks like cljs.user is undefined. do you get the same error for (ns cljs.user) or so?

oh, interesting. if I execute (ns cljs.user) before anything else - it starts working

which version is this? there was one 2.10 version that had this problem IIRC

can't remember which though

"shadow-cljs": "^2.11.4"

it’s no big deal, but I was puzzled

@thheller btw - regarding hot reload questions I had a couple of weeks earlier. I figured out why recompilation messes up React Native hot reload. That’s because the entry point file target/index.js gets rewritten every time - so at first Metro reacts correctly and tries to do a fast refresh, but then, when entry point file gets updated - it just reloads the whole thing. Although I finally got it to work as you suggested, I’m wondering whether it would be possible to prevent the entry point from getting recompiled every time.

you should disable any hot-reloading from the metro side

yes, that’s what I did

it is not needed and will only get in the way

but I’m curious why the entry point file gets recompiled every time

so you always have the latest code on disk

I could disable that but then you'd get old versions if you reloaded the RN app

you mean this is configurable?

no it isn't. but it could be.

but first I need a convincing reason why it should be 😉

I mean I can't see a scenarion where metro fast refresh and shadow hot-reload won't conflict with each other and mess each other up

it might make sense to allow choosing one or the other (I don’t have a strong opinion about this - since I never got fast refresh to work, I don’t know how convenient it is compared to shadow hot reload)

It seems that the extern inference doesn't work well with the go blocks:

(defn f
  []
  (.-foo (clj->js {"foo" 42})))
;; WARNING: :infer-warning

(defn f
  []
  (.-foo ^js (clj->js {"foo" 42})))
;; no warning

(defn f
  []
  (clojure.core.async/go (.-foo ^js (clj->js {"foo" 42}))))
;; WARNING again :infer-warning

yeah thats a known issue. go rewrites too much stuff and loses typehints

Is there a way to hide that particular warning?

I don't know. depends on the actual code. I mean if you actually use clj->js and then access a property that doesn't make sense at all?

you should always have as little code as possible in go blocks so ideally you never get to code that has to do this

What I'm actually trying to do is to wrap http://goog.net.XhrIo.send into a channel so that I don't have to do callbacks

don't know if there is an open core.async issue about this

thats fine but you can construct all of it outside a go

but using this channel requires the user code to be in a go-block, right? That's where I have other code that needs type-hinting

no it doesnt

I mean waiting on the channel result does yes but not constructing the xhr itself

I think this is what I mean:

(go
  (let [url (.getParameterValue parsed-href "url")]
      (<! (fetch-ch url))
      ;; other stuff
  ))

yes, fetch-ch itself wont report any warnings

but (.getParameterValue parsed-href "url") will

you can make a helper function for that to avoid the . access

(let [url (get-parameter-value parsed-href "url")] ...)

I know its annoying but so far no one has dared working on the core.async code

its not something I can work arround in shadow-cljs

if you don't care about inference you get (set! *warn-on-infer* false) in that file

I see. Yeah I guess that's one workaround