Repository navigation
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The intent is reasonable, but the change introduces a few behavioral risks.
Potential issues
settingmay benull/undefinedThe old code passed
settingdirectly toObject.assign, wherenull/undefinedsources are ignored. The new code will throw if the API returns no setting object.setting?.email_portandsetting ?? {}.Default
email_portcan be lostIf
settingdoes not containemail_port, this always overwrites the value fromdefaultEmailSettingwith''.defaultEmailSetting.email_port.The promise return value changed
The old arrow function returned:
The new block-bodied arrow function returns
undefined:If any caller relies on
loadEmailSetting().then(...)receivingemailSetting, that behavior is now broken.return Object.assign(...)if the return value matters.Normalization only happens on load
The comment says the port is unified as a string for display, validation, and submission, but this diff only normalizes on load. Make sure the submit payload is also converted consistently. If the API expects a number on submit, converting everything to a string could break the request.
String(...)is permissiveStringwill produce"NaN","true", or"[object Object]"for unexpected values. Validation should reject these, or the normalization should be stricter.Suggested patch
If
nullfrom the API is intended to mean “clear the port” rather than “use the default,” adjust the fallback logic accordingly:Minor optimization
Using
async/awaitwould make the loading/error flow clearer, but it is not required:Overall: no syntax problem, but check the
nullsafety, default-port fallback, and the changed promise return value.