具有覆盖构建功能的类扩展 StatelessWidget 和具有我自己的功能的常规类有啥区别
Posted
技术标签:
【中文标题】具有覆盖构建功能的类扩展 StatelessWidget 和具有我自己的功能的常规类有啥区别【英文标题】:What is the difference between class extends StatelessWidget with override build function and regular class with my own function具有覆盖构建功能的类扩展 StatelessWidget 和具有我自己的功能的常规类有什么区别 【发布时间】:2020-03-15 21:39:17 【问题描述】:我是 Flutter 的新手,但仍然不知道如何以正确的方式做事。我希望标题足够清楚,因为我不知道解决这个问题的正确关键字。首先 sn-p 扩展 StatelessWidget:
class FloatingActionButtonBuilder extends StatelessWidget
final Function function;
final String text;
final String toolTip;
final IconData icon;
const FloatingActionButtonBuilder(
Key key,
@required this.function,
@required this.text,
@required this.toolTip,
this.icon,
) : super(key: key);
@override
Widget build(BuildContext context)
return FloatingActionButton.extended(
onPressed: function,
foregroundColor: Colors.white,
tooltip: '$toolTip',
icon: Icon(
icon,
),
label: Text(
'$text',
style: TextStyle(
fontSize: 16.0,
),
),
);
第二次sn-p普通班:
class FloatingActionButtonBuilder2
final BuildContext context;
final Function function;
final String text;
const FloatingActionButtonBuilder2(
@required this.context,
@required this.function,
@required this.text,
);
Widget buildFAB(String toolTip, IconData icon)
return FloatingActionButton.extended(
onPressed: function,
foregroundColor: Colors.white,
tooltip: '$toolTip',
icon: Icon(
icon,
),
label: Text(
'$text',
style: TextStyle(
fontSize: 16.0,
),
),
);
我一直在使用的是普通的。最初,我制作了扩展 StatelessWidget,但后来我决定不这样做,因为我认为无论如何都没有区别并且没有考虑太多。现在,我的大脑不知从何而来想知道专家对这个特殊案例的看法,我们深表感谢深入的建议。而且我注意到使用覆盖构建功能我不需要 BuildContext 作为依赖项。
编辑: 使用 extends StatelessWidget 的页面片段(Scaffold 的floatingActionButton 属性):
class Test extends StatefulWidget
@override
_TestState createState() => _TestState();
class _TestState extends State<Test>
final String text = 'PUSH';
final IconData icon = Icons.add;
void push()
Navigator.of(context).push(
MaterialPageRoute(
builder: (context) => Test3(),
),
);
@override
Widget build(BuildContext context)
return Scaffold(
floatingActionButton: FloatingActionButtonBuilder(
function: push,
text: text,
toolTip: text,
icon: icon,
),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
crossAxisAlignment: CrossAxisAlignment.center,
children: <Widget>[
Text(
'PUSH PAGE',
style: TextStyle(
fontSize: 32.0,
),
),
Text(
'EXTENDS CLASS',
style: TextStyle(
fontSize: 32.0,
),
),
],
),
),
);
使用常规类的页面片段(Scaffold 的floatingActionButton 属性):
class Test3 extends StatefulWidget
@override
_Test3State createState() => _Test3State();
class _Test3State extends State<Test3>
final String text = 'POP';
final IconData icon = Icons.remove;
void pop()
Navigator.of(context).pop();
@override
Widget build(BuildContext context)
return Scaffold(
floatingActionButton: FloatingActionButtonBuilder2(
context: context,
function: pop,
text: text,
).buildFAB(text, icon),
body: Center(
child: Column(
mainAxisAlignment: MainAxisAlignment.center,
crossAxisAlignment: CrossAxisAlignment.center,
children: <Widget>[
Text(
'POP PAGE',
style: TextStyle(
fontSize: 32.0,
),
),
Text(
'REGULAR CLASS',
style: TextStyle(
fontSize: 32.0,
),
),
],
),
),
);
【问题讨论】:
如果你想让你的类有 UI,它需要是一个 Widget(有状态或无状态),因为这个类是 Flutter 所期望的,它包含 Flutter 翻译它所需的所有数据和逻辑类变成屏幕上的图形。如果你只给 Flutter 一些随机的课程,并期望它能够读懂你的想法并知道如何处理它,那么你将度过一段糟糕的时光。 两个 sn-ps 都可以正常工作,返回 FloatingActionButton。我想知道在实际实现中哪种方法更好以及原因。 那么你需要展示你是如何使用第二个 sn-p 的,因为它不能以大多数 Flutter 小部件所期望的方式使用。 (例如,您不能将非 Widget 类用作容器的子类。即,此代码无法编译:Container(child: FloatingActionButtonBuilder2(...))
)
我应该把实现放在哪里,我应该只编辑我的帖子吗?
编辑你的帖子,展示你是如何实现both sn-ps的。
【参考方案1】:
根据您的编辑,您的两种方法之间存在一个关键区别 - 方法 A 中的类 是 一个小部件,而方法 B 中的类仅包含一个 返回 的方法em> 一个小部件。
对于 Flutter 来说,这种差异非常显着。当您定义一个新的小部件时,Flutter 使用该小部件类来跟踪小部件树中的可视元素以进行更改。它能够检测到小部件何时更改并需要重绘,并且非常擅长这样做,而不会影响到任何超过绝对必要的小部件树。
但是,如果您通过方法调用创建小部件,Flutter 无法检测到您正在这样做,因此您会失去这些优化。这就是为什么在重构 UI 代码以将其分解为模块化部分时,Flutter 官方建议将 UI 代码分解为新的小部件类,而不是同一个小部件类中的单独方法。
更语义化的描述是这样的。在方法 A 中,小部件类具有作为小部件类的固有效果的构建方法。这个 build 方法被 Flutter 调用,它返回的 widget 成为 widget 类本身的子类。 (如果您在 Dart DevTools 中查看小部件树,您可以看到这一点。)在方法 B 中,构建方法只是碰巧返回小部件的另一种方法。该小部件将成为您将其传递给您调用该方法的任何其他小部件的子级(在您的情况下为Scaffold
)。因此,正在构建的小部件与类本身之间没有内在的关系。这种缺乏关系将体现在一个脆弱的小部件树和一个令人难以置信的马虎 UI 管理作为一个整体,导致应用程序被麻绳和祈祷结合在一起。
不使用第二种方法的另一个原因是什么?它无缘无故地使您的代码更加冗长。比较方法 A 和方法 B 的实现 - 括号中的所有内容都是相同的,但方法 B 需要对构建方法本身进行额外调用,并且您必须在使用“非小部件”类的任何地方执行此操作。您已经牺牲了 UI 声明中代码的简洁性,而不必在一个地方输入 StatelessWidget
……这是一个糟糕的交易。
此外,如果您的类不是适当的小部件,它就无法利用所有小部件生命周期事件。想要在小部件初始化时收到通知?什么时候在更新过程中?当它被导航到/离开时?什么时候处理?如果您想触发更新怎么办?假设它甚至是可能的,用一个泛型类来实现所有这一切都是一件非常痛苦的事情,而当你的类扩展 StatefulWidget
时,所有这些功能都很容易获得(加上试图强迫它在方法 B 中工作,你可能会最终还是要从头开始重新发明StatefulWidget
)。
简而言之,几乎没有充分的理由让一个通用的非小部件类具有您手动调用的构建器方法。如果您有 UI 代码,则它属于小部件类(除非您有 非常 很好的理由)。
【讨论】:
假设我有一个泛型类,它有 2 个构建方法,它们返回 RaisedButton 和 CupertinoButton。我可以使用 B 方法轻松编写这两种方法。但是使用更好的 A 方法,我需要创建 2 个扩展 StatefulWidget 的不同类,因为它只运行 @override 构建方法......对吗? @FederickJonathan 您也可以只在小部件类中拥有这些方法,并从 build 方法中调用其中一个或两个。当然,更惯用的方法是将这两种类型的按钮实现为单独的小部件类。 非常感谢你们。我的好奇心得到了完全的解答。【参考方案2】:不同之处在于,如果您使用 Stateful 或 Stateless 小部件扩展一个类,那么该类本身将成为一个小部件类,该类将返回一个小部件。简单来说,如果您使用有状态或无状态小部件扩展一个类,您将需要覆盖通常创建小部件的 build 函数,或者我们可以返回一个小部件:D
我建议你先了解更多关于类小部件(Stateful和Statless),我向你保证你会明白它是如何工作的。
【讨论】:
我不确定...因为这两个类都有返回类型 Widget 不一定需要扩展 Stateful 或 Stateless。 @FederickJonathan 在普通类中返回小部件不是强制性的。以上是关于具有覆盖构建功能的类扩展 StatelessWidget 和具有我自己的功能的常规类有啥区别的主要内容,如果未能解决你的问题,请参考以下文章