feat(protocol-designer,-shared-data): add liquid class scaffolding to PD

[ncdiehl11]

Overview

This PR introduces initial work for liquid class support in protocol designer. I create a full liquid class interface based on the API's Pydantic model. I also add utilities for getting all liquid class definitions and a feature flag to hide liquid classes from the UI. Lastly, I add some of the basic functionality for assigning a liquid class to a defined liquid, and displaying that liquid class in LiquidCard. A liquid class assigned to a defined liquid will be accessible through extended existing selectors (allIngredientNamesIds) for step forms.

closes AUTH-965
closes AUTH-968

Test Plan and Hands on Testing

• navigate to settings and flip on liquid classes feature flag
• navigate to protocol overview and add or modify a liquid
• select a liquid class (should only see water as this is the only built out definition as of now)
• save and verify that liquid definitions reflect liquid class
• add this liquid to a labware or inspect a labware that has already loaded this liquid
• verify that liquid card in toolbox reflects liquid class

Screen.Recording.2024-12-17.at.2.44.38.PM.mov

Changelog

• add liquid class interface
• add liquid class feature flag
• add liquid class definitions getter
• update selectors to accommodate liquid classes
• dad liquid class feature to DefineLiquidsModal, LiquidsToolbox, LiquidCard, LiquidDefinitions (behind feature flag)
• update tests

Review requests

• see test plan

Risk assessment

medium

[jerader]

nit, the other fields can be refactored as well.

Suggested change

	liquidClass: string | null | undefined
	liquidClass?: string | null

[jerader]

is this undefined here to avoid needing to add this to a migration?

[ncdiehl11]

I think these are unnecessarily allowed to be undefined or null in some cases. The modal disallows saving without a liquid name, and displayColor is always a valid hex string. I think description can be set to null for easier use downstream as well. Thoughts on this interface for the selector allIngredientGroupFields:

export interface LiquidGroup {
  name: string
  description: string | null
  displayColor: string
  liquidClass: string | null
  serialize: boolean
}

[ncdiehl11]

and since we're dealing with nullish initial values in DefineLiquidsModal, we can update that interface to

interface LiquidEditFormValues {
  name: string
  displayColor: string
  description: string
  liquidClass: string
  serialize: boolean
  [key: string]: unknown
}

[jerader]

i see, that makes sense to me.

i think we would need liquidClass to be undefined in OrderedLiquids at least because its included in the JSON protocols and if it is always null or a string, we'd need to make a migration for it. i'm all for adding this to the migration but not right now since there's no way to put it behind a FF. Do you mind adding a TODO or something above the type to remind us to migrate it later?

[ncdiehl11]

For sure! I will keep it as an optional property for now and we can remove the optionality and add a migration later

[jerader]

do we not have this type already?

[ncdiehl11]

I don't see it anywhere in ts types

[jerader]

looks great! left some comments. curious if adding liquidClass to the ingredients would be nice to have in the migration -- like populating it to null. though it'd be tricky to make a migration right now since we may need one in 8.3.0 or for plate reader, so i'd recommend adding a TODO for that for now if we decide to go down that route.

[koji]

for consistency

Suggested change

	const getLiquidDescription = (
	function getLiquidDescription(

[ncdiehl11]

I thought we usually defined utility functions with const notation?

[jerader]

wait i thought so too?

[koji]

sorry the comment isn't clear enough.

This returns JSX.Elment so the following method would be consistent.

function LiquidDescription()

[koji]

need this?

extends BaseLiquidHandlingProperties<BaseRetract>

[ncdiehl11]

I don't think so, since the interface is exactly the same. I wanted to add a Base interface so that Aspirate and Dispense could share it

[koji]

probably add ff mock code to protocol-designer/src/pages/ProtocolOverview/__tests__/LiquidDefinitions.test.tsx

[jerader]

awesome! 🎉