The real reason we tend to avoid GlobalKey
is not about performance. It is more related to the fact that it breaks a few patterns in flutter.
Widgets by definition should not be able to access concrete information of other widgets (such as their size or position). And GlobalKey
grant the ability to access such information; allowing peoples to do anti-pattern stuff.
Think of GlobalKey
as a mean to eject the reactive layer of Flutter.
A few examples of what peoples are tempted to do using GlobalKey
:
- Having a public singleton
GlobalKey
. Used as a mean to not lift the state up. Making interaction between widgets hard to predict, as the relationship isn't one-sided anymore (parent -> children becomes a two-way relationship)
- Using
GlobalKey
to compute the size of a layout. Then trigger a re-render with this information. This instead is the role of RenderObject
and shouldn't be done in widgets. It makes layout much harder to maintain
Builder
and similar on the other hand don't break these patterns. As, by definition Builder
does nothing. It's just a neat way of using a different BuildContext
.
This usually means that if you can solve your layout problem using Builder
instead of GlobalKey
, you're on the right track to a maintainable layout.
When to use GlobalKey
then?
Well, if you can, never. Try to instead use things such as context.ancestorStateOfType
or context.inheritWidgetOfExtactType
. You may also want to consider creating a custom RenderObject
for a specific layout. RenderObject
combined with parentData
may also be what you want if you need a relationship between parent/children
This can more complicated though. It can consume more time than you want. Or you may fall into an edge-case that is hard to implement using the current API.
In such situations, it is ok to use GlobalKey
as long as you know the potential consequences.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…