Fork me on GitHub

how should I do something like this correctly:

(def config 
   :a {}
   :b {:x (:x (ig/ref :a))
       :y (:y (ig/ref :a))}})


e.g. how to use ig/ref in nested form?


@lambder sorry, can you elaborate? I’m not sure what you’re doing there.


(:x (ig/ref :a) result in nil (as expected but not desired) I'd like to have the value associated with :x from the the map produced by ig/init :a multimethod call.


@lambder I added a thread reply to your other comment. The easiest way to achieve what you want is with an intermediate key that inits to (:x v) or whatever sub-key you want.


What would be the most out-of-the-box way of creating a duct project that serves both a cljs-equipped site and an API so that the ClojureScript frontend can exchange data with the backend? I gather from this issue ( that it is not possible via templates options, correct? My current approach would be to pull apart the prep'ed config, making 2 mid-level handlers each with their own middleware stack and routers, and joining them in a high-level cascading router. That would mean replacing my config with some variation on the expansion of :duct.module/web Is there a better way I'm missing?


@val_waeselynck You can use :duct.module.web/site and then just add in the :duct.middleware.web/format middleware manually.


@weavejester it works okay, but requires some more efforts to work soothly - as it is, any API client ends up with an HTML response in case of errors, whereas I'd rather convey a data representation of the error. I'll probably also add a custom error middleware in the API branch.


Also breaks wrt Anti-forgery token.


I can't seem to get this "merge 2 handlers into 1 top-level handler" to work, because I'm getting an ambiguous-key error on :duct.core/handler. I'd love to know if you think this is possible at all without completely giving up on the web module.


You can change the handlers associated with error events in Ataraxy to spit out HTML or data respectively, but you’ll need to check the content type manually. (I think Muuntaja also adds a key?)


The anti-forgery-token middleware requires a header for AJAX requests. X-CSRF-Token, I believe.


I don’t understand what you mean by “merge 2 handlers into 1 top-level handler”. That’s what routing is for.


I’m planning on adding better support for mixed site/api apps, so this should become easier in future.


@weavejester thanks. > I don’t understand what you mean by “merge 2 handlers into 1 top-level handler”. That’s what routing is for. I know, but I would like to have a routing solution that lets me divide incoming requests into 2 branches (site + api) and apply 2 different middleware stacks on these branches.


You can nest routes arbitrarily. Routing systems produce larger handlers from a collection of routes linked to smaller ones.


You can create three :duct.core/handler keys, one to hold the root, one to hold the API, and one to hold the Site.


Then just have give the route handler two routes: one to the site and one to the API.


@weavejester Well the error I'm getting (`ExceptionInfo Ambiguous key: :duct.core/handler ...`) seems to imply that it's not possible, because :duct.module/web will reject any config featuring several keys that inherit from :duct.core/handler. Here's a 'repro' config:


You need to override the handler passed to the web server as well. By default, the web server looks for the :duct.core/handler key, which is where the ambiguous key exception is coming from.


Something like that should work.


@weavejester thanks, will try that and come back to you


@weavejester Hmm the problem now is that the whole middleware stack is applied to the root handler as well as to the children, and I don't know how to prevent that.


I'm starting to think I'm after something that Duct is not designed to provide in its current version - maybe I should just give up on the web module and go down to integrant


It might be easier to start from either the :duct.module/web module, or manually connect up the pieces without the module.


However, please add this issue to the Duct template project (I don’t think there’s one there already).


I am planning on adding a module already to handle this, but an issue would allow people to give feedback on what they want.


> It might be easier to start from either the :duct.module/web module, or manually connect up the pieces without the module. Yeah I've tried that too, no luck so far 😞 essentially the issue stays the same.