Skip to content

Comments

fix(NcSelect*): add nullish types to modelValue#8214

Open
Sector6759 wants to merge 1 commit intonextcloud-libraries:mainfrom
Sector6759:ncselect-modelvalue-type
Open

fix(NcSelect*): add nullish types to modelValue#8214
Sector6759 wants to merge 1 commit intonextcloud-libraries:mainfrom
Sector6759:ncselect-modelvalue-type

Conversation

@Sector6759
Copy link

The default value for NcSelect, NcSelectTags is null and for NcSelectUsers it's undefined, but neither null nor undefined are part of the modelValue union type in any of those components. Furthermore, clicking the clear button of those components sets the modelValue to null. Manually setting the ref bound to the v-model to undefined does indeed work as of now and even "clears" the NcSelect* components the same way as setting it to null does. So in my opinion, null and undefined should be part of the union type. The modelValue of the NcSelecUsers component, which currently is the only one of those 3 written in TypeScript, already includes undefined in its union type because it does not itself declare a default value:

screenshot

🏁 Checklist

  • ⛑️ Tests are included or are not applicable
  • 📘 Component documentation has been extended, updated or is not applicable
  • 2️⃣ Backport to stable8 for maintained Vue 2 version or not applicable

Signed-off-by: Sector6759 <149817326+Sector6759@users.noreply.github.com>
Copy link
Contributor

@susnux susnux left a comment

Choose a reason for hiding this comment

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

I think we should only have one valid "unset" variant.
Either null or undefined but not both.

I would prefer undefined as it has not the weird type issue as null being an object.
Also undefined is the default for Vue refs like with const foo = ref<MyType>() it would default to undefined not null.

@susnux susnux requested a review from ShGKme February 17, 2026 15:20
@Sector6759
Copy link
Author

Sector6759 commented Feb 17, 2026

I agree with using undefined for the unset/default value BUT this could be considered a breaking change because some apps might rely on the current behavior using null. So for now I think it's best to just adjust the union type to reflect the current runtime behavior.

Copy link
Contributor

@susnux susnux left a comment

Choose a reason for hiding this comment

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

Yes but for SelectUsers it was never allowed / documented to put null but the types already included undefined so that component is fine like it ist.

For the other two components - yes somehow implicitly typed like that.
Maybe leave it like you did for those two but state that null is deprecated in the prop documentation of them.

* otherwise a single user data object will be emitted.
*/
const modelValue = defineModel<NcSelectUsersModel | NcSelectUsersModel[]>('modelValue')
const modelValue = defineModel<NcSelectUsersModel | NcSelectUsersModel[] | null>('modelValue')
Copy link
Contributor

Choose a reason for hiding this comment

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

here it was always undefined

Suggested change
const modelValue = defineModel<NcSelectUsersModel | NcSelectUsersModel[] | null>('modelValue')
const modelValue = defineModel<NcSelectUsersModel | NcSelectUsersModel[]>('modelValue')

@Sector6759
Copy link
Author

Sector6759 commented Feb 17, 2026

Yes but for SelectUsers it was never allowed / documented to put null but the types already included undefined so that component is fine like it ist.

NcSelectUsers uses undefined as its default value but clearing any selected user by clicking the clear button doesn't reset the modelValue back to undefined but instead sets the modelValue to null. So currently, compared to NcSelect and NcSelectTags, NcSelectUsers only uses a different default value, but the reset/cleared value is null like in the two other components. In my opinion, this justifies adding null to the modelValue union type of NcSelectUsers. I am merely trying to align the type information with the current actual runtime behavior.

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.

2 participants