Search select delayed population can cause user confusion

[AndrewIsh]

The final rendering of the <select> that displays search scope options is dependent on the response from the eds-raw.pl API request. We've found this request can take between 2 and 3 seconds to respond, at which point the EDS option is added. Since the EDS option is set to be the default, we encounter a poor user experience as the option is not initially available, so a user may select an alternative, then have their choice altered, or they may simply not know where the EDS option is.

We cannot shortcut this process, since the EDS option cannot be added until the API responds. So a possible solution would be to initially hide or disable the select box until the API response has arrived. This is not an ideal solution, but it is better than the current situation.

[mmabrahamson]

It looks like the delay is primarily caused by the SQL call to get the config data for the EDS API Plugin. that config data tells it whether it should set the dropdown to default or not, and then paints the dropdown and selects accordingly. I agree there doesn't seem to be a great shortcut for this. In the past, this was shortcutted via a jStorage library caching settings after the first load, but it caused headaches with admin settings that weren't getting properly updated when admin settings were changed.

In testing this change, I'm finding there's still a brief delay before the disable happens, long enough for someone moving quickly to click it and then get frustrated. I also absolutely agree that the delay is frustrating. I think we're running into a number of issues though:

Delay on the plugin JS being loaded and running.
Delay on the plugin checking the SQL settings.
Delay on painting the dropdown once SQL responds (this one is minimal).

Before I pull the PR for this one in, I'm looking to see if there's anything else that could be done to speed this all up, and I'm open to suggestions!

[kidclamp]

In the coverflow plugin we have an update_coverflow_js function:
https://github.com/bywatersolutions/koha-plugin-coverflow/blob/master/Koha/Plugin/Com/ByWaterSolutions/CoverFlow.pm#L355

We call it when the plugin settings are updated:
https://github.com/bywatersolutions/koha-plugin-coverflow/blob/master/Koha/Plugin/Com/ByWaterSolutions/CoverFlow.pm#L175

Could you do the same here? Build the dropdown when the options are saved in the admin interface, then simply pass the prebuilt dropdown into the JS so it is available when the page loads?

[mmabrahamson]

Thanks! I like this solution presented in the coverflow plugin. I'm putting this on my priority list to try and address for 20.05 forward. I'll update when more progress has been made on this!

[mmabrahamson]

PR #101 is attempting to fix this issue by removing the need to query the table for configuration on every load. It's working great locally but would love some more eyes on it if you have a 20.05 instance you can test against. Thanks for all the conversation around this! Once the PR is merged I'll close this issue.

[mmabrahamson]

PR #101 is merged to master and should resolve this issue.