Skip to content

Conversation

markbradley27
Copy link

What type of PR is this? (check all applicable)

  • Refactor
  • Feature
  • Bug Fix
  • Optimization
  • Documentation Update
  • Go Version Update
  • Dependency Update

Description

Rather than setting defaults on the output of the decode, this sets defaults on the input. This means that all of the fancy logic in decode that handles custom converters and TextUnmarshallers can apply to default values as well.

DRAFT: Still needs some error handling updates, encode support, and general polish, but sending this out as a draft to demonstrate that the approach works. You can see that the unit test still passes for all of the previously supported default types, as well as a new custom type. I'll try to get around to polishing this up soon.

Related Tickets & Documents

Added/updated tests?

  • Yes
  • No, and this is why: please replace this line with details on why tests
    have not been included
  • I need help with writing tests

Run verifications and test

  • make verify is passing
  • make test is passing

@PapaCharlie
Copy link

This is awesome, I also thought it was quite weird that applying the default values required a whole new piece of code when it's functionally the same thing as parsing the form values. I see you commented out some tests, mind if I take a crack?

@markbradley27
Copy link
Author

@PapaCharlie Not at all! I keep meaning to get back to this and just haven't found the time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[FEATURE] default values for custom types

2 participants