Refactored (src/user/data.js:212): Reduced complexity in function modifyUserData()

[alanj268]

P1B: Starter Task: Refactoring PR

Use this pull request template to briefly answer the questions below in one to two sentences each.
Feel free to delete this text at the top after filling out the template.

You are not permitted to use generative AI services (e.g., ChatGPT) to compose the answers.
Any such use will be treated as a violation of academic integrity.

1. Issue

Please provide a link to the associated GitHub issue:

#235

Full path to the refactored file:

src/user/data.js

What do you think this file does?
(Your answer does not have to be 100% correct; give a reasonable, evidence‑based guess.)

I think that this file provides a set of functions for interacting with, fetching, and updating various user account-related data, such as ban information, icon/avatar images, name and email, etc.

What is the scope of your refactoring within that file?
(Name specific functions/blocks/regions touched.)

I only refactored the code within the function modifyUserData() (previously on line 212).

Which Qlty‑reported issue did you address?
(Name the rule/metric and include the BEFORE value; e.g., “Cognitive Complexity 18 in render()”.)

212 Function with high complexity (count = 42): modifyUserData

2. Refactoring

How did the specific issue you chose impact the codebase’s adaptability?

The functions within the file were used to retrieve user data for a variety of features on the website (notifications, posts, profile, etc.), and so the complexity of the function used to make modifications to the user fields was related to many different parts of the website, meaning any change which required fetching and/or modifying user data involved this code. Improving the readability and complexity of it therefore would have an impact on the logic related to many features.

What changes did you make to resolve the issue?

I reduced the control-flow complexity of the function by rearranging some of the code, in particular moving many of the series of if-conditionals to a few different helper functions.

How do your changes improve adaptability? Did you consider alternatives?

Moving the code altering user information to different helper functions organized the code better, and making new functions means that further changes can continue to use these helper functions in different locations, improving code readability and avoiding redundancy. I considered rearranging the orders of the if-conditionals further, but I could not think of an easy way to do it that did not involve a large amount of nested if-statements.

3. Validation

How did you trigger the refactored code path from the UI?

The function was accessed automatically from the starting page, so I just opened the NodeBB instance in the browser.

Attach a screenshot of the logs and UI demonstrating the trigger.
(Run ./nodebb log; include the relevant UI view. Temporary logs should be removed before final commit.)

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 17481805981

Details

• 49 of 51 (96.08%) changed or added relevant lines in 1 file are covered.
• No unchanged relevant lines lost coverage.
• Overall coverage increased (+0.003%) to 78.532%

---

Changes Missing Coverage	Covered Lines	Changed/Added Lines	%
src/user/data.js	49	51	96.08%

Totals
Change from base Build 17435863312:	0.003%
Covered Lines:	24698
Relevant Lines:	29612

---

💛 - Coveralls