Conversation
* Implemented instant search that filters users as they type in the search box * Fetch all users once on page load using page: -1 parameter instead of paginated requests * Updated backend to support page: -1 for fetching all users without pagination
jask1m
force-pushed
the
feature/live-user-search
branch
from
c583f2c to
eb7c637
Compare
| let filtered = allUsers; | ||
| if (query.trim()) { | ||
| const searchTerm = query.trim().toLowerCase(); | ||
| filtered = allUsers.filter(user => { | ||
| return ( | ||
| user.firstName?.toLowerCase().includes(searchTerm) || | ||
| user.lastName?.toLowerCase().includes(searchTerm) || | ||
| user.email?.toLowerCase().includes(searchTerm) | ||
| ); |
There was a problem hiding this comment.
why not have the backend do this filtering? thats what wee did before this pr
There was a problem hiding this comment.
Yes, but I filter here on client so I can do a live search result update as user edits query, rather than making an API after a user clicks enter each time.
| if (currentSortOrder !== 'none') { | ||
| filtered = [...filtered].sort((a, b) => { | ||
| const aVal = a[currentSortColumn]; | ||
| const bVal = b[currentSortColumn]; | ||
|
|
||
| // Handle null/undefined | ||
| if (aVal == null && bVal == null) return 0; | ||
| if (aVal == null) return 1; | ||
| if (bVal == null) return -1; | ||
|
|
||
| // Compare based on type | ||
| let comparison = 0; | ||
| if (typeof aVal === 'string') { | ||
| comparison = aVal.localeCompare(bVal); | ||
| } else if (typeof aVal === 'number') { | ||
| comparison = aVal - bVal; | ||
| } else { | ||
| // Handle dates | ||
| const dateA = new Date(aVal); | ||
| const dateB = new Date(bVal); | ||
| comparison = dateA.getTime() - dateB.getTime(); | ||
| } | ||
|
|
||
| return currentSortOrder === 'asc' ? comparison : -comparison; | ||
| }); | ||
| } |
There was a problem hiding this comment.
100% the job of the backend, not here
| if (pageNum === -1) { | ||
| // Fetch all users (no pagination) | ||
| skip = 0; | ||
| limit = 0; // MongoDB uses 0 to mean "no limit" | ||
| } else { |
There was a problem hiding this comment.
is there a situation where we want to fetch every user ever
the pagination approach we have seems fine to me
There was a problem hiding this comment.
The rationale for this was that the initial load fetches all users and the client will handle filtering. I think the other approach to get the ux I want for search would be to debounce api calls as user types query but filtering on client seemed more appropriate.
There was a problem hiding this comment.
imagine its 3000+ rows to sort on, every time the user changes their input, thats a lot to ask for the browser when the backend is attached to mongodb
can we move this to the backend, and keep the pagination approach, we only ever need to return like the first 25 records
2 participants
In the admin dashboard, the search experience for user dashboard only filters candidates upon clicking
Enter. This PR improves the search experience by filtering realtime on each query keystroke. This workaround also reduces the frequency of API calls to the initial load and delete requests rather than at each search filter (because filtering happens on client now).Testing:
Sign in with: (email: test@one.sce, pw: sce)
link: https://unstultifying-barrable-patty.ngrok-free.dev/