Repository navigation
Jaden: Fix Community Members list filtering, sorting, and search (follow-up to #4281) (DONE Jaden) - #5514
Jaden: Fix Community Members list filtering, sorting, and search (follow-up to #4281) (DONE Jaden)#5514Jaden300 wants to merge 10 commits into
Conversation
… to #4281) - Replace hard-coded localhost:4500 endpoint with ENDPOINTS.HGN_COMMUNITY_MEMBERS - Always load the full member list from /hgnHelp/community instead of falling back to /hgnform/ranked when filters are active, so no member is excluded - Move skill filter, preference filter, and name/skill search to the client so every skill in the filter list works - Surface fetch errors instead of swallowing them; guard non-array responses - Remove the non-functional Score sort option; keep A-to-Z / Z-to-A name sort - Hide the Score line on member cards when no numeric score is present
✅ Deploy Preview for highestgoodnetwork-dev ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
- Use a Set with .has() for preference lookup - Document why the fetch catch block only sets error state
Jaden300
changed the title
Jaden300
changed the title
one-community
added
the
High Priority - Please Review First
There was a problem hiding this comment.
Hey Jaden! I went through the testing steps on this PR, and everything works great on my end:
-
Initial Load: All community members load correctly up front on /hgnhelp/community.
-
Search & Skill Filters: Searching by member name or skill keywords, as well as toggling single and multi-select skill filters, works as expected.
-
Sorting & Dark Mode: Toggling A-to-Z / Z-to-A flips the card order properly, and both light and dark modes display nicely.
devangsaraogi
left a comment
devangsaraogi
left a comment
There was a problem hiding this comment.
Hi @Jaden300,
I tested the current PR head locally on /hgnhelp/community using both an Admin and Volunteer account.
Verified that:
- all community members load successfully
- searching by member name works
- searching by skill keyword works
- normal skill filters behave consistently with the data returned by
/hgnHelp/community A-to-ZandZ-to-Asorting work correctlylightanddarkmode display correctly- the page is accessible and functional as a
Volunteer - I did not encounter any new console errors during testing
I also confirmed the documented limitation where the aggregate Frontend/Backend, MERN and Leadership filters return no results, so I did not treat those as new issues. The PR explicitly documents that limitation.
I did find one blocking issue with Filter by Preferences: selecting any preference results in No members found. The /hgnHelp/community response does not provide a preferences field, while the new client-side filtering logic expects one, so every member fails the preference filter.
Requesting changes for the preference-filter behavior.
| if (!matchesSkills) return false; | ||
| } | ||
|
|
||
| if (selectedPreferences && selectedPreferences.length > 0) { |
There was a problem hiding this comment.
Selecting any option under Filter by Preferences currently results in No members found.
I reproduced this with all available preference options. The /hgnHelp/community response does not appear to include a preferences field for the returned members, so user.preferences || [] becomes an empty array for every user. As a result, once any preference is selected, no users can match.
Since this PR moved filtering from /hgnform/ranked to client-side filtering of /hgnHelp/community, could the preference data be made available here or the previous preference-filtering behavior be preserved?
iAbhi001
left a comment
iAbhi001
left a comment
There was a problem hiding this comment.
Hi @Jaden300,
I tested your PR locally and verified the changes. Everything works as expected on my end:
- Initial Load: All community members load properly up front on
/hgnhelp/communitywithout relying on a hardcoded endpoint. - Search & Skill Filtering: Searching by member name and skill keywords functions smoothly. Both single and multi-select skill filters update the list correctly, and "Clear All" resets the view.
- Sorting & UI: Toggling between A-to-Z and Z-to-A flips the card order accurately. The missing score line is cleanly hidden, and the layout looks consistent across both light and dark modes.
Great work addressing the follow-up items. Approved!
DeepighaJ
left a comment
DeepighaJ
left a comment
There was a problem hiding this comment.
- Tested the Community Members page locally and verified that all members load correctly.
- Search functionality works for both member names and skill keywords.
- Single and multi-select skill filters return the expected matching members, and clearing all resets the filters correctly.
- The A–Z / Z–A sorting works as expected, and the page displays properly in both light and dark modes.
- As mentioned by previous reviewers the Filter by Preference returns no members which needs to be addressed if its a issue. Otherwise LGTM.
|
Root cause for the Filter by Preference issue: the /hgnHelp/community backend endpoint never returns a preferences field - communityController.js destructures general but only forwards general.location, dropping general.preferences. Since the frontend filter reads user.preferences, it's always undefined and no member can match. Opened a fix in HGNRest: OneCommunityGlobal/HGNRest#2351 (forwards general.preferences as an array). Once that merges, preference filtering here will work without any frontend changes needed - the client-side filter code already expects that shape. |
87d5111
This reverts commit 87d5111.
iAbhi001
left a comment
iAbhi001
left a comment
There was a problem hiding this comment.
Hi @Jaden300,
I tested the latest head of this PR locally on /hgnhelp/community across multiple accounts. The initial data load, sorting (A–Z / Z–A), and general name search are functioning smoothly without making repeated network requests.
However, I noticed an issue regarding skill display and skill-based search rendering:
- Top Skills Disappear on Filtered Cards: When searching or filtering by keywords (e.g., matching a user by name or term), the resulting member cards no longer render the
Top Skills:section. In the unfiltered list, cards display the list of skills properly, but once a search term is applied, that entire section vanishes from the card view. - Skill Keyword Search: When typing a skill directly into the search bar (such as
CSS,Bootstrap, orReact), matching members who possess those skills are not consistently retrieved or their skill list is stripped on render.
Could you look into RankedUserList.jsx / RankedUserCard.jsx to ensure that skill data is properly preserved and rendered when the filtered array is passed down to the card components?
Requesting changes to address this display bug. Thanks!
DeepighaJ
left a comment
DeepighaJ
left a comment
There was a problem hiding this comment.
I also reviewed the latest changes and was able to reproduce the skill-related issue mentioned above. Used the provided backend for testing.
- When filtering/searching members on
/hgnhelp/community, the Skills section is not consistently displayed on the filtered member cards, and searching directly by skill does not consistently return the expected members. - This affects the skill display and skill-based search functionality.
- Requesting changes to ensure skill data is preserved and rendered correctly when the filtered results are passed to the member cards.
iAbhi001
left a comment
iAbhi001
left a comment
There was a problem hiding this comment.
Thank you for the updates. I’ve reviewed the latest changes against the provided backend and was able to reproduce the skill-related issue mentioned previously.
Observations:
- On the
/hgnhelp/communitypage, the Skills section is dropped or inconsistently displayed on member cards after applying filters or searching. - Searching directly by "skill" does not reliably return the expected members.
Requested Changes:
Please review the filtering logic to ensure that skill data is preserved in the state and correctly passed down to the member card components when rendering filtered results. This is impacting both the skill display and the core skill-based search functionality.
Visual references attached below:
Search by skill keyword only matched raw DB field keys like UnitTest or ResponsiveUI, so natural-language terms members would actually type (e.g. testing, responsive) never matched. Top Skills on each card also rendered those same raw keys instead of the human-readable labels used in the filter buttons, making the skill list look inconsistent or missing real skills once a search or filter was applied. Now normalizeUser keeps a displaySkills list (formatted via formatSkillName) alongside the raw topSkills keys used for filter-button matching. Search matches against both the raw keys and the formatted labels, and UserCard renders the formatted labels.
vidiyala99
left a comment
vidiyala99
left a comment
There was a problem hiding this comment.
Tested 908e2e3 as Administrator on /hgnhelp/community with backend OneCommunityGlobal/HGNRest#2351 (153764a, which adds preferences to /hgnHelp/community), against the dev data (read-only), in dark mode.
What works:
- Loading: all 184 members load once from
ENDPOINTS.HGN_COMMUNITY_MEMBERS, and no request is made while filtering, searching or sorting. - Skills stay on the cards: after filtering and searching, every visible card still shows its skills (0 cards with an empty skills line), so the issue from the last reviews is fixed.
- Preferences: "Frontend" leaves 113 members, which matches the stored form data (screenshot 1).
- MERN / Frontend/Backend / Leadership return 0, as the "Known limitation" section says.
- The skill filter barely narrows the list.
/hgnHelp/communityreturns a score for every skill a member rated, andnormalizeUserkeeps all of them intopSkills(sorted by score), so the filter matches anyone who has the skill at any score:
| Filter | This PR | of those, self-rated 0 to 2 | GET /api/hgnform/ranked?skills=... (the strict rule) |
|---|---|---|---|
| React | 177 of 184 | 22 | 110 |
| Environment Setup | 180 | 25 | 30 |
| MongoDB | 180 | 26 | 133 |
Searching "mongo" also leaves 180 of 184. This is the same problem that came up on OneCommunityGlobal/HGNRest#2370 (which now keeps the backend filter strict: the selected skill must be in the member's top 4 for its section). Moving the filtering to the client brings it back. Applying the same rule here (or a minimum score such as 5+), using the scores you already have in skills, would make the filter meaningful again.
- "Top Skills" lists every skill. The first card shows about 20 skills under "Top Skills:", because
topSkillsis the full sorted list. Showing the top 4 or 5 (and keeping the full list for filtering) would match the label.
Requesting changes for item 1.
Screenshot 1: Frontend preference filter (113 members), dark
…er section Mirrors the strict rule already used by /api/hgnform/ranked - a skill only counts for filtering if it's among the top 4 by score within its section - so selecting a skill filter actually narrows the list instead of matching nearly every member who rated that skill at any score. This also caps the "Top Skills" shown on each card to match the label.
|
This branch has not been deployed
7 participants
Jaden: Fix Community Members list filtering, sorting, and search (follow-up to #4281) (DONE Jaden)- #5514
Description
Follow-up fixes for PR #4281. Addresses reviewer feedback and bugs in the
/hgnhelp/communitypage.Changes
http://localhost:4500URL withENDPOINTS.HGN_COMMUNITY_MEMBERSfromsrc/utils/URL.js, so the page works in every environment (Aditya-gam's comment)./hgnform/rankedwhen a filter is active. It fetches the full member list from/hgnHelp/communityonce and does all filtering, searching, and sorting on the client, so no member is excluded by the request and every skill in the filter list works (Aditya-gam's comment).Score: undefined / 10.Known limitation
The three aggregate skills (Frontend/Backend, MERN, Leadership) live on the form's
generalsection, which/hgnHelp/communitydoes not return, so filtering by those three yields no results. Fixing that needs a backend change in HGNRest and will be a separate PR.How to test
npm install, run the app./hgnhelp/community.Related PRs
Follow-up to #4281
vod.mov