feat: implement pagination #379
Conversation
| final List<ProposalModel> proposals = event is _Initial ? proposalsResult.asValue!.value : state.proposals + proposalsResult.asValue!.value; | ||
|
|
||
| final List<int> daoIds = GetIt.instance<FilterProposalsBloc>().selectedDaoIds ?? daos.map((DaoData dao) => dao.docId).toList(); | ||
| if (nb < 3 && proposalsResult.asValue!.value.filterByDao(daoIds).isEmpty) { |
There was a problem hiding this comment.
what is the "nb" magic number - this needs to have a real name.
There was a problem hiding this comment.
You're right. I think retryCounter is a great choice because, in this case, the query can return an empty list or the filtering that happens after the query, even though there are more proposals on the next pages. So, if the initial list is empty (and we cannot scroll), the function calls itself up to a maximum of three times. This logic applies not only at the start of the list but also in the middle and the end.
| final List<int> daoIds = GetIt.instance<FilterProposalsBloc>().selectedDaoIds ?? daos.map((DaoData dao) => dao.docId).toList(); | ||
| if (nb < 3 && proposalsResult.asValue!.value.filterByDao(daoIds).isEmpty) { | ||
| offset += first; | ||
| nb ++; |
There was a problem hiding this comment.
I don't understand this code - offset += first
What is first?
There was a problem hiding this comment.
Offset starts at 0 and increments by first (the number of items per page).
| if (proposalsResult.isValue) { | ||
| final List<ProposalModel> proposals = event is _Initial ? proposalsResult.asValue!.value : state.proposals + proposalsResult.asValue!.value; | ||
|
|
||
| final List<int> daoIds = GetIt.instance<FilterProposalsBloc>().selectedDaoIds ?? daos.map((DaoData dao) => dao.docId).toList(); |
There was a problem hiding this comment.
does it always need to filter by daoID even if all daoIDs are selected? e.g. are there results that aren't even in a dao the user is a member of?
I mean it could be - they could have joined a dao and left,
but I would expect that to be part of the query, not additional code running after the query?
There was a problem hiding this comment.
The selected daos, when null, means that all the daos are selected. The filterByDao is for UI purposes: the filter page should display the proposal count for all your daos, while the proposals page will show only the selected dao proposals. And yes, you can see only your daos, and all of this is already part of the existing code, which I haven’t changed.
Regarding the scenario where a user could have joined a dao and left, when the filter is initiated (not during pagination), the daos will be up to date. This ensures that the user only sees active daos they are currently a member of.
There was a problem hiding this comment.
Movie looks good!
But, I don't really understand the pagination code
Added a few questions to that
Normally you'd just have offset and limit, and go with that... I guess we are doing some additional filtering here which complicates things - would be easier to make all filters be part of the query so pagination works as expected.
If all filtering is part of the query then the database takes care of pagination
Explicit change requests:
variable naming ("nb", "first")
typing ("dynamic")
|
Upon review, the website proposals query is extremely long ... |
Scope
Ticket
Added pagination for proposals and refactored code to improve readability and adhere to coding standards.
Note:The proposals were filtered byPayoutandPolicysince the latest version will only support these 2 types for simplification purposes.Note:The valid states for history proposals are:Approved,Rejected,Archived, andProposed.Note:The pagination is happening when scrolling.Video:
https://files.fm/f/tyrbchb4bh