Improvement suggestions on @slack/types for better TypeScript support

[seratch]

Description

This issue is for the discussion about @raycharius's suggestions described at #1226 :

Also, I think there are some opportunities for refactoring that would make this package even more useful than it already is. While developing v.2 of slack-block-builder, I've noticed I'm doing a lot of typing on my end, since a lot of the types aren't available through this package.

• Moving union types to their own exported types. For example, elements supported within the ActionsBlock having a type of ActionsElements. For SectionBlock, SectionElements. Etc.
• Moving enum values to their own exported enums.

@raycharius
As long as the changes never bring breaking changes to existing apps, we are happy to discuss the changes. I haven't checked your library in detail yet but can you elaborate a bit more about the plans in your mind? If sharing a draft pull request with us is easier for you, that's also helpful to learn your intention.

What type of issue is this? (place an x in one of the [ ])

• bug
• enhancement (feature request)
• question
• documentation related
• testing related
• discussion

Requirements (place an x in each of the [ ])

• 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.
• I've searched for any related issues and avoided creating a duplicate issue.

[raycharius]

Cheers!

So, as one example, I've created my own enums for things like button styles, filters, etc. By putting those in their own enums in @slack/types, those could just be imported for use other than type checking.

And overall, some ideas on how to make it a bit more maintainable and flexible.

I'll put together a draft PR for this, as there's not much work involved, and it will provide us with some concrete context.

More soon!

[raycharius]

Hi!

I've created a draft pull request demonstrating improvements to @slack/types.

• Moving all string values to exported enums. By doing so, these enums can be imported and used as values and for typing in projects. See this commit.
• Moving all inline union types to their own types to reduce redundancy as well as a change meant to simplify the next proposal... See this commit.
• Using discriminated union types to enforce various construct requirements. Currently, all types have optional properties when there is a condition around whether or not it is optional. By introducing these types, typing becomes more strict and overall there's a better TS experience to catch issues before they are caught by API calls. If this looks like something that you think would be valuable – happy to invest the time in this. See this commit.
• Also, what do you think about adding a check to make sure arrays of enums have unique values?

[seratch]

Thanks for promptly sharing the draftPR! I left a comment about changing the types to enums. #1228 (comment)

[filmaj]

It's been a while since we've posted anything on this issue, but FYI I am slowly organizing for the next major release of @slack/types and I definitely think the suggestions discussed by @raycharius in this issue as well as in #1228 are certainly worth including. Specifically:

• discriminative unions for certain types to model either/or relationships
• enums in general where appropriate

I've tagged this issue for the 3.x milestone.

[filmaj]

I'm going to close this issue and actually open separate issues for each of the three suggestions contained in this issue. I will reference this issue in the new issues I open. I am doing so as it will be easier to discuss and tackle each one separately - from my perspective, I am supportive of some of the suggestions but not all, so I'd like to have more focussed discussions on each suggestion.