fix: reinstate reference page filter with search by title and desc.#1465
fix: reinstate reference page filter with search by title and desc.#1465Anshumancanrock wants to merge 3 commits into
Conversation
|
hii @ksen0 , This PR is up for review, please take a look. |
|
Hi @Anshumancanrock thanks for working on this, it's got some false positives at the moment - by description, what is expected is that the filter filters based on the title and the short description (@limzykenneth please correct me if I've misunderstood the goal though):
Also I think only if possible without adding much more lines of code filtering by category title would also be good, ie display the whole category if filter keyword matches.
|
84cc7ca to
7d83d43
Compare
|
Hi @ksen0 , Thanks for catching! Fixed both: The filter was matching against the full HTML description instead of the short one-line description shown on the page. Now it uses
|
|
Hi @Anshumancanrock, thank you for working on this. I tested this locally, and here is what I found. What works well Suggested issues to address Here is how they were translated in PR #1377 before they were removed: cc @ksen0 @doradocodes would love your thoughts on this. |
|
Thanks @Nwakaego-Ego ! Good catch on the localization, @Anshumancanrock do you mind adding the strings back based on the link/comment above? Thank you |
|
@Nwakaego-Ego @ksen0 Thanks for the review! Good catch on the translation key. I've restored the original |
|
Hi @Anshumancanrock sorry to keep going back and forth! But the fact that this is a bit of a subtle feature is the reason it was removed before it could be implemented well! So thank you for the patience. @Nwakaego-Ego thanks for your review, please also include more subtle and weird tests as you keep testing this- same reason as above. In addition to above tests, I tried the string "sin." In case when there is:
then partial substring matches should be excluded. Currently MANY are shown because "sin" is a substring of "since" "single" and "using", which are common words. (I am not trying to be difficult, I just didn't think of it before 😅 ) @Anshumancanrock if you could include all the different tests listed here as unit tests that would be amazing. |
|
Hi @Anshumancanrock are you still working on this one? Let me know if you prefer for someone else to complete this one! Please ping if you're still on it by ~July 11th, otherwise we'll continue the work directly. Thanks again for all your work on it already. |
|
Hi @Anshumancanrock, just checking in. Please let us know if you are still working on this or if you need any help. |
|
Hi @ksen0 @Nwakaego-Ego , Yes, I am working on the issue and will push the changes shortly. |
|
Hi @ksen0, thanks for the detailed feedback. I've reworked the matching so partial substrings no longer flood the results. It now does two passes: Strict pass: exact function/section name matches + whole-word description matches. So now when there's a precise match, it ignores partial substrings like you described: sin returns sin() (and anything with the actual word "sin" in the description), but no longer matches "using", "since", "single", or "asin". I also added unit tests for all the cases from this thread : sin/sin. substring stuff, exact name matches, prefix fallbacks, category/subcategory matches, whole-word descriptions, and case-insensitivity. 14 new tests, all green, full suite passing. One quick question: in the fallback pass I kept substring matching on descriptions too, since it only triggers when nothing better matches. I thought "show something relevant" is better than showing nothing, but happy to limit it to names if you prefer. |
… tests
The reference filter matched keywords as raw substrings everywhere, so a
search for "sin" flooded results with common words containing it as a
substring ("using", "since", "single") and unrelated names ("asin").
Filtering now runs in two passes:
1. strict - exact function/section name matches + whole-word description
matches
2. loose - substring fallback, used only when the strict pass finds
nothing (so prefix searches like "typog" -> Typography and
"circ" -> circle still work)
When an exact or whole-word match exists, partial substrings are excluded,
exactly as requested in review. Keyword normalisation also strips trailing
punctuation so "sin." resolves to "sin".
The matching logic is extracted into pure, exported functions
(filterCategoryData, normalizeKeyword) and covered by unit tests for every
scenario raised in the PR discussion.
5011a43 to
53d6a7c
Compare




Problem
The search/filter input on the reference page was rendered but non-functional. The component was never hydrated on the client, so typing into it did nothing.
Fixes: #1401
What this PR does
Testing
Built and tested locally across all reference categories. Filter matches, clear button, and empty state all work as expected.