oxidecomputer / oxidecomputer/typify
Use names of children as a source for current object naming
Nobody has claimed this yet.
- Dominant language
- Rust
- Stars
- 898
- Forks
- 114
- Avg merge
- 4h 18m
- Merged PRs (30d)
- 14
Description
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.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Begin with the oneOf enum-generation path that currently emits Variant0 and Variant1; compare it with the oneOf-only case described in the issue. Use the provided OpenAPI examples, especially StateChangeCauseView, to check that child titles produce Result and Error while unnamed children retain a fallback name. Done means generated Rust variants are more human-readable without breaking existing naming.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- rust
- Domain
- compilers, developer-experience
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100