-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Move FromRequest
and IntoResponse
into new axum-core
crate
#564
Conversation
FromRequest
and IntoResponse
into their own crateFromRequest
and IntoResponse
into new axum-core
crate
I have an idea on how to resolve the type parameter default issue! We can have a |
Okay, so to elaborate: The crate feature will be a With this scheme, we could even keep the
So.. Does that sound good or tad to crazy and unprecedented? 😄 |
You can do something like |
Ooohh, this is also an interesting possibility. It doesn't allow to keep the
Actually, it should not be a problem to just have a separate trait FromRequest<B = crate::body::Body>: axum_core::FromRequest<B> {}
impl<B, T> FromRequest<B> for T where T: axum_core::FromRequest<B> {} Which effectively works as a trait alias. |
This would mainly benefit users using |
It would be so nice if |
Also worth noting that there is discussion in hyper about splitting the |
Right, yeah. The alternative would be to copy the core FWIW, I think trait aliases also won't allow |
I'll try an implement the suggestions here and see what it feels like to use them. |
I’m leaning towards dropping the default types. It’s less ergonomic but also easier to understand and easy to document. When hyper moves towards 1.0 we can reevaluate. |
c77f3cc
to
9123996
Compare
@jplatte How do you feel about the state of this? As I wrote above I'm fine with it, even though its slightly less ergonomic. Would rather keep things conceptually simple and explore different solutions in the future. I would also like to get 0.4 out sometime soon-ish together with axum-extra since I need those for something else I'm building 🤓 |
The ergonomic hit only applies to writing custom extractors now with |
Yep that’s correct. |
@davidpdrsn Shouldn't the macros in the |
That would require the macros to be public API, which I don’t want. |
@davidpdrsn Why the |
For when we have deprecated enum variants in some of the rejections. Please hop on discord for future questions like this. Otherwise everyone watching the repo keep getting notifications. |
I was confused because
Sorry, I don't have Discord. I thought that asking a question about a particular piece of code in the PR where it was last touched was appropiate. If you don't want watchers to get notified about questions, you should probably update the readme, since it states that opening issues to ask questions is fine, and that also creates notifications for watchers. |
Hm good question 🤔 I don't specifically remember.
If you don't have discord then its no big deal, the questions just feel slightly unrelated to this PR but its alright. Questions are very welcome 😊 EDIT: You're also welcome to open a discussion. |
Fixes #561
What changed:
B
type param inFromRequest
andRequestParts
is gone 😞 Users will now have to doimpl FromRequest<axum::body::Body> ...
to get the previous behavior. This is annoying I think. Not quite sure if getting rid of the dependency on hyper is worth it. Haven't made up my mind quite yet.BodyAlreadyExtracted
,HeadersAlreadyExtracted
, andExtensionsAlreadyExtracted
now have public constructors (they're unit structs) since they're used in both axum-core and axum.axum::Error
has moved toaxum_core::Error
(still re-exported from the old location) and itsnew
constructor is now public since its used in both crates. I'm not very happy about this since users outside of axum shouldn't create this type. It only exists as a wrapper that makesBoxError
implementstd::error::Error
.JsonRejection
has changed a bit. It now containsBytesRejection
instead ofBodyAlreadyExtracted
since it callsBytes::from_request
.hyper::body::to_bytes
into axum-core. Luckily it had no dependencies on hyper itself.hyper::Body
no longer implementsFromRequest
. We previously hadRawBody
as the wrapper for it. I think thats a fine.Headers
needs to live in core because ofimpl IntoResponse for (StatusCode, Headers)
and friends. Not very happy with this but loosing those impls would hurt ergonomics so think the tradeoff is fine.These things are obviously breaking so will have to be released in 0.4
TODO