fix: explain blocklist-hidden results on posts page#96
fix: explain blocklist-hidden results on posts page#96AlejandroAkbal wants to merge 1 commit intomainfrom
Conversation
WalkthroughSingle file modification that changes error handling for blocklisted tags in post data loading. When a blocklisted tag is selected, Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
✨ Simplify code
📝 Coding Plan
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@pages/posts/`[domain].vue:
- Around line 389-405: The synthetic empty IPostPage return object in
pages/posts/[domain].vue currently sets links.prev and links.next to empty
strings which pagination logic treats as truthy; update that returned object
(the literal cast to IPostPage) so that links.prev and links.next are null
(sentinel for “no page”) instead of '' to ensure previous/next page checks
behave correctly; keep other fields unchanged.
- Around line 589-594: The blocklist comparison in the computed
isBlockedTagSelected uses raw string comparisons which are case-sensitive;
update the predicate to normalize casing (e.g., toLowerCase()) for both the
selectedBlockList entries and tag names before comparing, extract and reuse that
predicate function (e.g., normalizeAndMatches(blockTag, tag)) so other blocklist
checks use the same logic, and update references to selectedBlockList,
selectedTags, and isBlockedTagSelected to call the normalized comparison to
avoid case-mismatch misses.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: 5b67ffdb-2d09-42c7-bdac-9353a782915f
📒 Files selected for processing (1)
pages/posts/[domain].vue
| return { | ||
| data: [], | ||
| meta: { | ||
| items_count: 0, | ||
| total_items: 0, | ||
| current_page: 0, | ||
| total_pages: 0, | ||
| items_per_page: 0 | ||
| }, | ||
| links: { | ||
| self: '', | ||
| first: '', | ||
| last: '', | ||
| prev: '', | ||
| next: '' | ||
| } | ||
| } as IPostPage |
There was a problem hiding this comment.
Use null sentinels for prev/next in the synthetic empty page.
Line 402-Line 403 currently return empty strings, but pagination logic treats only null/undefined as “no page”. This can make previous-page state incorrect for blocklisted queries.
Proposed fix
links: {
self: '',
first: '',
last: '',
- prev: '',
- next: ''
+ prev: null,
+ next: null
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| return { | |
| data: [], | |
| meta: { | |
| items_count: 0, | |
| total_items: 0, | |
| current_page: 0, | |
| total_pages: 0, | |
| items_per_page: 0 | |
| }, | |
| links: { | |
| self: '', | |
| first: '', | |
| last: '', | |
| prev: '', | |
| next: '' | |
| } | |
| } as IPostPage | |
| return { | |
| data: [], | |
| meta: { | |
| items_count: 0, | |
| total_items: 0, | |
| current_page: 0, | |
| total_pages: 0, | |
| items_per_page: 0 | |
| }, | |
| links: { | |
| self: '', | |
| first: '', | |
| last: '', | |
| prev: null, | |
| next: null | |
| } | |
| } as IPostPage |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pages/posts/`[domain].vue around lines 389 - 405, The synthetic empty
IPostPage return object in pages/posts/[domain].vue currently sets links.prev
and links.next to empty strings which pagination logic treats as truthy; update
that returned object (the literal cast to IPostPage) so that links.prev and
links.next are null (sentinel for “no page”) instead of '' to ensure
previous/next page checks behave correctly; keep other fields unchanged.
| const isBlockedTagSelected = computed(() => { | ||
| return ( | ||
| selectedBlockList.value.length > 0 && | ||
| selectedBlockList.value.some((blocklistTag) => selectedTags.value.map((tag) => tag.name).includes(blocklistTag)) | ||
| ) | ||
| }) |
There was a problem hiding this comment.
Normalize tag casing before blocklist comparisons.
Line 592 compares raw strings. Because blocklist entries and query tags can differ by case, blocked tags can be missed. Please normalize both sides (e.g., lowercase) and reuse the same predicate in all blocklist checks to avoid behavior drift.
Proposed fix
+ const selectedTagNameSet = computed(() => new Set(selectedTags.value.map((tag) => tag.name.toLowerCase())))
+
const isBlockedTagSelected = computed(() => {
- return (
- selectedBlockList.value.length > 0 &&
- selectedBlockList.value.some((blocklistTag) => selectedTags.value.map((tag) => tag.name).includes(blocklistTag))
- )
+ return selectedBlockList.value.some((blocklistTag) => selectedTagNameSet.value.has(blocklistTag.toLowerCase()))
})📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| const isBlockedTagSelected = computed(() => { | |
| return ( | |
| selectedBlockList.value.length > 0 && | |
| selectedBlockList.value.some((blocklistTag) => selectedTags.value.map((tag) => tag.name).includes(blocklistTag)) | |
| ) | |
| }) | |
| const selectedTagNameSet = computed(() => new Set(selectedTags.value.map((tag) => tag.name.toLowerCase()))) | |
| const isBlockedTagSelected = computed(() => { | |
| return selectedBlockList.value.some((blocklistTag) => selectedTagNameSet.value.has(blocklistTag.toLowerCase())) | |
| }) |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@pages/posts/`[domain].vue around lines 589 - 594, The blocklist comparison in
the computed isBlockedTagSelected uses raw string comparisons which are
case-sensitive; update the predicate to normalize casing (e.g., toLowerCase())
for both the selectedBlockList entries and tag names before comparing, extract
and reuse that predicate function (e.g., normalizeAndMatches(blockTag, tag)) so
other blocklist checks use the same logic, and update references to
selectedBlockList, selectedTags, and isBlockedTagSelected to call the normalized
comparison to avoid case-mismatch misses.
1 participant
Summary
Validation
Feedback issue: https://feedback.r34.app/p/posts/212/hiding-blocking-tags
Summary by CodeRabbit
Bug Fixes
User Experience