This is a continuation of the discussion in #168630 (comment), which is summarized below.

@chunhtai noticed a lot of cases where people asked why their widget rebuild for no reason, to just find out they unknowingly created a dependency using .of, .maybeOf, as well as their per-property variations (denoted as of-methods).

Due to this observation, @chunhtai proposed during a review (discussion here) that MenuController.of should not create a dependency.

I suspect that this might not have been a good idea, because 1) this breaks the consistency where almost all other .of-methods in Flutter create dependencies, and 2) if some code needs to get the property "of" this, it should want to be notified when the property changes... at least in build. I suspect that the complexity here is that apps might call of during build or during other lifecycle callbacks, and my assumption in the 2nd point only applies to the build method.

Therefore I propose that we might want of methods to create dependency if and only if within the build phase.

Questions:

1. Is it enough to decide the need only based on the phase? It would be best if @chunhtai can recall the cases where people unknowingly created unwanted dependencies.
2. How should we design the API? I propose to:

• Add a new method to BuildContext that implements the aforementioned logic.
• Use this new method as the default behavior for .of methods.
• If needed, add a new optional parameter bool? createDependency to the .of methods.