Customer tests for flutter_svg are failing on this change.

In google this change uncovered 6 buggy tests, which were accidentally passing with Directionality.of returning null even though they shouldn't. Fixes for that a purely in the test by adding a Directionality widget to them.

One widget in google3 needs to have Directionality.of replaced by Directionality.maybeOf.

@dnfield @Hixie @gspencergoog Curious to hear what you think about this change. I think overall it improves the readability of the code by removing a lot of ! in places where we just assume Directionality.of to be non-null (and it also now throws a nice error message in case somebody forgot to include a Directionality widget). However, it is a breaking change. Running this through our customer tests, I found a single instances that need to replace their usage of Directionality.of with the newly introduced Directionality.maybeOf API:

• In flutter_svg, there is one valid call of Directionality.of that is legitimately ok to return null.

At the same time, this change also uncovered 7 buggy tests in google, where the test authors forgot to include a Directionality widget (even though they should have).

Overall, I am in favor of this change, but like I said, it is slightly breaking.

Some of our .of API has a nullOk flag, e.g. Brightness.of, MediaQuery.of. Would we want to apply similar refactors to those?

If not, I think we might want to just add a nullOk here to make it consistent.

If so, I think we should evaluate when it's ok for these to be null or not. It seems like we have API usages that expect this to be nullable. I'd probably be more in favor of adding some assert(s) to this so that tests have to opt in to a nullOk. I'm having trouble deciding whether this is really the right way to go - I can think of cases where you'd ask about the direcitionality of your context and be ok with it not existing, and other cases where you wouldn't. You can make that clear already by using ! in your call. I'm a little concerned about adding yet another way to deal with missing inherited widgets in the tree (e.g. always allow null, allow null if nullOk, allow null if maybeOf).

@gspencergoog is working on removing the nullOk parameters from those other methods you mentioned. We will introduce maybeOf methods for those as well.

Yes, see https://flutter.dev/go/eliminating-nullok-parameters

I'm in favour of making every .of non-nullable, and adding .maybeOf wherever it makes sense. We should create a single migration guide for the whole thing.

OK, I'm happy to expand mine to include all the others (I think I have most of them in my doc already).

SGTM. In that case I'm in favor of this approach.

Looks like we are in agreement on this change. Here's my plan for executing it:

1. I'll submit a PR that adds Directionality.maybeOf to Flutter, leaving Directionality.of unchanged for now.
2. That change rolls into google3.
3. We update flutter_svg to use maybeOf (and bump its minimum flutter version).
4. The updated flutter_svg rolls into google.
5. I update Directionality.of in flutter to be non-null.
6. Profit!

The first step of this plan is #69117.

@gspencergoog I will add these APIs to https://flutter.dev/go/eliminating-nullok-parameters so we remember to include them in the migration guide.

This PR now represents step 5 of the plan in my previous post. Submitting this is blocked on submitting dnfield/flutter_svg#435 first.

Looks like SVG customer test is still unhappy.

Yeah, i still need to submit dnfield/flutter_svg#435 to make those happy.