You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Consider Theme.of()! and other related topics #67163
Outside of the ~half dozen internal uses of this API, locally there's just one. Maybe we should remove it, rather than perpetuating it? It appears to just be a hack to get around the fact that new routes don't see the same inherited widgets that the caller who's built the route does (it's a hack because it only deals with the special case of Theme). The InheritedTheme.wrap method is supposed to be a more general way of dealing with this issue. https://api.flutter.dev/flutter/widgets/InheritedTheme/wrap.html
If most callers are going to have to migrate their Theme.of(context) calls to be Theme.of(context)! after we launch null safety, should we make this change before the null safety launch? (in which case it should probably be something higher than P5)
Oh, actually, I just realized that Theme.of doesn't actually have a nullOk parameter. I mean, it's a similar problem, so maybe it should be linked, but I was just trying to address the nullOk problem.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
goderbauer commentedon Oct 2, 2020
For
Theme.ofit can only return null when theshadowThemeOnlyis set to true. My suggestion: Splitting this up into two methods:Theme.of(BuildContect context)never returns null. This is the most common usage.Theme.shadowThemeOf(BuildContext context)may return null.HansMuller commentedon Oct 5, 2020
Outside of the ~half dozen internal uses of this API, locally there's just one. Maybe we should remove it, rather than perpetuating it? It appears to just be a hack to get around the fact that new routes don't see the same inherited widgets that the caller who's built the route does (it's a hack because it only deals with the special case of Theme). The InheritedTheme.wrap method is supposed to be a more general way of dealing with this issue. https://api.flutter.dev/flutter/widgets/InheritedTheme/wrap.html
tvolkert commentedon Oct 23, 2020
If most callers are going to have to migrate their
Theme.of(context)calls to beTheme.of(context)!after we launch null safety, should we make this change before the null safety launch? (in which case it should probably be something higher than P5)gspencergoog commentedon Oct 23, 2020
@tvolkert I agree, probably should be higher priority. I already have a design doc for doing this, among others: https://flutter.dev/go/eliminating-nullok-paramters (I know, I'm fixing the name typo in the go link).
gspencergoog commentedon Oct 23, 2020
Oh, actually, I just realized that Theme.of doesn't actually have a
nullOkparameter. I mean, it's a similar problem, so maybe it should be linked, but I was just trying to address thenullOkproblem.HansMuller commentedon Oct 23, 2020
Per #67163 (comment) we don't need a nullable Theme.of(), we need to fix the one code path that uses
Theme.shadowThemeOf(BuildContext context).github-actions commentedon Aug 10, 2021
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.