Question about generating urls with dispatch-rules from imported modules

[Yury Bulka]

Dear Racket community,

First of all I want to say hello since this is my first post here.

I have a question about using the url dispatch library:
https://docs.racket-lang.org/web-server/dispatch.html

More specifically about the url-generation function in the context of
inter-module dependencies.

Let's say in `routing.rkt` I define some request handlers and then map
them to urls using dispatch-rules.

The request handlers call functions from another module that are
responsible for generating the x-expressions (let's call this module
`templates.rkt`). The x-expressions need to include hyperlinks to urls
defined via dispatch-rules in main.rkt, i.e., call the url-generating
function.

The url-generating function, in turn, needs to be provided the request
handler as the first argument.

That means that the xexpr-generating function needs to have access to
the url-generating function and all the request handlers it might
need to include hyperlinks to, or it may need to be provided with all
the generated urls in advance.

Something like this wouldn't work if render-post needed to generate a url:

;; A request handler associated with a url
(define (single-post-view request post-id)
(response/xexpr (render-post (post-id))) ;; render-post is in another file/module

I wouldn't want to make templates.rkt require routing.rkt (I'm not sure
this is technically possible to have modules depend on each other like
that), nor would I want to provide all the request handlers as arguments
to `render-post`. I also thought about putting the url-generating
function into a parameter, but `render-post` also needs access to the
request handlers.

What approach should I take?

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook

[Yury Bulka]

Oops, small correction:

> The x-expressions need to include hyperlinks to urls
> defined via dispatch-rules in main.rkt, i.e., call the url-generating
> function.

Should be `routing.rkt` instead of `main.rkt`.

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook

[Bogdan Popa]

I solved this in koyo by defining an alternate version[1] of
`dispatch-rules' whose generated `reverse-uri' functions take route
names rather than functions as arguments:

https://koyoweb.org/dispatch/index.html#%28form._%28%28lib._koyo%2Fdispatch..rkt%29._dispatch-rules%2Broles%29%29

The generated function is installed into a parameter on app init and
another function[2] knows how to look it up and apply it when called:

https://koyoweb.org/url/index.html#%28def._%28%28lib._koyo%2Furl..rkt%29._current-reverse-uri-fn%29%29

I hope that helps!

[1]: https://github.com/Bogdanp/koyo/blob/331701e9e8d7f553955ea5a950df424ee13ce9d4/koyo-lib/koyo/dispatch.rkt
[2]: https://github.com/Bogdanp/koyo/blob/331701e9e8d7f553955ea5a950df424ee13ce9d4/koyo-lib/koyo/url.rkt#L60

[Yury Bulka]

Thank you for sharing this!

I'm wondering, if this is a common use case, maybe it is worth adding to
web-server/dispatch in some form?

Or, if not, maybe we can extend the documentation to include some hints
on how to approach this otherwise?

It is great to have powerful libraries outside the main distribution,
but the main distribution is the place where newcomers like me are going
to look first.

--
Yury Bulka
https://mamot.fr/@setthemfree
#NotOnFacebook

[Yury Bulka]

Meanwhile here's my attempt at doing a koyo-like url generation with a
wrapper around web-server/dispatch's url-generating function:

(define-values (app-dispatch app-url)
(dispatch-rules ; the standard one
[...]))

(define (app-url/names route-name . args)
;; define a mapping between symbolic names and handlers
(define route-names
(hash 'item-list item-list-view
'item-detail item-detail-view))
(apply app-url (hash-ref route-names route-name) args))

And then I can store the function in a parameter that is used by the
templates.

It is of course not a general solution (for instance, the rules in
dispatch-rules and the route-names can go out of sync if one forgets to
update either of them) and they are not dynamic.

But for an ultra-minimalistic application this might do when you don't
feel like adding a new external dependency.

[Dominik Pantůček]

Hello,

just a quick and dirty hack I use to get the best of default
dispatch-... for my use-case when dispatching API requests:

(define-for-syntax (dispatch-api-case-helper stx)
(syntax-parse stx
(((method:id (path+args:expr ...) proc:id) rest ...)
#`((("api" path+args ...) #:method #,(symbol->string
(syntax->datum #'method)) proc)
#,@(dispatch-api-case-helper #'(rest ...))))
(((else proc:id))
#'((else proc)))
(()
#'())))

(define-syntax (dispatch-api-case stx)
(syntax-parse stx
((_ rest ...)
#`(dispatch-case
#,@(dispatch-api-case-helper #'(rest ...))))))

(define dispatch-api-request-real
(dispatch-api-case
(get ("number" (number-arg)) api-number-test)
(get ("ping") api-ping)
(post ("auth") auth-login)
(delete ("auth") auth-logout)
(put ("auth") auth-passwd)
(get ("auth" "info") auth-user-info)
(get ("partners") partners-list)
(get ("partners" (string-arg)) partner-detail)
(get ("partners" (string-arg) "payments") partner-payments)
(get ("partners" (string-arg) "debt") partner-debt)
(get ("debts") partners-debts)
(get ("partners" (string-arg) "history") partner-debt-history)
(get ("invoices" "issued") invoices-issued-list)
(get ("invoices" "issued" (string-arg)) invoice-info)
(post ("notes") notes-add)
(else api-404)))

Not very general, but maybe you'll find that useful (especially if the
(string-arg) and similar can make your life easier like it was the case
for me.

When I needed a url-generation function in earlier project, I basically
did the same with more syntax mess around, that used either set! or
parameter from different module to store the dispatch-url -generated
procedure.

Basically it is about customized version of dispatch-rules that does the
dispatch-case and dispatch-url independently and provides the results by
different means.


Cheers,
Dominik

[Greg Hendershott]

Although I haven't tried to use it hands-on, the description of the imperative flavor makes me think it might be intended to help with this?

  https://docs.racket-lang.org/web-server/dispatch.html#%28part._.Imperative_.Dispatch_.Containers%29

p.s. In general you can do mutual requires with lazy-require. However you defer some errors to runtime, and, you need to list explicitly each definition you want to import. IMHO it's better for when the motivation to be lazy is about deferring loading and initializing a module, than it is for mutual imports. For the latter I tend to just try to move the shared definitions to some new module that the others require.

[Yury Bulka]

Greg Hendershott <greghen...@gmail.com> writes:

> Although I haven't tried to use it hands-on, the description of the
> imperative flavor makes me think it might be intended to help with this?
>
> https://docs.racket-lang.org/web-server/dispatch.html#%28part._.Imperative_.Dispatch_.Containers%29

Hm, that's interesting - it seems to allow modifying a set of already
defined urls; but there might be a usage pattern for my use case that
I'm failing to see.

> p.s. In general you *can* do mutual requires with lazy-require. However you

> defer some errors to runtime, and, you need to list explicitly each
> definition you want to import. IMHO it's better for when the motivation to
> be lazy is about deferring loading and initializing a module, than it is
> for mutual imports. For the latter I tend to just try to move the shared
> definitions to some new module that the others require.

Thank you for commenting on that. Good to know.