Throughout the SDK, there are a lot of places where string constants or enums could be used in order to leverage Intellisense and/or eliminate errors due to mis-typing.
For example, in Cards, CardAction is a string property ("imBack") vs. a string const or enum.
Totally agree that anything that can be done to help the dev is great, but we need to ensure that we retain the flexibility to set an arbitrary string value if we need to. For example when integrating with alexa you can set the activity type string to whatever the alexa request type is, but having the enum helps for discoverability and use of pre-defined types.
@cmayomsft The point is a good one. The problem with that is compatibility.
Enums break compat in weird ways even if you're only adding things. Likewise, scoping things to enums means the flexibility of the string is gone.
The Microsoft Graph, for example, does the string approach. We (Gareth++) all look at using a back-compat enum of some sort, but there was just no good solution.
So these properties all have to stay strings. Changing them to enums is a non starter as this is a protocol level thing. With that said, adding string constants is fine but keep in mind that a lot of these properties, like the CardAction.type, are very open ended and every channel is likely to have a different set of values it supports. There are some common standard ones like imBack but teams adds its on set of action types and if we were to do a native Facebook adapter there would be an entirely different set of action types that would be valid.
After years of dealing with API versioning, I have to agree with leaving them strings... enums are not forward compatible. 馃槪 As long as there's a static class filled with all the possible values for a given version I think that provides a happy medium.
Agree, static class filled with all the possible values are a happy medium.
This doesn't feel closed to me. Totally understand the point @stevenic makes above, but having to remember these strings and make sure they are typed correctly is way to easy to introduce bugs.
Yeah, probably shouldn't be closed until the static class/constants are there an accounted for.
Most helpful comment
After years of dealing with API versioning, I have to agree with leaving them strings... enums are not forward compatible. 馃槪 As long as there's a static class filled with all the possible values for a given version I think that provides a happy medium.