Fix #1758 Correct type definitions for OptionGroups and *Options types

[zimeg]

Summary

This PR corrects the type definitions for the OptionGroups type by enforcing a PlainTextElement type for the label of OptionGroups and Option[] for options of MessageOptions. Fixes #1758 by removing compilation errors when using these types.

Reviewers

With the changes in this PR, verify that the code sample in the linked issue compiles without error.

To inspect this change in Slack, create the following command (and add it to a testing app) to test the noted sample. Verify text appears after typing "plain_text" in the selector.

Example app.options typing

To properly compile the related example, ack must be typed with a block_suggestion or interactive_message middleware type like so:

- app.options('someCallbackId', async ({ ack }) => {
+ app.options('someCallbackId', async ({ ack }: SlackOptionsMiddlewareArgs<'block_suggestion'>) => {

Example command code

app.command('/ticket', async ({ ack, body, client }: SlackCommandMiddlewareArgs  & { client: WebClient }) => {
  await ack();

  try {
    const result = await client.views.open({
      trigger_id: body.trigger_id,
      view: {
        type: 'modal',
        callback_id: 'someCallbackId',
        title: {
          type: 'plain_text',
          text: 'Selections'
        },
        blocks: [
          {
            type: "section",
            block_id: "selector",
            text: {
              type: "mrkdwn",
              text: "Do you like plain text?"
            },
            accessory: {
              action_id: "option_callback",
              type: "external_select",
              placeholder: {
                type: "plain_text",
                text: "plain_text?"
              }
            }
          },
        ],
      }
    });
    console.log("yay!");
  }
  catch (error) {
    console.error("oops:", error);
  }
});

Notes

• One test no longer expects an error for interactive_message! There is another app.options test still expecting an error when using a { type: 'interactive_message' } parameter, and I am unsure if this is correct behavior. The FIXME comment above suggests that the type should be OptionsRequest<'interactive_message'>, however this is a deprecated type.
• The generic Option is used for *Options instead of a PlainTextOption or MrkdwnOption since the type of Option might differ by OptionGroups – see the differences in the text section for the Options object.
• Filtering of options in these groupings seems to not work... I am curious if there is already an issue to track this? 🤔

Requirements

• I've read and understood the Contributing Guidelines and have done my best effort to follow them.
• I've read and agree to the Code of Conduct.

[codecov]

Codecov Report

Merging #1790 (0cb3fc1) into main (4cfb6f7) will not change coverage.
The diff coverage is n/a.

❗ Current head 0cb3fc1 differs from pull request most recent head 062f0c7. Consider uploading reports for the commit 062f0c7 to get more accurate results

@@           Coverage Diff           @@
##             main    #1790   +/-   ##
=======================================
  Coverage   82.27%   82.27%           
=======================================
  Files          18       18           
  Lines        1523     1523           
  Branches      441      441           
=======================================
  Hits         1253     1253           
  Misses        172      172           
  Partials       98       98           

📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more

[zimeg]

Note: This seems related to the changes in #878.

[seratch]

@E-Zim I know this is confusing but the legacy dialog's options/option groups are already correct so we should not change them. We need to improve the types only for external select for Block Kit.

[seratch]

If the option group here is used for both legacy dialog and block kit based external data select, perhaps we need to have the two (meaning DialogOptionGroups and OptionGroup) instead.

[zimeg]

I added the DialogOptionGroups<Options> interface to accommodate these different types, with differences being in the label type. I opted to follow a similar pattern as OptionGroups<Options> (by including the generic), but if you'd think explicitly using the DialogOptions for options would be a better pattern (or something else), I'm happy to change this! For example:

export interface DialogOptionGroups {
  option_groups: ({
    label: string;
    options: DialogOptions[];
  })[];
}

[zimeg]

@seratch Thank you for catching that difference and reviewing these changes! I have updated the types to match the different option types, though I am curious if you have any different thoughts about how these changes should be made (if so, happy to make the changes).

I also noticed (and noted in the description) an oddity between two tests for the interactive_message type. Wanted to raise this in case this isn't behaving as expected!

[seratch]

This test change should be valid as the app.options pattern here now works properly

[seratch]

@E-Zim Thanks for working on this! This PR is ready to merge now 🎉