想象一下，我有一个带有抽屉、应用栏、正文等的应用（标准材质脚手架）。
我现在正在考虑实现它的正确方法是什么，因为我基本上不希望小部件中有任何状态（即我想将状态（数据）保留在专用模型中/存储/控制器类并让小部件只负责 UI/像素）。
只要控制器告诉我，我就可以使顶级根应用小部件有状态，然后 setState((){})（注意虚拟回调，我将使用它来触发重建）。然后子小部件将被重建，并从商店/模型/...中读取他们感兴趣的值。
我可以使顶级小部件无状态，只将叶子标记为有状态。
鉴于 Flutter 声称已针对频繁的 Widget 重建进行了优化，那么一个选项是否比另一个更好？我敢打赌，叶子方法可能性能更高，但它更冗长（类的两倍）。
【问题讨论】：
我现在正在考虑实现它的正确方法是什么，因为我基本上不希望小部件中有任何状态（即我想将状态（数据）保留在专用的模型/存储/控制器类中并保留小部件只负责 UI/像素）。
imo 实现它的正确方法是颤振团队如何设计要使用的状态类。当您执行此操作时，您将一个状态对象注入您的 UI 类：
class HomePage extends StatefulWidget {
@override
_HomePageState createState() => new _HomePageState();
}
class _HomePageState extends State<HomePage> {...}
即只有与小部件和/或其直接子小部件相关的状态数据存储在小部件的状态中。
仅在 1 个（最顶层）小部件中跟踪状态是一个坏主意（复杂性）。当状态对象很大时，在比较 setState() 上的先前状态和当前状态时，看到框架有很多基础需要覆盖。不使用独立更改的较小状态对象似乎是一种浪费。此外，从维护的角度来看，当状态对象仅与当前小部件相关时，很容易获得您正在查看的内容的上下文。
在我看来，您正在与框架作斗争，您能否详细说明为什么您不希望小部件中有任何状态的具体原因/示例？
【讨论】：
TabBarView，每个选项卡都加载并显示来自 REST 界面的一些数据。现在我可以使这些选项卡中的每一个都成为有状态的，负责加载其数据，并将它们包装在StatelessWidget 中。但是每次我切换选项卡并重新加载数据时，都会重新创建每个。如果我使父级有状态（并负责加载数据），我会使选项卡无状态并且不重新加载任何内容。我很想听听您对此的看法。