any use from integrate with axum extra typed path?

[dzmitry-lahoda]

i wonder, if can reduce any boilerplate by some integration with axum extra typed path?

[jplatte]

It's not a bad idea. If aide was to wrap the typed_* methods from axum-extra, one could derive TypedPath + Deserialize + JsonSchema + OperationIo on a typed-path struct and it should "just work".

Maybe we should have an extra #[aide] attribute too, though I think just #[aide(input_with = "axum::extrat::Path<Self>")] would work as a start.

Are you interested in working on this? If yes, do you need any guidance?

[dzmitry-lahoda]

I was thinking to start from macro-free (function+types only) solution. Do you think it is viable?

Just like in examples directory.

[jplatte]

Yeah, wrapping the typed_* methods should not require any macro changes. What I mentioned about an attribute would likely only be a convenience feature on top of the existing input_with functionality.

[dzmitry-lahoda]

Are you interested in working on this?

seems i am working on this. i guess can get it myself. so prefer to do minimal amount of changes to support basics to get things working.

[dzmitry-lahoda]

@jplatte I plan to start tinkering with it on monday.

i am trying give method with typed path, return value, query, body with Deserialize, JsonSchema and TypedPath, infer all what is possible, like including docs to be read from doc comments. Do not want write docs as separate step (similar like displaydoc::Display can be used to provide error message in pure Rust; in API just will use JsonSchema).

Just purely functional approach, no extending #[aide].

If aide was to wrap the typed_* methods from axum-extra, one could derive TypedPath + Deserialize + JsonSchema + OperationIo on a typed-path struct and it should "just work".

If yes, do you need any guidance?

I general I am fine with given guidance, so anything to mention will route me to right direction faster are welcomed.

[dzmitry-lahoda]

error[E0119]: conflicting implementations of trait `OperationInput` for type `bytes::Bytes`
   --> crates/aide/src/axum/inputs.rs:173:1
    |
173 | / impl<T> OperationInput for T
174 | | where
175 | |     T: schemars::JsonSchema + axum_extra::routing::TypedPath,
    | |_____________________________________________________________^ conflicting implementation for `bytes::Bytes`
    |
   ::: crates/aide/src/impls/bytes.rs:10:1
    |
10  |   impl OperationInput for Bytes {
    |   ----------------------------- first implementation here
    |
    = note: upstream crates may add a new impl of trait `schemars::JsonSchema` for type `bytes::Bytes` in future versions
    = note: upstream crates may add a new impl of trait `std::fmt::Display` for type `bytes::Bytes` in future versions
    = note: upstream crates may add a new impl of trait `axum_extra::routing::TypedPath` for type `bytes::Bytes` in future versions

For more information about this error, try `rustc --explain E0119`.
warning: `aide` (lib) generated 1 warning

not sure what to do with this. TypedPath is trait.

[dzmitry-lahoda]

mod private {
    use super::*;
    trait MyOperationInput: schemars::JsonSchema + axum_extra::routing::TypedPath {}


#[cfg(feature = "axum-extra-typed-routing")]
impl<T> OperationInput for T
where
    T: MyOperationInput,
{
    fn operation_input(ctx: &mut crate::generate::GenContext, operation: &mut Operation) {
        let schema = ctx.schema.subschema_for::<T>().into_object();
        let params = parameters_from_schema(ctx, schema, ParamLocation::Path);
        add_parameters(ctx, operation, params);
    }
}
}

   Compiling aide v0.14.2 (/home/dz/github.com/tamasfe/aide/crates/aide)
warning: unused import: `schemars::JsonSchema`
   --> crates/aide/src/axum/mod.rs:748:13
    |
748 |         use schemars::JsonSchema;
    |             ^^^^^^^^^^^^^^^^^^^^
    |
    = note: `#[warn(unused_imports)]` on by default

error[E0119]: conflicting implementations of trait `operation::OperationInput` for type `Box<_>`
   --> crates/aide/src/axum/inputs.rs:179:1
    |
179 | / impl<T> OperationInput for T
180 | | where
181 | |     T: MyOperationInput,
    | |________________________^ conflicting implementation for `Box<_>`
    |
   ::: crates/aide/src/impls/mod.rs:117:1
    |
117 | / impl<T> OperationInput for Box<T>
118 | | where
119 | |     T: OperationInput,
    | |______________________- first implementation here
    |
    = note: downstream crates may implement trait `axum_extra::routing::TypedPath` for type `std::boxed::Box<_>`
    = note: downstream crates may implement trait `axum::inputs::private::MyOperationInput` for type `std::boxed::Box<_>`

did not helped.
also, cannot use unstable features of rust.

[dzmitry-lahoda]

@jplatte any ideas?

Currently Path works because it is concrete type

impl<T> OperationInput for Path<T>
where
    T: JsonSchema,
{
    fn operation_input(ctx: &mut crate::generate::GenContext, operation: &mut Operation) {
        let schema = ctx.schema.subschema_for::<T>().into_object();
        let params = parameters_from_schema(ctx, schema, ParamLocation::Path);
        add_parameters(ctx, operation, params);
    }
}

May be can do ApiTypedPath<T:TypedPath> like thing?

[dzmitry-lahoda]

#[derive(aide_macros::OperationIo)]
#[aide(input_with = "axum::extract::Path<Self>")]

Does not really works for me. Because I want TypedPath doc comments to be description of Operation.

So need other extractor?

#[aide(input_with = "axum::extract::TypedPath<Self>")]

[dzmitry-lahoda]

like this

impl OperationInput for TestPath
{
    fn operation_input(ctx: &mut aide::generate::GenContext, operation: &mut Operation) {

        let mut schema = schemars::schema_for!(Self);
        let description = schema.schema.metadata().description.clone();
        let summary = schema.schema.metadata().title.clone();
        // let x = schema.schema.metadata().clone();
        
        let mut schema = ctx.schema.root_schema_for::<TestPath>().schema;
        
        let params = parameters_from_schema(ctx, schema, ParamLocation::Path);
        operation.description = description;
        //operation.summary = summary;
        add_parameters(ctx, operation, params);
    }
}

[dzmitry-lahoda]

@jplatte need to pick

#[aide::axum::routing::TypedPath]
#[typed_path("foo/bar")]

macro which just addes axum extra and imps OperationInput with proper description (doc comment on TypedPath enabled struct) in OperationInput.

OR

#[axum_extra::routing::TypedPath]
#[typed_path("foo/bar")]
#[derive(aide_macros::OperationIo)]
#[aide(input_with = "aide::axum::extract::TypedPath<Self>")]

OR

#[derive(aide_macros::OperationIo)]
#[aide(typed_path = "foo/bar")]

?

Would be awesome to have some decision today, as I am on tight schedule.

[tamasfe]

I'd pick the first.

Definitely not the last in order to keep axum-specific features out of generic macros.

[jplatte]

Yeah, first one makes sense to me too.

[dzmitry-lahoda]

Okey, tried, but """failed""".

Problem with to do 1,

#[aide::axum::routing::TypedPath]
#[typed_path("foo/bar")]

Seems that I need copy paste whole well tested TypedPath from macro thing (unless using other type of macro, not derive, like #[TypedPath]) . Which is well written and big. so I doubt it is good for basic support.

I looked into what to to make extractor TypedPath, but appears that machinery which does Path good is private to axum crate.
Possible, but also will be some kind of copy paste.

From other side, may be Path to be extended with description?