feat: [alpha] Providers grid refactor

[lily-de]

Overview of new providers architecture

1. Centralized Provider Registry:

• All providers are defined in one place, which makes it clear where to add or update a provider.
  This also streamlines maintaining shared logic or styling across providers.

2. Consistent Base Components

• Each provider wraps a common “base” component (in this case, a set of <ActionButton>s inside a ProviderCard) to ensure consistent look and feel.
• Any styling or functionality changes in the base component automatically propagate to all providers.

3. Default vs. Custom Actions

• The registry offers default actions (common operations) for most use cases.
• For edge cases, providers can define custom actions or callbacks, keeping the system flexible.

4. Easier Maintenance & Onboarding

• Because definitions live in one folder, newcomers can quickly see all available providers and how they’re structured.
• Adding or updating a provider involves adding/updating a single file in that folder, rather than scattering definitions across multiple components.

How to view

1. run just run-ui-alpha
2. On the more menu you can file 'see new providers grid' in indigo text

Note -- currently buttons do not affect any change, you will just see a success toast pop up to indicate that process for linking callback functions to buttons worked

Details

Terminology

• Actions / CardActions / ActionButton / ProviderActions: here "Action" in all these terms refers to something that a provider needs in order to be configured or interacted with by the user. These are things such as:
  • adding keys
  • updating current settings
  • refreshing (e.g. for ollama running in the background)
  • launching goose with a certain provider on onboarding
  • deleting keys
• Callbacks: The functions that are executed upon pressing a button on the card, different buttons have different callbacks -- the Add button pulls up a provider settings modal, the delete button pulls up a confirm modal, the refresh button check for ollama running, etc

Adding a new provider

Adding a new provider with buttons involves adding a similar relatively small item to a mapping

• name
• description
• any required/optional parameters for configuration
• what buttons to display - the placement of the buttons is handled downstream in a sub component and button definitions can be grouped together into a list of actions mapped to callbacks to generate the final button at rendering time so similar style buttons can have unique callbacks for different cards

example

OpenAI

{
    name: 'OpenAI',
    details: {
      id: 'openai',
      name: 'OpenAI',
      description: 'Access GPT-4, GPT-3.5 Turbo, and other OpenAI models',
      parameters: [
        {
          name: 'OPENAI_API_KEY',
          is_secret: true,
        },
      ],
      getActions: (provider, callbacks) => {
        const { onAdd, onDelete, onShowSettings } = callbacks || {};
        return [
          {
            id: 'default-provider-actions',
            renderButton: () => (
              <DefaultProviderActions
                name={provider.name}
                isConfigured={provider.isConfigured}
                onAdd={onAdd}
                onDelete={onDelete}
                onShowSettings={onShowSettings}
              />
            ),
          },
        ];
      },
    },
  },

Updating card styling (buttons primarily)

• Updating styling of the card requires editing the button definitions as needed and then updating their placement in a sub component that controls where different buttons show up (CardHeader is currently where the green check goes, CardBody is where other actions/buttons such as editing or adding keys)