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

Component: p-autocomplete wrong display of chip if multiple=true and optionValue and optionLabel is set #15495

Open
lorenyaSICKAG opened this issue May 8, 2024 · 3 comments
Labels
Status: Needs Triage Issue will be reviewed by Core Team and a relevant label will be added as soon as possible

Comments

@lorenyaSICKAG
Copy link

lorenyaSICKAG commented May 8, 2024

Describe the bug

We've got an p-autocomplete component where we have set multiple = true. And we have set the new option optionValue as well as optionLabel. When selecting an option, the created chip is empty.

image

Environment

Simple autocomplete component within an reactive angular form with other autocomplete fields which are working correctly when using multiple = false or without an set optionValue.

Reproducer

Stackblitz here

Angular version

17.3.7

PrimeNG version

17.16.0

Build / Runtime

Angular CLI App

Language

TypeScript

Node version (for AoT issues node --version)

18.14.2

Browser(s)

Chrome

Steps to reproduce the behavior

No response

Expected behavior

Displaying the value of the objects' property defined in optionLabel within the chip .

@lorenyaSICKAG lorenyaSICKAG added the Status: Needs Triage Issue will be reviewed by Core Team and a relevant label will be added as soon as possible label May 8, 2024
@Sinan997
Copy link

How can i see the code you wrote in this link?

@lorenyaSICKAG
Copy link
Author

Sorry, I copied the applicaton url. Here you can see the code: https://stackblitz.com/edit/github-7hs33e-zqqhbr?file=README.md

@yorickp
Copy link

yorickp commented May 24, 2024

Encountered a similar issue after upgrading from version 17.13.0 to 17.17.0. Also felt like the newly introduced optionValue input property seemed to be at the root cause.

Potential workaround

Let me start with how I was able to eliminate the problem, as that might already help those encountering the same issue.
We also use it with [multiple]="true" and value binding through formControlName, though did not test their relevance to the issue.

We did not have a value assigned for optionValue in with version 17.13.0, and all worked as expected. Updating to 17.17.0 made the labels of selected options no longer being rendered.

Added:

[optionValue]="optionValueFn"

to the p-autoComplete, with optionValueFn being initialised as:

optionValueFn = (option) => option as any

That solved it for us. Curious whether that can also somehow help you out of a jam, @lorenyaSICKAG.

Short explanation

optionValue expects a value of type string | ((item: any) => string), though that probably is a mistake and should become less strictly typed than the current string expectation. As when assigning (option) => option as any makes the autocomplete behave as before, it feels like under the hood the string type does not actually seem to be a hard expectation.

Towards potential cause

What most probably ís relevant, as already mentioned, is that it feels like the introduction of optionValue introduced an assumption of string typed values on option selection while it did not had such type expectations before.

When not passing any value to the newly introduced optionValue (as it did not exist yet), having updated PrimeNG, regression occurred in our implementation similar to what @lorenyaSICKAG describes.

Note

The component seems to fallback to optionLabel to update the value binding when an option gets selected, while before it added the option as-is to the (form control) value.

Illustration of the unexpected behaviour

On selection of an option, with v17.13.0, the form control value used to get updated from

[{ id: 1, label: 'My initialised option' }, { id: 2, label: 'Another initialised option' }]

to

[
  { id: 1, label: 'My initialised option' }, { id: 2, label: 'Another initialised option' },
  { id: 3, label: 'My newly selected option' }
]

With v17.17.0 the same code initialises the value as before:

[{ id: 1, label: 'My initialised option' }, { id: 2, label: 'Another initialised option' }]

But on selection of an additional option, the form control value now becomes:

[
  { id: 1, label: 'My initialised option' }, { id: 2, label: 'Another initialised option' },
  'My newly selected option'
]

So this illustrates that at first sight is seems to update the value based on optionLabel (?), which was not the case in v17.13.0.

When removing an option it gets worse, the latter assumption seems to get applied to all initialised values as well, e.g. when removing the second option, the value becomes:

['Another initialised option', 'My newly selected option']`

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status: Needs Triage Issue will be reviewed by Core Team and a relevant label will be added as soon as possible
Projects
None yet
Development

No branches or pull requests

3 participants