fix(kselect): accept null in v-model [KHCP-13685]

[portikM]

Summary

Jira: https://konghq.atlassian.net/browse/KHCP-13685

Typescript checks are getting tighter in v5.5.4, v-model now differentiates between undefined and null support. Since the backend APIs only recognize null as a value to unset an entry in the DB (particularly true for booleans) and not undefined, allow passing null as the ModelValue (treat passing a null the same as passing undefined)

[netlify]

✅ Deploy Preview for kongponents-sandbox ready!

Name	Link
🔨 Latest commit	ee3ba78
🔍 Latest deploy log	https://app.netlify.com/sites/kongponents-sandbox/deploys/671285c7c7794d0008a61124
😎 Deploy Preview	https://deploy-preview-2450--kongponents-sandbox.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[netlify]

✅ Deploy Preview for kongponents ready!

Name	Link
🔨 Latest commit	ee3ba78
🔍 Latest deploy log	https://app.netlify.com/sites/kongponents/deploys/671285c7a62048000882df8f
😎 Deploy Preview	https://deploy-preview-2450--kongponents.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify site configuration.

[kaiarrowood]

LGTM! Thanks Max!

[adamdehaven]

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

[Justineo]

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 null values for form components in general. A few questions to think about:

• Should we consider foo a controlled prop if typeof props.foo !== 'undefined'?
• If so, how should we represent the "controlled but unset" state for a <Select> component if null is not allowed? (We are currently using '', which feels a bit weird to me.)

[portikM]

• Should we consider foo a controlled prop if typeof props.foo !== 'undefined'?

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 null with the GET response and again convert back to null before we build the payload for PUT

[adamdehaven]

The problem with this approach is it doesn't save us any work, we still have to do the conversion from away from null with the GET response and again convert back to null before we build the payload for PUT

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 null, others may require undefined or have different logic, and that logic could change over time.

Mutating data to be acceptable by an external interface (e.g. Kong APIs) should be the responsibility of the host application.

[Justineo]

Should we consider foo a controlled prop if typeof props.foo !== 'undefined'?

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)

I wasn't specifically referring to how accepting null makes it easier to connect to our backend API. Rather, if we're using undefined to differentiate between controlled and uncontrolled props, then null might be necessary to represent an explicitly empty value. And we should think about what null value represents for each component. Like what does null even mean for Checkbox or Switch?

We shouldn't be changing the component behavior based on the requirements of our APIs.

I agree. However, in this case, I was thinking less about it being a backend requirement and more about whether we should generally allow null values.

[portikM]

Okay, so I've updated this PR to support null in KSelect only. I've tested both components in sandbox and they looked good.

cc @kaiarrowood @Justineo @adamdehaven

[kongponents-bot]

Preview package from this PR in consuming application

In consuming application project install preview version of kongponents generated by this PR:

@kong/kongponents@pr-2450