feat: Filter Storage Mode Responses by Submission Id

[frankchn]

Problem

Users have trouble finding specific responses and trying to download attachments for these responses.

Solution

This introduces a new textbox which filters submissions by reference ID so users can jump to a certain response immediately.

Screenshots

Notes

This is a resubmission of #71 as the earlier PR was reverted due to performance issues.

[liangyuanruo]

Note - do not merge until read from primary is verified, and internal processes are complete.

[liangyuanruo]

I think we have an issue - every time the search box is cleared, the database has to perform an expensive scan to paginate and serve the first page. This is probably the root cause of CPU saturation on secondaries.

[frankchn]

@liangyuanruo Ah OK I didn't know the scan and serve can be so expensive on Mongo. I thought it would be more like the equivalent of a SELECT ORDER BY submission_time DESC LIMIT 10 kind of thing. Is there any way to add an index to the store to make it faster.

One thing we can do is to just add a button to trigger the filter instead of doing debouncing and triggering on keydowns.

[liangyuanruo]

Is there any way to add an index to the store to make it faster.

We already have an index on the created column today.

One thing we can do is to just add a button to trigger the filter instead of doing debouncing and triggering on keydowns.

Something like that could work, although we should probably introduce both a "search" and a "clear" button.

I'll create a new issue for awareness since the potential fixes would involve engineering as well as design.

[liangyuanruo]

Blocked by #276.

[frankchn]

I have added a "Filter" button so the expensive pagination queries won't happen unless explicitly requested by the user.

[liangyuanruo]

Can we put in a Reset button too? The current UI will confuse users because it doesn't quite make sense to filter when the search box is empty. Could we also disable the filter button if the input doesn't match the regex for a MongoDB ObjectID (/^[0-9a-fA-F]{24}$/)? This could save on network calls to the backend.

For the Reset button, I suspect we can reuse the same styling as "Open in new window".

[frankchn]

I just decided to use the standard buttons instead. Probably OK for now?

[frankchn]

@liangyuanruo I suspect introducing a "Clear" button that sends a request to the backend to paginate will cause the # of requests to increase.

Instead of clearing the textbox manually and pasting in the next ID, users may decide to just click the Clear button to clear the textbox. This brings us back to the same issue that we had with the original design.

[frankchn]

@liangyuanruo Updated per discussion.

[frankchn]

@liangyuanruo I updated this based on the design in #276 -- main change being that I let the text box appear on a second row instead as it is a bit of a squeeze in the zeplin mockup if the user's screen is too narrow.

Let me know what you think!

[liangyuanruo]

thanks @frankchn . i tested the new behavior and it's great. can we do up the UI before merging:

1. Get the search icon to look as per the design, instead of being a blue button
2. Address layout issues for smaller screen sizes. It might be easier to address this by implementing an input box that is positioned as per the design. The components can simply be stacked for the mobile view.
   

[r00dgirl]

@frankchn adding on

1. replace copy 'Reset' with 'Refresh'
2. placeholder for search box 'Search by reference no.'

[frankchn]

Hi @syan-syan, made the second change, but the Reset link is actually for going back to the un-filtered view I think.

[frankchn]

@liangyuanruo PTAL again, thanks!

[r00dgirl]

Hi @syan-syan, made the second change, but the Reset link is actually for going back to the un-filtered view I think.

I know, I'm thinking it may be scary to users since 'Reset' is often associated with drastic changes (could be wiping out all the data?), while what people generally expect with 'Refresh' is what we have planned for showing the unfiltered results

[frankchn]

@syan-syan No problem, updated! cc @liangyuanruo

[liangyuanruo]

lgtm @frankchn , except for a last-bit layout issue for the iPad Pro. could i trouble you to fine-tune the CSS?

[frankchn]

Well, this is better but still not perfect, partly because the iPad Pro has enough horizontal resolution to be treated as a desktop browser for bootstrap purposes, so things spill out. At least all the fields are visible? :p

[frankchn]

I am thinking of merging this and getting some feedback, and also changed the text for going back to looking at all responses to "View All". I think users might just end up clicking "Refresh" if they want to reload the particular filtered item.