(feat) O3-4398 : add new mutate lab orders prop to enable workspace callers to correctly mutate data

[amosmachora]

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 a new optional prop mutateLabOrders that allows the workspace callers to pass a mutate function when the user has completed submitting the laboratory result.

Screenshots

This is an example of a use case where this will help in the labs ESM.

lab-results-fix.mp4

Related Issue

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

Other

An accompanying PR on the labs app can be found here.

[denniskigen]

The current implementation of the mutateLabOrders callback appears to serve two purposes simultaneously:

1. Launching the test-results-form-workspace workspace.
2. Triggering revalidation of lab orders

Is this dual responsibility intentional? Given that we're already operating within the workspace context when invoking this form, should the workspace launch be considered a separate concern from the data revalidation?

If so, consider separating these concerns by:

1. Keeping the workspace launch as a distinct action.
2. Passing only the revalidation logic via props.

This would better align with the Single Responsibility Principle and prevent workspace re-launching from within an already active workspace context.

[denniskigen]

I've left this additional comment that should clarify what I meant above.

[denniskigen]

I've also tested this out locally and I don't see how the Add lab results button in the Laboratory app is related to the Add results button in the Orders app.

Your other PR adds a mutate function that gets passed down to the workspace when you launch the Lab results form by clicking the Add lab results button in the Laboratory app.

On the other hand, the Add results button in the Orders table in Patient Chart has a different handler altogether.

Could you help shed some light on that, @amosmachora?

[amosmachora]

The two buttons are not related at all. They all launch the same workspace on their click handlers but from different places in the app.

That's why I wouldn't want to couple the mutateLabOrders functionality to the workspace itself and would like it to remain agnostic and have what it needs be passed down as an optional prop. I am not sure I am answering your question.

Do you think they should use the same handler?

[denniskigen]

So the thing is, AFAICT, even if you pass mutateLabOrders down as a prop to the workspace, it only gets passed to the workspace that gets launched from clicking the Add lab results button in the Lab app.

Adding it as a prop to the orders app doesn't work because the logic that triggers launching that workspace has no knowledge of the mutateLabOrders prop.

[amosmachora]

Isn't that what we want? I think that was essentially what I was trying to achieve to find a way for whatever caller to pass a mutate function and have it just work. This was essential in the lab since it allowed for the mutation of lab orders rendered as rows. if for example in the orders app, a need would arise to mutate something (highly unlikely) they would pass a prop and it would just work.

Now that I think of it maybe the prop could be named more generically like mutate.

Adding it as a prop to the orders app doesn't work because the logic that triggers launching that workspace has no knowledge of the mutateLabOrders prop.

that's why I made it optional since it is very specific to the lab workspace and no other workspace instance.

Does this feel like a hack? Any better ideas

[amosmachora]

Hello @denniskigen yesterday during the coffee break you said you had ideas where we could achieve this functionality without passing the prop, whenever you find a way just highlight it and I will make the change.