(fix) O3-3978: Fix error in orders details table when orders are potentially undefined

[mccarthyaaron]

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 addresses an issue where filling in the test results of a lab order from the laboratory app and then navigating to the patient chart and then to the orders section throws an error “Cannot read property of undefined (reading length). The same issue does not exist when the test results are filled in from the patient chart.
The error is caused by reading the property length on tableRows here when tableRows is undefined. tableRows derives its value from allOrders as shown here which is returned by the usePatientOrders() hook.
For this PR we are going to focus on the orders key /order/patientUuid={patientUuid} as it's the one we use to fetch the orders.
In both cases, where the results are filled in from the patient chart and when they are filled in from the laboratory app, the mutation logic is the same. But the implications are different due to the orders key being mounted in the patient chart scenario(because the orders widget is mounted as the results are being filled in) versus not being mounted in the laboratory scenario.

In both scenarios, the client cache is mutated to undefined. But in the patient chart scenario there is an immediate revalidation triggered - a console.log shows that for a brief moment data is undefined, isLoading is true, isValidating is true. And a fetch request for the orders key is seen in the network tab. Although data is undefined, isLoading is true so a skeleton is rendered then eventually the data is displayed when its fetched.

In the laboratory app scenario, there is no re-fetch of the data related to the orders key after filling in the results as the key is not currently mounted- the network tabs proves this. If the user then navigates to the orders section in the patient chart, the orders key returns data as undefined but now isLoading and isValidating are both false. It is as if the orders key is not treated as being mounted for the first time(such that isLoading is true) but rather one for which data already exists although undefined. So there is a brief moment when the orders widget mounts, before it revalidates on mount ,where data is undefined and isLoading and isValidating are both false. So the last if clause is executed and throws on reading the property length on tablesRows which is now undefined.

The suggested solution is to add an optional chaining operator to tableRows.length and to return an empty array from the useOrders hook when the value of data from the orders key is undefined or null.

Screenshots

orders.mp4

Related Issue

https://openmrs.atlassian.net/browse/O3-3978

[denniskigen]

Thanks, @mccarthyaaron!