Fork me on GitHub
#reitit
<
2020-10-27
>
seqable01:10:36

Bit confused about getting frontend to leave anchor links alone.

Precicate to check if the anchor click event default action
should be ignored. This logic will ignore the event
if anchor href matches the route tree, and in this case
the page location is updated using History API.

seqable01:10:03

but using ignore-anchor-click? all my anchor links just take me to a blank page instead of navigating on-page to where they should. Have replaced them with scroll-to events instead which is ok but seems a bit silly

seqable09:10:36

:ignore-anchor-click? (constantly true) did the trick, but still a bit confused then on the purpose of the included pred - why'd one ever want to let reitit start a navigation event and suppress on-page nav when there's no router match but an anchor is available? Seems nonintuitive, might be wise to have docs clarify a bit there.

juhoteperi10:10:39

@joen.tolgraven As the docs say, it will only affect anchors which match the route tree.

seqable11:10:26

that was not my experience. If it did that would've made total sense!

juhoteperi11:10:30

That's how it is written, though bugs are possible. But if is ignoring the default handler, you should see the on-navigate call and the match from the handled anchor.

juhoteperi11:10:19

If the match is nil and on-navigate is called something is broken, if match is not empty, your route tree is somehow matching the anchor (not-found route or something)

seqable11:10:25

Cheers, bug makes a lot more sense yeah. Have since changed route tree and can't replicate with current setup, will have a look back later. Match wasn't nil but :name was. No fallback routes. Will try investigate

Eyal H16:10:33

Hey, I'm using the coerce-response-middleware middleware to validate the response returning from the API. My question is as follows: • I'm doing some logic which is related to the response I'm returning in the :handler endpoint • I want to be able to do this logic after the coerce-response-middleware is happening, to be sure that the response is valid How do I accomplish that?

Eyal H07:10:43

@U055NJ5CC Your help is much appriciated

ikitommi16:10:56

@U01AV7MNK3P no default way to do that, as response coercion happens in mw chain after handler has returned

ikitommi16:10:34

you could add a custom mw into the chain before the response-coercion to do that

ikitommi16:10:24

or you could extend reitit: • create a new mw which adds a :post-handler route data key, with a value of a fn of type response -> reaponse • you can use :compile keys to make it good: read the :post-handler at router creation time and return a mw that executes the handler in return phase. If that doesn't exist, do not mount the mw • add a :spec key to mw to document the new key • add the new mw into chain • add a :post-handler key to routes, it is run after the coercion • as route data accumulates, you can put :post-handler anywhere in the route tree and all endpoints under it have that hope this helps.

ikitommi16:10:57

["/api" {:get {:handler ..., :post-handler (fn [res] ....log the data... res)}]

ikitommi16:10:50

you could also make the :post-handler accept a vector of fns and compose those using comp

markbastian16:10:11

Is there a way to add field level documentation, like a summary key on the params themselves?

ikitommi16:10:24

or you could extend reitit: • create a new mw which adds a :post-handler route data key, with a value of a fn of type response -> reaponse • you can use :compile keys to make it good: read the :post-handler at router creation time and return a mw that executes the handler in return phase. If that doesn't exist, do not mount the mw • add a :spec key to mw to document the new key • add the new mw into chain • add a :post-handler key to routes, it is run after the coercion • as route data accumulates, you can put :post-handler anywhere in the route tree and all endpoints under it have that hope this helps.