-
Notifications
You must be signed in to change notification settings - Fork 59
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
(fix) Reworked logic for gravida calculation #337
Conversation
parityAbortion + parityTerm + 1; | ||
} | ||
return gravida; | ||
return parseInt(parityTerm) + parseInt(parityAbortion); |
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.
So in other words the Gravida is the summation of the parityTerm
with parityAbortion
?
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.
Affirmative.
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.
Per our conversation from Coffee Break call, you might need to consider the current pregnancy in your calculation @arodidev.
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.
@denniskigen I did a bit of consultation, and it seems the convention should be to do a summation of the two.
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.
Mostly LGTM. I've left a suggestion related to using a different function for the number validation and a JSDoc comment string.
@@ -260,17 +260,14 @@ export class CommonExpressionHelpers { | |||
}; | |||
|
|||
calcGravida = (parityTerm, parityAbortion) => { |
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.
calcGravida = (parityTerm, parityAbortion) => { | |
/** | |
* Calculates the gravida (total number of pregnancies) based on term pregnancies and abortions/miscarriages. | |
* | |
* @param {number|string} parityTerm - The number of term pregnancies. | |
* @param {number|string} parityAbortion - The number of abortions (including miscarriages). | |
* @returns {number} The total number of pregnancies (gravida). | |
* @throws {Error} If either input is not a valid number. | |
* | |
* @example | |
* const gravida = calcGravida(2, 1); | |
* console.log(gravida); // Output: 3 | |
*/ | |
calcGravida = (parityTerm, parityAbortion) => { |
const term = parseInt(parityTerm, 10); | ||
const abortion = parseInt(parityAbortion, 10); | ||
|
||
if (isNaN(term) || isNaN(abortion)) { |
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.
if (isNaN(term) || isNaN(abortion)) { | |
if (!Number.isInteger(term) || !Number.isInteger(abortion)) |
Perhaps Number.isInteger is a better check here since we're specifically dealing with whole numbers. Unlike isNaN
, which allows any valid number (including decimals), Number.isInteger
will reject decimals. Additionally, isNaN
attempts to coerce the input into a number before checking, which can lead to unintended behavior, while Number.isInteger
will return false for any non-number types. If we decide to consider decimal inputs in the future, reverting to isNaN
would be more appropriate.
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.
Thanks @denniskigen, this has been resolved.
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.
I'm naive when it comes to the business aspects but the code LGTM
* redo gravida logic * handle non integer values * Use Number.isInteger() over isNaN() plus JSDoc comments
Requirements
Summary
This PR corrects the gravida calculation logic within the form engine.
Screenshots
Related Issue
Other