-
-
Notifications
You must be signed in to change notification settings - Fork 6.4k
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
[REQ] [dart-dio] Refactor api methods and classes #15477
Comments
@jaumard (2018/09) @josh-burton (2019/12) @amondnet (2019/12) @sbu-WBT (2020/12) @kuhnroyal (2020/12) @agilob (2020/12) @ahmednfwela (2021/08) |
I don't like the idea of mixing the methods. class PetApi {
final PetApiRaw rawApi;
...
Future<Response<Pet>> getPetById(String id, ...) async {
// serialize ...
final rawResponse = await rawApi.getPetById(id);
/// deserialize ...
return response;
}
} This would still allow consumers to construct/use/extent the raw API but it doesn't clutter the typed API classes. |
I am in favor of this as well, this will also minimize breaking changes |
@kuhnroyal please check this PR #15485 |
@ahmednfwela I thought about this for a while, but had not time to thoroughly go through your PRs. But due to the limited amount of time left for 7.0.0, I think we should do this in a new |
@kuhnroyal I think this separation is critical right now, since maintaining the generator at its current state will be impossible once more features are added. this PR was pretty much done except for the handling of container variable types |
I absolutely agree, I am just wondering if it is better to introduce a new experimental generator that can replace the old one in a later version. These changes are massive and I don't feel comfortable merging them into the current generator. |
@kuhnroyal The thing is, I was planning on merging both the just look at the amount of issues |
But there is no need to break 2 generators and replace them with one that is mostly untested when the release comes. |
the main problem with that is:
UPDATE: I have changed the PR to introduce a new generator instead. |
Is your feature request related to a problem? Please describe.
currently
dart-dio
e.g.:
json_serializable
: https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/dart/libraries/dio/serialization/json_serializable/apibuilt_value
: https://github.com/OpenAPITools/openapi-generator/tree/master/modules/openapi-generator/src/main/resources/dart/libraries/dio/serialization/built_value/apiDescribe the solution you'd like
We can mitigate both of these issues with some non-breaking refactor of the generated API classes, essentially removing that
api
mustache folder, that each serializer has to adapt.IJsonSerializationRepository
which all serialization options have to implement.It will include these 2 abstract methods
The text was updated successfully, but these errors were encountered: