Skip to content
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

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

Closed
2 tasks done
raphaelgodart opened this issue May 8, 2024 · 3 comments · Fixed by #1287
Closed
2 tasks done

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

raphaelgodart opened this issue May 8, 2024 · 3 comments · Fixed by #1287
Labels
type: bug Something isn't working type: enhancement New feature or request Workflow: In progress Issue will be part of the next release

Comments

@raphaelgodart
Copy link

Prerequisites

  • I have read the Contributing Guidelines.
  • 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: #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 #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
@raphaelgodart raphaelgodart added the triage We discuss this topic in our internal weekly label May 8, 2024
@danielleroux
Copy link
Collaborator

danielleroux commented May 16, 2024

@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.
image

@danielleroux danielleroux added type: bug Something isn't working type: enhancement New feature or request and removed triage We discuss this topic in our internal weekly labels May 16, 2024
@matthiashader matthiashader added the Workflow: In progress Issue will be part of the next release label May 28, 2024
@raphaelgodart
Copy link
Author

raphaelgodart commented Jun 6, 2024

@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
Copy link
Collaborator

danielleroux commented Jun 6, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug Something isn't working type: enhancement New feature or request Workflow: In progress Issue will be part of the next release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants