sap.m.Input selectedKey binding clears Input text at start if key is not found in suggestions

[endrx]

OpenUI5 version:
1.73.2

Browser/version (+device/version):
Chrome

URL (minimal example if possible):
https://next.plnkr.co/edit/CLfGEmXtMmZiPVlxo3jD

Steps to reproduce the problem:

1. click "Click to run"
2. Preview: no text in Input
3. delete in App.view.xml text 'selectedKey="{/key}"'
4. Preview: there is a text 'initial text' in Input
5. return text 'selectedKey="{/key}"'
6. Preview: no text in Input
7. in App.controller.js replace 'key: "init2"' with 'key: "init"'
8. Preview: there is a text in Input

What is the expected result?
text 'initial text' is always in Input at start.

Any other information?
in version 1.62.1 it was working as expected here.

[Shtilianova]

Hello @endrx ,
Thank you for sharing this finding. I've created an internal incident 2080062014. The status of the issue will be updated here in GitHub.
Regards, Diana

[d3xter666]

Dear @endrx ,

Thank you for the detailed description.
Actually, this is the desired behaviour. You could check the implementation here: https://github.com/SAP/openui5/blob/master/src/sap.m/src/sap/m/Input.js#L728

When there's a selected item, nothing else matters.
In this particular case, there's a selected item which is missing in your data.
If there's a valid data, you'd see that everything works as expected.

If this is not enough to convince you, then let's take another approach.
What if I have valid data for selected item and text? Which one should take precedence? :)
Now we know that it'd be the selectedItem.

Cheers

[endrx]

Dear @d3xter666 ,

I used sap.m.Input like autocomplete input with searching at server (it is impossible to load all items to Input because there are many thousands of them).

Items are {key, text}. And since version 1.70.0 I confused what to do. My sap.m.Input has to be initialized with some text and key. Do I really need also to add this init item to suggestions items to have init text&key in Input?

I thought that suggestions are suggestions for input, not mandatory restrictions.

Best Regards

[d3xter666]

Dear @endrx ,

I'm not sure I understand your scenario clearly.
As far as I understand, you have suggestion items which are coming from the server and one of them is selected. Is that correct?

If that is the case, initially you'd have an empty input until the backend / API call is completed and suggestions data is there. Then, is the selectedItem key and the suggestion items coming from the same request?

What I've tried to explain above is that "value" and "selectedItem" could not work alongside. Always one of them would take precedence. In other words "selectedItem" would overwrite "value".
We'd need to update our documentation for that. Thanks!

You might work around this behaviour by creating temp model with an initially selected item, and when the backend call completes, it'd overwrite your temp model.

However, I'm still wondering why would you need that as there would be a text in the input and later that text would be changed with something else. Am I missing something else?

Best Regards

[endrx]

Dear @d3xter666 ,

My scenario is:

Many contacts in database (10000+). Each of them is having id, because contact names may be the same (although that is not ok).

And some page for editing some data set, which includes a contact field. So, sap.m.Input there is supposed to give user opportunity to select one of available contacts. Suggestions are loaded from server after user has entered 2 or more characters. After pressing [Save] button on page, data set is saved to server.

But this page also should allow to edit existing data sets. In this case, sap.m.Input should allow to be initialized with some contact and its id. And if user immediately presses [Save], this contact value should be saved (with id).

Best Regards

[d3xter666]

Dear @endrx ,

Then the current situation should be just fine. You don't need to provide explicitly text for the "value" for either scenarios.

Here it is:

• When the user enters new data, then the Input should be empty => value = null/undefined/"". When they type something, Suggestions come into place and everything should be ok.
• The second scenario with Editing should also be ok. There is a record which you'd want to edit. Then the Input is filled with a selectedItem from the Suggestions. The reported issue with the Plunker snippet, however, shows that there's not a match in the Suggestion items with some specific key. From that perspective, I believe this is more an issue on the business logic than in the control itself. Here, I've updated the Plunker to show it: https://next.plnkr.co/edit/jqzSwMuxs3knyDmu
  Am I missing something else?

Cheers

[endrx]

Dear d3xter666,
Sorry for delayed answer.

In my case there are a lot of suggestions (>10000). It would be impossible to contain all of them in JS file. Search is planned to start when user enters 3 or more characters. Then client requests records from server with user entered text as parameter, and server returns a limited set of records, that are then inserted to Input suggestions.

In previous versions of UI5 it was possible to set text and key into sap.m.Input without any suggestions provided.

Or maybe there is other way to do what I need? Without using sap.m.Input with suggestions?

[jonaszuberbuehler]

@d3xter666 I think the problem @endrx is facing has to do with the fact that initially only a subset (depending on the model setting) of the suggestionItems aggregation will be loaded and available on the client side. If this initial set does not contain the key of the item bound via selectedKey there is nothing being shown to the user.

There are some workarounds like manually loading the suggestion item that should be shown initially (e.g. waiting for change event on selectedKey binding) but this should IMO be handled by the control itself.

What is the official recommendation to handle this scenario (initial suggestion item not included in the initial payload of suggestionItems)?

[jonaszuberbuehler]

@d3xter666 Please have a look at https://plnkr.co/edit/eZMfV2jICFHGWi5j

I set the sizeLimit of the ODataModel to 10 and set the initial key to an entry that does not get loaded initially. As a result nothing is shown in the input. Uncommenting line 17 sets the key to an entry that gets fetched initially and the input works as expected.

In this scenario even loading the entity explicitly (line 19) doesn't work, which is kinda strange IMO. Doing the same with a JSONModel does work however.

@endrx Please correct me if this is not the situation that you were facing.

[ThomasChadzelek]

@jonaszuberbuehler I guess "loading the entity explicitly (line 19) doesn't work" because suggestions are using a list binding which is based on indices, and that list binding still has no idea where 'ERNSH' fits in its /Customers collection.

I think UI5 should re-consider this situation and offer an end-to-end solution, thus I take the freedom to reopen this issue.

[jonaszuberbuehler]

@ThomasChadzelek Thanks! There should at least exist a clean possibility to inform the list binding about the now existing entity if this situation will not be handled by the framework itself.

[ThomasChadzelek]

@jonaszuberbuehler "possibility to inform the list binding about the now existing entity": not sure if this is the way to go, or in other words: I cannot imagine right now how that could be done. A list binding needs to take filters etc. into account and it needs to know the entity's position within the collection. Just saying "hey, there is a 'ERNSH' within /Customers" is not enough.

My naive idea would be that sap.m.Select keeps on searching (and thus requesting more data) until the selectedKey is found. Or we need a totally different mechanism to efficiently look up the selectedKey w/o reading the whole suggestionItems. There should be no need for the application to help out here.

[jonaszuberbuehler]

For the 'clean' solution there should definitely be a mechanism to hint the control how to retrieve the selected entity. Requesting more data won't be a viable solution IMO.

[ThomasChadzelek]

@jonaszuberbuehler Isn't the selectedKey already hint enough? A "totally different mechanism to efficiently look up the selectedKey w/o reading the whole suggestionItems" could make use of that...

[jonaszuberbuehler]

@ThomasChadzelek Not sure if it is (thinking about composite keys...) but the experts will know for sure ☺️.

[ThomasChadzelek]

@jonaszuberbuehler "composite keys" - That's a good point! I missed that aspect. Thanks for your input!

[d3xter666]

Hi guys,

Sorry for being a bit late 😳

You'd need to know that this is a scenario where the functionality spreads over multiple components, but not only on the Controls level- on the one side there's the data and on the other, the controls which display that data.
The data comes from the model. Or in other words, the data layer should be the one responsible for the data retrieval.
At this basic control level, there's no way for the Input to know on how to fetch the missing item. It's just a bound property.

On the other hand, what does "selectedKey" mean in the context of the Input: It just populates the field with some text.
From that perspective, yes, the Input won't show/fetch anything until it finds something which is matching the selectedKey and is within the available data set.
But you could "workaround" it by providing the text from the desired item.
Another option would be to somehow always include the selected key into the first 10 items of the data set.

Regarding the explicit call for the item in the oData, yes, the call updates the data, however, items aggregation is not populated for some reason. I don't think this is related to the control itself, but should be rather something with the oData model or the way the data array is being extended.
This means that the "ERNSH" item is not inside Input's suggestionItems and the selectedKey has nothing to match against.
This could be easily checked by getting the model and checking the data and by calling Input's getItems() method.

Cheers

[jonaszuberbuehler]

Thanks @d3xter666

Another option would be to somehow always include the selected key into the first 10 items of the data set.

This is actually the way we're currently dealing with this situation. But it feels more like a workaround than a clean solution to me.

[ClarkDennison]

Any idea what this was closed? Seems that @jonaszuberbuehler spelled out the issue pretty clearly. Seems like a tonof code to write in order to "fix" it.

[ThomasChadzelek]

Hello @Martotko !

I am taking the freedom to reopen this issue, which does not seem to be properly solved. Please explain why you close it, in case you feel the need to close it again :-)

Best regards,
Thomas

[ndeshev]

Hello @endrx, @jonaszuberbuehler

I've checked the provided example in the first post - since v.1.96 sap.m.Input behaves different and the initial value is being displayed.

Kind Regards,
Nikolay

[ClarkDennison]

Not to belabor this point but it still does not work. I had to implement a workaround (ie, use a local JSON model) to get mine to work. Here is a much more detailed discussion but it's pretty easy to replicate by reducing the model size.

Discussion here

I would strongly urge you to open this item back up as I think fixing it would really improve UI5.

Regards,
Clark

[ndeshev]

Hello @ClarkDennison,

I've checked the thread in the link.
So basically you are setting a selectedKey that doesn't correspond to a matching item and expect to get a selected item.
We have purposely implemented the exact opposite logic - if no item that matches the key is available - the value is set to empty.

This is because our users have a lot of different use cases and we want to take as most of them as we can into account.
And indeed, there are a lot of use cases that require the currently implemented logic. We have discussed the key/value synchronizations in a lot of the different cases that we looked into over the time, even added a section in the documentation specially for that.

The bottom line is, we can not support all of them, it is impossible, as some of them are contradicting each other (are mutually exclusive).

Regards,
Nikolay