Skip to content

Ignore default on refinements - #795

Merged
Baccata merged 1 commit into
series/0.17from
dfrancoeur/791-default-refinements
Feb 9, 2023
Merged

Baccata merged 1 commit into
series/0.17from
dfrancoeur/791-default-refinements

Conversation

@daddykotex

@daddykotex daddykotex commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

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
Copy Markdown
Contributor Author

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

@lewisjkl

lewisjkl commented Feb 8, 2023

Copy link
Copy Markdown
Contributor

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

Baccata commented Feb 9, 2023

Copy link
Copy Markdown
Contributor

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

Baccata commented Feb 9, 2023

Copy link
Copy Markdown
Contributor

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
Copy Markdown
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