Server Function Implicit Arguments #5260
Description
Feature Request
One of the features that make the Dioxus server function model so powerful, is the ability to attach custom extractors just by appending some custom type that implements the FromRequestParts trait from Axum, causing the server to run its from_request_parts method on each request, which builds an instance of the given type and makes it accessible to the handler logic, so that the actions performed and/or data returned may depend on these additional parameters that the client doesn't need to send when making the request, or at least not explicitly pass down as function arguments.
One particular use case where this becomes really useful, is for implementing authentication based on a session token that the client stores as a cookie, that's implicitly sent on every request, allowing the server to resolve the requesting user's identity, to verify granted permissions, etc. This, I believe, results in a very elegant solution, since it makes possible for all session logic to be effectively managed from the server, by basically reading/setting Cookie/Set-Cookie headers, without requiring any client-side implementation. However this only works precisely because the nature of a cookie is such that the browser takes care of automatically setting it and sending it based on a simple system that can effectively be controlled completely from the server.
A similar kind of situation where an approach like this, I believe, would make sense, is when using local/session storage entries representing user configuration parameters: it would improve ergonomics significantly if one could just as easily implement a separate trait (e.g. UpdateRequestParts) for such a custom type, declaring a method that runs client-side on each request and can read and modify its parts before being sent.
All in all, this would make it such that attaching a type like this to the attribute of a server function, results not only on a server-side extractor, but rather something like a fully equipped argument, one that the client can "write" into the request, and then the server can "read" from it, and expose to the corresponding handler, all of this happening implicitly.
Another interesting case that I've thought of where this functionality could be useful, is for things like logging, where you potentially want some global service to run on every request, or the ones marked for that, like for debugging purposes (e.g. printing to the browser console the url of each request).
Would this make sense to you?
Thanks!