-
Notifications
You must be signed in to change notification settings - Fork 21
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
fix(kselect): accept null in v-model [KHCP-13685] #2450
base: main
Are you sure you want to change the base?
Conversation
✅ Deploy Preview for kongponents-sandbox ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
✅ Deploy Preview for kongponents ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM! Thanks Max!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
issue: we should not be updating OSS component behavior based on Kong APIs that will change over time.
The host app should be responsible for handling sending the proper values to the API
Our internal requirements seem to reflect a common pattern, and there are considerations specifically from the frontend perspective. I suggest we focus the discussion on whether we want to allow
|
But that's basically what we are already doing and doesn't help us at all, plus it doesn't work for all Kongponents (KSelect) The problem with this approach is it doesn't save us any work, we still have to do the conversion from away from |
This should be expected then. We shouldn't be changing the component behavior based on the requirements of our APIs. Just as certain endpoints may require Mutating data to be acceptable by an external interface (e.g. Kong APIs) should be the responsibility of the host application. |
I wasn't specifically referring to how accepting null makes it easier to connect to our backend API. Rather, if we're using
I agree. However, in this case, I was thinking less about it being a backend requirement and more about whether we should generally allow |
Okay, so I've updated this PR to support |
Preview package from this PR in consuming applicationIn consuming application project install preview version of kongponents generated by this PR:
|
Summary
Jira: https://konghq.atlassian.net/browse/KHCP-13685
Typescript checks are getting tighter in v5.5.4,
v-model
now differentiates betweenundefined
andnull
support. Since the backend APIs only recognizenull
as a value to unset an entry in the DB (particularly true for booleans) and notundefined
, allow passingnull
as theModelValue
(treat passing anull
the same as passingundefined
)