Open
Conversation
Contributor
WalkthroughAdded a new exported utility function Changes
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 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}
Contributor
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 `@assets/js/SearchTagInputHelper.ts`:
- Around line 9-12: The current two-step normalization in
SearchTagInputHelper.ts (the `value = value.replace(/\s+or\s+/gi, '|')` followed
by `value = value.replace(/\s/g, '_')`) breaks sequences like "OR OR" by leaving
an adjacent OR token that becomes part of a tag; change the first replacement to
collapse any run of one-or-more "or" tokens (use a regex that matches a sequence
of \bor\b tokens with surrounding whitespace, e.g.,
/\s*(?:\bor\b(?:\s+\bor\b)*)\s*/gi) and replace the entire run with a single '|'
before you replace remaining spaces with underscores so `value` is normalized
correctly. Ensure you update the `value` assignment in SearchTagInputHelper.ts
where these two replace calls occur.
In `@test/assets/search-tag-input-helper.test.ts`:
- Around line 12-14: The test currently checks mixed-case separators but misses
adjacent-separator edge cases; add a new spec in search-tag-input-helper.test.ts
that calls normalizeSearchTagInput with inputs containing repeated/adjacent
separators (e.g., "cat OR OR dog", "cat or OR or dog") and asserts the output
normalizes to "cat|dog" (or equivalent pipe-separated tokens), so the
normalizeSearchTagInput function is exercised against malformed adjacent
separators and prevents the malformed-output bug.
🪄 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: 5428f2ae-c338-492f-98ed-a1cf1679729e
📒 Files selected for processing (4)
assets/js/SearchTagInputHelper.tscomponents/pages/home/SimpleSearch.vuecomponents/pages/posts/navigation/search/SearchMenu.vuetest/assets/search-tag-input-helper.test.ts
Contributor
There was a problem hiding this comment.
♻️ Duplicate comments (2)
assets/js/SearchTagInputHelper.ts (1)
9-9:⚠️ Potential issue | 🟠 MajorLine 9: Separator regex is too broad and converts standalone/edge
orinto invalid pipes.Current behavior turns
normalizeSearchTagInput('or')into|andnormalizeSearchTagInput('cat or')intocat|. That produces malformed queries and treats non-separatororas an operator.Proposed fix
- value = value.replace(/\s*(?:\bor\b(?:\s+)?)+\s*/gi, '|') + // Only treat OR as a separator when it is between tokens, and collapse repeated OR runs + value = value.replace(/\s+\bor\b(?:\s+\bor\b)*\s+/gi, '|')🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@assets/js/SearchTagInputHelper.ts` at line 9, The replace regex in normalizeSearchTagInput is too permissive and turns standalone or-edge "or" into stray pipes; update the replacement to only match "or" as a whole word (use word boundaries, e.g. \b or equivalent) when acting as a separator, then after performing the replacement collapse consecutive '|' characters and trim any leading/trailing '|' from value so inputs like "or" or "cat or" don't become malformed "|" or "cat|". Ensure you reference normalizeSearchTagInput and the variable value when making these changes.test/assets/search-tag-input-helper.test.ts (1)
25-29:⚠️ Potential issue | 🟡 MinorAdd regression coverage for edge-position
ortokens.This suite still doesn’t verify standalone/trailing
or('or','cat or'), which is where malformed|output can slip in.Suggested test additions
it('collapses adjacent/repeated OR separators into a single pipe', () => { expect(normalizeSearchTagInput('cat OR OR dog')).toBe('cat|dog') expect(normalizeSearchTagInput('cat or OR or dog')).toBe('cat|dog') expect(normalizeSearchTagInput('cat OR OR OR dog')).toBe('cat|dog') }) + + it('does not treat standalone or edge-position "or" as a separator', () => { + expect(normalizeSearchTagInput('or')).toBe('or') + expect(normalizeSearchTagInput('cat or')).toBe('cat_or') + expect(normalizeSearchTagInput('or cat')).toBe('or_cat') + }) })🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@test/assets/search-tag-input-helper.test.ts` around lines 25 - 29, Add regression tests to cover edge-position "or" tokens for normalizeSearchTagInput: include cases for a standalone "or" input ('or'), leading 'or' ('or cat'), trailing 'cat or', and combinations like 'cat OR or' to ensure they don't produce malformed '|' characters; update test file search-tag-input-helper.test.ts and add expectations that these inputs normalize to either an empty string or the single tag without stray pipes (e.g., 'or' -> '', 'cat or' -> 'cat', 'or cat' -> 'cat').
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Duplicate comments:
In `@assets/js/SearchTagInputHelper.ts`:
- Line 9: The replace regex in normalizeSearchTagInput is too permissive and
turns standalone or-edge "or" into stray pipes; update the replacement to only
match "or" as a whole word (use word boundaries, e.g. \b or equivalent) when
acting as a separator, then after performing the replacement collapse
consecutive '|' characters and trim any leading/trailing '|' from value so
inputs like "or" or "cat or" don't become malformed "|" or "cat|". Ensure you
reference normalizeSearchTagInput and the variable value when making these
changes.
In `@test/assets/search-tag-input-helper.test.ts`:
- Around line 25-29: Add regression tests to cover edge-position "or" tokens for
normalizeSearchTagInput: include cases for a standalone "or" input ('or'),
leading 'or' ('or cat'), trailing 'cat or', and combinations like 'cat OR or' to
ensure they don't produce malformed '|' characters; update test file
search-tag-input-helper.test.ts and add expectations that these inputs normalize
to either an empty string or the single tag without stray pipes (e.g., 'or' ->
'', 'cat or' -> 'cat', 'or cat' -> 'cat').
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro
Run ID: c62689b2-53e3-4808-893b-9a84591ccd97
📒 Files selected for processing (2)
assets/js/SearchTagInputHelper.tstest/assets/search-tag-input-helper.test.ts
- Replace \s+or\s+ with a regex that collapses one-or-more adjacent 'or' tokens (e.g. 'cat OR OR dog' → 'cat|dog') per CodeRabbit feedback - Add test cases for repeated/adjacent separators
Using | as the OR-group separator conflicted with the existing use of | as the AND tag separator throughout the pipeline. Switch to , which is not used in booru tag names and survives the full App → API → Wrapper pipeline unmodified.
AlejandroAkbal
force-pushed
the
auto-triage/2-feature-or-search
branch
from
4fd4a4d to
5c22ff0
Compare
Contributor
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 `@assets/js/SearchTagInputHelper.ts`:
- Around line 1-15: The normalizeSearchTagInput function produces
leading/trailing or empty commas for inputs like "OR cat", "cat OR", or "OR";
update normalizeSearchTagInput to sanitize the comma-delimited result by
splitting on ',', trimming each token, filtering out empty tokens, and rejoining
with ',' (or simply remove leading/trailing commas and collapse consecutive
commas) so inputs return '' for 'OR' and 'cat' for 'OR cat'/'cat OR'; add unit
tests asserting normalizeSearchTagInput('OR cat') === 'cat',
normalizeSearchTagInput('cat OR') === 'cat', and normalizeSearchTagInput('OR')
=== '' to cover these edge cases.
In `@test/assets/search-tag-input-helper.test.ts`:
- Around line 4-29: Add unit tests for edge cases to document and assert the
current guard behavior of normalizeSearchTagInput: add a test that passes empty
and falsy inputs ('' , null as unknown as string, undefined as unknown as
string) and asserts they return '' to verify the early-return/guard clause; and
add a test for boundary OR tokens ('OR cat', 'cat OR', 'OR') that documents
current behavior (expect ',cat', 'cat,', ',' respectively) or updates
expectations if you change the helper to strip leading/trailing separators —
reference the normalizeSearchTagInput function in the test suite to locate where
to add these cases.
🪄 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: f62b2219-0763-4826-a19d-9918cd8eec85
📒 Files selected for processing (4)
assets/js/SearchTagInputHelper.tscomponents/pages/home/SimpleSearch.vuecomponents/pages/posts/navigation/search/SearchMenu.vuetest/assets/search-tag-input-helper.test.ts
Comment on lines
+1
to
+15
| export function normalizeSearchTagInput(rawValue: string) { | ||
| if (!rawValue) { | ||
| return '' | ||
| } | ||
|
|
||
| let value = rawValue.trim() | ||
|
|
||
| // Collapse one or more OR tokens (case-insensitive) into a comma — the OR-group delimiter | ||
| value = value.replace(/\s*(?:\bor\b(?:\s+)?)+\s*/gi, ',') | ||
|
|
||
| // Replace remaining spaces (within individual tag names) with underscores | ||
| value = value.replace(/\s/g, '_') | ||
|
|
||
| return value | ||
| } |
Contributor
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
# Find the file and examine it
find . -name "SearchTagInputHelper.ts" -o -name "*SearchTagInput*"Repository: Rule-34/App
Length of output: 90
🏁 Script executed:
# Search for usages of normalizeSearchTagInput
rg "normalizeSearchTagInput" --type ts --type tsxRepository: Rule-34/App
Length of output: 82
🏁 Script executed:
# Look for test files related to this function
fd -e spec.ts -e test.ts -e __tests__ | head -20Repository: Rule-34/App
Length of output: 319
🏁 Script executed:
# Check git history to understand context
git log --oneline -10 -- assets/js/SearchTagInputHelper.ts 2>/dev/null || echo "Git history not available"Repository: Rule-34/App
Length of output: 123
🏁 Script executed:
# Read the test file to see all test cases
cat -n test/assets/search-tag-input-helper.test.tsRepository: Rule-34/App
Length of output: 1588
🏁 Script executed:
# Find where normalizeSearchTagInput is actually used in the application
rg "normalizeSearchTagInput" --type ts -A 2 -B 2Repository: Rule-34/App
Length of output: 2896
🏁 Script executed:
# Check the full file to understand the implementation
cat -n assets/js/SearchTagInputHelper.tsRepository: Rule-34/App
Length of output: 573
🏁 Script executed:
# Search for where normalizeSearchTagInput is actually called in the application
rg "normalizeSearchTagInput" -B 3 -A 3 --type ts | grep -v "test/"Repository: Rule-34/App
Length of output: 290
🏁 Script executed:
# Look for any validation or processing of the output value
rg "normalizeSearchTagInput\(" -B 5 -A 5 --type tsRepository: Rule-34/App
Length of output: 3033
🏁 Script executed:
# Search more broadly for imports of this helper
rg "SearchTagInputHelper" --type tsRepository: Rule-34/App
Length of output: 177
🏁 Script executed:
# Search for where normalizeSearchTagInput might be used without explicit import
rg "normalizeSearchTagInput" --type js --type ts --type tsx --type jsx 2>/dev/null | head -30Repository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Look for any page or component that might handle search tag input
find . -name "*search*" -type f | grep -E "\.(ts|tsx|js|jsx)$" | head -20Repository: Rule-34/App
Length of output: 100
🏁 Script executed:
# Check pages directory for search functionality
ls -la pages/ 2>/dev/null | head -20Repository: Rule-34/App
Length of output: 811
🏁 Script executed:
# Search in Vue files for normalizeSearchTagInput
rg "normalizeSearchTagInput" --type-add 'vue:*.vue' --type vue 2>/dev/null || rg "normalizeSearchTagInput" pages/Repository: Rule-34/App
Length of output: 508
🏁 Script executed:
# Check if the function might be called differently or if it's a new addition
git log --all --oneline -- assets/js/SearchTagInputHelper.ts | head -5Repository: Rule-34/App
Length of output: 123
🏁 Script executed:
# Look at the index.vue file to see if it uses search tag input
grep -n "normalizeSearchTagInput\|SearchTagInput" pages/index.vueRepository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Check if there are any JavaScript files using it
find . -name "*.js" -type f | xargs grep -l "normalizeSearchTagInput" 2>/dev/nullRepository: Rule-34/App
Length of output: 39
🏁 Script executed:
# Get the recent commits to see if this is a new function or if usage was removed
git log --all --format="%H %s" | head -20Repository: Rule-34/App
Length of output: 2044
🏁 Script executed:
# Examine the SimpleSearch.vue component to see how searchQuery is used
cat -n components/pages/home/SimpleSearch.vue | head -50Repository: Rule-34/App
Length of output: 1637
🏁 Script executed:
# Look for where searchQuery is consumed after normalization
grep -n "searchQuery" components/pages/home/SimpleSearch.vue | head -20Repository: Rule-34/App
Length of output: 273
🏁 Script executed:
# Check the SearchMenu.vue component
cat -n components/pages/posts/navigation/search/SearchMenu.vue | head -50Repository: Rule-34/App
Length of output: 1941
🏁 Script executed:
# Look for the actual API call or query building to understand how the normalized value is used
rg "searchQuery" components/pages/home/SimpleSearch.vue -A 5 -B 5Repository: Rule-34/App
Length of output: 721
🏁 Script executed:
# Let's trace through the actual behavior with a specific edge case
# Check if there are any integration tests that might test "OR cat" scenario
rg "OR cat\|cat OR" test/ -t tsRepository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Let's check the complete onSearchChange and customTagFromQuery logic
cat -n components/pages/home/SimpleSearch.vue | sed -n '33,65p'Repository: Rule-34/App
Length of output: 863
🏁 Script executed:
# Look for any query building logic that might process the tag further
rg "emit.*searchTag\|emit.*submit" components/pages/home/SimpleSearch.vue -A 5 -B 5Repository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Check if there's any validation or normalization of the tags when passed to parent
rg "searchTag" components/ -A 3 -B 3 | head -40Repository: Rule-34/App
Length of output: 1815
🏁 Script executed:
# Check if there's any further processing of the emitted tag value
# Look for parent components that listen to 'searchTag' event
rg "@(submit|searchTag)=" components/ -A 2 -B 2Repository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Let's also verify the actual regex behavior with a test
python3 << 'EOF'
import re
def normalizeSearchTagInput(rawValue: str) -> str:
if not rawValue:
return ''
value = rawValue.strip()
# Collapse one or more OR tokens (case-insensitive) into a comma
value = re.sub(r'\s*(?:\bor\b(?:\s+)?)+\s*', ',', value, flags=re.IGNORECASE)
# Replace remaining spaces with underscores
value = re.sub(r'\s', '_', value)
return value
# Test edge cases
test_cases = [
"OR cat",
"cat OR",
"OR",
" OR cat ",
"cat OR dog",
"OR OR cat",
]
for test in test_cases:
result = normalizeSearchTagInput(test)
print(f"'{test}' -> '{result}'")
EOFRepository: Rule-34/App
Length of output: 175
🏁 Script executed:
# Check if there's any parent component that listens to the searchTag event and processes it
cat -n components/pages/home/SimpleSearch.vue | tail -20Repository: Rule-34/App
Length of output: 785
🏁 Script executed:
# Look at the full SearchMenu component to see how it handles the searchTag event
grep -n "normalizeSearchTagInput\|searchQuery\|onSearchChange" components/pages/posts/navigation/search/SearchMenu.vue | head -20Repository: Rule-34/App
Length of output: 397
🏁 Script executed:
# Check how the search results are actually built/used in the application
rg "searchTag" pages/ -A 5 | head -30Repository: Rule-34/App
Length of output: 920
🏁 Script executed:
# Let's look at the complete onSearchChange function in SearchMenu.vue to see if there's any additional handling
sed -n '112,130p' components/pages/posts/navigation/search/SearchMenu.vueRepository: Rule-34/App
Length of output: 480
🏁 Script executed:
# Check the complete flow - see what the parent component does with the emitted value
grep -n "onSearchTag\|onSearchSubmit" pages/index.vue -A 8 | head -30Repository: Rule-34/App
Length of output: 1039
🏁 Script executed:
# Let's verify what happens when the tag is used in navigation
grep -n "tag" pages/posts/\[domain\]/ -A 3 -B 3 2>/dev/null | head -40Repository: Rule-34/App
Length of output: 37
🏁 Script executed:
# Search for actual post search/filter logic
find . -name "*posts*" -type f -name "*.vue" | head -10Repository: Rule-34/App
Length of output: 37
Add test coverage and fix leading/trailing comma edge case.
The edge cases with leading/trailing OR tokens are real. Inputs like "OR cat", "cat OR", or "OR" produce ",cat", "cat,", and "," respectively. While the existing tests cover trimming, repeated OR collapsing, and space-to-underscore conversion, they don't cover these leading/trailing scenarios.
The normalized value is passed directly to downstream API calls without additional sanitization, so these malformed delimiters should be filtered out:
Recommended fix
// Replace remaining spaces (within individual tag names) with underscores
value = value.replace(/\s/g, '_')
+ // Remove any leading or trailing commas from edge OR tokens
+ value = value.replace(/^,+|,+$/g, '')
+
return value
}Add test cases covering the edge scenarios:
normalizeSearchTagInput('OR cat')should return'cat'normalizeSearchTagInput('cat OR')should return'cat'normalizeSearchTagInput('OR')should return''
📝 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.
Suggested change
| export function normalizeSearchTagInput(rawValue: string) { | |
| if (!rawValue) { | |
| return '' | |
| } | |
| let value = rawValue.trim() | |
| // Collapse one or more OR tokens (case-insensitive) into a comma — the OR-group delimiter | |
| value = value.replace(/\s*(?:\bor\b(?:\s+)?)+\s*/gi, ',') | |
| // Replace remaining spaces (within individual tag names) with underscores | |
| value = value.replace(/\s/g, '_') | |
| return value | |
| } | |
| export function normalizeSearchTagInput(rawValue: string) { | |
| if (!rawValue) { | |
| return '' | |
| } | |
| let value = rawValue.trim() | |
| // Collapse one or more OR tokens (case-insensitive) into a comma — the OR-group delimiter | |
| value = value.replace(/\s*(?:\bor\b(?:\s+)?)+\s*/gi, ',') | |
| // Replace remaining spaces (within individual tag names) with underscores | |
| value = value.replace(/\s/g, '_') | |
| // Remove any leading or trailing commas from edge OR tokens | |
| value = value.replace(/^,+|,+$/g, '') | |
| return value | |
| } |
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@assets/js/SearchTagInputHelper.ts` around lines 1 - 15, The
normalizeSearchTagInput function produces leading/trailing or empty commas for
inputs like "OR cat", "cat OR", or "OR"; update normalizeSearchTagInput to
sanitize the comma-delimited result by splitting on ',', trimming each token,
filtering out empty tokens, and rejoining with ',' (or simply remove
leading/trailing commas and collapse consecutive commas) so inputs return '' for
'OR' and 'cat' for 'OR cat'/'cat OR'; add unit tests asserting
normalizeSearchTagInput('OR cat') === 'cat', normalizeSearchTagInput('cat OR')
=== 'cat', and normalizeSearchTagInput('OR') === '' to cover these edge cases.
Comment on lines
+4
to
+29
| describe('normalizeSearchTagInput', () => { | ||
| it('maps typed OR separators to commas case-insensitively', () => { | ||
| expect(normalizeSearchTagInput('cat OR dog')).toBe('cat,dog') | ||
| expect(normalizeSearchTagInput('cat or dog')).toBe('cat,dog') | ||
| expect(normalizeSearchTagInput('cat Or dog')).toBe('cat,dog') | ||
| expect(normalizeSearchTagInput('cat oR dog')).toBe('cat,dog') | ||
| }) | ||
|
|
||
| it('maps multiple OR separators to commas', () => { | ||
| expect(normalizeSearchTagInput('cat OR dog or fish')).toBe('cat,dog,fish') | ||
| }) | ||
|
|
||
| it('preserves existing behavior of converting spaces in tags to underscores', () => { | ||
| expect(normalizeSearchTagInput('black hair')).toBe('black_hair') | ||
| expect(normalizeSearchTagInput('black hair OR blue eyes')).toBe('black_hair,blue_eyes') | ||
| }) | ||
|
|
||
| it('trims surrounding whitespace', () => { | ||
| expect(normalizeSearchTagInput(' cat OR dog ')).toBe('cat,dog') | ||
| }) | ||
|
|
||
| it('collapses adjacent/repeated OR separators into a single comma', () => { | ||
| expect(normalizeSearchTagInput('cat OR OR dog')).toBe('cat,dog') | ||
| expect(normalizeSearchTagInput('cat or OR or dog')).toBe('cat,dog') | ||
| expect(normalizeSearchTagInput('cat OR OR OR dog')).toBe('cat,dog') | ||
| }) |
Contributor
There was a problem hiding this comment.
🧹 Nitpick | 🔵 Trivial
Good test coverage — consider adding edge case tests.
The tests thoroughly cover the main scenarios and address the prior review feedback about adjacent OR tokens. Consider adding tests for:
- Boundary OR tokens:
"OR cat","cat OR","OR"alone — to document whether leading/trailing commas are expected or should be stripped. - Empty/falsy inputs:
"",null,undefined— to verify the guard clause at lines 2-4 of the helper.
📝 Suggested additional test cases
it('handles empty and falsy inputs', () => {
expect(normalizeSearchTagInput('')).toBe('')
expect(normalizeSearchTagInput(null as unknown as string)).toBe('')
expect(normalizeSearchTagInput(undefined as unknown as string)).toBe('')
})
it('handles leading/trailing OR tokens', () => {
// Document current behavior (produces leading/trailing commas)
// or update if the helper is changed to strip them
expect(normalizeSearchTagInput('OR cat')).toBe(',cat')
expect(normalizeSearchTagInput('cat OR')).toBe('cat,')
expect(normalizeSearchTagInput('OR')).toBe(',')
})🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@test/assets/search-tag-input-helper.test.ts` around lines 4 - 29, Add unit
tests for edge cases to document and assert the current guard behavior of
normalizeSearchTagInput: add a test that passes empty and falsy inputs ('' ,
null as unknown as string, undefined as unknown as string) and asserts they
return '' to verify the early-return/guard clause; and add a test for boundary
OR tokens ('OR cat', 'cat OR', 'OR') that documents current behavior (expect
',cat', 'cat,', ',' respectively) or updates expectations if you change the
helper to strip leading/trailing separators — reference the
normalizeSearchTagInput function in the test suite to locate where to add these
cases.
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Summary
Implements OR search support at the App layer for Feature: OR search (73 votes).
Users can now type
cat OR dog(case-insensitive) in the search bar and get real OR semantics from upstream booru sites.How it works
normalizeSearchTagInputconverts user-typedORkeywords into a comma delimiter, producing a single tag string that encodes the OR group:cat OR dog→cat,dog(one tag element in the URL, encoded ascat%2Cdog)black hair OR blue eyes→black_hair,blue_eyesThe comma is used because
|is already the AND tag separator throughout the pipeline (?tags=tag1|tag2|tag3). Using|for OR groups would cause the existing.split('|')logic to destroy OR information before it ever reaches the API.A comma-delimited OR-group tag passes through the URL, App, and API unchanged as a single array element, and the Universal-Booru-Wrapper PR translates it to engine-specific OR syntax at query time.
Changes
assets/js/SearchTagInputHelper.ts— replaceORkeyword with,instead of|test/assets/search-tag-input-helper.test.ts— update all test expectations to use,Depends on
Summary by CodeRabbit
Release Notes
New Features
Tests