Refactor (src/user/search.js): simplify filterAndSortUids to reduce complexity

[jnbain]

1. Issue

Please provide a link to the associated GitHub issue:
#262

Link to the associated GitHub issue:
#262

Full path to the refactored file:
src/user/search.js

What do you think this file does?
I think this file handles the user search on the server side. It looks up user IDs based on what was put in the search bar, and then filters them by things like online, verified, and banned. After that, it sorts the users if a sort field is given and returns the results so they can be shown in the UI.

What is the scope of your refactoring within that file?
The scope of my refactoring was the filterAndSortUids function. I focused on reducing the complexity of the function while keeping the same behavior for filtering and sorting users. Most of the code stayed the same, I just split it up it helpers to make it readable and manageable, while also reducing the complexity.

Which Qlty‑reported issue did you address?
I worked on the Qlty reported issue "Function with high complexity (count=11): filderAndSortUids. Before my changes, the function had a complexity of 11, and my goal was to lower that by cleaning up the logic and splitting things into clearer steps.

2. Refactoring

How did the specific issue you chose impact the codebase’s adaptability?
My changes made the code easier to understand and adapt in the future. I broke down long, nested checks into smaller steps so it's clearer what each part does. This way, if someone needs to add a new filter or something else, they can do it without making the function even more complicated.

What changes did you make to resolve the issue?
I cleaned up the function by breaking it into smaller steps. I organized how filters and fields are collected, and I made sure the checks for group membership and banned users happen in their own clear blocks. I also made the sorting easier to follow by moving it into its own helper.

How do your changes improve adaptability? Did you consider alternatives?
My changes make the function easier to adapt in the future because each part is more separate and clear. If new filters or sort options need to be added, it’s straightforward to plug them in without making the whole function more complicated. I did think about rewriting it into multiple smaller functions, but I chose to keep it in one place with helper calls so the flow is still easy to follow.

3. Validation

How did you trigger the refactored code path from the UI?
I triggered my refactored code by using the search feature in the NodeBB UI. I typed a username into the search bar on the Users page, which called the filterAndSortUids function I refactored.
Attach a screenshot of the logs and UI demonstrating the trigger.

Attach a screenshot of qlty smells --no-snippets <full/path/to/file.js> showing fewer reported issues after the changes.

[coveralls]

Pull Request Test Coverage Report for Build 17507742114

Details

• 66 of 70 (94.29%) changed or added relevant lines in 2 files are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.04%) to 78.568%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/controllers/composer.js	38	42	90.48%

Totals
Change from base Build 17435863312:	0.04%
Covered Lines:	24725
Relevant Lines:	29629

---

💛 - Coveralls