ix-select does not allow looping over array of objects anymore since v2.2.0

raphaelgodart commented 1 month ago

Prerequisites

[X] I have read the Contributing Guidelines.
[X] I have not leaked any internal/restricted information like screenshots, videos, code snippets, links etc.

What happened?

Since iX v2.2.0 the value property of ix-select-item must be a string. That is enforced by this PR: https://github.com/siemens/ix/pull/1159

That change has broken our implementation, as we're using ix-select and ix-select-item to display a select box of object from an array. Due to the changes in PR https://github.com/siemens/ix/pull/1159, since ix v2.2.0, the selected item is not displayed anymore in the select box in our implementation. I've created a Stackblitz to illustrate the problem: https://stackblitz.com/edit/siemens-ix-select-issues. In the Stackblitz:

Example 1 illustrates how the official documentation expects the user to use ix-select
Example 2 illustrates how we're using ix-select. Note that when selecting an item in the select box, the selected item is not displayed in the select box (that used to work in iX v2.1.2, but does not work anymore since iX v2.2.0). The selected item is however still set correctly in Typescript.
Example 3 converts our implementation to use strings instead of objects as the value of ix-select-item. That implementation is not optimal though because, to get the actually selected item from the array, some additional code must be written in the valueChange handler to fetch the real object from the array, based on the string that is passed in the valueChange CustomEvent.
Example 4 illustrates how a standard html select works directly with objects. Which is how ix-select used to work and ideally should work.

Example 3 makes ix-select work with objects, given that the objects have a property of type string that can be used as ix-select-item value. However, extra code must be added to the valueChange handler to get the object from the original array. Is ix-select supposed to behave this way? Is it expected from users that such extra code must be written in the valueChange handler to get the selected object?

What type of frontend framework are you seeing the problem on?

Angular

Which version of iX do you use?

v2.2.0

Code to produce this issue.

https://stackblitz.com/edit/siemens-ix-select-issues

danielleroux commented 1 month ago

@raphaelgodart We discussed this and your are right. We will try to provide a solution that object as value is still possible as it is implemented with the native select. But we have to check if additional issue are existing regarding the comparison between ix-select value and ix-select-item value. The ix-select was designed to be string based.

raphaelgodart commented 3 weeks ago

@matthiashader I reviewed PR #1287. Do I understand correctly that it reverts the breaking change which was introduced in v2.2.0 but that in v3.0.0 strings will again be mandatory, and that object iteration will not be possible anymore in v3.0.0?

danielleroux commented 3 weeks ago

Yes it is still planned. We try to get closes to the html standard (https://html.spec.whatwg.org/multipage/form-elements.html#the-select-element)

attribute DOMString [value](https://html.spec.whatwg.org/multipage/form-elements.html#dom-select-value);

to be compatible with standard form, also some pitfalls are easier to handle regarding property change detection (change by value/ change by reference)

Here a html example: https://stackblitz.com/edit/stackblitz-starters-ds7jcc?file=index.html which shows the issue regarding working with objects

siemens / ix