-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix #1758 Correct type definitions for OptionGroups
and *Options
types
#1790
Conversation
Codecov Report
@@ 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 |
Note: This seems related to the changes in #878. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@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.
label: string; | ||
value: string; | ||
}[]; | ||
options: Option[]; | ||
} | ||
export interface OptionGroups<Options> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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[];
})[];
}
@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 |
@@ -50,7 +50,7 @@ expectType<void>( | |||
app.options<'interactive_message'>({ callback_id: 'a' }, async ({ options, ack }) => { | |||
expectType<InteractiveMessageSuggestion>(options); | |||
// https://github.com/slackapi/bolt-js/issues/720 | |||
expectError(ack({ options: blockSuggestionOptions })); | |||
ack({ options: blockSuggestionOptions }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This test change should be valid as the app.options pattern here now works properly
@E-Zim Thanks for working on this! This PR is ready to merge now 🎉 |
Summary
This PR corrects the type definitions for the
OptionGroups
type by enforcing aPlainTextElement
type for thelabel
ofOptionGroups
andOption[]
foroptions
ofMessageOptions
. 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 ablock_suggestion
orinteractive_message
middleware type like so:Example command code
Notes
interactive_message
! There is anotherapp.options
test still expecting an error when using a{ type: 'interactive_message' }
parameter, and I am unsure if this is correct behavior. TheFIXME
comment above suggests that the type should beOptionsRequest<'interactive_message'>
, however this is a deprecated type.Option
is used for*Options
instead of aPlainTextOption
orMrkdwnOption
since the type ofOption
might differ byOptionGroups
– see the differences in thetext
section for theOptions
object.Requirements