Term `middleware` is confusing; other thoughts about simpleui

[whamtet]

Excellent feedback @telekid,

I think you're right that we should use a better name than middleware for the reason you state. The key idea is that we might want to transform the request before we bind request parameters to the function argument. We only want to do that when the function is being updated, not on the initial render. That's why its different from regular ring middleware. For the case where you want to transform the response object that should be handled by regular ring middleware.

For the case when you want to update e.g. headers simply use the req middleware (name soon to be changed) as it receives the entire request object. I think prebind might be a better name than middleware, do you agree?

[telekid]

The key idea is that we might want to transform the request before we bind request parameters to the function argument

Makes sense.

We only want to do that when the function is being updated, not on the initial render.

Makes sense, though (I think?) I can imagine a different implementation that conditionally applies a traditional ring middleware within the standard ring middleware chain (but included via your current req metadata strategy) when the component is serving as an endpoint root, but not when it is participating as a child component of a different render.

For the case when you want to update e.g. headers simply use the req middleware (name soon to be changed) as it receives the entire request object

In my case I'm interested in updating response headers, not request headers, so this won't quite do. I am still having trouble imaging how I might modify response headers as part of the same request that is returning an HTML fragment as part of a ctmx component re-render. Where would I put that traditional middleware? Should I modify the routes returned by ctmx's make-routes function, manually appending middleware to the route that corresponds to the component in question? My initial reaction is that doing so feels a bit cumbersome.

[whamtet]

I would suggest you have two options. Firstly you can always return a regular ring response map from component update. By default when you return html represented as hiccup it is rendered and put into a response map. If the component returns a map ctmx assumes it's already a valid ring response.

You can also use regular ring middleware and check for the HX-Request=true header. Details. This is not set on initial render. The limitation is that it doesn't know exactly which component it is going to.

I could modify the existing middleware option to receive both request and response but I wonder if its easier to just return a map directly from the component. What do you think?

[telekid]

Apologies for the slow response!

I could modify the existing middleware option to receive both request and response but I wonder if its easier to just return a map directly from the component. What do you think?

This makes sense. Not sure why this hadn't occurred to me the first time around. I'll give this a shot next time I'm working in that area of my codebase.

Thanks for your help!

[whamtet]

@telekid here's a PR to address the issue https://github.com/whamtet/ctmx/pull/28/files