-
Notifications
You must be signed in to change notification settings - Fork 322
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider moving State
off of Request
#643
Comments
State
off of Request
State
off of Request
please consider actix-web design, it's state can be multi different type in a server. |
@Silentdoer Could you elaborate more? |
#645 has an impl conflict for some reason but is effectively what I'm proposing here. |
Actix uses a struct async fn handler(a: Data<DB>, b: Data<Template>) ... |
we can get multi states by State argument in handler,like Request ext function? Such as state.server_state(), state.global_state() |
I think there are likely performance implications of doing this, but ext and State could be the same thing potentially. As it is, if you want multiple Similarly, if State weren't a generic, it could be a starting value for each request's ext typemap, which then gets additional values inserted into it. Without any tide change, it would be possible to experiment with this by using a typemap as State and cloning values onto the request typemap in a middleware. I think this might be a nice improvement to tide, but I'd like to see how it looks in an actual application and do some benchmarking |
Ok, thanks for your patience. |
@Fishrock123 This is not a direction I feel comfortable with; as per #642 (comment) in case we cannot set |
Just to be clear, this isn't to solve the issue that #644/#642 solves... to me this is just general ergonomics cleanup that was encountered during those. It seems like there would be a lot less for users to type when they don't need state and also less for middleware which will probably never interact with a specific state type. Related, this is probably a compilation type boost, since there will be less generic functions to worry about. |
@Fishrock123 We considered going down this path a while ago, and one downside of this is that it does break the Extension trait model; in order for this to work both |
As discussed yesterday, this doesn't prevent an extension trait model, although it does change it. If you're just trying to extend pub trait RequestExt {
fn bark(&self) -> String;
}
impl RequestExt for Request {
fn bark(&self) -> String {
"woof".to_string()
}
} However if you have something like pub trait StateRequestExt {
async fn fetch_from_db(&self, req: Request) -> Result;
}
impl StateRequestExt for DatabaseState {
async fn fetch_from_db(&self, req: Request) -> {
// do something with request and state
}
} |
It would be nice to not have
Request
have a generic parameter, for e.g. theAsyncRead
trait which requires pinning. See #642 (comment) for where this was originally encountered.However in interest of keeping middleware simple it would still be nice to allow
(Request, Next) -> Fut<Result<>>
, but forState
it would probably ideal to have an extra parameter, kinda like Surf'sClient
, e.g.(Request, State, Next) -> Fut<Result<>>
.I was thinking maybe
server.middleware()
/ endpoints could takeimpl Into<Middleware<State>>
/ endpoint, and so then that trait could be applied to both of the above with an extra function wrapper for the simple case, allowing both to work, and scopingState
to the middleware/endpoint stack.The text was updated successfully, but these errors were encountered: