flutter - 具有覆盖构建功能的类扩展 StatelessWidget 和具有我自己的功能的常规类有什么区别

Question

我是 Flutter 的新手，但仍然不知道如何以正确的方式做事。我希望标题足够清楚，因为我不知道解决这个问题的正确关键字。第一个片段扩展了 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,
        ),
      ),
    );
  }
}

第二个片段是一个普通的类:

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 作为依赖项。

编辑 :
使用扩展 StatelessWidget 的页面片段(Scaffold 的 floatActionButton 属性):

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 的 floatActionButton 属性):

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,
              ),
            ),
          ],
        ),
      ),
    );
  }
}

Answer 1

根据您的编辑，您的两种方法之间存在一个关键区别 - 方法 A 中的类是一个小部件，而方法 B 中的类仅包含一个返回小部件的方法。

对于 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 代码，它属于一个小部件类(除非你有很好的理由)。