Options props can be mutated - options behaviour comment in v0.9.1

[dauriata]

Oruga version: 0.9.1

Thanks for all the work done with v0.9 ! I have some questions / comments regarding the new options api in v0.9.1

I would have expected to be able to pass any object as options, and maybe tell what should be the "value" and "label" field, and/or use slot for label. With version 0.9.1 it seems to be very specific, object are required to have a value property, if not the props are mutated by adding a "hidden" property which seems not good as it can have side effect on the rest of the app. It looks like it should also not have a key property or it else it would be overwritten.

I am also concerned how this would scale for large datasets ( maybe not for tabs or steps that would not go over 10 entries but certainly for autocomplete where it could be common to search across thousand entries ) I see that all options are rendered in the DOM even when hided, this may not be optimal. And maybe I don't get all the implication but I also think that using crypto.randomUUID is overkill, I think a simple sequence counter would do if at all needed. Why not use the index of the returning options array as key ?

[holtolee]

For info crypto.randomUUID break the app in Nuxt (crypto.randomUUID is not a function), no issue with 0.9.0-pre.2

[mlmoravek]

Hey and thanks for your feedback!!

And maybe I don't get all the implication but I also think that using crypto.randomUUID is overkill, I think a simple sequence counter would do if at all needed. Why not use the index of the returning options array as key ?

At first I used the useId native Vue composable. But the composables have the restriction of being called in the component setup context. So when a reactive hook is triggered due to an external update of the options prop, the related composable property is recalculated outside the setup context. Therfore I needed an alternative solution to useId. The first and easiest way for me was to use a native browser implementation (like crypto.randomUUID). However, I confirm your problems with nuxt here... and I see your concerns this to be an overkill. We can try to change it to a simpler sequence counter. Feel free to open a PR :)

[mlmoravek]

Regarding the options prop interface: I needed a way to add some internal information to the options object. However, I don't want to mutate the real options object as it was done before. So I adapted the options implementation of the FormKit library (you can see some example usecases here: https://formkit.com/inputs/select

Short explanation of the options prop type: Most components which use the options prop, the options prop can be defined as follows:

• an array of simple primitives, where the primitive will be the string casted label representation and tthe value.
• an array of objects, where the object is defined as { value: any, label: string, attrs: object }. The value' is the real value object that you access by the v-model prop and other events. Thelabelis the visible representation of this option. Theattrsis an object that will bev-bind` to the option/item component, which can be used to add additional information depending on the component.
• Some other types can be found here: https://github.com/oruga-ui/oruga/blob/a336db21ae1b344a0b8302adcbcb28fc74039d05/packages/oruga/src/composables/useOptions.ts#L39-L42

And a more detailed explanation will surely follow in the docs (see #1079).

[mlmoravek]

I see that all options are rendered in the DOM even when hided, this may not be optimal.

For example, with the autocomplete component, having the options already rendered and only hiding them using v-show when the string to autocomplete does not match the option is much more performant than removing them from the DOM.

[pflirae]

For info crypto.randomUUID break the app in Nuxt (crypto.randomUUID is not a function), no issue with 0.9.0-pre.2

related to #1105