Framework: ComboBox should not fetch initial data.

[RobertZenz]

The ComboBox should not fetch/send initial data for the dropdown list.

Imagine the following scenario: The ComboBox are powered by data providers which are fetching the items from a database and the application has a lot of comboboxes in one form. That means that not only will be data send in the order of 40*itemsize*comboboxcount (because the default initial data size is 40), but also the providers will need to provide that data, with potentially costly database operations, slowing everything down. Ideally, the ComboBox would only fetch the first time as is required, for example when the user starts typing or the dropdown is opened.

Additionally, the size of the initial fetch that is performed is 40, even though the first page of the combobox only displays ~10 items.

[bjung82]

This odd behaviour was the main reason we invested several weeks to reimplement our own comboboxes using texfield with button.

We have many comboboxes on many forms...

[RobertZenz]

@bjung82 Out of curiosity, are your implementations FLOSS? Because I'd like to see those. Also, I've implemented a workaround by deactivating the data provider until the ComboBox receives the first focus, which is working quite well (kudos to a colleague of mine at work who came up with the idea). Now that I think about it, I have to extract that into an easier reusable component...maybe I can find the time tomorrow to do that.

On another note, we (as the company) still hope to have a ComboBox one day which allows us to put any control into the dropdown, for example a table.

[RobertZenz]

I've now found the time and extracted our workaround into the LazyComboBox, which should be rather easily reusable.

[stale[bot]]

Hello there!

It looks like this issue hasn't progressed lately. There are so many issues that we just can't deal them all within a reasonable timeframe.

There are a couple of things you could help to get things rolling on this issue (this is an automated message, so expect that some of these are already in use):

• Check if the issue is still valid for the latest version. There are dozens of duplicates in our issue tracker, so it is possible that the issue is already tackled. If it appears to be fixed, close the issue, otherwise report to the issue that it is still valid.
• Provide more details how to reproduce the issue.
• Explain why it is important to get this issue fixed and politely draw others attention to it e.g. via the forum or social media.
• Add a reduced test case about the issue, so it is easier for somebody to start working on a solution.
• Try fixing the issue yourself and create a pull request that contains the test case and/or a fix for it. Handling the pull requests is the top priority for the core team.
• If the issue is clearly a bug, use the Warranty in your Vaadin subscription to raise its priority.

Thanks again for your contributions! Even though we haven't been able to get this issue fixed, we hope you to report your findings and enhancement ideas in the future too!

[RobertZenz]

So, that's it. All my tickets are now marked as stale, and as far as I can tell, all of them are still valid.

Is this your approach to treating bugs from your users, especially bugs that are quite heavy weight like this one?

[TatuLund]

@RobertZenz , I am sorry if you feel it that way. Purpose of this is to find out the issues that needs the attention most among the 3000+ open issues we have. There are lot of outdated and duplicate issues there, also issues that has been fixed by byproduct of other fixes, etc.