Specify behavior of previous search results when form is changed

[sammyjava]

We need to specify what happens to previous search results when the search form is updated (change of selector, change of text input, etc.). There are various options, add to this list if it is not complete:

• leave the previous search results there, only change when the form is submitted and new results are loaded: ADF,AC
• clear search results on any change to the form (via onChange events)
• clear search results AND replace with some sort of text to the effect of "Yo! Your search results have been erased because you changed the search form!"
• produce search results dynamically on every change to every element of a form: selector change, typing text into boxes. In this case there will be no SEARCH button and there will be a lot more HTTP traffic.

[adf-ncgr]

I vote for "leave the previous search results there, only change when the form is submitted and new results are loaded". It seems simplest and I don't see any clear advantage to anticipating the next user move.

[alancleary]

I also vote for "leave the previous search results there, only change when the form is submitted and new results are loaded".

Something else I didn't mention in issue #3 is that the existing web components always show an alert that indicates the search status, i.e. it says when a search is in progress, has succeeded, or failed. Currently it doesn't say anything useful when a search succeeds or fails but this could be updated to include the user's search parameters so the screenshot use-case @sammyjava mentioned wouldn't be thrown off by a form that has been changed but not submitted.

[adf-ncgr]

This raises a good point: I think we ought to update the URLs with search parameters for easy sharing (even better than taking a screenshot); and of course, we'd have to use query params specified in a URL if supplied. Probably hijacking this issue...

[alancleary]

This raises a good point: I think we ought to update the URLs with search parameters for easy sharing (even better than taking a screenshot); and of course, we'd have to use query params specified in a URL if supplied. Probably hijacking this issue...

This should be part of the spec for the component, although I don't think it needs to be implemented in the prototype since it's a plug and play feature in the Web Component implementation.

[sammyjava]

Yeah, the React demo is strictly for UI spec purposes. The pagination, query string URI, etc. should be plug-n-play as @alancleary says. At least I hope so. :) And that was a classic thread-jack.

[sammyjava]

@cann0010 any comments? It looks like we've got two in favor of just leaving search results up, which I'll implement unless you have strong opposition.

[alancleary]

Yeah, the React demo is strictly for UI spec purposes. The pagination, query string URI, etc. should be plug-n-play as @alancleary says. At least I hope so. :) And that was a classic thread-jack.

Another requirement that should be spec'd for all components that load data from services is making sure that promise returned by the service function is cancleable. This is to avoid race conditions when the service is being slow and/or the user makes another request before the previous one has been fulfilled. This can be done with the LisCancelPromiseController class.

[sammyjava]

I'm closing this with saying that we've decided to let search results persist until a new set of results is received. I've added it to https://github.com/legumeinfo/component-search-ui-srs/blob/main/general-requirements.md