当我必须创建小部件的“模板”时,我使用了很多StatelessWidgets,这些小部件在我的应用程序中多次使用,因为文档是这样说的:
当您所描述的用户界面的部分不依赖于对象本身中的配置信息和小部件被充气的BuildContext之外,BuildContext无状态小部件非常有用。
下面是一个示例:
class StepInputButton extends StatelessWidget {
final int pos;
final String value;
const StepInputButton({
this.pos,
this.value
});
@override
Widget build(BuildContext context) {
return Row(
// Text, Icon and a tiny button
);
}
}上面的代码很好,因为我可以在代码中使用const StepInputButton(val, "val"),和CONST,从而提高了性能。
问题
我正在使用著名的Provider小部件来管理状态,我的应用程序页面通常如下所示:
class SuccessPage extends StatelessWidget {
@override
Widget build(BuildContext context) {
var prov = Provider.of<Type>(context);
return Scaffold(...);
}
}这是我与Scaffold应用程序的一页,它有一个抽屉、一个浮动动作按钮和一个appTitle。在这里,我使用StatelessWidget,因为我不使用setState(),因为提供者为我做了所有的工作。但他们仍然在官方的“颤栗博士”中说:
对于可以动态更改的组合,例如,由于具有内部时钟驱动状态,或者依赖于某种系统状态,可以考虑使用
。
那么,我必须将class SuccessPage extends StatelessWidget改为class SuccessPage extends StatefulWidget吗?我有优势吗?
注意:如果您想以另一种方式提出这个问题:我是否应该使用StatefulWidgets来创建状态将要更改的“应用程序页”,以及使用状态不改变的“可重用小部件”创建StatelessWidgets?
发布于 2019-12-12 18:23:47
当小部件本身正在维护自己的状态时,StatefulWidget是必需的。在您给出的示例中,Provider包正在为您处理状态,假设您在小部件树上使用正确的提供者类型(例如,ChangeNotifierProvider)。在这段代码中,似乎没有任何东西可以从小部件的生命周期中受益,所以您不需要访问像initState或dispose这样的方法。
因此,小部件本身没有什么可管理的,因此将类转换为有状态类是不必要的。
不过,我可能建议的一件事是使用Consumer而不是直接调用Provider.of。Consumer为您处理调用,并消除小部件是否会在Provider检测到状态更改时得到更新的任何模糊。
发布于 2019-12-12 17:25:31
您可以将StatelessWidget用于不改变其状态的小部件,这将始终保持不变。例如,appBar是无状态的。只调用一次StatelessWidget的StatelessWidget函数,任何Variable(s)、Value(s)或Event(s)中的任何更改都不能再次调用它。
因此,当您需要更改状态(ex值)然后使用StatefulWidgets时,StatelessWidget基本上用于构建静态的UI小部件。
发布于 2019-12-12 17:48:15
保持简单:
如果您的小部件中有non-__final全局变量,那么您需要一个StatefulWidget
final,那么应该使用StatelessWidget;原因:
setState();来实现它,因此我们使用StatefulWidget来实现这种用例。如果在构造函数中初始化全局变量就足够了,那么以后就不需要给它赋值了,那么在这种情况下使用setState();。我一直试图保持它很简单,不够技术性,所以,如果你仍然有任何疑问,请评论这个答案。
https://stackoverflow.com/questions/59309718
复制相似问题