Design Doc: Extensible Enums in Federated Plugins #189696

Activity

1. Mairramer

   added

   design docTracks a design discussion documentTracks a design discussion document

   on Jul 18, 2026
2. flutter-triage-bot

   added

   📜Issue was posted to Discord. Remove to have the issue reannounced. (For "design doc", "emergency")Issue was posted to Discord. Remove to have the issue reannounced. (For "design doc", "emergency")

   on Jul 18, 2026
3. puneetkukreja98

   added

   in triagePresently being triaged by the triage teamPresently being triaged by the triage team

   c: proposalA detailed proposal for a change to FlutterA detailed proposal for a change to Flutter

   team-ecosystemOwned by Ecosystem teamOwned by Ecosystem team

   and removed

   in triagePresently being triaged by the triage teamPresently being triaged by the triage team

   on Jul 20, 2026
4. puneetkukreja98 commented on Jul 20, 2026

   

   puneetkukreja98

   on Jul 20, 2026

   Contributor

   More actions

   Assigning team-ecosystem since this design doc proposes a API pattern for Flutter's federated plugins, with the camera plugin serving as the motivating example.
5. stuartmorgan-g

   added

   P1High-priority issues at the top of the work listHigh-priority issues at the top of the work list

   triaged-ecosystemTriaged by Ecosystem teamTriaged by Ecosystem team

   on Jul 21, 2026
6. Mairramer commented on Sep 30, 2026

   

   Mairramer

   on Sep 30, 2026

   ContributorAuthor

   More actions

   @stuartmorgan-g @loic-sharma

   While reviewing some PRs, I came across this one: #193528. It has a similar pattern to what we're trying to address in packages.

   Do you think it would be worth expanding this to the Flutter repo as well? Mainly to establish when a public enum makes more sense than a public class (and vice-versa), and whether the conversion is worth the effort.

   Depending on the outcome, I can also move this to flutter/rfc. I'm just waiting for the final decision.