Why not just pass in formAttr if it contains id and name already?

I actually went this direction since I was getting a TS error:

I'm not sure why this error is appearing, since I should be ensuring that id is defined with the ternary check, but the error went away when I narrowed the object. Do you know offhand why that might be happening? I wasn't sure I wanted to spend more time troubleshooting it when this solution worked.

Hmm yeah, the number | undefined part comes from the fact that we are wrapping HydratedAttributeType with Partial in the AttributeForm type, which makes things less easy to handle (my bad).

If you change the attributes type in AttributeForm to: Array< HydratedAttributeType | { id: undefined; terms: [] } > it will more accurately represent the type and allow you to use formAttr.id ? formAttr : undefined for the value prop here.

This also gets run after the hydratedAttributes are initial fetched, which makes the form dirty. Should we just set this as it's own function and only call it when the user updates or removes it?

Well, the intention here was just to have the hydratedAttributes act as a proxy for the attributes in the form data, only with the terms data populated. So we can just alter this variable as we would otherwise alter the form data and get the behavior we want. It feels like it would complicate it more to have another callback that may or may not be called in conjunction with onChange.

Can you elaborate on what state would cause the form to become "dirty?" We'd only be updating this when we want to update the form data.

Can you elaborate on what state would cause the form to become "dirty?" We'd only be updating this when we want to update the form data.

You can notice this when looking at the Update button, when you load an existing product with attributes the Update button shows as disabled initially (meaning there are no changes) and once the onChange here is called it becomes active, allowing a user to save. This could also cause issues in the future if we decide to rely more on the fieldsChanged values.

I understand the reasoning behind this and see how you need it, but it be nice if we only trigger onChange once actual changes have been made and not just for the bootstrapping of the field.

The reason for suggesting a separate callback function is because this may be difficult to handle within a useEffect, as it would be difficult to differentiate if hydratedAttributes was updated by an actual change or just the initial loading.

I believe this filter seems to break the select control, where I cannot search for any other attribute.

Do you mean in just in the edit modal? That's my intention here and what I assumed would be the behavior we want (unless I misunderstand). See my other comment above for more context.

I finally got it working, it may of been a couple things. The need for the use of the SelectControlMenuSlot to have the dropdown show correctly and I was testing this on a site that had over a 1000 of attributes, so the selected items may of not come back as part of the initial list, thus not showing up, also reasoning for just using the standard SelectControl as mentioned above.

Nice!