Open nik-here opened 7 months ago
I was thinking of something similar, albeit more focused on the type parameters (and not the properties):
#[derive(serde::Serialize, serde::Deserialize, utoipa::ToSchema)]
struct Pet<T> {
id: u64,
name: String,
age: Option<i32>,
generic_property: T,
}
struct Pet2(Pet<String>);
impl<'__s> utoipa::ToSchema<'__s> for Pet2 {
fn schema() -> (&'__s str, utoipa::openapi::RefOr<utoipa::openapi::schema::Schema>) {
Pet::<String>::to_schema_builder()
.with_type_parameter_alias::<T>("String")
.build()
}
}
We already have ObjectBuilder
. So maybe ObjectBuilder::with_type_parameter_alias()
would be better.
Anyway the crux of it is implementing with_type_parameter_alias::<P>()
to be able to replace the token used when building the schema.
What about an another approach to the macro
ToSchema
for aliases? This library could add another trait like this:The purpose of
build_schema
is to dynamically generate new schemas, depending on the given HashMapgenerice_properties
.This trait would be implemented by the macro
ToSchema
instead of the traitToSchema<'__s>
for generic structs. However non generic structs implementToSchema<'__s>
directly. On top theToSchema<'__s>
trait would lose the functionaliases
.Each alias would implement
ToSchema<'__s>
separately and they callbuild_schema
with a generated HashMap.Here is an quick example, how an implementation by the macro should look like:
As you can see this issue https://github.com/juhaku/utoipa/issues/703 would be fixed by this.
Additionally it would be possible to implement a macro
#[alias]
, which is mentioned here https://github.com/juhaku/utoipa/issues/790#issue-1970346581.What are your thoughts on this?