Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Okay, this PR has quite a few things to talk about.
First of all, what is the purpose of this PR? It's about solving the duplicate properties problem we had with our previous paging code.
Pages like the Games List or the Subs List allow Custom Filtering like "Starts With Letter" that needs to apply before paging. The query is bound using a custom Request class. However, the paging system itself needs to know about those queries as well, otherwise it can't make the page buttons link to the proper url with the proper query parameters.
Make a custom PageOf implementation like SubmissionPageOf that has all the same properties of SubmissionRequest. The issue being that refactorings will miss this and break paging, along with the usual problems of unnecessarily duplicating code.
Always include the Request in the PageOf itself. So instead of making a
SubmissionPageOf<SubmissionEntry>
we instead make aPageOf<SubmissionEntry, SubmissionRequest>
. Inside the PageOf there is a .Request property that contains the original request data. The pager then uses this to make the pager buttons.This PR implements this change.
But it does a bit more. Every PageOf now needs an additional type, so this would require a lot of additional code refactorings everywhere we use a page. But most of our pages don't even use Custom Filtering! They just use the default implementation of a request: the
PagingModel
.So this PR not only changes the
PageOf<T>
into aPageOf<T, T2>
, it also implements a "fallback"PageOf<T>
which is just aPageOf<T, PagingModel>
, so that most places don't need to deal with the additional type.I also had the idea of renaming our PagingModel class into something like
DefaultPagingRequest
, since it's now an IRequest and every custom Request implementation inherits it. But I wanted a somewhat minimal solution first, and renaming can come after.I have two things left that irk me about this PR:
I separated this PR into commits to look at in an isolated way.
That's all.