After upgrading Outsystems UI from 2.14.0 to 2.27.0 it was noticed that the OnSelected event of DropdownServerSideItem started sending the id of the item instead of the id of the dropdown for the event parameter DropdownId:
As a workaround we started sending the actual dropdown.id as a parameter too.
Thanks for the feedback @Dorine Boudry
We've created a task to review this experience (ROU-12609 for future reference) and will probably add the DropdownServerSide identifier back since it's a more seamless experience than calling an extra API. But let's see.
(Note: the release notes for 2.16.0 were complemented to make this clearer)
Cheers,GM
Hi @Leandro Oliveira ,
I can trace this back to a change in version 2.16, the inputs to the OnSelected event were renamed, and the description of the first one changed.
I have reported this to OS as it is confusing : it is still named DropdownId, but in the description and implementation it is the id of a dropdown item. This is also a breaking change for people who for example use it as input to some client actions like for example DropdownServerSideNotVallid.
As the component was only introduced in 2.14 (22/01/2023) and this change happened in 2.16 (09/07/2023), you might be one of the very few who actually got their code broken by this, though.
I think your workaround should be applied in the component, i.e. even if they decide it has to be the item id, the action should also take in the dropdown id (as a third input), so actions that need it can get it passed in. Or else, they could offer a client function GetDropdownServerSideId(DropdownServerSideItemId)
Dorine
Hello @Leandro Oliveira and @Dorine Boudry
This was done in 2023, so I had to go look at this again, but once I opened the component, I got a bit confused, and I would like you to clarify the question.
After a change in 2.16.0, we've unified all components' events, and now that I was looking at it again, the DropdownId should be called DropdownServerSideItemId, and the DropdownItemId should be called ItemId.
By design, returning the DropdownServerSideId was considered wrong, so it was fixed.
Given this and given that we can access the runtime widget Id once we name the block, why should we add a parameter returning the ID of the parent dropdown or a high-code API (in this case, a client action is not on our plans or according to some guidelines)? What would be the use cases that you can't achieve?
yes for the name change 👍
the use case is
Of course, this is an edge case, if you only have one dropdown, there is no problem, you can just hardcode the widget id inside the action, no need to get it from the input.
And if you have several dropdowns that need the same logic OnSelected, then a workaround is to, as Leandro is doing, extend the event with your own extra input of the dropdown id, but this is another point where developer error can lead to wrong results.
On the returning the DropdownServerSideId was considered wrong
I understand that you want to unify and having the id of the thing causing an event on every component's event is a good standard.
But components don't exist in a vacuum, and in the code, we sometimes need the bigger picture. In other words, sometimes, we need to know the context (typically parent of a child) to act on that.
So what is the solution for that ?
I think having a GetParentWidgetId(ChildWidgetId) client function is not too bad, it means you don't clutter up your child events with parent id's, but when a developer needs it, it is there.
There would only be a handful of components where this is needed.
Hi @Gonçalo Martins and @Dorine Boudry ,
Thanks you for your quick responses. My intent with this post is to warn people that use the event parameter with the original behavior, since after the update it was not working accordingly to its name. For this case I think it is also relevant to describe the breaking change on the update notes, as this was not expected from the initial analysis on what have changed and what was breaking.
Best regards