I’d like to see an example of how to re-use bidi routes defined on the server, on the client

Is this possible without duplicating the routes?

@borkdude a naive thought would be to postwalk the routes to make a CLJS version

or to make the routes bidi routes without resources, and then postwalk them to add the resources back in keyed off the handler id

bidi is cljc - if you use keywords as your targets, then it works on the client too

You can serve the route structure as edn over transit, or embedded in the html

yeah that's what I was trying to get at, but you said it much better 🙂

One footnote to add: many apis are hypermedia constrained, where URIs are embedded in responses. This adds dynamism and flexibility to change over time. Bidi can generate these URIs from the server side route structure and communicate them on each response. However, dynamically communicating the entire route structure and request time still meets this constraint. Just be fore-warned about the downsides of statically compiling all your routes in your cljs code

If you control both ends, this advice is moot

I thought about those keywords too, but how do I tell bidi that a keyword corresponds to a yada-resource on the server?

Probably the way @danielcompton suggests. Maybe it would be a nice feature to be able to provide bidi a mapping from keywords to functions (resources, ring handlers)

I do control both ends and will probably try .cljc for this

Just tracked down a very confusing problem, thought I'd share it for the group. I had a yada resource with :access-control {:authorization {:methods {:get :user}}}. I was also associng-in :authentication-schemes [{<myscheme>}] in a postwalk later over all of the protected resources. I could add the authorization to my resource or assoc-in authentication in the postwalk and I would have a valid resource that I could start my app with

But if I did both together I got a schema error

I finally figured out that the problem is that when making the resource with the shorthand :access-control {:authorization ...} it is expanded out to [:access-control :realms "default" :authentication-schemes]. So my postwalk needed to add authentication like this:

(defn update-resources [routes f & args]
  (walk/postwalk
    (fn [x]
      (if (instance? Resource x)
        (resource (apply f x args))
        x))
    routes))

(update-resources
  ["" [(index/index-routes spanner config)
       (account/account-routes spanner)]]
  assoc-in [:access-control :realms "default" :authentication-schemes] (sessions/authentication-schemes spanner))

The confusing part was that each of the steps would work separately, but when combining them together I no longer had a valid resource