feat(api-client, app, react-api-client): Feat add robot door status check to desktop and odd

[koji]

Overview

add api-client and react-api-client to check door status via /robot/door/status endpoint
This PR needs #13584 (Adding a new endpoint for the robot status)

For Flex, doorRequiredClosedForProtocol is always true, so in this PR the item is used as an alternative of isOT3.

{
  "data": {
    "status": "closed",
    "doorRequiredClosedForProtocol": true
  }
}

[design]
Desktop
https://www.figma.com/file/0hYQ4lFJbAAI33jQMRt1Di/Release%3A-Desktop-June-Flex-launch?node-id=22521%3A106668&mode=dev

ODD
https://www.figma.com/file/AoTLAYuWawlaWItB1umOjr/Release%3A-Opentrons-Flex-Touchscreen?node-id=20416%3A122097&mode=dev

when a robot is missing modules/instruments or both -> not display Snackbar
when a robot is ready to run (instruments and modules are attached), but the door is open -> display Snackbar (7sec)

close RQA-1614

Test Plan

Desktop app

1. Setup protocol
2. Open the robot door
   Banner will show up in the header and the run start button is disabled

Touchscreen app

1. Setup protocol
2. Open the robot door
   Snackbar will show up and the play button is disabled

Changelog

• add getDoorStatus to api-client and useDoorQuery to react-api-client for the new endpoint, /robot/door/status/
• update ProtocolSetup components for Desktop app and ODD app
• update Snackbar type for passing duration

Review requests

Risk assessment

low

[codecov]

Codecov Report

Merging #13585 (d6d9d9e) into chore_release-7.0.0 (8384096) will increase coverage by 0.01%.
Report is 5 commits behind head on chore_release-7.0.0.
The diff coverage is 95.00%.

Additional details and impacted files

@@                   Coverage Diff                   @@
##           chore_release-7.0.0   #13585      +/-   ##
=======================================================
+ Coverage                71.32%   71.33%   +0.01%     
=======================================================
  Files                     2422     2423       +1     
  Lines                    68142    68178      +36     
  Branches                  7934     7946      +12     
=======================================================
+ Hits                     48600    48634      +34     
- Misses                   17685    17688       +3     
+ Partials                  1857     1856       -1     

Flag	Coverage Δ
app	69.00% <93.33%> (+0.04%)	⬆️
react-api-client	69.47% <100.00%> (+0.17%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files Changed	Coverage Δ
app/src/organisms/ToasterOven/ToasterContext.ts	100.00% <ø> (ø)
app/src/organisms/ToasterOven/ToasterOven.tsx	19.04% <0.00%> (ø)
...rganisms/Devices/ProtocolRun/ProtocolRunHeader.tsx	89.50% <100.00%> (+0.19%)	⬆️
.../src/pages/OnDeviceDisplay/ProtocolSetup/index.tsx	77.46% <100.00%> (+1.34%)	⬆️
react-api-client/src/robot/useDoorQuery.ts	100.00% <100.00%> (ø)

... and 5 files with indirect coverage changes

[koji]

• add test ProtocolSetup for ODD
• clean up code

[mjhuff]

I'm having difficulty getting the snackbar to appear whenever a "newly uploaded protocol" toast is present. 9/10 times, the snackbar doesn't render. When it does render above the protocol added toast, it looks good!

If you can't figure out an exact reason why this is happening, I think we need something else on the screen to alert uses to close the door. Maybe a chip in the ProtocolRunHeader?

Code is great! Just one small nit.

[koji]

I'm having difficulty getting the snackbar to appear whenever a "newly uploaded protocol" toast is present. 9/10 times, the snackbar doesn't render. When it does render above the protocol added toast, it looks good!

If you can't figure out an exact reason why this is happening, I think we need something else on the screen to alert uses to close the door. Maybe a chip in the ProtocolRunHeader?

Code is great! Just one small nit.

One question about the protocol you used.
Is the protocol was ready to run? (Right instruments and modules were attached?)

[mjhuff]

I'm having difficulty getting the snackbar to appear whenever a "newly uploaded protocol" toast is present. 9/10 times, the snackbar doesn't render. When it does render above the protocol added toast, it looks good!
If you can't figure out an exact reason why this is happening, I think we need something else on the screen to alert uses to close the door. Maybe a chip in the ProtocolRunHeader?
Code is great! Just one small nit.

One question about the protocol you used. Is the protocol was ready to run? (Right instruments and modules were attached?)

Ah good point. One was not ready to run, the other was a magnetic block protocol. Here's the protocol I used:
MagneticBlockTest2.py.zip

[koji]

I'm having difficulty getting the snackbar to appear whenever a "newly uploaded protocol" toast is present. 9/10 times, the snackbar doesn't render. When it does render above the protocol added toast, it looks good!
If you can't figure out an exact reason why this is happening, I think we need something else on the screen to alert uses to close the door. Maybe a chip in the ProtocolRunHeader?
Code is great! Just one small nit.

One question about the protocol you used. Is the protocol was ready to run? (Right instruments and modules were attached?)

Ah good point. One was not ready to run, the other was a magnetic block protocol. Here's the protocol I used: MagneticBlockTest2.py.zip

Thank you.
I just tested my branch with the protocol you shared with me.
Seems that there is a bug on Magnetic module.

However, the snackbar shows up and disappear after 7 sec.
I guess that might be a timing issue. I set refetch duration 10sec.
As a result, sometimes the snackbar shows up immediately, but mostly it will take a few seconds.

[mjhuff]

I think the higher refetch interval will solve our current problems.

Thanks for doing all this! 🚪 🚀