有没有一种方法可以避免悬挂式的小部件嵌套？

Question

我将尝试扑打，但是我发现的GitHub上的所有示例都包含具有很高嵌套的小部件的代码，这对可读性不利。例如，这个：

可以不知何故避免了吗？有更好的做法可以改善我的开发人员体验吗？

Answer 1

我认为，与扑朔迷离和拥有良好的发展经验一起使用的最重要的事情就是拥有一个清晰的结构。您可以遵循很多结构，但是扑动的方式是很多嵌套。例如，在更大的项目中，我遵循这个概念：

- [folder] lib
    - [folder] models
    - [folder] apis
    - [folder] bloc (or any other state management / business logic pattern)
    - [folder] pages
        - [folder] page 1
        - [folder] page 2
        - [folder] page 3
            - pageview.dart
            - widget 1.dart
            - widget 2.dart
            - widget 3.dart
    - [folder] widgets (every widget which is used appwide)
    - main.dart

我对此感到满意。我有用于API，模型，业务逻辑，页面的CLEA场所，并且由于您可以重构代码并从中创建小部件，因此我的页面比您在github示例中看到的小。我还可以快速找到小部件，这些小部件在我的应用程序中多个位置都使用。

找到一个良好的结构并创建许多小部件，以后很容易理解您的代码。我当然只能为自己说话，因为我很舒服。

Answer 2

重要的是要注意，无论是HTML，Android XML左右，我们都会筑巢。因此，大多数地方都允许筑巢。

尽管我已经看到您提供的示例有一些不必要的嵌套。

例如

 void updateListView() {

        final Future<Database> dbFuture = databaseHelper.initializeDatabase();
        dbFuture.then((database) {

            Future<List<Note>> noteListFuture = databaseHelper.getNoteList();
            noteListFuture.then((noteList) {
                setState(() {
                  this.noteList = noteList;
                  this.count = noteList.length;
                });
            });
        });
  }

在这里，我们可以使用等待关键字避免上述嵌套

void updateListView() {
    // I don't know why is it even there but if it is required then it should be done in
    // below way which is commented out
    // final Database database = await databaseHelper.initializeDatabase(); 
    List<Note> noteList = await databaseHelper.getNoteList();
    setState(() {
      this.noteList = noteList;
      this.count = noteList.length;
    });
}

，上面的代码应适当地覆盖为可读的大声笑

Answer 3

当然。您只需提起这样的树的任何更深的部分，然后将其放入单独的功能中。我的代码通常看起来像这样：

@override
Widget build(BuildContext context) {
  return Padding(
    padding: EdgeInsets.only(top: 8),
    child: buildContent(),
  );
}

然后：

Widget buildContent() {
  return Column(
    children: [
      buildFirst(),
      buildSecond(),
      buildThird(),
    ],
  );
}

等等。我很愿意将一个小部件或两个小部件放在单独的功能中，并在有意义的情况下给它一个有意义的名称。即使我正在使用一个大型监视器，但我也不关心80个字符等有害的旧习惯，但我的进度不超过三个，也许最多有四个级别，而没有非常有力的理由，我不知道t召回最近满足了任何此类原因。

您也不总是需要凹痕。对于简单的事情，例如：

Expanded(child: buildList(context)),

我总是将它们保持在一行。另外，使用简短的小部件，例如：

return EmptyText(t.emptyData, icon: Icons.no_data);

当然，如果有任何复杂和重复使用的片段，您可能想单独将其放入自定义的小部件中 - 就像This emptyText 一样不仅仅是带有图标的列，下面的中心文本。一个带有单个 build（）函数的简单无状态小部件，仅此而已。但是，因为我在多个位置和中使用它，因为它与上面的单行相比，它更方便，而不是一次又一次地包括相同的 column 它自己的小部件。

我一定要避免的是嵌套的三元操作员，尤其是当树枝是复杂的树木时 - 我认为它们是最糟糕的罪犯，反对可读性。我总是将分支提升到自己的功能中，只提到它们：

return ifSomething ? buildOne() : buildAnother();

顺便说一句，您总是可以诉诸于嵌套软件包，如果您确实需要嵌套，但您不想向右走。

Answer 4

这是声明性方式颤抖起作用的重要组成部分。所以不，恕我直言，您无法避免筑巢。如果可以的话，那将是一个解决方法，绕过了颤抖的基本概念。
就像我说的那样，只要使用颤抖的方式。