Redirection is meant initially to change the page state.
If a redirection to an /@api/xxx url is done, then the server could make the redirection directly - in dev, the client would do it.
Actions (form_api or fetch) request/response fields can be used to plug previous response to next request.
The $pathname, $query, $request, $response fields must be available to the expressions in "request" parameter.
Currently, actions have specific code in their custom-elements to merge the fetch's $response with their redirection attribute.
This allows actions, as clients, to redirect to another page state, and pass parameters through $query to another action which is triggered by the presence of that parameter in the $query.
If an action was redirecting to another action on the same page, it could pass the $response to that action, which then would be fused as an expression in the request parameter of that action, without passing the parameters through a new page state.
If an action is redirection to another action that is not on the same page, the client won't be able to chain those actions. Only the server can.
In practice, chained actions should be maintained on separate "administrative" pages, and client mode would be there as a way to debug them to see how response is merged into next request.
Important note: this mecanism of changing page state is still useful when the user must see different forms because of the result of API calls - e.g, the login form.
Redirection is meant initially to change the page state. If a redirection to an /@api/xxx url is done, then the server could make the redirection directly - in dev, the client would do it.
Actions (form_api or fetch) request/response fields can be used to plug previous response to next request. The $pathname, $query, $request, $response fields must be available to the expressions in "request" parameter.
Currently, actions have specific code in their custom-elements to merge the fetch's $response with their redirection attribute.
This allows actions, as clients, to redirect to another page state, and pass parameters through $query to another action which is triggered by the presence of that parameter in the $query.
If an action was redirecting to another action on the same page, it could pass the $response to that action, which then would be fused as an expression in the request parameter of that action, without passing the parameters through a new page state.
If an action is redirection to another action that is not on the same page, the client won't be able to chain those actions. Only the server can. In practice, chained actions should be maintained on separate "administrative" pages, and client mode would be there as a way to debug them to see how response is merged into next request.
Important note: this mecanism of changing page state is still useful when the user must see different forms because of the result of API calls - e.g, the login form.