App Platform enum type

[Elhebert]

Hi,

Thanks for the great work on this.

When I was looking at the code I noticed that the App platform type were quite generic. I was going to start a PR to add enums where the DO API clearly defines the possible options.

However I discovered that in #230 the enums were added but then were removed in #232 (specific commit: 3ac3f7d).

I was wondering what was the reasoning behind that decision? Providing the enums improves the quality of the typings and reduce the potential errors.

Thanks,
Elhebert

[pjpimentel]

hello @Elhebert 😀

As the package is a wrapper to digital ocean' api, it should only: receive the input, send the request, return the output.

If we restrict the input with a enum and when digital ocean change the enum on their side, we have to check the docs, update the types and launch a new patch version of this package.

I think it's better to keep the source of truth of this values with the digital ocean api because:

1. it will, probably, reduce the maintenance required for this package.
2. the dev using this package will, anyway, have to consult the official documentation of the api then, the "enum" with most trustable values are there.

what do you think? hard coding the enum in the package would be good? there's a alternative? if we a create a enum and expose it like a raw object without restricting the type can help?

i think there still some hard coded enums here because when i wrote the first lines i thought it was a good idea in the beginning

[Elhebert]

You are raising good points. However I don't believe that Digital Ocean with change their response enums. That would introduce breaking changes that is never desirable in public facing APIs.

We had a custom DO api in a project that we are replacing with dots because it's more complete and robust than what we had. Our tests suite had some issues with some of the mocking we were doing because our types where not compatible (due to the enums we had) with the one that dots is providing. Which raised this topic.

I don't have strong opinions on strings instead of enums. It's mostly a quality of life improvement that, in my case, makes mocking the response easier. I also provides rather useful information without having to leave the code editor 😬.

As you are the maintainer you are the one choosing what is included in the code base. Especially if it's going to increase the maintenance needed. So I totally understand the decision. I'll be happy to provide a PR should you want to revert to using enums.