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

Ignore default on refinements #795

Merged
merged 1 commit into from
Feb 9, 2023

Conversation

daddykotex
Copy link
Contributor

@daddykotex daddykotex commented Feb 8, 2023

In this PR, I attempt to solve #791 which renders product member as if they were required. The issue happens because the Smithy definitions happen in a v1 IDL language version and the shape in question gets Default trait added.

The boolean that indicates whether or not the member should be wrapped in option check for Required or Default trait on the shape, and if they are there, it will make it required.

So a non-required field, gets an automatic Default because it is defined in a v1 spec, and thus the rendering code scraps the optionality off of it.

In this PR, I replace the Default trait presence check with a more involved one. The check is now:
if hasDefault && typeIsNotExternal.

I assume a Type.external necessarily mean a refined type (but I'm not 100% sure about that).

In any case, this change behaves
how I want and we can see that in the few examples that are updated in this PR. I added and extra field with @required to make sure it was still respected.

In this PR, I attempt to solve #791 which renders product
member as if they were required. The issue happens because
the Smithy definitions happen in a v1 IDL language version
and the shape in question gets `Default` trait added.

The boolean that indicates whether or not the member should
be wrapped in option check for `Required` or `Default` trait
on the shape, and if they are there, it will make it required.

So a non-required field, gets an automatic `Default` because it
is defined in a v1 spec, and thus the rendering code scraps the
optionality off of it.

In this PR, I replace the `Default` trait presence check with
a more involved one. The check is now:
`if hasDefault && typeIsNotExternal`.

I assume a Type.external necessarily mean a refined type (but
I'm not 100% sure about that.

In any case, this change behaves
how I want and we can see that in the few examples that are
updated in this PR. I added and extra field with `@required` to
make sure it was still respected.
@daddykotex
Copy link
Contributor Author

This comment is relevant for a better understanding: #791 (comment)

@lewisjkl
Copy link
Contributor

lewisjkl commented Feb 8, 2023

Looks good to me!

I assume a Type.external necessarily mean a refined type (but I'm not 100% sure about that).

I think you are right here, I think we only use ExternalType for refinements.

@Baccata
Copy link
Contributor

Baccata commented Feb 9, 2023

I assume a Type.external necessarily mean a refined type (but I'm not 100% sure about that).

That's a fair assessment, imho

@Baccata
Copy link
Contributor

Baccata commented Feb 9, 2023

I think we're gonna need a custom validator to issue a warning in cases when we have refinements triggered on members that have default values. But I'm happy to defer that, as this PR improves the situation already.

@Baccata Baccata marked this pull request as ready for review February 9, 2023 10:15
@Baccata Baccata merged commit 6328cf8 into series/0.17 Feb 9, 2023
@Baccata Baccata deleted the dfrancoeur/791-default-refinements branch February 9, 2023 10:16
@daddykotex
Copy link
Contributor Author

I think we're gonna need a custom validator to issue a warning in cases when we have refinements triggered on members that have default values. But I'm happy to defer that, as this PR improves the situation already.

Already on it 👍

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

Successfully merging this pull request may close these issues.

3 participants