List does not search for data from earlier page

[Blackbaud-ScottFreeman]

Expected behavior

When providing multiple pages of data through the [data] input, going to the last page and filtering should still find records from earlier pages. This may be due to how the list request is sending a page number when requesting data. See the Plunker below where I reset the page number for the list provider example in order to bring back data from earlier pages. Honestly, it seems like a change in search text should make the requested page irrelevant since you don't know what page the data you're searching for will be on after filtering. Changing search text should send you back to page 1 much like searching for a new term on google.

Actual behavior

Records from earlier pages are not found.

Steps to reproduce

Using the Plunker below:

1. Notice that Banana exists twice in the List
2. Go to page 2
3. Enter Banana as your search text and hit Enter
4. Notice that there are no results even though you should see the two Banana entries.

Plunker (see example SKY UX 2 plunker template at: https://plnkr.co/edit/6y0bbKtapJlnVSg5xq7M?p=preview

[Blackbaud-PatrickOFriel]

Yeah I think this is a problem with the in-memory data provider. I'll take a look

[Blackbaud-ScottFreeman]

That could be part of it. I just realized that setting the pageNumber to 1 in the provider example is actually incorrect because that will only ever show you the first page of data when you have search text regardless of what page you try to go to. Thinking about that issue, I'm not quite sure how the list provider is supposed to know which page of data to display if the requested page number may not exist after filtering the data.

[Blackbaud-PatrickOFriel]

https://plnkr.co/edit/bIPWSiTLseJGe7RYTIw1?p=preview I figure I can do something like this in the in memory provider to fix it. Check out the second list in the plunker and see if you can break the behavior

[Blackbaud-PatrickOFriel]

Ah, breaks when paging should actually exist in search results. I'll bang on it a little more

[Blackbaud-ScottFreeman]

In our spa, I currently have a list provider with 200 dummy records with 20 records per page. That has been helpful for finding these little quirks. Let me know if you want some code but I'm essentially for looping 200 records in the list provider constructor.

[Blackbaud-PatrickOFriel]

Ah I didn't see you manually changed the page number to 1 in the plunker (I was wondering why it seemed to be working in the documentation of the local branch I was in). My changes will allow it to work without that because the paging will reset to 1 automagically once it receives the searched items that are less than a page. Try this out: https://plnkr.co/edit/O4uWHTKMPE6IIxBG11OV?p=preview

[Blackbaud-PatrickOFriel]

There is a behavior that my changes don't cover however. That is this scenario:

1. Move to the second page of data.
2. Search for the letter a (something that's in all records)
   Current behavior = Stay on the current page
   Expected behavior = Move back to first page?

@Blackbaud-ToddRoberts or someone else in design how this this scenario react?

[Blackbaud-ScottFreeman]

Here is a plunker that shows what happens when the number of pages are taken out from under the list.
https://plnkr.co/edit/zFdeI8ZMnJXF5Bs8UXTY?p=preview
Go to the last page (20), then search for value 1. You will see that page 4 is now selected with no data shown by the provider because page 20 was requested. It's almost like the list provider would need to calculate the new max pages and see if the requested pages is greater than that so it could then adjust to return the last page.

My argument for searching going back to page 1 is working under the assumption that data in the list has some default sorting. In our case, it'll probably be the most recently sent emails in descending sent date order. If the user gets to page 3 without finding what they're looking for, they may then try to search in order for their results to be more specific. If their search result still has 2 pages, it seems unlikely that they would want to see the older results. They were likely looking for the most recent sent email that would be on the first page. The is very similar to searching a on the web. You get a couple of pages in, don't see what you're looking for, modify the search criteria, then go to the first page where the most relevant results are.

[Blackbaud-PatrickOFriel]

Yep, I see exactly what you mean. I think the solution would be to make it the responsibility of list search to set the list paging number to 1 when search is first invoked.

[Blackbaud-PatrickOFriel]

@Blackbaud-ToddRoberts gave me the go ahead to always move to page 1 when search is invoked. Shouldn't be a crazy change to make

[Blackbaud-ScottFreeman]

Awesome, thanks for working through this.

[Blackbaud-PatrickOFriel]

No problem, thanks for working with me to get to the root of the issue

[Blackbaud-PatrickOFriel]

I have a pull request started for this at #711, but I'm out of town starting tomorrow for the next week and a half. If someone wants to add a unit test for the changes I made, it can go in fairly quickly. Otherwise I'll be back on the 31st of May to take a look again.

[Blackbaud-PatrickOFriel]

In 2.0.0-beta.30