client: Restore “Mark all” button to 2.18 behaviour #1460
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In 2.18, when in “unread” mode, if there were no unread items, clicking the button would clear out all items and trigger a reload or refresh status of the “Load more” button, depending on whether the client was aware of more unread items on the server. When we ported entries to React in f3b279c, we accidentally broke the “Mark all as read” button, making it keep all the items it marked in the view (a). We also did not port the code that would load more items afterwards (b). It got further broken during porting routing to React in 405a3ec. We looked for the `filter` field on a wrong object (c). We fixed (c) and attempted to fix (a) in ec544b7 but the patch just made it keep all the items it did not mark, such as those marked as read manually beforehand, instead. This patch makes it so that the button removes all the items in the view except for the active item and loads more items afterwards, returning to behaviour similar to 2.18. Since we currently do not have a sane dispatch method in EntriesPage, we unfortunately have to trigger a virtual click on the “Load more” button. To make that work, we also need to keep the old offsets since when we clear the entries, there would be no way to get the offsets back in the `moreOnClick` handler.
This does not help since the offset is only calculated on pressing the button (initially undefined).
✅ Deploy Preview for selfoss canceled.
|
|
Because the Unfortunately, the dispatcher appears to bring another bug:
|
|
I also noticed the following weird behaviour but that does not appear to be a regression:
|
This is still somewhat broken: switching filter will trigger `RESET_OFFSET`, which will start loading more, and its spinner will get stuck.
The aborting short circuit has been introduced in 28d27f3 It can happen that the request is cancelled by another request but the second request will use `setLoadingState` instead of `setMoreLoadingState` so `moreLoadingState` will be stuck on `LOADING`. Not sure if it this cannot introduce a race if the same state is used in both requests. Tried testing with {let a = new AbortController(); let f = fetch('wait.php?seconds=3', {signal: a.signal}); f.then(r => console.log(r, a)); setTimeout(() => {a.abort(); f.then((r) => console.log(r, a.signal))}, 100);}
jtojnar
force-pushed
the
mark-read-on-unread
branch
from
5dd1263
to
4e6a3fc
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
In 2.18, when in “unread” mode, if there were no unread items, clicking the button would clear out all items and trigger a reload or refresh status of the “Load more” button, depending on whether the client was aware of more unread items on the server.
When we ported entries to React in f3b279c, we accidentally broke the “Mark all as read” button, making it keep all the items it marked in the view (a). We also did not port the code that would load more items afterwards (b).
It got further broken during porting routing to React in 405a3ec. We looked for the
filterfield on a wrong object (c).We fixed (c) and attempted to fix (a) in ec544b7 but the patch just made it keep all the items it did not mark, such as those marked as read manually beforehand, instead.
This patch makes it so that the button removes all the items in the view except for the active item and loads more items afterwards, returning to behaviour similar to 2.18.