Skip to content
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

(feat) O3-2814: Add field validation to the lab order form #1649

Merged

Conversation

usamaidrsk
Copy link
Member

@usamaidrsk usamaidrsk commented Feb 8, 2024

Requirements

  • This PR has a title that briefly describes the work done including the ticket number. If there is a ticket, make sure your PR title includes a conventional commit label. See existing PR titles for inspiration.
  • My work conforms to the OpenMRS 3.0 Styleguide and design documentation.
  • My work includes tests or is validated by existing tests.

Summary

This PR adds form validation to the lab orders from

Screenshots

image

Related Issue

O3-2814

Other

Copy link
Member

@denniskigen denniskigen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Some good work here, @usamaidrsk, thanks! Just a few things to clean up before this is ready to go.

Comment on lines 34 to 40
labReferenceNumber: z.string({
required_error: 'Lab reference number is required',
invalid_type_error: 'Lab reference number is required',
}),
testType: z.object(
{ label: z.string(), conceptUuid: z.string() },
{ required_error: 'Test type is required', invalid_type_error: 'Test type is required' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT, invalid_type_error is used to specify a custom error message that will be displayed when the type of a value does not match the expected type defined in the schema. So, in this case, it will complain if the values provided in the validated fields are not strings. The error message provided should be reflective of that. Or if we're not validating type mismatches, we could remove it entirely.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, @denniskigen!
We should use invalid_type_error for objects, because the error thrown by Zod in case the input is removed says "Expected object, recieved null".

@usamaidrsk, we don't need need invalid_type_error messages for string, required_error should handle that for the strings. Please see if removing invalid_type_error for z.object doesn't throw the error I shared above, i.e. required_error takes care of it or not.
Thanks!

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @denniskigen
Here I used the same error message as of required, just because Expected string, received null would not give clear meaning to the user on the form.

If there is a suggestion, I would like to know, then I can replace with that.

Comment on lines 34 to 40
labReferenceNumber: z.string({
required_error: 'Lab reference number is required',
invalid_type_error: 'Lab reference number is required',
}),
testType: z.object(
{ label: z.string(), conceptUuid: z.string() },
{ required_error: 'Test type is required', invalid_type_error: 'Test type is required' },
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi, @denniskigen!
We should use invalid_type_error for objects, because the error thrown by Zod in case the input is removed says "Expected object, recieved null".

@usamaidrsk, we don't need need invalid_type_error messages for string, required_error should handle that for the strings. Please see if removing invalid_type_error for z.object doesn't throw the error I shared above, i.e. required_error takes care of it or not.
Thanks!

);

const cancelOrder = useCallback(() => {
setOrders(orders.filter((order) => order.testType.conceptUuid !== inProgressLabOrder.testType.conceptUuid));
setOrders(orders.filter((order) => order.testType.conceptUuid !== getValues().testType.conceptUuid));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

getValues expect an arg 🤔

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If no arguments, it returns the entire form values. which I used here
Thanks @vasharma05

@denniskigen
Copy link
Member

denniskigen commented Feb 9, 2024

Just me, or does it appear as though the Priority ComboBox component have a double red outline when validation fails?

Removing this override should fix it, I think:

  :global(.cds--list-box) {
    border: none;
  }

Thanks for being patient, it's very close!

@denniskigen denniskigen changed the title (feat) O3-2814 Add form validation to lab order form (feat) O3-2814: Add field validation to the lab order form Feb 9, 2024
@usamaidrsk
Copy link
Member Author

usamaidrsk commented Feb 9, 2024

@denniskigen

 :global(.cds--list-box) {
    border: none;
  }

removing this in thelab-order-form.scss resolved the issue.

image

Copy link
Member

@denniskigen denniskigen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @usamaidrsk!

@denniskigen denniskigen force-pushed the ft-add-validations-to-lab-order-form branch from 6861ede to 860a17d Compare February 9, 2024 20:50
@denniskigen denniskigen force-pushed the ft-add-validations-to-lab-order-form branch from 860a17d to 4592b26 Compare February 9, 2024 20:53
@denniskigen
Copy link
Member

Following my fixup commit, the error message container is now pinned to the bottom of the page:

Desktop

CleanShot 2024-02-09 at 11  30 16@2x

Tablet

CleanShot 2024-02-09 at 11  35 50@2x

@denniskigen denniskigen merged commit b9046f1 into openmrs:main Feb 9, 2024
6 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants