Replies: 1 comment
-
|
@NormySan I understand where you're coming from. But there is no way to properly document the API without an attribute on the enum values, which is what this provides, as well as a way to selectively expose enum values over the API, where you might not want all exposed. I think the goal of isolating your core domain and API is noble. But we haven't found any reason where attributes (metadata) is a violation of that principle. As for the solution to this, I think maybe |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
We've started getting deprecation errors related to our enums since we don't explicitly add the
TypeandEnumValueattributes to them. In our case this is causing issues since our design philosophy is that the API layer should not bleed into the core domain which it does when we start adding API-specific attributes to our core domain enums. The whole reason why we choose this library was because of its superb support for this pattern. But with these new additions it doesn't look like there is a nice way to avoid this unless we manually add the enums through a custom type mapper.So I'm starting this discussion to get some insight into this and maybe see if there are good solutions that we could implement in our project. I would be open to provide a PR that could help in cases like ours where the core domain should not contain any API related definitions.
Beta Was this translation helpful? Give feedback.
All reactions