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

Make defaultValue take precedence over useKeysAsDefaultValue if present #672

Closed
wants to merge 2 commits into from

Conversation

JonathanSun
Copy link
Contributor

@JonathanSun JonathanSun commented Nov 3, 2022

Why am I submitting this PR

When useKeysAsDefaultValue=true, only apply the replacement if no defaultValue is specified.

Does it fix an existing ticket?

Yes #671

Checklist

  • only relevant code is changed (make a diff before you submit the PR)
  • tests are included and pass: yarn test (see details here)
  • documentation is changed or added

@karellm
Copy link
Member

karellm commented Nov 8, 2022

@JonathanSun This is a breaking change so I'm very reluctant to add this to the project as it will introduce an unexpected behaviour for current users.

That said I think what you want to do make total sense. I believe a much better solution is to rely on the defaultValue option and pass it a function. The only argument missing to do what you want is the extracted default value.

I believe we could remove skipDefaultValues and useKeysAsDefaultValue altogether and simplify the API while at it!

What do you think?

@JonathanSun
Copy link
Contributor Author

@JonathanSun This is a breaking change so I'm very reluctant to add this to the project as it will introduce an unexpected behaviour for current users.

That said I think what you want to do make total sense. I believe a much better solution is to rely on the defaultValue option and pass it a function. The only argument missing to do what you want is the extracted default value.

I believe we could remove skipDefaultValues and useKeysAsDefaultValue altogether and simplify the API while at it!

What do you think?

Sure. See #676 for this suggestion. It's still a breaking change, but I agree that it is a cleaner, more powerful option.

@karellm
Copy link
Member

karellm commented Nov 8, 2022

Closing in favour of #676

@karellm karellm closed this Nov 8, 2022
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.

None yet

2 participants