Skip to content
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

Automatically generate copyWith #43

Open
bartekpacia opened this issue Mar 16, 2022 · 4 comments
Open

Automatically generate copyWith #43

bartekpacia opened this issue Mar 16, 2022 · 4 comments
Labels
enhancement New feature or request

Comments

@bartekpacia
Copy link

bartekpacia commented Mar 16, 2022

It'd be useful if DTOs (or all classes, so commands and queries as well? I really don't know) already came with copyWith() generated.

There could be some flag in contracts_generator.yaml to enable copyWith() generation (to reduce size of the generated code and time of generation when the project doesn't need this feature).

@bartekpacia bartekpacia added the enhancement New feature or request label Mar 16, 2022
@shilangyu
Copy link
Contributor

Maybe the copy withs should be generated in a separate file as extension methods (which then will be re-exported by the contracts)? It will be annoying that contracts will have to be imported to be able to use copy with, but in return it will keep the original contracts file clean.

What do you think?

@bartekpacia
Copy link
Author

IMHO it's okay :)

@shilangyu
Copy link
Contributor

I would like to implement a more modular approach where anyone could provide custom annotations to generated classes. Then, one could annotated DTOs with @CopyWith() if they please. However this has a few issues:

  1. Usually annotating is not enough and some extra modifications have to be applied to the class (for example @JsonSerializable() needs a fromJson constructor and a toJson method)
  2. It needs a more granular approach than "annotate all"/"annotate none" (for example @CopyWith() will crash if annotated on an incorrect class). The means we would need some user-provided resolving unit, ie more than a config file

I hope that point 1 will get solved once promised metaprogramming lands in dart

@bartekpacia
Copy link
Author

Thanks for explaining 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants