Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reconsider Public Enum Usage #380

Closed
MrSkwiggs opened this issue Jan 27, 2025 · 3 comments
Closed

Reconsider Public Enum Usage #380

MrSkwiggs opened this issue Jan 27, 2025 · 3 comments

Comments

@MrSkwiggs
Copy link
Contributor

I was in the process of reviewing #373 and decided to open a discussion regarding Ignite's use of public-facing enums.

Problem

Public enums in our API risk introducing source-breaking changes for users.
If developers switch over these enums, adding/removing a case will break their code.

This forces us to treat every enum modification as a breaking change, slowing iteration.

Proposed Solution

Replace public-facing enums with struct-based static constants. For example:

// Example of a recently introduced public enum  
public enum Name: String, Sendable {
  /// The image to display in Twitter cards.
  case twitterImage = "twitter:image"
}

// Proposed  
public struct Name: CustomStringConvertible, ExpressibleByStringLiteral {
  let value: String

  public static let twitterImage = Self(value: "twitter:image")  
  // or better yet
  public static let twitterTitle = "twitter:title"
}

Benefits

  • Retains the same ergonomic syntax (Name.twitterImage).
  • Eliminates exhaustivity risks for users.
  • Allows us to freely add/remove "cases" without breaking source compatibility.

Considerations

This approach is used by other Swift frameworks to promote API stability (eg. Vapor)

Next Steps

  1. Audit all public enums to identify candidates.
  2. Incrementally refactor in phases?

Questions

  • Are there enums that must remain enums (e.g., for pattern matching)?
  • Should we prioritize specific areas first?
@twostraws
Copy link
Owner

Removing cases will break source compatibility no matter what we do, but from what I can see the adding problem only exists when tied into exhaustivity checking – when a user has to cover all cases. Are there some examples that are likely to hit users? In this case, I'm not sure when users would switch over meta tag names and implement them all, and if someone they did do that then they'd probably want to be notified when another case was added.

@MrSkwiggs
Copy link
Contributor Author

and if they did do that then they'd probably want to be notified when another case was added.

In the end, it's a decision that needs to be consciously made, and if we decide it's something we're ok with then that's also completely fine 👌

At any rate, feel free to close this if it is not relevant for Ignite 👍

@JPToroDev
Copy link
Collaborator

Very happy to revisit this down the line if we find any of our existing enums falling short!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants