Documentation error: dependOnInheritedWidgetOfExactType

[tedhenry100]

From https://api.flutter.dev/flutter/widgets/BuildContext/dependOnInheritedWidgetOfExactType.html

This method should not be called from widget constructors or from State.initState methods

From https://api.flutter.dev/flutter/widgets/State/initState.html

You cannot use BuildContext.dependOnInheritedWidgetOfExactType from this method

Which one is it? Is it "should not" which is a best practices recommendation or is it "cannot" which is a technical impossibility?

A common case where using the build context inside initState is convenient is to get some unchanging inherited widget like a services object. (A sort of dependency injection without having to pass/inject the dependency manually all the way down the widget tree.)

@override
void initState() async {
    super.initState();
    var data = await this.context.dependOnInheritedWidgetOfExactType<Services>().loadData();
    this.setState(() {
        this._data = data;
    });
}

Also there is a formatting error in the initState documentation when rendered as HTML: The last bullet point about dispose runs into the next paragraph.

[petermichaux]

It appears the "should not" wording was introduced by @Hixie on Aug 29, 2016
in the following commit.

ea6bf47#diff-16a8dc6e114c65d7a516fc759bac2316

It looks like that documentation was based on the work of @HansMuller on Aug 26, 2016 in the following commit.

d0e72d6#diff-16a8dc6e114c65d7a516fc759bac2316

Is it only an assert that stops the getting of inherited widgets during initState? If getting inherited widgets during initState is otherwise technically possible, is what is perhaps seen as a best practice by the Flutter team really something that should be limited? Is knowing the inherited widgets at the time of initState really such a bad thing? Everything else that that a program might do during initState is based on the app's state at the time initState executes. Why not have access to the inherited widgets at that time too?

[creativecreatorormaybenot]

@petermichaux Two things:

1. You do not have to declare yourself a dependency.
2. The purpose of didChangeDependencies is solving exactly this problem (it is called right after initState and allows you to use it).

[Hixie]

In the documentation, we don't really distinguish between "should not" and "cannot" because nobody stops you from forking the framework, removing whatever asserts make it "impossible", and violating the "cannot" anyway.

I'll change these to "should not" for consistency, and will make sure the right behaviour is mentioned.

[github-actions]

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.