Proposal: shrink the MediaQuery API surface #183701

Activity

1. nate-thegrate commented on Mar 14, 2026

   

   nate-thegrate

   on Mar 14, 2026

   ContributorAuthor

   More actions

   Exceptions would be:

   • maybeLineHeightScaleFactorOverrideOf
   • maybeParagraphSpacingOverrideOf
   • maybeWordSpacingOverrideOf

   These methods refer to nullable MediaQueryData properties, so even with a MediaQuery in the widget tree they can still return null.

   Oddly, there's both a displayCornerRadiiOf and a maybeDisplayCornerRadiiOf method for the nullable displayCornerRadii property. I imagine we may want to get rid of one of them, but I don't have a strong opinion about it.
2. 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

   frameworkflutter/packages/flutter repository. See also f: labels.flutter/packages/flutter repository. See also f: labels.

   team-frameworkOwned by Framework teamOwned by Framework team

   a: qualityA truly polished experienceA truly polished experience

   and removed

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

   on Mar 18, 2026
3. justinmc

   added

   triaged-frameworkTriaged by Framework teamTriaged by Framework team

   P3Issues that are less important to the Flutter projectIssues that are less important to the Flutter project

   on Mar 24, 2026
4. pull

   added a commit that references this issue on Sep 21, 2026

   Update `MediaQuery` documentation (flutter#183702)

   ...

   b993ec8
5. victorsanni commented on Nov 10, 2026

   

   victorsanni

   on Nov 10, 2026

   Contributor

   More actions

   MediaQuery's maybeOf methods are unneccessary;

   are they? Flutter does support widget trees without a MediaQuery (RawView, widgets above View in multi-view runWidget apps, and wrapWithView: false tests, etc).

   Also won't this break (public) optionally depending on a single MediaQuery property? Unless we expose _MediaQueryAspect which I don't see why we should do?

   Overall this seems like way too much churn (even with the dart fix) for a proposal that doesn't seem a pressing community demand. Basically a classic Breaking changes that would improve the overall API proposal.
6. nate-thegrate commented on Nov 10, 2026

   

   nate-thegrate

   on Nov 10, 2026

   ContributorAuthor

   More actions

   Overall this seems like way too much churn (even with the dart fix) for a proposal that doesn't seem a pressing community demand.

   To be honest I 100% agree. I was fairly disappointed with how complicated #194091 was: when compared to the convenience of a smaller API surface it doesn't really feel worth it.

   
   

   I'll also go ahead and voice my opinion on a few areas of disagreement:

   Flutter does support widget trees without a MediaQuery (RawView, widgets above View in multi-view runWidget apps, and wrapWithView: false tests, etc).

   You're correct to say this, but I still think that MediaQuery's maybeOf methods are unneccessary: just because it's technically possible for a context to lack a MediaQuery answer doesn't mean that it's realistically possible. The View widget automatically builds a MediaQuery; in order to create a scenario without one, a developer would have to use runWidget instead of runApp and ignore the advice from the runWidget docs: "It is up to the caller to include at least one View widget… RenderObjectWidgets without an ancestor View widget will result in an exception."

   
   

   Also won't this break (public) optionally depending on a single MediaQuery property?

   Based on my definition of "optionally depending on a single property", it's not possible to do it with the existing API. If there's a MediaQuery in scope (which is all but guaranteed), a method like maybeSizeOf or maybePaddingOf will always create a dependency.

   
   

   I think it'd be worth revisiting Breaking changes that would improve the overall API proposal, since much of what's listed there was written prior to when data-driven fixes were introduced.

   But for now I think it makes sense to close this issue and the linked PR. Thanks for looking into this and sharing your feedback.
7. nate-thegrate

   closed this as not plannedon Nov 10, 2026