Fix "only this person" #473
Conversation
…ld not refresh itself; (2) the status description and actual logic of the "show this user" are inconsistent (1) This causes the page to become blank when users want to filter by posters only in the deeper levels of the thread. (2) When a user filters by the poster of a certain post, long-pressing on another post displays "Show all posts," but clicking it actually filters by the user of that other post.
…ed methods in hole_detail
|
Is it possible that when only this person triggers, we do not pull-to-refresh, but instead we record posts that have been fetched and set their, say, attribute to invisible to users? |
This was done in 3cb7ca1. I removed the |
|
"Perhaps the best solution would be to automatically fetch the next 10 posts on pull-to-refresh until posts satisfying the filter are found. However, this sounds like it would put a lot of pressure on the backend." |
|
sorry for the late comment. |
… it will automatically quit.
|
this should work. |
| @@ -68,7 +68,7 @@ String preprocessContentForDisplay(String content) { | |||
| if (element is UrlElement) { | |||
| // Only add tag if tag has not yet been added. | |||
| if (RegExp("\\[.*?\\]\\(${RegExp.escape(element.url)}\\)") | |||
| .hasMatch(content) || | |||
| .hasMatch(content) || | |||
There was a problem hiding this comment.
Please avoid including irrelevant code formatting in your commits.
Each commit should ideally contain only the necessary changes. As we don't currently have a code formatting guideline, if your IDE automatically formats code (e.g., randomly adding/removing spaces, tabs, newlines), please review your file changes carefully before committing.
Both VSCode and Android Studio allow you to commit specific lines within a file. This enables you to include only the intended changes in your current commit, deferring other formatting adjustments to subsequent commits (or reverting them).
| if (!scrollToEnd && selectedPerson != null) { | ||
| func(); | ||
| } |
There was a problem hiding this comment.
This strikes me as rather confusing and over-abstracted.
If you're passing in a function callback and a selectedPerson parameter, simply to check a condition and then conditionally execute that callback, wouldn't it make more sense to perform that check directly at the point where this function is invoked? Especially considering there's currently only one instance in the entire codebase where an actually useful value is being passed in, and the logic within the callback bears absolutely no relation to refreshing.
What's your rationale for putting this code – which, to me, looks completely non-reusable and seems to have no bearing on what refreshListView is supposed to do – inside the refreshListView method?
This PR:
However, there's still an operation that can easily trap users: if a user filters by the poster of a deeper comment and then pulls down to refresh, the entire page becomes blank because the pull-to-refresh only fetches the first 10 posts. Perhaps the filter setting should be reset upon pull-to-refresh?
Perhaps the best solution would be to automatically fetch the next 10 posts on pull-to-refresh until posts satisfying the filter are found. However, this sounds like it would put a lot of pressure on the backend.