Use names of children as a source for current object naming
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Stack tecnológico
- rust
Línea de trabajo
Comienza con la ruta de generación de enums de oneOf que actualmente emite Variant0 y Variant1; compárala con el caso que solo usa oneOf descrito en el issue. Usa los ejemplos de OpenAPI proporcionados, especialmente StateChangeCauseView, para comprobar que los títulos de los elementos hijos producen Result y Error, mientras que los elementos hijos sin nombre conservan un nombre alternativo. La tarea estará terminada cuando las variantes de Rust generadas sean más legibles sin romper la nomenclatura existente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Hi! So, I have this spec:
Spec with oneOf and additional properties
{
"openapi": "3.0.0",
"info": {
"title": "My API",
"version": "1.0.0"
},
"paths": {
"/my_request": {
"post": {
"operationId": "my_request",
"requestBody": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/JsonRpcResponse_for_Result_and_Error"
}
}
},
"required": true
},
"responses": {
"200": {
"description": "",
"content": {
"application/json": {
"schema": {
"type": "string"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"JsonRpcResponse_for_Result_and_Error": {
"oneOf": [
{
"properties": {
"result": {
"type": "string"
}
},
"required": [
"result"
],
"type": "object",
"title": "Result"
},
{
"properties": {
"error": {
"type": "string"
}
},
"required": [
"error"
],
"type": "object",
"title": "Error"
}
],
"properties": {
"id": {
"type": "string"
}
},
"required": [
"id"
],
"title": "JsonRpcResponse_for_Result_and_Error",
"type": "object"
}
}
}
}
And it produces the following code:
#[derive(:: serde :: Deserialize, :: serde :: Serialize, Clone, Debug)]
#[serde(untagged)]
pub enum JsonRpcResponseForResultAndError {
Variant0 {
id: ::std::string::String,
result: ::std::string::String,
},
Variant1 {
error: ::std::string::String,
id: ::std::string::String,
},
}
It's not a big deal, nor it is a bug. But a suggestion for improvement. The struct generates Variant0 and Variant1 enum options. In this case, what can be generated instead is Result and Error enum options:
#[derive(:: serde :: Deserialize, :: serde :: Serialize, Clone, Debug)]
#[serde(untagged)]
pub enum JsonRpcResponseForResultAndError {
Result {
id: ::std::string::String,
result: ::std::string::String,
},
Error {
error: ::std::string::String,
id: ::std::string::String,
},
}
Like it does for the following schema:
Spec with oneOf only
{
"openapi": "3.0.0",
"info": {
"title": "My API",
"version": "1.0.0"
},
"paths": {
"/my_request": {
"post": {
"operationId": "my_request",
"requestBody": {
"content": {
"application/json": {
"schema": {
"$ref": "#/components/schemas/JsonRpcResponse_for_Result_and_Error"
}
}
},
"required": true
},
"responses": {
"200": {
"description": "",
"content": {
"application/json": {
"schema": {
"type": "string"
}
}
}
}
}
}
}
},
"components": {
"schemas": {
"JsonRpcResponse_for_Result_and_Error": {
"oneOf": [
{
"properties": {
"result": {
"type": "string"
},
"id": {
"type": "string"
}
},
"required": [
"result",
"id"
],
"type": "object",
"title": "Result"
},
{
"properties": {
"error": {
"type": "string"
},
"id": {
"type": "string"
}
},
"required": [
"error",
"id"
],
"type": "object",
"title": "Error"
}
],
"title": "JsonRpcResponse_for_Result_and_Error",
"type": "object"
}
}
}
}
So I guess the change may be to use titles of object's children as a source for naming current enum Option.
I would provide a real example we are dealing with at https://github.com/near/nearcore/, which is a spec for StateChangeCauseView.
The result is kinda messy - you can see Variant10. The original type is actually a struct with enum flattened into it
I believe fixing this would provide a more human readable code and would be better for developer experience for most cases.
- Lenguaje dominante
- Rust
- Estrellas
- 898
- Forks
- 114
- Merge medio
- 4 h 18 min
- PR fusionados (30 d)
- 14
Guía de contribución
No hay ninguna guía de contribución indexada para este repositorio
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de oxidecomputer/typify
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
oxidecomputer/typify#1077 · 1 comentario ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 55/100
oxidecomputer/typify#1075 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 50/100
oxidecomputer/typify#1060 ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 48/100
oxidecomputer/typify#1059 ·
-
Dificultad 3/5 1-2 días Aptitud para principiantes 65/100
oxidecomputer/typify#1022 · 1 comentario ·
Todos los issues de oxidecomputer/typify
Issues similares
-
bug github_actions
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
registrystack/registry-stack#1393 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
longbridge/gpui-kit#3223 ·
-
bug engine
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
rocky-data/rocky#2181 ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 70/100
oasisprotocol/oasis-sdk#2523 ·
-
[indexer] [QA] Add a focused test for the new NonRetryableError / assertSocketAlive() behavior. Abiertobot:ai-assisted component:indexer QA-roadmap status:untriaged
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
midnightntwrk/midnight-indexer#1557 ·