Fork me on GitHub
#yada
<
2017-04-30
>
borkdude18:04:28

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

borkdude18:04:49

Is this possible without duplicating the routes?

danielcompton20:04:20

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

danielcompton20:04:43

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

malcolmsparks20:04:14

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

malcolmsparks20:04:35

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

danielcompton20:04:32

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

malcolmsparks20:04:35

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

malcolmsparks20:04:44

If you control both ends, this advice is moot

borkdude20:04:11

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

borkdude20:04:27

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)

borkdude20:04:54

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

danielcompton20:04:20

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

danielcompton20:04:50

But if I did both together I got a schema error

danielcompton21:04:18

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))

danielcompton21:04:43

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