Draft: Improve types

[raycharius]

Summary

Draft pull request to discussion in this issue around improving @slack/types. See discussion here.

Requirements (place an x in each [ ])

• 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.

[seratch]

I'm afraid that changing union type to enum may not be fully backward-compatible. I cannot tell what the possible troubles are by this but at least, unions and enums are not the same. To me, just naming the union types would be a safer refactoring. What do you think?

[rr-codes]

Just my two cents, but I really love enums more than unions aha

[raycharius]

I've been playing around with this a bit, and you are totally right. For some reason, I always though of enums as a subset of union types, but it will not work with simple strings.

Naming the union types would definitely make the code more structured, but that would be a change that's more internal for your team as opposed to offering value for developers using the SDK.

There is one other possibility, to have those values available as imports – export an object literal instead of an enum and create union types that reference the values in those objects. Advantage would be having those available as constants instead of working with strings for those using the package, but not sure if that's in scope.

[raycharius]

What are thoughts on the discriminating union types for more strict type checking?

Advantages:

• A much better and more type-safe experience with the package and SDK, such as with the WebClient.

Disadvantages:

• Would require more swift updates to the package if API validation changes.
• It could be a breaking change, depending on how breaking is defined. It could throw compiler errors for objects that don't comply with the API validation, but unless there are some cases that I'm not taking into consideration, it would readonly only be showing issues with current code that would probably be rejected by the API anyway.

[filmaj]

I am closing this pull request - but have referenced the commits in it extensively! - in favour of having the different discussions about each type of change in this PR separately. They are:

• types 3.0: discriminated union types where appropriate #1816
• types 3.0: discuss continued use of string literals/unions vs. switching to enums #1817
• types: export additional union types used internally #1818

Thank you very much for your work in this PR. I know it has dragged on for literal years, but I think we will actually incorporate at least some of the suggestions from this work into the project!