Adding an "Other" enum value to an API often seems like a flexible solution for unknown future cases, but it creates significant problems. It weakens type safety, forcing consumers to handle an undefined case and potentially misinterpret data. It also makes versioning difficult, as any new enum value must be mapped to "Other" in older versions, obscuring valuable information and hindering analysis. Instead of using "Other," consider alternatives like an extensible enum, a separate field for arbitrary data, or designing a more comprehensive initial enum. Thorough up-front design reduces the need for "Other" and leads to a more robust and maintainable API.
TypeScript enums are primarily useful for representing a fixed set of named constants, especially when interfacing with external systems expecting specific string or numeric values. While convenient for basic use cases, enums have limitations regarding tree-shaking, dynamic key access, and const assertions. Alternatives like string literal unions, const objects, and regular objects offer greater flexibility, enabling features like exhaustiveness checking, computed properties, and runtime manipulation. Choosing the right approach depends on the specific requirements of the project, balancing simplicity with the need for more advanced type safety and optimization.
Hacker News users generally discussed alternatives to TypeScript enums, with many favoring union types for their flexibility and better JavaScript output. Some users pointed out specific benefits of enums, like compile-time exhaustiveness checks and the ability to iterate over values, but the consensus leaned towards unions for most use cases. One comment mentioned that enums offer better forward compatibility when adding new values, potentially preventing runtime errors. Others highlighted the awkwardness of TypeScript enums in JavaScript, particularly reverse mapping, and emphasized unions' cleaner translation. A few commenters suggested that const assertions with union types effectively capture the desirable aspects of enums. Overall, the discussion frames enums as a feature with niche benefits but ultimately recommends simpler alternatives like union types and const assertions for general usage.
Summary of Comments ( 61 )
https://news.ycombinator.com/item?id=43193160
HN commenters largely agree with Raymond Chen's advice against adding "Other" enum values to APIs. Several commenters share their own experiences of the problems this creates, including difficulty in debugging, versioning issues as new enum members are added, and the loss of valuable information. Some suggest using an associated string value alongside the enum for unexpected cases, or reserving a specific enum value like "Unknown" for situations where the actual value isn't recognized, which provides better forward compatibility. A few commenters point out edge cases where "Other" might be acceptable, particularly in closed systems or when dealing with legacy code, but emphasize the importance of careful consideration and documentation in such scenarios. The general consensus is that the downsides of "Other" typically outweigh the benefits, and alternative approaches are usually preferred.
The Hacker News post "API design note: Beware of adding an "Other" enum value" discussing Raymond Chen's blog post about the pitfalls of adding "Other" to enums generated a moderate amount of discussion with 27 comments. Many commenters concurred with Chen's points, sharing their own experiences and expanding on the potential problems.
Several compelling comments highlighted the cascading issues caused by "Other" enum values. One commenter pointed out how this practice forces consumers of the API to implement awkward workarounds, often involving string parsing or custom data structures to handle the "Other" cases. This can lead to increased code complexity and maintenance burdens, especially as the API evolves. They emphasized how this negates the benefits of using enums in the first place, which are meant to provide type safety and clarity.
Another commenter elaborated on the difficulties in versioning APIs with "Other" enums. When new enum values are introduced in later versions, existing clients using the "Other" category may become incompatible or require significant refactoring to handle the updated values. This can create backward compatibility challenges and complicate the upgrade process for developers. This commenter also pointed out how the use of
Otheroften masks genuine bugs where an appropriate enum value should have been defined but wasn't.Some commenters suggested alternative strategies to avoid using "Other". One popular suggestion was to provide an extensible enum mechanism, allowing consumers to define their own values if needed. Another commenter proposed using a dedicated "Unknown" value instead of "Other", signifying that the value is not recognized by the current version of the API but might be handled gracefully in future versions. The use of "Unknown" implies a future where the unknown values will be given proper meaning as opposed to "Other," which implies something outside the intended domain of the enum.
A few comments also focused on the importance of careful API design and communication between API providers and consumers. They highlighted the need for thorough documentation and clear guidelines on how to handle unexpected or unknown values. One commenter stressed the importance of using a versioning strategy that allows clients to adapt gracefully to changes in the API.
In summary, the comments generally agreed with Chen's premise and provided further evidence and anecdotes supporting the avoidance of "Other" in enums. They discussed the practical challenges and offered alternative solutions for API designers. The discussion reinforced the importance of thoughtful API design, versioning, and communication to prevent issues caused by the ambiguous nature of "Other" values.