Route parameters arrive to :will-enter as strings and you need to coerce them to a different type if that's what you need. In the Person component you can see this:

:will-enter      (fn [app {:person/keys [id] :as route-params}]
                      (log/info "Will enter user with route params " route-params)
                      ;; be sure to convert strings to int for this case

With rroute/route-to! you pass a params map and it receives it exactly as is. That's the difference.

okay! any ideas how i could convert this string into a java.util.UUID? (in the cljc file)

Yes, use this https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/ids.cljc#L56-L59 like (id-string->id :uuid uuid-str)

It works! Thanks!

The component works and loads it's query correctly, but dr/change-route doesn't seems to change the url path

Indeed, it does not. In Fulcro, unlike other similar framework/libraries, the notions of routing and URL management are separate. This is largely because Fulcro is designed to be UI agnostic. RAD's routing helpers tie in the HTML5 history/URL control, but otherwise you need to take care to manage the URL yourself. See the com.fulcrologic.rad.routing.history ns for some helpers. This recent post explains it in more detail https://clojurians.slack.com/archives/C68M60S4F/p1661886186549229?thread_ts=1661858678.861289&cid=C68M60S4F.

Take a look at the source for rroute/route-to!. That might serve as a useful example https://github.com/fulcrologic/fulcro-rad/blob/develop/src/main/com/fulcrologic/rad/routing.cljc#L42-L45

Thank you very much, this thread saved me a lot of searching time!

No worries, hope it helps!

Because it is messing with low-level js values at compile time. JSValue is the cljs compiler’s rep of #js data before it is converted to low-level source. This allows the macro to seamlessly pass-through a js argument to use-effect, and to convert a CLJ data structure for dependencies through as a js value without needing runtime conversion.

so using #js [a b c] as deps is identical to using [a b c] in terms of performance, and there is no intermediate clj data structure in the mix at runtime

This I get, but are you saying use-callback and use-memo do not need this kind of optimization?

I didn’t understand that’s what you were trying to get at.

laziness on my part

and probably the fact that the actual overhead is so small to be insignificant so I didn’t bother…useEffect seems like a heavily used one. I think I wasn’t the only person doing those…

so could be it was just two diff people writing them

yeah, Wilker wrote a lot of those. I touched them up.

Ok, got it. How much of an performance impact did you observe?

I didn’t

I think use-effect was a “premature optimization” 😄

I think as I was writing use-root and use-component and use-uism it seemed to me like use-effect was being called a lot, and so it bothered me that the deps were being reconverted on every render

Using #js in the code works just as well, but ppl forget to do it

so it was just a syntax nicety. If you want to port the others to macros happy to accept a PR 😄