Don't use . that way. Stuff like event.features should be (.-features ^js event). The ^js part can be there only once where you first define the name - in this case, right in the signature, like [^js event props page].

Thanks @U2FRKM4TW for pointing that out, I’ve tried using

(defn on-click-map-icons [event props page]
     (def feature (first (.-features ^js event)))
    (when (= page "results")
    (if   (= feature.source "selected-item") (router/redirect! props :router {:page "item" :item (:id {:id feature.properties.itemid })}) ))
    (when (= page "item")
        (if (= feature.source "subitem")
          (router/redirect! props :router {:page "item" :item (:id {:id itemid } ) :subitem (:sub-id {:sub-id feature.properties.subitemid})  }))))

I didn't mean just that interop with event - I meant all interop field access in your code.

Also, you probably want to use let instead of def.

Ah I see

@U2FRKM4TW I am able to get to properties like

(.-properties ^js feature) 
#js {:title sample_note,  :noteid 3}

Choose any one or a combination or them:

(.. feature -properties -title)
(.-title (.-properties feature))
(-> feature .-properties .-title)
(. (. feature -properties) -title)

CLJS/JS interop and CLJ/Java interop are almost identical. Completely identical if you don't go outside of the . and -.

Thank You

No, all requires have to be a part of an ns form. I'm not familiar with dynamic load in webpack. Is it loading the module during the run time, when e.g. some relevant component is requested? If so, then CLJS have module splitting for that.

You can't use <p! ?

The test framework has no more special support for core.async than for Promises and I suspect <p! is cljs-only as well

Well I was thinking cause he wants to block on the promise return is my guess. So if he makes the cljs code in a go block with <p! he'd get the blocking behavior. But I guess not really since the go block itself will be async now. The same way you said await would just move the problem up as well.

I think I'd just make the clj code async as well. Maybe use CompletableFuture instead of a Clj promise, since those have a much similar interface to JS promises

Using Promesa maybe could also help. It is already Clj and Cljs compatible.

I did end up using core.async and <p!

it still required me to split my tests between CLJ and CLJS as I needed to wrap things in async and go

In general I'm trying not to pull in too many external libs

Fair enough. I think nilern is right though, I'm not sure await would have helped, because you can only use await inside of async, similar to how you can only use <p! inside go. So you might have had to shenanigan things either way. It's the whole colored function problem.

yeah like I said, I'm stating my dream; not a call to action 😛

Haha ya. Its going to get a bit weirder too, because Java will get green threads, and CLJ will probably use that for async. But CLJS will need to stick to async/await or go/<p!

Oh, nice solution you found in the end!