feat(app): add generic run paused splash screen

[mjhuff]

Closes EXEC-387

Overview

Add a fallback run paused splash screen that will show when no specific errorType is handled explicitly. The exact logic used to display the splash message will most likely change (and we'll add specific error type subtext later).

Test Plan

• Make sure the ODD enable run notes FF is on.
• curl --location '<robot ip>:31950/settings' \ --header 'opentrons-version: *' \ --header 'Content-Type: application/json' \ --header 'Accept: application/json' \ --data '{ "id": "enableErrorRecoveryExperiments", "value": true }' (Please set this to false when you're done testing).
• Run anything that will throw a pick up tip failed error (make sure edge is pushed). Verify that the splash screen appears (note that cancelling the run after this point doesn't work currently).

Changelog

• Added "Run paused" splash screen.

Risk assessment

low

[jerader]

can't this be simplified to just const subText = protooclName ?? null?

[mjhuff]

The intention is we will very shortly add more errorTypes to the list.

[koji]

question

what is the purpose of using switch here?
in the future displaying something here?

[mjhuff]

Yep, exactly. See PR description.

[sfoster1]

Reviving this - would love to see this factored into an independent, pure, exported-for-testability function e.g.

export /* for testability */ function subtext(props: RunPausedSplashProps, /* may require future extra args */): string | null {
   switch(...) return (...)
   return null
}

export function RunPausedSplash(...): ... {
    return (.. <SplashBody>{subtext(props)}</SplashBody>...)
}

This seems minor, but I know that we use the open-coded let+switch in a lot of places and then test everything with rendered-dom inspection later, and in my view it makes the component functions really big and hard to follow. I think the pattern of factoring out functions and testing them as independent units can be nicer.

[koji]

LGTM!

[mjhuff]

@jerader @koji Thank you both for reviewing!

[sfoster1]

Have some code-style stuff.

[sfoster1]

Reviving this - would love to see this factored into an independent, pure, exported-for-testability function e.g.

export /* for testability */ function subtext(props: RunPausedSplashProps, /* may require future extra args */): string | null {
   switch(...) return (...)
   return null
}

export function RunPausedSplash(...): ... {
    return (.. <SplashBody>{subtext(props)}</SplashBody>...)
}

This seems minor, but I know that we use the open-coded let+switch in a lot of places and then test everything with rendered-dom inspection later, and in my view it makes the component functions really big and hard to follow. I think the pattern of factoring out functions and testing them as independent units can be nicer.

[sfoster1]

this optionality is getting kind of tough to follow. could we

1. factor the common parts into a common function
2. put the unique parts, I guess with uniqueness defined by the feature flag, in independent functions that don't in and of themselves check the feature flag
3. have this component check the feature flag and delegate?

[mjhuff]

Yeah sounds good!

[mjhuff]

#14873 (comment)

Can't respond to this in-line for some reason. I agree with you - this isn't a pattern we have used extensively, and I think that's historically because of how React used to work with the stack reconciler, back when I'm guessing we first used React. I think we can make the case pretty easily for it if we pull this out for use in the same file, and I'm fine doing this if the same-file approach works with you.