Skip to content

fix: Add custom decoder for TypeDecoder#27

Merged
EnriqueL8 merged 2 commits intomasterfrom
fix_typedecoder
Jul 5, 2018
Merged

fix: Add custom decoder for TypeDecoder#27
EnriqueL8 merged 2 commits intomasterfrom
fix_typedecoder

Conversation

@EnriqueL8
Copy link
Copy Markdown
Contributor

When generating swagger with Query Parameters, Neil realised that the TypeDecoder could not decode some special types like GreaterThan. This is due to the fact that these types contain a Operator Enum field.

When decoding, the decoder has to return a value in a specific type. In this example, the value returned is a String:

value = container.decode(Sting.self, key: .key)

In the case of the TypeDecoder, it returns dummy values to keep the compiler happy. When decoding an Enum is returns a dummy value. This causes an error because that dummy value is not of the same type as that Enum. Furthermore, we could not construct an enum from rawValue because none of the cases match the empty string.

To solve this issue, we implement a custom decoder for these special types where we decide to not decode the Operator Enum field since it already has a default value. We will only decode the value field associated with those types.

@EnriqueL8 EnriqueL8 self-assigned this Jul 3, 2018
Copy link
Copy Markdown
Contributor

@ianpartridge ianpartridge left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks fine, but I'm wondering... Why are the operators var instead of let? For example in struct GreaterThan we have:

private var `operator`: Operator = .greaterThan

If this was:

private let `operator`: Operator = .greaterThan

would the TypeDecoder be able to decode?

@EnriqueL8
Copy link
Copy Markdown
Contributor Author

AMAZING! I did not see that - works perfectly

@ianpartridge
Copy link
Copy Markdown
Contributor

Excellent, and I think we can fix this in a patch release?

@EnriqueL8
Copy link
Copy Markdown
Contributor Author

yeah - I think a patch will be fine even if we are modifying external "api"

@EnriqueL8 EnriqueL8 merged commit 83e5cb3 into master Jul 5, 2018
@EnriqueL8 EnriqueL8 deleted the fix_typedecoder branch July 5, 2018 11:23
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