feat(actions): Restructure ActionFormIndex and utilize ModalContext in forms

[hannasage]

Purpose

To eliminate complexity created by PackageActionForm and each form handling their own modals.

Linked Issues to Close

N/A
(Part of ongoing CHIP Actions work)

Approach

Previously, we piped in props to an action form within the PackageActionForm component by cloning the children and piping data from the parent thru as new props. This gets confusing and convoluted whenever you want to add new props, have a unique prop for a specific form, etc. It also creates weird nesting dependencies for our form pages.

React.Children.map(
    children as CloneableChild[],
        (child: CloneableChild) =>
            React.cloneElement(child, {
                // Child has to be configured to take these
                item,
             })

🤢 Yucky icky gross complexity, yikez

So, to remedy this complexity and open us up to more accessible props, we now handle the following responsibilities from PackageActionForm within the ActionFormSwitch component:

• Fetching the item (package)
• Validating the action is valid for the given package
• Displaying any fetch/validation errors for the above
• Piping the item object through to the form page (Form pages have additionally been made to use the prop instead of using a fetch)

switch (type) {
    case Action.WITHDRAW_PACKAGE:
      return <WithdrawPackage item={item} />;
    case Action.ENABLE_RAI_WITHDRAW:
    case Action.DISABLE_RAI_WITHDRAW:
      return <ToggleRaiResponseWithdraw item={item} />;
    case Action.ISSUE_RAI:
      return <RaiIssue item={item} />;
    case Action.WITHDRAW_RAI:
      return <WithdrawRai item={item} />;
    case Action.RESPOND_TO_RAI:
      return <RespondToRai item={item} />;
    default:
      return <Navigate path="/" />;
  }

😍 Beautiful gorgeous wonderful simplicity, yay

One layer up, in ActionFormIndex where we render the switch, we also wrap it in a page container, the modal context, and provide breadcrumbs so form pages can remain singularly focused on rendering form fields and controlling their data.

Assorted Notes/Considerations/Learning

In testing CHIP actions, we've identified cases where control over props is a large advantage, so this untangling of prop control for action forms becomes even more useful as we move into waiver actions that have additional requirements.

[hannasage]

BEGONE ye ol' dependency! One example of how we no longer need to wrap these as the responsibilities handled by this are now handled in ActionFormIndex (breadcrumbs and page container), and ActionFormSwitch (item fetching and piping as props).

[hannasage]

Notably we add a dependency, but isolate its usage to a point that wraps all action forms instead of wrapping them individually, and provides a replicable solution for future form indexes (i.e. Submission forms when refactored to a dynamic-path approach like Actions forms).

[pkim-gswell]

I'm liking the refactor decisions for these package actions 👍.
Leaving some suggestions/comments.

[pkim-gswell]

Continuing on from my initial comment, RespondToRai would look like this:

// attachments
{attachmentList.map(({ name, label, required }) => (
  <I.FormField
    key={name}
    control={form.control}
    name={`attachments.${name}`}
    render={SlotAttachments({
      label: (
        <>
          {label}
          {required ? <I.RequiredIndicator /> : ""}
        </>
      ),
      message: <I.FormMessage />,
    })}
  />
))}

// additionalInfo
<I.FormField
  control={form.control}
  name="additionalInformation"
  render={SlotAdditionalInfo({
    label: "Add anything else that you would like to share with CMS.",
    description: "4,000 characters allowed",
  })}
/>

[13bfrancis]

Left a few comments/questions for you

[13bfrancis]

I don't know why but when I see context I smile inside lol

[13bfrancis]

When Paul is good with this I am. I like what you got going here

[github-actions]

🎉 This PR is included in version 1.5.0-val.1 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀