cc @dnfield @Hixie
要求に応じて、それはフックによって解決される問題が何であるかについての完全な詳細です。

フレームワーク内でこれを簡単にしようとすると、ユーザーが考えるべき複雑さが実際に隠されるのではないかと心配しています。

ある種のabstract class Disposable破棄する必要のあるクラスを強く型付けした場合、ライブラリの作成者にとっては、この一部が改善される可能性があるようです。 そのような場合、あなたがそのように傾いているならば、あなたはこのようなより単純なクラスをより簡単に書くことができるはずです：

class AutomaticDisposingState<T> extends State<T> {
  List<Disposable> _disposables;

  void addDisposable(Disposable disposable) {
    assert(!_disposables.contains(disposable));
    _disposables.add(disposable);
  }

  <strong i="8">@override</strong>
  void dispose() {
    for (final Disposable disposable in _disposables)
      disposable.dispose();
    super.dispose();
  }
}

これにより、繰り返される数行のコードが削除されます。 デバッグプロパティ用に同様の抽象クラスを作成することも、両方を組み合わせたクラスを作成することもできます。 初期状態は次のようになります。

<strong i="12">@override</strong>
void initState() {
  super.initState();
  controller = TextEditingController(text: 'Hello world');
  addDisposable(controller);
  addProperty('controller', controller);
}

使い捨てクラスにそのようなタイピング情報を提供するのを見逃しているだけですか？

フレームワーク内でこれを簡単にしようとすると、ユーザーが考えるべき複雑さが実際に隠されるのではないかと心配しています。

ウィジェットは、ユーザーが考えなければならない複雑さを隠します。
それが本当に問題なのかわかりません。

結局、それを好きなように因数分解するのはユーザー次第です。

問題は使い捨てだけではありません。

これは問題の更新部分を忘れます。 ステージロジックは、didChangeDependenciesやdidUpdateWidgetなどのライフサイクルに依存することもできます。

いくつかの具体的な例：

• didChangeDependencies内にロジックを持つSingleTickerProviderStateMixin。
• super.build(context)依存するAutomaticKeepAliveClientMixin

フレームワークには、状態ロジックを再利用したい例がたくさんあります。

• StreamBuilder
• TweenAnimationBuilder
  ..。

これらは、更新メカニズムで状態を再利用する方法に他なりません。

しかし、彼らは「ビルダー」の部分で述べたのと同じ問題に苦しんでいます。

それは多くの問題を引き起こします。
たとえば、Stackoverflowで最も一般的な問題の1つは、「変更時にルートをプッシュする」などの副作用にStreamBuilderを使用しようとする人々です。

そして最終的に彼らの唯一の解決策はStreamBuilderを「排出」することです。
これには以下が含まれます。

• ウィジェットをステートフルに変換する
• initState + didUpdateWidget + didChangeDependenciesでストリームを手動でリッスンします
• ストリームが変更されたら、didChangeDependencies / didUpdateWidgetの以前のサブスクリプションをキャンセルします
• 破棄時にサブスクリプションをキャンセルする

これは_多くの作業_であり、事実上再利用できません。

問題

Stateロジックを複数のStatefulWidgetまたがって再利用することは、そのロジックが複数のライフサイクルに依存するようになるとすぐに非常に困難になります。

典型的な例は、 TextEditingController （ただし、 AnimationController 、暗黙のアニメーションなど）を作成するロジックです。 そのロジックは複数のステップで構成されています。

• State変数を定義します。
  dart TextEditingController controller;
• コントローラー（通常はinitState内）を作成します。デフォルト値になる可能性があります。
  dart <strong i="19">@override</strong> void initState() { super.initState(); controller = TextEditingController(text: 'Hello world'); }
• Stateが破棄されたときに、コントローラーを破棄しました。
  dart <strong i="24">@override</strong> void dispose() { controller.dispose(); super.dispose(); }
• build内のその変数でやりたいことを何でもします。
• （オプション）そのプロパティをdebugFillProperties公開します：
  dart void debugFillProperties(DiagnosticPropertiesBuilder properties) { super.debugFillProperties(properties); properties.add(DiagnosticsProperty('controller', controller)); }

これ自体は複雑ではありません。 問題は、そのアプローチを拡張したいときに始まります。
一般的なFlutterアプリには数十のテキストフィールドがある場合があります。これは、このロジックが複数回複製されることを意味します。

このロジックをどこにでもコピーして貼り付けると「機能」しますが、コードに弱点が生じます。

• 手順の1つを書き直すのを忘れがちです（ dispose呼び出しを忘れるなど）
• コードに多くのノイズを追加します

なぜこれが問題なのか理解するのに本当に苦労しています。 Flutterアプリケーションをたくさん書いたのですが、それほど問題にはならないようです。 最悪の場合でも、プロパティを宣言し、初期化し、破棄し、デバッグデータに報告するのは4行です（通常、初期化したのと同じ行で宣言できるため、通常は少なくなります。アプリは一般的にデバッグプロパティに状態を追加することを心配する必要はありません。これらのオブジェクトの多くには、破棄する必要のある状態がありません）。

プロパティタイプごとのミックスインが機能しないことに同意します。 私はビルダーパターンが良くないことに同意します（それは文字通り上記の最悪のシナリオと同じ数の行を使用します）。

NNBDを使用すると（具体的には、イニシエーターがthis参照できるようにlate final使用）、次のようなことができます。

typedef Initializer<T> = T Function();
typedef Disposer<T> = void Function(T value);

mixin StateHelper<T extends StatefulWidget> on State<T> {
  bool _active = false;
  List<Property<Object>> _properties = <Property<Object>>[];

  <strong i="8">@protected</strong>
  void registerProperty<T>(Property<T> property) {
    assert(T != Object);
    assert(T != dynamic);
    assert(!_properties.contains(property));
    _properties.add(property);
    if (_active)
      property._initState();
  }

  <strong i="9">@override</strong>
  void initState() {
    _active = true;
    super.initState();
    for (Property<Object> property in _properties)
      property._initState();
  }

  <strong i="10">@override</strong>
  void dispose() {
    for (Property<Object> property in _properties)
      property._dispose();
    super.dispose();
    _active = false;
  }

  void debugFillProperties(DiagnosticPropertiesBuilder properties) {
    super.debugFillProperties(properties);
    for (Property<Object> property in _properties)
      property._debugFillProperties(properties);
  }
}

class Property<T> {
  Property(this.owner, this.initializer, this.disposer, [ this.debugName ]) {
    owner.registerProperty(this);
  }

  final StateHelper<StatefulWidget> owner;
  final Initializer<T> initializer;
  final Disposer<T> disposer;
  final String debugName;

  T value;

  void _initState() {
    if (initializer != null)
      value = initializer();
  }

  void _dispose() {
    if (disposer != null)
      disposer(value);
    value = null;
  }

  void _debugFillProperties(DiagnosticPropertiesBuilder properties) {
    properties.add(DiagnosticsProperty(debugName ?? '$T property', value));
  }
}

あなたはそれをこのように使うでしょう：

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.title}) : super(key: key);

  final String title;

  <strong i="14">@override</strong>
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> with StateHelper<MyHomePage> {
  late final Property<int> _counter = Property<int>(this, null, null);
  late final Property<TextEditingController> _text = Property<TextEditingController>(this,
    () => TextEditingController(text: 'button'),
    (TextEditingController value) => value.dispose(),
  );

  void _incrementCounter() {
    setState(() {
      _counter.value += 1;
    });
  }

  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    return Scaffold(
      appBar: AppBar(
        title: Text(widget.title),
      ),
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: <Widget>[
            Text(
              'You have pushed the ${_text.value.text} this many times:',
            ),
            Text(
              '${_counter.value}',
              style: Theme.of(context).textTheme.headline4,
            ),
            TextField(
              controller: _text.value,
            ),
          ],
        ),
      ),
      floatingActionButton: FloatingActionButton(
        onPressed: _incrementCounter,
        tooltip: 'Increment',
        child: Icon(Icons.add),
      ),
    );
  }
}

本当に物事を良くするようには見えません。 まだ4行です。

ウィジェットは、ユーザーが考えなければならない複雑さを隠します。

彼らは何を隠しますか？

問題は行数ではなく、これらの行が何であるかです。

StreamBuilderは、 stream.listen + setState + subscription.closeとほぼ同じ行数になる可能性があります。
しかし、 StreamBuilderを書くことは、いわば、何の反省も伴わずに行うことができます。
その過程で起こりうる間違いはありません。 それは単に「ストリームを渡し、そこからウィジェットを構築する」だけです。

コードを手動で作成するには、さらに多くの考慮事項が必要です。

• ストリームは時間とともに変化しますか？ それを処理するのを忘れた場合、バグがあります。
• サブスクリプションを閉じるのを忘れましたか？ 別のバグ
• サブスクリプションにはどの変数名を使用しますか？ その名前は利用できない場合があります
• テストはどうですか？ テストを複製する必要がありますか？ StreamBuilderを使用すると、ストリームをリッスンするための単体テストを作成する必要がなくなり、冗長になります。 しかし、常に手動で書くと、間違いを犯す可能性があります。
• 一度に2つのストリームをリッスンすると、コードを汚染する非常に類似した名前の複数の変数が発生するため、混乱が生じる可能性があります。

彼らは何を隠しますか？

• FutureBuilder / StreamBuilderは、リスニングメカニズムを非表示にし、現在のスナップショットを追跡します。
  2つのFutureを切り替えるロジックも、 subscription.close()がないことを考えると、かなり複雑です。
• AnimatedContainerは、前の値と新しい値の間にトゥイーンを作成するロジックを非表示にします。
• Listviewは、「ウィジェットを表示どおりにマウントする」というロジックを非表示にします

アプリは通常、デバッグプロパティに状態を追加することを心配する必要はありません

debugFillPropertiesメソッドを維持する複雑さに対処したくないので、そうしません。
しかし、開発者に「箱から出してすぐに使用できるようにしますか？すべてのパラメーターと状態プロパティがFlutterのdevtoolで利用可能でしたか？」 彼らはそう言うだろうと確信しています

多くの人が、Reactのdevtoolと真に同等のものを望んでいることを私に表明してきました。 Flutterのdevtoolはまだありません。
Reactでは、ウィジェットのすべての状態とそのパラメーターを確認し、何もせずに編集できます。

同様に、 provider +他のパッケージを使用すると、デフォルトでは、何もしなくてもアプリケーションの状態全体が表示されると言ったとき、人々は非常に驚いていました（この厄介なdevtoolバグを法として）

私はFutureBuilderの大ファンではないことを認めなければなりません。人々はいつFutureをトリガーするかを考えていないため、多くのバグが発生します。 サポートをやめるのは無理はないと思います。 StreamBuilderは大丈夫だと思いますが、Streams自体は複雑すぎると思います（上記のコメントで述べたように）ので...

なぜ誰かがトゥイーンの作成の複雑さについて考えなければならないのですか？

ListViewは、ウィジェットをマウントするロジックを表示どおりに隠しているわけではありません。 それはAPIの大きな部分です。

問題は行数ではなく、これらの行が何であるかです。

私はここでの懸念を本当に理解していません。 線は単純な定型文のように見えます。 モノを宣言し、モノを初期化し、モノを処分します。 行数ではない場合、何が問題なのでしょうか。

FutureBuilderに問題があることに同意します。

少し話題から外れていますが、開発では、Flutterが数秒ごとに偽のホットリロードをトリガーする必要があることをお勧めします。 これにより、FutureBuilder、キー、その他多くの誤用が浮き彫りになります。

なぜ誰かがトゥイーンの作成の複雑さについて考えなければならないのですか？

ListViewは、ウィジェットをマウントするロジックを表示どおりに隠しているわけではありません。 それはAPIの大きな部分です。

私たちはそれに同意します。 私のポイントは、フックが行うことはTweenAnimationBuilder / AnimatedContainer / ...が行うことと厳密に同等であるため、「ロジックを隠す」というフックのようなものを批判することはできないということでした。
ロジックは隠されていません

結局、アニメーションは良い比較だと思います。 アニメーションには、暗黙的対明示的というこの概念があります。
暗黙のアニメーションは、そのシンプルさ、構成可能性、読みやすさから愛されています。
明示的なアニメーションはより柔軟ですが、より複雑です。

この概念をストリームのリスニングに変換すると、 StreamBuilderは_暗黙のリスニング_ですが、 stream.listenは_明示的なリスニング_です。

より具体的には、 StreamBuilderを使用すると、ストリームが変更されるシナリオを処理することを忘れたり、サブスクリプションを閉じることを忘れたりすることはできません。
複数のStreamBuilder組み合わせることもできます

stream.listenは少し高度で、エラーが発生しやすくなっています。

ビルダーは、アプリケーションを簡素化するために強力です。
しかし、以前に合意したように、Builderパターンは理想的ではありません。 書くことも使うことも冗長です。
この問題とフックが解決するものは、* Buildersの代替構文に関するものです

たとえば、 flutter_hooksは、 FutureBuilderおよびStreamBuilderと厳密に同等です。

Widget build(context) {
  final AsyncSnapshot<T> snapshot = useStream(stream);
}

続けて、 AnimatedContainerはuseAnimatedSize / useAnimatedDecoractedBox / ...で表すことができます。

double opacity;

Widget build(context) {
  final double animatedOpacity = useAnimatedDouble(opacity, duration: Duration(milliseconds: 200));
  return Opacity(
    opacity: animatedOpacity,
    child: ...,
  );
}

私のポイントは、「論理を隠す」というフックのようなものを批判することはできないということでした。

それは議論ではありません。 議論は「開発者が考えるべき論理

開発者が考えるべきそのようなロジックの例はありますか？

たとえば、TextEditingControllerの所有者（作成者、廃棄者）のように。

このコードのように？

Widget build(context) {
  final controller = useTextEditingController();
  final focusNode = useFocusNode();
}

フックがそれを作成し、それを処分します。

これについて何が不明確なのかわかりません。

はい、正確に。 そのコードでのコントローラーのライフサイクルが何であるかわかりません。 字句スコープが終了するまで続きますか？ 国家の生涯？ 他に何かありますか？ 誰がそれを所有していますか？ 私がそれを他の誰かに渡した場合、彼らは所有権を取得できますか？ これは、コード自体では明らかではありません。

あなたの議論は、実際の問題ではなく、フックが何をするのかについての理解の欠如によって引き起こされているようです。
これらの質問には、すべてのフックと一致する明確に定義された回答があります。

そのコードでのコントローラーのライフサイクルが何であるかわかりません

また、それについて考える必要もありません。 それはもはや開発者の責任ではありません。

字句スコープが終了するまで続きますか？ 国家の生涯

国家の生涯

誰がそれを所有していますか？

フックはコントローラーを所有します。 コントローラを所有しているのはuseTextEditingControllerのAPIの一部です。
これはuseFocusNode 、 useScrollController 、 useAnimationController 、..に適用されます。

ある意味で、これらの質問はStreamBuilder当てはまります。

• StreamSubscriptionのライフサイクルについて考える必要はありません
• サブスクリプションは州の存続期間中持続します
• StreamBuilderはStreamSubscriptionを所有しています

一般的に、あなたは考えることができます：

final value = useX(argument);

厳密に同等のものとして：

XBuilder(
  argument: argument,
  builder: (context, value) {

  },
);

それらは同じルールと同じ動作をします。

開発者の責任ではなくなりました

基本的にそれがここでの意見の相違だと思います。 明確ではない定義された存続期間を持つ値を返す関数のようなAPIを持つことは、IMHOであり、その値をクロージャーに渡すことに基づくAPIとは根本的に大きく異なります。

このスタイルを使用するパッケージを作成する人には問題ありませんが、コアフラッターAPIに含めたい種類とは逆のスタイルです。

@Hixie
@rrousselGitが言っていたのは、それらは同じものであるということではなく、ライフサイクルに関して「同じルールと同じ動作」を持っているということだと思いますか？ 正しい？

ただし、同じ問題を解決することはできません。

私はここで間違っているかもしれませんが、昨年の秋にフラッターを試してみると、1つのウィジェットにこれらのビルダーが3つ必要だったとしたら、多くのネストが必要だったと思います。 3つのフック（3行）と比較して。
また。 フックは構成可能であるため、複数のフックで構成される状態ロジックを共有する必要がある場合は、他のフックといくつかの追加ロジックを使用する新しいフックを作成し、1つの新しいフックを使用することができます。

ウィジェット間で状態ロジックを簡単に共有するようなものは、2019年のフラッター秋を試したときに私が見逃していたものでした。

もちろん、他にも多くの可能な解決策がある可能性があります。 多分それはすでに解決されていて、私はそれをドキュメントで見つけられませんでした。
しかし、そうでない場合、第一級市民として利用可能な場合、フックや同じ問題の別の解決策のようなものがあれば、開発を大幅にスピードアップするためにできることはたくさんあります。

OPが言及しているように、あらゆる種類の問題があるビルダーアプローチを使用することを私は絶対に提案していません。 私が提案するのは、initState / disposeを使用することです。 なぜそれが問題なのかよくわかりません。

https://github.com/flutter/flutter/issues/51752#issuecomment-664787791のコードについて人々がどのように感じているのか興味があり

@Hixieフックは、ライフサイクルを単一の関数呼び出しに区分するため、使いuseAnimationControllerようにフックを使用する場合、initStateについて考えて破棄する必要はありません。 それは開発者から責任を取り除きます。 作成したすべてのアニメーションコントローラーを破棄したかどうかを心配する必要はありません。

initStateとdisposeは、1つのことには問題ありませんが、複数の異なるタイプの状態を追跡する必要があることを想像してみてください。 フックは、クラスのライフサイクルに分散させるのではなく、抽象化の論理単位に基づいて構成されます。

あなたが求めているのは、毎回手動でエフェクトを処理できるのに、なぜ関数があるのか​​ということと同じだと思います。 私はそれが完全に同じではないことに同意しますが、それはおおむね似ているように感じます。 以前にフックを使用したことがないようですので、問題はあまり明白ではないようです。したがって、おそらくflutter_hooksパッケージを使用して、フックを使用して中小規模のプロジェクトを実行することをお勧めします。それがどのように感じるか。 私はこれをあらゆる点で言います。Flutterのユーザーとして、他の人と同じように、フックが解決策を提供するこれらの問題に遭遇しました。 これらの問題が本当に私たちに存在することをあなたに納得させる方法がわかりません。もっと良い方法があるかどうか私たちに知らせてください。

Reactの観点からいくつかの考えを追加します。
関連性がない場合はご容赦ください。ただし、フックについての考え方を簡単に説明したいと思います。

フックは間違いなく物を「隠している」。 または、それをどのように見るかに応じて、それらをカプセル化します。 特に、それらは局所的な状態と効果をカプセル化します（私たちの「効果」は「使い捨て」と同じものだと思います）。 「暗黙性」とは、呼び出されるコンポーネントにライフタイムを自動的に付加することです。

この暗黙性は、モデルに固有のものではありません。 コンポーネント自体からカスタムフック全体、各プリミティブフックに至るまで、すべての呼び出しに引数が明示的にスレッド化されていることを想像できます。 しかし実際には、ノイズが多く、実際には役に立たないことがわかりました。 そのため、現在実行中のコンポーネントを暗黙的なグローバル状態にしました。 これは、コードでerrorHandlerFrameを渡す代わりに、VMのthrowが最も近いcatchブロックを上向きに検索する方法に似ています。

さて、それはそれらの中に暗黙の隠された状態を持つ関数です、それは悪いように見えますか？ しかし、Reactでは、一般的なコンポーネントもそうです。 それがコンポーネントの要点です。 これらは、有効期間が関連付けられている関数です（UIツリー内の位置に対応します）。 コンポーネント自体が状態に関してフットガンではない理由は、ランダムなコードからコンポーネントを呼び出すだけではないためです。 他のコンポーネントからそれらを呼び出します。 したがって、UIコードのコンテキストにとどまるため、それらの存続期間は理にかなっています。

ただし、すべての問題がコンポーネントの形をしているわけではありません。 コンポーネントは、状態と効果、およびツリーの位置に関連付けられた存続期間という2つの機能を組み合わせたものです。 しかし、最初の能力はそれ自体で役立つことがわかりました。 関数がコードをカプセル化できるので一般的に役立つのと同じように、ツリーに新しいノードを作成しなくても、状態と効果のバンドルをカプセル化（および再利用）できるプリミティブがありませんでした。 それがフックです。 コンポーネント=フック+返されたUI。

先ほど申し上げたように、コンテキスト状態を隠す任意の関数は怖いです。 これが、リンターを介して規則を施行する理由です。 フックには「色」があります—フックを使用する場合、関数はフックでもあります。 また、リンターは、コンポーネントまたは他のフックのみがフックを使用できるように強制します。 これにより、任意の関数がコンテキストUIの状態を隠すという問題が解消されます。これは、それらがコンポーネント自体よりも暗黙的ではなくなったためです。

概念的には、フック呼び出しを単純な関数呼び出しとは見なしません。 useState() use State()ように、構文があれば、 代数効果を備えたフックのようなものをモデル化できます。 したがって、その意味では、それらは通常の関数になりますが、状態を「使用」するという事実は、型シグネチャの一部になります。 次に、React自体をこのエフェクトの「ハンドラー」と考えることができます。 とにかく、これは非常に理論的ですが、プログラミングモデルの観点から先行技術を指摘したいと思いました。

実際には、ここにはいくつかのことがあります。 まず、フックはReactの「追加の」APIではないことに注意してください。 これらは、現時点でコンポーネントを作成するため

それらが可能にするものに関しては、重要な機能は、状態+効果的なロジックをカプセル化し、通常の関数合成の場合と同じようにそれをチェーン化する機能だと思います。 プリミティブは構成するように設計されているため、 useState()ようなフック出力を取得し、それをカスタムuseGesture(state)への入力として渡し、それをいくつかのカスタムuseSpring(gesture)への入力として渡すことができます。千鳥状の値を与える小さなデモと、フックとは何かを簡単に要約した記事です。

これは定型文を減らすことではなく、ステートフルカプセル化ロジックのパイプラインを動的に構成する機能

これが役に立ったかどうかはわかりませんが、プログラミングモデルに何らかの視点を与えることを願っています。
他の質問にお答えします。

OPが言及しているように、あらゆる種類の問題があるビルダーアプローチを使用することを私は絶対に提案していません。 私が提案するのは、initState / disposeを使用することです。 なぜそれが問題なのかよくわかりません。

＃51752（コメント）のコードについて人々がどのように感じているのか興味があります。 initState / disposeよりも優れているとは思いませんが、フックが好きな人はそれも好きですか？ フックは良いですか？ 悪い？

lateキーワードは状況を改善しますが、それでもいくつかの問題があります。

このようなPropertyは、自己完結型の状態、または時間の経過とともに変化する可能性のあるパラメーターに依存しない状態に役立つ場合があります。 ただし、状況が異なると使いづらくなる場合があります。
より正確には、「更新」部分がありません。

たとえば、 StreamBuilderすると、リッスンされるストリームは時間の経過とともに変化する可能性があります。 ただし、オブジェクトは1回しか初期化されないため、ここでそのようなことを実装する簡単な解決策はありません。

同様に、フックにはウィジェットのKeyと同等のものがあります。これにより、キーが変更されたときに状態の一部が破棄され、再作成される可能性があります。

その例はuseMemo 、これはオブジェクトのインスタンスをキャッシュするフックです。
キーと組み合わせて、 useMemoを使用して暗黙的なデータフェッチを行うことができます。
たとえば、ウィジェットがメッセージIDを受信する場合があります。これを使用して、メッセージの詳細を取得します。 ただし、そのメッセージIDは時間の経過とともに変化する可能性があるため、詳細を再取得する必要がある場合があります。

useMemo場合、次のようになります。

String messageId;

Widget build(context) {
  final Future<Message> message = useMemo(() => fetchMessage(messageId), [messageId]);

}

この場合、buildメソッドが10回呼び出されても、 messageIdが変わらない限り、データのフェッチは再度実行されません。
ただし、 messageIdが変更されると、新しいFutureが作成されます。

現在の状態のflutter_hooksがダーツのために洗練されているとは思わないことは注目に値します。 私の実装は、本格的なアーキテクチャというよりもPO​​Cです。
しかし、StatefulWidgetsのコードの再利用性に問題があると私は信じています。

どこにあるかは覚えていませんが、理想的な世界のフックは、 async*とsync*隣にあるカスタム関数発生器であると提案したことを覚えています。これは、Danがuse State提案したものと似ている可能性があります。 useStateではなくuse State useState

@gaearon

これは定型文を減らすことではなく、ステートフルカプセル化ロジックのパイプラインを動的に構成する機能についてであることを強調したいと思います。

それはここで議論されている問題ではありません。 あなたが説明したことを実行できないことについて話すために、別のバグを提出することをお勧めします。 （これは非常に異なる問題のように聞こえますが、正直なところ、ここで説明する問題よりも説得力があります。）このバグは、特にロジックの一部が冗長すぎることに関するものです。

いいえ、彼は正しいです、混乱するかもしれないのは私の言葉遣いです。
前に述べたように、これはコードの行数ではなく、コードの行自体です。

これは状態の因数分解についてです。

このバグは、「状態ロジックの再利用が冗長/困難すぎる」という問題と、initStateで宣言するコードが必要なプロパティがある場合に、状態にコードが多すぎるという問題について非常に明確です。破棄し、debugFillPropertiesで。 気になる問題が何か違う場合は、その問題を説明する新しいバグを提出することをお勧めします。

解決したい問題を完全に理解するまで、フック（または任意の解決策）を忘れることを強くお勧めします。 問題を明確に理解することによってのみ、新しい機能を支持する説得力のある議論を明確にすることができます。なぜなら、それらが解決する問題に対して機能を評価する必要があるからです。

その時、私がその号で言ったことをあなたは誤解していると思います。

問題は決して定型文ではなく、再利用性です。

ボイラープレートは再利用性の問題の結果であり、原因ではありません

この問題の説明は次のとおりです。

状態ロジックを再利用/構成したい場合があります。 ただし、使用可能なオプションは、ミックスイン、ビルダー、または再利用しないかのいずれかです。これらにはすべて独自の問題があります。

既存のオプションの問題は定型文に関連している可能性がありますが、私たちが解決しようとしている問題はそうではありません。
Buildersの定型文を減らすことは1つのパス（フックが行うことです）ですが、別のパスがある場合があります。

たとえば、私がしばらく提案したかったのは、次のようなメソッドを追加することでした。

context.onDidChangeDependencies(() {

});
context.onDispose(() {

});

しかし、これらには独自の問題があり、問題を完全に解決するわけではないので、私はしませんでした。

@rrousselGit 、問題をより適切に反映するために、ここの上部にある元の問題ステートメントを自由に編集してください。 また、デザインドキュメントを自由に作成してください： //flutter.dev/docs/resources/design-docs一緒に繰り返すことができます（ここでも、 @ Hixieが示唆しているように、今のところ、問題ステートメントの可能な限り

私はこの問題を何度か見直しました。 正直なところ、誤解がどこから来ているのかわからないので、何を改善すればいいのかわかりません。
元のコメントは、再利用性/因数分解の要望について繰り返し言及しています。 ボイラープレートについての言及は、「フラッターは冗長です」ではなく、「一部のロジックは再利用できません」です。

デザインドキュメントの提案は公平ではないと思います。 そのような文書を書くのにはかなりの時間がかかります、そして私は私の自由な時間にこれをしています。
私は個人的にフックに満足しています。 私はこれらの問題を自分の利益のために作成しているのではなく、かなりの数の人々に影響を与える問題についての認識を高めるためです。

数週間前、私は既存のFlutterアプリのアーキテクチャについて話し合うために雇われました。 彼らはおそらくここで言及されているものとまったく同じでした：

• 複数のウィジェットで再利用する必要のあるロジックがいくつかあります（読み込み状態の処理/一部のウィジェットが表示されたときに「メッセージ」を既読としてマークする/ ...）
• 彼らはミックスインを使おうとしましたが、それが大きなアーキテクチャの欠陥を引き起こしました。
• また、複数の場所でそのロジックを書き直すことにより、「作成/更新/破棄」を手動で処理しようとしましたが、バグが発生しました。
  いくつかの場所では、彼らはサブスクリプションを閉じるのを忘れていました。 他では、 streamインスタンスが変更されるシナリオを処理しませんでした

• 一部のウィジェットが表示されたときに「メッセージ」を既読としてマークする

これは、自分のアプリの1つで発生した問題に似ているため、興味深いケースです。そこで、コードをどのように実装したかを調べましたが、このバグで説明されている問題はあまり見られません。私が問題を理解するのに苦労している理由です。 これは問題のコードです：

https://github.com/jocosocial/rainbowmonkey/blob/master/lib/src/views/forums.dart

問題が実際に発生していることを確認するために調査できる実際のアプリの例はありますか？

（ところで、一般的に、ストリームをまったく使用しないことを強くお勧めします。一般的に、ストリームは事態を悪化させると思います。）

（ところで、一般的に、ストリームをまったく使用しないことを強くお勧めします。一般的に、ストリームは事態を悪化させると思います。）

（私は心から同意します。しかし、コミュニティは現在反対の反応を示しています。FlutterからChangeNotifier / Listenable / ValueNotifierを公式パッケージに抽出すると役立つかもしれません）

問題が実際に発生していることを確認するために調査できる実際のアプリの例はありますか？

残念ながら違います。 私は他の人を助けている間に私が経験したことを共有することができるだけです。 手元にアプリがありません。

これは、自分のアプリの1つで発生した問題に似ているため、興味深いケースです。そこで、コードをどのように実装したかを調べましたが、このバグで説明されている問題はあまり見られません。私が問題を理解するのに苦労している理由です。 これは問題のコードです：

実装では、ロジックはライフサイクルに関連付けられておらず、_build_内に配置されているため、問題を回避することができます。
その特定の場合には意味があるかもしれません。 その例が良かったかどうかはわかりません。

より良い例は、プルツーリフレッシュです。

典型的なプルトゥリフレッシュでは、次のことが必要になります。

• 最初のビルドで、ロード/エラー状態を処理します
• 更新時：
  
  
  
  • 画面がエラー状態だった場合は、ロード画面をもう一度表示します
  
  
  • ロード中に更新が実行された場合は、保留中のHTTPリクエストをキャンセルします
  
  
  • 画面にデータが表示された場合：
  
  
  • 新しい状態が読み込まれている間、データを表示し続けます
  
  
  • 更新が失敗した場合は、以前に取得したデータを表示し続け、エラーのあるスナックバーを表示します
  
  
  • 更新が保留されている間にユーザーがポップして画面に再び入る場合は、ロード画面を表示します
  
  
  • 更新が保留されている間、Re​​freshIndicatorが表示されていることを確認してください
  
  

そして、すべてのリソースと複数の画面にそのような機能を実装したいと思います。 さらに、画面によっては、一度に複数のリソースを更新したい場合があります。

ChangeNotifier + provider + StatefulWidgetは、このロジックを因数分解するのに非常に多くの困難を伴います。

私の最新の実験（不変性に基づいており、 flutter_hooks依存しています）は、箱から出してすぐにスペクトル全体をサポートします。

final productsProvider = FutureProvider<List<Product>>.autoDispose((ref) async {
  final cancelToken = CancelToken();
  ref.onDispose(cancelToken.cancel);

  return await repository.fetchProducts(cancelToken: cancelToken);
});

// ...

Widget build(context) {
  // Listens to the Future created by productsProvider and handles all the refresh logic
  AsyncValue<List<Product>> products = useRefreshProvider(
    productsProvider,
    // TODO consider making a custom hook to encaplusate the snackbar logic
    onErrorAfterRefresh: (err, stack) => Scaffold.of(context).showSnackBar(...),
  );

  return RefreshIndicator(
    onRefresh: () => context.refresh(productsProvider),
    child: products.when(
      loading: () {
        return const SingleChildScrollView(
          physics: AlwaysScrollableScrollPhysics(),
          child: CircularProgressIndicator(),
        );
      },
      error: (err, stack) {
        return SingleChildScrollView(
          physics: const AlwaysScrollableScrollPhysics(),
          child: Text('Oops, something unexpected happened\n$err'),
        );
      },
      data: (products) {
        return ListView.builder(
          itemCount: products.length,
          itemBuilder: (context, index) {
            return ProductItem(products[index]);
          },
        );
      },
    ),
  );
}

このロジックは完全に自己完結型です。 これは、任意の画面内の任意のリソースで再利用できます。

また、1つの画面で複数のリソースを一度に更新したい場合は、次のことができます。

AsyncValue<First> first = useRefreshProvider(
  firstProvider,
  onErrorAfterRefresh: ...
);
AsyncValue<Second> second = useRefreshProvider(
  secondProvider,
  onErrorAfterRefresh: ...
);

return RefreshIndicator(
  onRefresh: () {
     return Future.wait([context.refesh(firstProvider), context.refresh(secondProvider)]);
  }
  ...
)

そのロジックをすべてウィジェットの外のアプリの状態にし、アプリの状態に現在のアプリの状態を反映させることをお勧めします。 プルして更新する場合、ウィジェット内に状態は必要ありません。更新が保留中であることを周囲の状態に通知し、その将来が完了するのを待つだけです。

エラーとロードとデータのレンダリング方法を決定するのは、周囲の状態の責任ではありません。

このロジックをアンビエント状態にしても、UIからすべてのロジックが削除されるわけではありません。
UIは、エラーを全画面表示にするかスナックバーに表示するかを決定する必要があります。
それでも、ページがリロードされたときにエラーを強制的に更新する必要があります

そして、これは再利用性が低くなります。
レンダリングロジックが周囲の状態ではなくウィジェットで完全に定義されている場合、それは_any_Futureで機能しますFlutter内に直接含めることもできます。

私はあなたがあなたの最後のコメントで何を主張しているのか本当に理解していません。 私のポイントは、前に引用したコードで示されているように、上記の更新インジケーターコードのように単純なことを行うためにフレームワークを変更する必要がないということです。

更新インジケーターだけでなく、アニメーションなどのこれらのタイプのインタラクションが多数ある場合は、アプリの状態にするよりも、必要に最も近い場所にカプセル化する方がよいでしょう。アプリの状態だからです。アプリ内の複数の場所で必要ない場合は、アプリ内のすべてのインタラクションの詳細を知る必要はありません。

機能の複雑さとその再利用性については同意していないと思います。
そのような機能が簡単であることを示す例はありますか？

上で書いた1つのアプリのソースにリンクしました。 それは確かに完璧なコードではなく、次のリリースのためにその一部を書き直す予定ですが、この号で説明した問題は発生しませんでした。

しかし、あなたはFlutterの技術リーダーの1人です。
問題に直面した場合でも、すぐに解決策を考え出すのに十分なスキルがあります。

しかし一方で、かなりの数の人々が次のコードの何が問題なのかを理解していません。

FutureBuilder<User>(
  future: fetchUser(),
  builder: ...,
)

この事実は、StackOverflowでQ / AIがどれほど人気が​​あるかによって証明されています。

問題は、再利用可能で堅牢な方法で状態ロジックを抽象化することが不可能であるということではありません（そうでなければ、この問題を作成しても意味がありません）。
問題は、そうするのに時間と経験の両方が必要なことです。

公式のソリューションを提供することで、アプリケーションが保守不能になる可能性が低くなり、全体的な生産性と開発者のエクスペリエンスが向上します。
誰もがあなたの物件の提案を思い付くことができるわけではありません。 そのようなものがFlutter内に構築された場合、それは文書化され、可視性を獲得し、最終的には最初から考えたことのない人々を支援します。

問題は、アプリが何であるか、状態がどのように見えるかなどに実際に依存することです。 ここでの質問が「アプリの状態をどのように管理するか」である場合、答えはフックのようなものではありません。それを行うためのさまざまな方法について説明し、さまざまな状況に応じてさまざまな手法を推奨する多くのドキュメントです...基本的に、この一連のドキュメント： https ：

一時的な状態とアプリの状態がありますが、別のユースケースもあるようです。単一のタイプのウィジェットのみに関係するが、それでもそのタイプのウィジェット間で共有したい状態です。

たとえば、 ScrollControllerはある種のアニメーションを呼び出す場合がありますが、それをグローバルアプリの状態にすることは必ずしも適切ではありません。これは、アプリ全体で使用する必要のあるデータではないためです。 ただし、複数のScrollControllerが同じロジックを持っている可能性があり、それぞれの間でそのライフサイクルロジックを共有する必要があります。 状態はまだScrollControllerだけなので、グローバルアプリの状態ではありませんが、ロジックをコピーして貼り付けるとエラーが発生しやすくなります。

さらに、このロジックをパッケージ化して、将来のプロジェクトだけでなく、他のプロジェクトでもより構成しやすくすることができます。 サイトuseHooksを見ると、特定の一般的なアクションを区分化するロジックの多くの部分がわかります。 useAuthを使用する場合は、一度書き込むだけで、 initStateまたはdispose呼び出しを逃したかどうか、または非同期関数にthenがあるかどうかを心配する必要はありません。 catch 。 関数は一度だけ書かれるので、エラーの余地は基本的になくなります。 したがって、この種のソリューションは、同じアプリの複数の部分や複数のアプリ間でより構成しやすいだけでなく、エンドプログラマーにとっても安全です。

私はフックを使用している人々に異議はありません。 私の知る限り、それを妨げるものは何もありません。 （何かがそれを妨げている場合は、それについてバグを報告してください。）

このバグはフックに関するものではなく、「状態ロジックの再利用は冗長/困難すぎる」に関するものであり、これがFlutterへの変更を必要とする理由を理解するのにまだ苦労しています。 アプリケーションを何らかの方法で構造化することで冗長性を回避する方法を示す多くの例（フックを含む）があり、それに関するドキュメントはすでにたくさんあります。

なるほど、Flutterを変更せずにビルドされたフックパッケージのようなものが存在する場合、フックのファーストパーティソリューションが必要なのはなぜですか？ @rrousselGitはこれによりよく答えることができると

表面上はflutter_hooksパッケージがすでに存在するため、それに加えて、フックをサポートするためにFlutterに基本的な変更を加える必要がある理由も混乱しています。

Flutterに変更が必要な理由を理解するのにまだ苦労しています。

コミュニティがパッケージを作成したためにこの問題が解決したと言うことは、私がFreezedを作成したため、Dartはデータクラスと共用体型を必要としないと言っているようなもの
Freezedは、これらの問題の両方の解決策としてコミュニティに非常に好まれているかもしれませんが、それでも私たちはもっとうまくやることができます。

Flutterチームは、コミュニティがこれまで以上に活​​用しています。 スタック全体を変更する両方の機能があります。 個々の部分の専門家である人々。 そして必要な仕事を後援するための給料。

この問題にはそれが必要です。
注意：Reactチームの目標の1つは、JSXのように、フックを言語の一部にすることです。

言語のサポートがなくても、アナライザーでの作業が必要です。 ダートパッド; flutter / devtools; また、Flutterが行うさまざまなことすべてを単純化するための多くのフック（暗黙のアニメーション、フォームなど）。

Flutterの一般的な哲学は小さなコアを持っているとはいえ、それは良い議論だと私は同意します。 そのため、Googleからのものであっても、パッケージとして新しい機能を追加することが増えています。文字やアニメーションを参照してください。 これにより、時間の経過とともに学習および変更するための柔軟性が高まります。 パッケージが不十分であるという説得力のある技術的な理由がない限り、このスペースについても同じことを行います（そして、拡張メソッドを使用すると、これまで以上に可能性が低くなります）。

Flutterのコアに物事を入れるのは難しいです。 直接の経験からよく知っているように、1つの課題は、リアクティブUIアーキテクチャで何がうまく機能するかについて私たち全員が学ぶにつれて、状態が進化している領域であるということです。 2年前、勝者を選ぶことを余儀なくされた場合は、BLoCを選択した可能性がありますが、もちろん、プロバイダーパッケージが引き継がれ、現在はデフォルトの推奨事項です。

私は、flutter_hooksまたは牽引力のある同様のフックパッケージをサポートするGoogle採用の貢献者を快適に想像することができました（もちろん、私たちの注意を奪い合う他の仕事は

興味深い議論、@ timsneath。 Rustコミュニティも同様のことを行います。言語またはフレームワークのコアライブラリまたは標準ライブラリに導入されると、それを取り出すのが非常に難しいためです。 Rustの場合、下位互換性を永久に維持したいので不可能です。 したがって、彼らはパッケージが到着するまで待ち、少数の勝者だけが現れるまで互いに競争し、それからそれを言語に折り畳みます。

これは、Flutterの場合と同様のケースである可能性があります。 Reactがクラスからフックに移動しなければならなかったが、それでもクラスを維持しなければならず、人々が移行しなければならなかったように、後でフックよりも良いものがあるかもしれません。 その場合、コアに追加する前に、競合する状態管理ソリューションを用意する方がよい場合があります。 そして、おそらく私たちコミュニティは、フックの上で革新するか、さらに良い解決策を見つけようとする必要があります。

私はその懸念を理解していますが、これは状態管理ソリューションに関するものではありません。

このような機能は、AttachedwidgetとStatefulWidgetに近いものです。 これは低レベルのプリミティブであり、言語機能と同じくらい低くなる可能性があります。

フックはフレームワークから独立しているかもしれませんが、それは運によってのみです。
前に述べたように、この問題への別のパスは次のようになります。

context.onDispose(() {

});

そして同様のイベントリスナー。
しかし、それをフレームワークから実装することは不可能です。

チームが何を思いつくのかわかりません。
しかし、そのようなソリューションがElementのすぐ隣になければならない可能性を排除することはできません

拡張機能はそれを助けますか？

（ただし、別の問題でそれについて話す必要があるかもしれません。ここではトピックから外れています。人々が目にしている問題ごとに1つの問題があれば、適切な場所で解決策について話し合うことができればと思います。そうではありません。 context.onDisposeが冗長性にどのように役立つかを明確にします。）

これに関連して私たちが思いつくことができるいくつかの本当に良い言語の提案があると強く思います。

それらが特定の状態管理イディオムをどのように可能にするかよりも、それらについてより具体的に話すことが役立つと思います。 次に、それらが何を可能にし、どのようなトレードオフを伴う可能性があるかをより真剣に検討することができます。

特に、VMランタイムとJSランタイムの両方でどのように機能するかを検討することができます。

context.onDisposeが冗長性にどのように役立つかは明確ではありません。）

前に述べたように、この問題は冗長性よりもコードの再利用性に関するものです。 しかし、より多くのコードを再利用できる場合、これは暗黙的に冗長性を減らすはずです。

context.onDisposeがこの問題に関連する方法は、現在の構文では次のとおりです。

AnimationController controller;

<strong i="11">@override</strong>
void initState() {
  controller = AnimationController(...);
}

<strong i="12">@override</strong>
void dispose() {
  controller.dispose();
}

問題は：

• これはクラス定義と緊密に結合されているため、再利用できません
• ウィジェットが大きくなると、途中に数百行のコードがあるため、初期化と破棄の関係が読みにくくなります。

context.onDispose 、次のことができます。

<strong i="21">@override</strong>
void initState() {
  controller = AnimationController(...);
  context.onDispose(controller.dispose);
}

興味深い部分は次のとおりです。

• これはもはやクラス定義と緊密に結合されていないため、関数に抽出できます。
  理論的には、半複雑なロジックを持つことができます。
  `` `ダーツ
  AnimationController someReusableLogic（BuildContext context）{
  最終コントローラー= AnimationController（...）;
  controller.onDispose（controller.dispose）;
  controller.forward（）;
  void listener（）{}
  controller.addListener（listener）;
  context.onDispose（（）=> controller.removeListener（listener））;
  }
  ..。

@オーバーライド
void initState（）{
コントローラー= someReusableLogic（context）;
}
`` `

• すべてのロジックがバンドルされています。 ウィジェットの長さが300に増えても、 controllerのロジックは簡単に読み取ることができます。

このアプローチの問題は次のとおりです。

• context.myLifecycle(() {...})はホットリロードできません
• 関数をウィジェット定義に緊密に結合せずに、 someReusableLogicにStatefulWidgetからプロパティを読み取らせる方法は不明です。
  たとえば、 AnimationControllerのDurationウィジェットのパラメータとして渡すことができます。 したがって、期間が変化するシナリオを処理する必要があります。
• ValueNotifierに頼ったり、リスナーを処理したりせずに、時間の経過とともに変化する可能性のあるオブジェクトを返す関数を実装する方法は不明です。
  
  
  
  • これは、計算された状態にとって特に重要です。
  
  

言語の提案について考えます。 私にはいくつかのアイデアがありますが、今話す価値のあるものは何もありません。

前に述べたように、この問題は冗長性よりもコードの再利用性に関するものです

Ok。 それについて具体的に説明している新しいバグを提出していただけませんか？ このバグは、文字通り「状態ロジックの再利用は冗長/困難すぎる」と呼ばれます。 冗長性が問題ではない場合、_this_は問題ではありません。

context.onDispose 、次のことができます。

<strong i="11">@override</strong>
void initState() {
  controller = AnimationController(...);
  context.onDispose(controller.dispose);
}

contextがこれに関連する理由がわかりません（そしてonDisposeは命名規則に違反しています）。 ただし、破棄中に実行するものを登録する方法が必要な場合は、今日これを簡単に行うことができます。

mixin StateHelper<T extends StatefulWidget> on State<T> {
  List<VoidCallback> _disposeQueue;

  void queueDispose(VoidCallback callback) {
    _disposeQueue ??= <VoidCallback>[];
    _disposeQueue.add(callback);
  }

  <strong i="17">@override</strong>
  void dispose() {
    if (_disposeQueue != null) {
      for (VoidCallback callback in _disposeQueue)
        callback();
    }
    super.dispose();
  }
}

このように呼んでください：

class _MyHomePageState extends State<MyHomePage> with StateHelper<MyHomePage> {
  TextEditingController controller;

  <strong i="21">@override</strong>
  void initState() {
    super.initState();
    controller = TextEditingController(text: 'button');
    queueDispose(controller.dispose);
  }

  ...

AnimationController someReusableLogic(BuildContext context) {
  final controller = AnimationController(...);
  controller.onDispose(controller.dispose);
  controller.forward();
  void listener() {}
  controller.addListener(listener);
  context.onDispose(() => controller.removeListener(listener));
}
...

<strong i="25">@override</strong>
void initState() {
  controller = someReusableLogic(context);
}

あなたもそれを行うことができます：

AnimationController someReusableLogic<T extends StatefulWidget>(StateHelper<T> state) {
  final controller = AnimationController(...);
  state.queueDispose(controller.dispose);
  controller.forward();
  void listener() {}
  controller.addListener(listener);
  state.queueDispose(() => controller.removeListener(listener));
  return controller;
}
...

<strong i="6">@override</strong>
void initState() {
  controller = someReusableLogic(this);
}

このアプローチの問題は次のとおりです。

• context.myLifecycle(() {...})はホットリロードできません

このコンテキストでは、initStateで呼び出されるものだけのためであるため、問題ではないようです。 私は何かが足りないのですか？

• 関数をウィジェット定義に緊密に結合せずに、 someReusableLogicにStatefulWidgetからプロパティを読み取らせる方法は不明です。
  たとえば、 AnimationControllerのDurationウィジェットのパラメータとして渡すことができます。 したがって、期間が変化するシナリオを処理する必要があります。

disposeキューと同じように、didChangeWidgetキューを追加するのは非常に簡単です。

mixin StateHelper<T extends StatefulWidget> on State<T> {
  List<VoidCallback> _disposeQueue;
  List<VoidCallback> _didUpdateWidgetQueue;

  void queueDispose(VoidCallback callback) {
    _disposeQueue ??= <VoidCallback>[];
    _disposeQueue.add(callback);
  }

  void queueDidUpdateWidget(VoidCallback callback) {
    _didUpdateWidgetQueue ??= <VoidCallback>[];
    _didUpdateWidgetQueue.add(callback);
  }

  <strong i="24">@override</strong>
  void didUpdateWidget(T oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (_didUpdateWidgetQueue != null) {
      for (VoidCallback callback in _didUpdateWidgetQueue)
        callback();
    }
  }

  <strong i="25">@override</strong>
  void dispose() {
    if (_disposeQueue != null) {
      for (VoidCallback callback in _disposeQueue)
        callback();
    }
    super.dispose();
  }
}

AnimationController conditionalAnimator(StateHelper state, ValueGetter<bool> isAnimating, VoidCallback listener) {
  final controller = AnimationController(vsync: state as TickerProvider, duration: const Duration(seconds: 1));
  state.queueDispose(controller.dispose);
  controller.addListener(listener);
  state.queueDispose(() => controller.removeListener(listener));
  if (isAnimating())
    controller.repeat();
  state.queueDidUpdateWidget(() {
    if (isAnimating()) {
      controller.repeat();
    } else {
      controller.stop();
    }
  });
  return controller;
}

このように使用されます：

import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  <strong i="6">@override</strong>
  Widget build(BuildContext context) {
    return MaterialApp(
      home: MyHomePage(animating: false),
    );
  }
}

class MyHomePage extends StatefulWidget {
  MyHomePage({Key key, this.animating}) : super(key: key);

  final bool animating;

  <strong i="7">@override</strong>
  _MyHomePageState createState() => _MyHomePageState();
}

class _MyHomePageState extends State<MyHomePage> with StateHelper<MyHomePage>, SingleTickerProviderStateMixin {
  AnimationController controller;

  <strong i="8">@override</strong>
  void initState() {
    super.initState();
    controller = conditionalAnimator(this, () => widget.animating, () { print(controller.value); });
  }

  <strong i="9">@override</strong>
  Widget build(BuildContext context) {
    return Center(
      child: FadeTransition(
        opacity: controller,
        child: Text('Hello', style: TextStyle(fontSize: 100.0, color: Colors.white)),
      ),
    );
  }
}

• ValueNotifierに頼ったり、リスナーを処理したりせずに、時間の経過とともに変化する可能性のあるオブジェクトを返す関数を実装する方法は不明です。

  • これは、計算された状態にとって特に重要です。

これがここで何を意味するのかわからない、ValueNotifier、たとえばValueListenableBuilderの何が問題になっていますか？

前に述べたように、この問題は冗長性よりもコードの再利用性に関するものです

Ok。 それについて具体的に説明している新しいバグを提出していただけませんか？ このバグは、文字通り「状態ロジックの再利用は冗長/困難すぎる」と呼ばれます。 冗長性が問題ではない場合、これは問題ではありません。

私はこの議論にかなり不快になり始めています。 私はすでにこの点に前に答えました：
この問題のトピックは再利用性であり、冗長性は再利用性の問題の結果として議論されます。 主要なトピックとしてではありません。

上部のコメントには、冗長性について言及している箇条書きが1つだけあります。これは、主に2つのレベルのインデントを対象とするStreamBuilderの場合です。

なぜコンテキストがこれに関連するのかわかりません[...]。 ただし、破棄中に実行するものを登録する方法が必要な場合は、今日これを簡単に行うことができます。

context.onDispose立ち上げたとき、私はそれが良い解決策ではないとはっきり言った。
それが議論とどのように関係しているかを尋ねられたので、私はそれを説明しました。

なぜに関してはcontextの代わりにStateHelperこれは（StatelessWidgetでの作業のように）、より柔軟性があるので、それはあります

context.myLifecycle（（）{...}）はホットリロード可能ではありません

このコンテキストでは、initStateで呼び出されるものだけのためであるため、問題ではないようです。 私は何かが足りないのですか？

変更される可能性があります：

initState() {
  context.myLifecycle(() => print('hello'));
}

の中へ：

initState() {
  context.myLifecycle(() => print('world'));
}

これは、 myLifecycleコールバックへの変更を適用しません。

しかし、使用した場合：

myLifecycle() {
  super.myLifecycle();
  print('hello');
}

その後、ホットリロードが機能します。

これがここで何を意味するのかわからない、ValueNotifier、たとえばValueListenableBuilderの何が問題になっていますか？

この構文は、Builderを使用する必要がないように設計されているため、元の問題に戻りました。

さらに、関数を本当に構成可能にしたい場合は、 ValueGetter + queueDidUpdateWidget提案ではなく、関数はパラメーターとしてValueNotifierを取る必要があります。

AnimationController conditionalAnimator(StateHelper state, ValueListenable<bool> isAnimating, VoidCallback listener) {
...
}

この関数を使用しているウィジェットによっては、 didUpdateWidget以外の場所からisAnimatingを取得したい場合があるためです。
ある場所では、didUpdateWidgetかもしれません。 別の例では、didChangeDependenciesである可能性があります。 さらに別の場所では、 stream.listenのコールバック内にある可能性があります。

しかし、これらのシナリオを簡単にValueNotifierに変換し、関数にそのような通知機能をリッスンさせる方法が必要です。
ですから、私たちは私たちの生活を著しく困難にしています。
私が思うこのパターンよりも、 ConditionalAnimatorBuilderを使用する方が現実的で簡単です。

なぜに関してはcontextの代わりにStateHelperこれは（StatelessWidgetでの作業のように）、より柔軟性があるので、それはあります

StatelessWidgetは、ステートレスウィジェット用です。 重要なのは、状態を作成したり、物を破棄したり、didUpdateWidgetに反応したりしないということです。

はい、ホットリロードのことです。 そのため、initStateにクロージャを配置するのではなくメソッドを使用します。

申し訳ありませんが、これを言い続けており、イライラしているに違いないことは理解していますが、ここで解決しようとしている問題が何であるかはまだわかりません。 元のバグの要約と元の説明の大部分によると、それは冗長だと思いましたが、そうではないことを理解しています。 それで、問題は何ですか？ ここには相互に排他的な欲求がたくさんあり、このバグの多くのコメントに広がっているようです。

• 何かを処分する方法を宣言することは、それを割り当てるのと同じ場所で行われるべきです...
• ...そしてそれを割り当てる場所はそれを割り当てているので一度だけ実行する必要があります...
• ...そして、ホットリロードで動作する必要があります（定義上、1回だけ実行されるコードは再実行されません）...
• ...そして、ステートレスウィジェット（定義上、状態を持たない）で機能する状態を作成できる必要があります...
• ...そして、didUpdateWidgetやdidChangeDependenciesなどへのフックを有効にする必要があります...

私たちがここで関わっているこの反復的なダンスは、物事を成し遂げるための生産的な方法ではありません。 前にも言ったように、ここで何かを得るための最良の方法は、直面している問題を理解できる方法で説明し、すべてのニーズを1か所で説明し、ユースケースで説明することです。 ソリューションをリストしないことをお勧めします。特に、ニーズを満たさないことがわかっているソリューションはリストしないことをお勧めします。 これらのソリューションを不適切にする必要性が説明に記載されていることを確認してください。

正直なところ、基本的にはまったく異なるフレームワーク設計を求めているように思えます。 それはまったく問題ありませんが、Flutterではありません。 別のフレームワークを実行する場合、それは別のフレームワークになりますが、_this_フレームワークで実行する作業はまだたくさんあります。 実際、あなたが説明することの多くは、JetpackComposeの設計方法と非常に似ています。 コンパイラの魔法が必要なため、私はそのデザインの大ファンではないので、何が起こっているのかをデバッグするのは本当に難しいですが、多分それはあなたの路地にありますか？

ここには相互に排他的な欲求がたくさんあり、このバグの多くのコメントに広がっているようです。

それらは相互に排他的ではありません。 フックはこれらのすべてを実行します。 ソリューションに焦点を当てたくないので、詳細には立ち入りませんが、すべてのチェックボックスをオンにします。

前にも言ったように、ここで何かを得るための最良の方法は、直面している問題を理解できる方法で説明し、すべてのニーズを1か所で説明し、ユースケースで説明することです。

私はまだそのトップコメントがそれをどのように失敗するのか理解できません。
他の人に何がはっきりしていないのか、私にはわかりません。

実際、あなたが説明することの多くは、JetpackComposeの設計方法と非常に似ています。 コンパイラの魔法が必要なため、私はそのデザインの大ファンではないので、何が起こっているのかをデバッグするのは本当に難しいですが、多分それはあなたの路地にありますか？

私はそれをよく知らないが、簡単な検索で、私は_yes_と言うだろう。

それらは相互に排他的ではありません。

上記のすべての箇条書きは、ここで解決しようとしている問題の一部ですか？

しかし、彼らはすべてのボックスをチェックします

ボックスをリストできますか？

私はまだそのトップコメントがそれをどのように失敗するのか理解できません。

たとえば、OPは、問題はStatefulWidgetsに関するものであると明示的に述べていますが、この問題に関する最近のコメントの1つは、StatelessWidgetsで機能しなかったため、特定の提案は適切ではないと述べました。

OPであなたは言う：

Stateロジックを再利用することは困難です。 最終的に複雑で深くネストされたbuildメソッドになるか、複数のウィジェット間でロジックをコピーして貼り付ける必要があります。

したがって、これから、要件には次のものが含まれていると思います。

• ソリューションを深くネストしてはなりません。
• ソリューションは、状態を追加しようとする場所に多くの同様のコードを必要としてはなりません。

最初のポイント（ネスティングについて）は問題ないようです。 深くネストされたものを実行する必要があることを示唆しようとはしていません。 （とはいえ、何が深くネストされているかについては意見が分かれる可能性があります。これはここでは定義されていません。後で他のコメントは、ビルダーが深くネストされたコードを引き起こすことを示唆していますが、私の経験では、ビルダーはかなり優れています。

2番目のポイントは、冗長性がないという要件であるように思われます。 しかし、あなたはこれが冗長性についてではないことを何度か説明しました。

OPが行う次のステートメントは、問題を説明しています。

Stateロジックを複数のStatefulWidgetまたがって再利用することは、そのロジックが複数のライフサイクルに依存するようになるとすぐに非常に困難になります。

正直なところ、これが何を意味するのか本当にわかりません。 私にとって「難しい」とは、通常、理解しにくい複雑なロジックがたくさん含まれていることを意味しますが、ライフサイクルイベントの割り当て、破棄、および対応は非常に簡単です。 問題を与える次のステートメント（ここでは、「複雑ではない」と明示的に説明されているため、おそらく問題の説明ではない例をスキップしています）は次のとおりです。

問題は、そのアプローチを拡張したいときに始まります。

これは、「非常に難しい」とは「非常に冗長」を意味し、「複雑ではない」例と「非常に難しい」の例の唯一の違いは、同様のコードが多数出現することから生じることを示唆しました。 「例をスケーリングした結果は、文字通り、同じコードが何度も発生するということです（つまり、冗長性、定型コード）。

これは、問題を説明する次のステートメントによってさらにサポートされます。

このロジックをどこにでもコピーして貼り付けると「機能」しますが、コードに弱点が生じます。

• 手順の1つを書き直すのを忘れがちです（ dispose呼び出しを忘れるなど）

コードをコピーして貼り付けるときに冗長性があるため、間違いを犯しやすいため、おそらく非常に難しいのでしょうか。 しかし、繰り返しになりますが、私が「冗長性」と表現するこの問題に対処しようとしたとき、問題は冗長性ではないとおっしゃいました。

• コードに多くのノイズを追加します

繰り返しになりますが、これは私に冗長性/ボイラープレートを言っているように聞こえますが、それはそうではないと説明しました。

OPの残りの部分は、気に入らない解決策を説明しているだけなので、おそらく問題を説明していません。

これは、OPが問題を説明できない方法を説明していますか？ OP内で実際に問題を説明しているものはすべて冗長性を説明しているように見えますが、それが問題であると提案するたびに、そうではなく、別の問題があると言います。

誤解は言葉の意味に帰着すると思います。
例えば：

コードに多くのノイズを追加します

繰り返しになりますが、これは私に冗長性/ボイラープレートを言っているように聞こえますが、それはそうではないと説明しました。

この点は、 controller.dispose()の数ではなく、これらのコード行が読者にもたらす価値です。
その線は常にそこにあるべきであり、常に同じです。 そのため、リーダーに対するその値はほとんどnullです。

重要なのは、この線の存在ではなく、その不在です。

問題は、そのようなcontroller.dispose()が多ければ多いほど、disposeメソッドで実際の問題を見逃す可能性が高くなることです。
コントローラーが1つ、廃棄が0の場合、簡単にキャッチできます。
100個のコントローラーと99個の廃棄がある場合、不足しているコントローラーを見つけるのは困難です。

次に、次のようになります。

コードをコピーして貼り付けるときに冗長性があるため、間違いを犯しやすいため、おそらく非常に難しいのでしょうか。 しかし、繰り返しになりますが、私が「冗長性」と表現するこの問題に対処しようとしたとき、問題は冗長性ではないとおっしゃいました。

前のポイントで述べたように、コードのすべての行が等しいわけではありません。

比較すると：

+ T state;

<strong i="24">@override</strong>
void initState() {
  super.initState();
+  state = widget.valueNotifier.value;
+  widget.valueNotifier.addListener(_listener);
}

+ void _listener() => seState(() => state = widget.valueNotifier.value);

void dispose() {
+ widget.valueNotifier.removeListener(_listener);
  super.dispose();
}

対：

+ ValueListenableBuilder<T>(
+   valueListenable: widget.valueNotifier,  
+   builder: (context, value, child) {

+    },
+ );

その場合、これらのスニペットは両方とも同じ行数を持ち、同じことを行います。
ただし、 ValueListenableBuilderが望ましいです。

その理由は、重要なのは行数ではなく、これらの行が何であるかということです。

最初のスニペットには次のものがあります。

• 1つのプロパティ宣言
• 1つのメソッド宣言
• 1つの割り当て
• 2つのメソッド呼び出し
• これらはすべて、2つの異なるライフサイクルにまたがっています。 3ビルドを含める場合

2番目のスニペットには次のものがあります。

• 1クラスのインスタンス化
• 1つの無名関数
• ライフサイクルはありません。 ビルドを含める場合は1

これにより、ValueListenableBuilderが_simpler_になります。

これらの行が言っていないこともあります：
ValueListenableBuilderは、時間の経過に伴うvalueListenable変化を処理します。
widget.valueNotifierが時間の経過とともに変化しないシナリオでも、問題はありません。
ある日、その声明は変わるかもしれません。 この場合、ValueListenableBuilderは新しい動作を適切に処理しますが、最初のスニペットではバグが発生しています。

したがって、ValueListenableBuilderは単純であるだけでなく、まったく同じ行数で、コードの変更に対する耐性も高くなります。

これで、ValueListenableBuilderが望ましいということには同意できると思います。
問題は、「すべての再利用可能な状態ロジックにValueListenableBuilderと同等のものがないのはなぜですか？」です。

たとえば、次の代わりに：

final controller = TextEditingController(text: 'hello world');
...
controller.dispose();

私たちは持っているでしょう：

TextEditingControllerBuilder(
  initialText: 'hello world',
  builder: (context, controller) {

  },
);

initialTextへの変更をホットリロードできるという追加の利点があります。

この例は少し些細なことかもしれませんが、この原則を少し高度な再利用可能な状態ロジック（ ModeratorBuilder ）に使用できます。

これは小さなスニペットでは「問題ありません」。 しかし、アプローチを拡張したいので、いくつかの問題が発生します。

• ビルダーは「ノイズが多すぎる」問題に戻ります。

たとえば、次のようにモデルを管理している人がいます。

class User {
  final ValueNotifier<String> name;
  final ValueNotifier<int> age;
  final ValueNotifier<Gender> gender;
}

しかし、ウィジェットは、 name 、 age 、およびgender両方を一度にリッスンしたい場合があります。
つまり、次のことを行う必要があります。

return ValueListenableBuilder<String>(
  valueListenable: user.name,
  builder: (context, userName, _) {
    return ValueListenableBuilder<int>(
      valueListenable: user.age,
      builder: (context, userAge, _) {
        return ValueListenableBuilder<Gender>(
          valueListenable: user.gender,
          builder: (context, userGender, _) {
            return Text('$userGender. $userName ($userAge)');
          },
        );
      },
    );
  },
);

これは明らかに理想的ではありません。 initState / dispose内の汚染を除去して、 buildメソッドを汚染しました。

（例のためにListenable.mergeを無視しましょう。ここでは重要ではありません。構成についてです）

Builderを広範囲に使用した場合、この正確なシナリオで自分自身を簡単に確認できます。 Listenable.merge相当するもの

• カスタムビルダーを書くのは面倒です

  Builderを作成する簡単な解決策はありません。 ここではリファクタリングツールは役に立ちません。単に「ビルダーとして抽出」することはできません。
  さらに、それは必ずしも直感的ではありません。 カスタムビルダーを作成することは、人々が最初に考えることではありません。特に、多くの人が定型文に反対するでしょう（私はそうではありませんが）。

  人々はカスタムの状態管理ソリューションを作成する可能性が高く、最終的には不良コードになる可能性があります。

• ビルダーのツリーを操作するのは面倒です

  前の例でValueListenableBuilderを削除するか、新しい例を追加したいとしますが、これは簡単ではありません。
  コードがコンパイルされない理由を理解するために、（）と{}のカウントに数分費やすことができます。

今述べたBuilderの問題を解決するためのフックがあります。

前の例をフックにリファクタリングすると、次のようになります。

final userName = useValueListenable(user.name);
final useAge = useValueListenable(user.age);
final useGender = useValueListenable(user.gender);

return Text('$userGender. $userName ($userAge)');

以前の動作と同じですが、コードに線形インデントが追加されました。
つまり：

• コードが大幅に読みやすくなりました
• 編集が簡単です。 恐れる必要はありません（）{}; 新しい行を追加します。

それはメインのproviderが好きなものの1つです。 MultiProvider導入することで、多くのネストを削除しました。

同様に、 initState / disposeアプローチとは対照的に、ホットリロードの恩恵を受けます。
新しいuseValueListenableを追加した場合、変更はすぐに適用されます。

そしてもちろん、再利用可能なプリミティブを抽出する機能はまだあります。

String useUserLabel(User user) {
  final userName = useValueListenable(user.name);
  final useAge = useValueListenable(user.age);
  final useGender = useValueListenable(user.gender);

  return '$userGender. $userName ($userAge)';
}

Widget build(context) {
  final label = useUserLabel(user);
  return Text(label);
}

このような変更はextract as functionで自動化でき、ほとんどのシナリオで機能します。

それはあなたの質問に答えますか？

もちろん。 しかし、そのようなものの問題は、実際に正しいことを行うのに十分な情報がないことです。 例えば：

Widget build(context) {
  if (random.nextBool())
    final title = useLabel(title);
  final label = useLabel(name);
  return Text(label);
}

...本当に紛らわしい方法でバグが発生することになります。

コンパイラの魔法でそれを回避することができますが（Composeはそれを行う方法です）、Flutterの場合、基本的な設計上の決定の一部に違反します。 キーを使用して回避することはできますが、パフォーマンスが大幅に低下し（変数ルックアップにはマップルックアップやハッシュなどが含まれるため）、Flutterの基本的な設計目標の一部に違反します。

以前に提案したプロパティソリューション、またはそれから派生したものは、すべてのコードを1か所にまとめるという前述の目標を達成しながら、コンパイラの魔法を回避しているようです。 なぜそれがうまくいかないのか、私にはよくわかりません。 （明らかに、didChangeDependenciesなどにもフックして完全なソリューションにするように拡張されます。）（パフォーマンス要件に違反するため、これを基本フレームワークに配置しません。）

あなたが言うように、発生する可能性のあるバグが原因で、フックを条件付きで呼び出すべきではありません。 詳細については、ReactJSのRules ofHooksドキュメントを参照してください。 基本的な要点は、それらの実装では呼び出し順序によって追跡されるため、条件付きで使用するとその呼び出し順序が壊れ、正しく追跡できなくなるということです。 フックを適切に使用するには、条件付きロジックなしでbuildのトップレベルでフックを呼び出します。 JSバージョンでは、あなたは戻ってきます

const [title, setTitle] = useLabel("title");

Dartに相当するものも同様ですが、JSのように解凍しないため、長くなります。

var titleHook = useLabel("title");
String title = titleHook.property;
Function setTitle = titleHook.setter;

条件付きロジックが必要な場合は、ビルドメソッドでtitleを使用することを決定できます。これは、呼び出し順序が引き続き保持されるためです。 あなたが提起するこれらの問題の多くは、私が上でリンクしたフックドキュメントで説明されています。

もちろん。 そして、あなたはパッケージでそれを行うことができます。 そのような要件は私たちの設計哲学に違反するだろうと言っているだけです。そのため、Flutterフレームワークにそれを追加しません。 （具体的には、読みやすさとデバッグ可能性を最適化します。コードが機能しているように見えますが、条件付き（コードでは明らかでない場合があります）が機能しない場合があるため、コアフレームワーク。）

デバッグ/条件付きの動作は問題ではありません。 そのため、アナライザープラグインが重要です。 このようなプラグインは次のようになります。

• 関数がuseMyFunctionという名前なしでフックを使用する場合に警告
• フックが条件付きで使用されている場合は警告
• フックがループ/コールバックで使用されている場合は警告します。

これはすべての潜在的な間違いをカバーしています。 Reactは、これが実行可能なことであることを証明しました。

次に、次のようなメリットがあります。

• より読みやすいコード（前に示したように）
• より良いホットリロード
• より再利用可能/構成可能なコード
• より柔軟–計算された状態を簡単に作成できます。

計算された状態については、フックはオブジェクトのインスタンスをキャッシュするのに非常に強力です。 これは、パラメーターが変更された場合にのみウィジェットを再構築するために使用できます。

たとえば、次のようにすることができます。

class Example extends HookWidget {
  final int userId;

  Widget build(context) {
    // Calls fetchUser whenever userId changes
    // It is the equivalent to both initState and didUpdateWidget
    final future = useMemo1(() => fetchUser(userId), userId);

    final snapshot = useFuture(future);
    if (!snapshot.hasData)
      return Text('loading');
    return Text(snapshot.data.name);
  }  
}

このようなuseMemoフックを使用すると、パフォーマンスを簡単に最適化し、initとupdateの両方を宣言的に処理できるため、バグも回避できます。

これは、 Property / context.onDispose提案が見逃しているものです。
ロジックをライフサイクルに緊密に結合したり、コードをValueNotifier複雑化したりしない限り、宣言型の状態に使用することは困難です。

ValueGetter提案が実用的でない理由の詳細：

リファクタリングが必要な場合があります。

final int userId;

Widget build(context) {
  final future = useMemo1(() => fetchUser(userId), userId);

の中へ：

Widget build(context) {
  final userId = Model.of(context).userId;
  final future = useMemo1(() => fetchUser(userId), userId);

useMemoはライフサイクルに関連付けられていないため、フックを使用すると、この変更は問題なく機能します。

しかし、 Property + ValueGetter場合、これを機能させるにはPropertyの実装を変更する必要があります。これは、 Propertyコードが複数の場所で再利用。 そのため、再利用性が再び失われました。

FWIWこのスニペットは次のものと同等です。

class Example extends StatefulWidget {
  final int userId;
  <strong i="45">@override</strong>
  _ExampleState createState() => _ExampleState();
}

class _ExampleState extends State<Example> {
  Future<User> future;

  <strong i="46">@override</strong>
  void initState() {
    super.initState();
    future = fetchUser(widget.userId);
  }

  <strong i="47">@override</strong>
  void didUpdateWidget(Example oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (oldWidget.userId != widget.userId) {
      future = fetchUser(widget.userId);
    }
  }

  <strong i="48">@override</strong>
  Widget build(BuildContext context) {
    return FutureBuilder<User>(
      future: future,
      builder: (context, snapshot) {
        if (!snapshot.hasData)
          return Text('loading');
        return Text(snapshot.data.name);
      },
    );
  }
}

@rrousselGitが言及しているのと同じ問題を解決するだけでなく、読みやすさとデバッグ可能性も念頭に置いた解決策を見つける必要があると思います。 Vueには独自の実装があり、条件や呼び出し順序がReactのようにバグを引き起こさない場合に、探しているものとより一致する可能性があります。

たぶん次のステップは、VueがVueの制約を与えられたバージョンを作成したのと同じように、Flutterの制約を与えられた、このフレームワークのフックのバージョンであるFlutterに固有のソリューションを作成することです。 私はReactのフックを定期的に使用していますが、アナライザープラグインを持っているだけでは不十分な場合があり、おそらく言語にもっと統合する必要があります。

いずれにせよ、コンセンサスが得られるとは思いません。 何が読めるかについても意見が合わないようです

念のため、これを共有しているのは、コミュニティにこの問題に関する問題があることを知っているからです。 私は個人的に、Flutterがこれについて何もしないかどうかを気にしません（私はこの種の悲しいと思いますが）：私たちが持っている限り：

• 適切なアナライザープラグインシステム
• ダートパッド内でパッケージを使用する機能

私が強くお勧めするフックプラグインを追求したいが、いくつかの問題が発生している場合は、それらの問題について問題を提出し、それらの問題を修正するためにPRを提出することをお勧めします。 喜んでご協力させていただきます。

これは、以前のPropertyアイデアの新しいバージョンです。 それはdidUpdateWidgetと破棄を処理します（そしてdidChangeDependenciesのような他のものを処理するように簡単に作ることができます）; ホットリロードをサポートしています（プロパティとホットリロードを登録するコードを変更でき、正しいことを実行します）。 明示的な型を必要とせずに型安全です（推論に依存します）。 プロパティの宣言と使用法を除いて、すべてが1つの場所にあり、パフォーマンスは適度に優れている必要があります（ただし、より冗長な方法ほど優れているわけではありません）。

プロパティ/プロパティマネージャー：

import 'package:flutter/foundation.dart';
import 'package:flutter/widgets.dart';

typedef InitStateCallback<T> = T Function(T oldValue);
typedef DidUpdateWidgetCallback<T, W extends StatefulWidget> = T Function(W oldWidget);

class Property<T, W extends StatefulWidget> {
  Property({
    T value,
    this.initState,
    this.didUpdateWidget,
    this.dispose,
  }) : _value = value;

  T get value {
    assert(_value != null);
    return _value;
  }
  T _value;

  final InitStateCallback<T> initState;
  void _initState(Property<T, W> oldProperty) {
    if (initState != null)
      _value = initState(oldProperty?.value);
    assert(_value != null);
  }

  final DidUpdateWidgetCallback<T, W> didUpdateWidget;
  void _didUpdateWidget(StatefulWidget oldWidget) {
    if (didUpdateWidget != null) {
      final T newValue = didUpdateWidget(oldWidget);
      if (newValue != null)
        _value = newValue;
    }
  }

  final ValueSetter<T> dispose;
  void _dispose() {
    if (dispose != null)
      dispose(value);
  }
}

mixin PropertyManager<W extends StatefulWidget> on State<W> {
  final Set<Property<Object, W>> _properties = <Property<Object, W>>{};
  bool _ready = false;

  Property<T, W> register<T>(Property<T, W> oldProperty, Property<T, W> property) {
    assert(_ready);
    if (oldProperty != null) {
      assert(_properties.contains(oldProperty));
      _properties.remove(oldProperty);
    }
    assert(property._value == null);
    property._initState(oldProperty);
    _properties.add(property);
    return property;
  }

  <strong i="9">@override</strong>
  void initState() {
    super.initState();
    _ready = true;
    initProperties();
  }

  <strong i="10">@override</strong>
  void reassemble() {
    super.reassemble();
    initProperties();
  }

  <strong i="11">@protected</strong>
  <strong i="12">@mustCallSuper</strong>
  void initProperties() { }

  <strong i="13">@override</strong>
  void didUpdateWidget(W oldWidget) {
    super.didUpdateWidget(oldWidget);
    for (Property<Object, W> property in _properties)
      property._didUpdateWidget(oldWidget);
  }

  <strong i="14">@override</strong>
  void dispose() {
    _ready = false;
    for (Property<Object, W> property in _properties)
      property._dispose();
    super.dispose();
  }
}

使用方法は次のとおりです。

import 'dart:async';

import 'package:flutter/foundation.dart';
import 'package:flutter/material.dart';

import 'properties.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  <strong i="18">@override</strong>
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Example(userId: 1),
    );
  }
}

class User {
  User(this.name);
  final String name;
}

Future<User> fetchUser(int userId) async {
  await Future.delayed(const Duration(seconds: 2));
  return User('user$userId');
}

class Example extends StatefulWidget {
  Example({ Key key, this.userId }): super(key: key);

  final int userId;

  <strong i="19">@override</strong>
  _ExampleState createState() => _ExampleState();
}

class _ExampleState extends State<Example> with PropertyManager {
  Property future;

  <strong i="20">@override</strong>
  void initProperties() {
    super.initProperties();
    future = register(future, Property(
      initState: (_) => fetchUser(widget.userId),
      didUpdateWidget: (oldWidget) {
        if (oldWidget.userId != widget.userId)
          return fetchUser(widget.userId);
      }
    ));
  }

  <strong i="21">@override</strong>
  Widget build(BuildContext context) {
    return FutureBuilder<User>(
      future: future.value,
      builder: (context, snapshot) {
        if (!snapshot.hasData) return Text('loading');
        return Text(snapshot.data.name);
      },
    );
  }
}

便宜上、AnimationControllersなどの準備されたPropertyサブクラスを作成できます。

おそらく、State.buildメソッドでも機能するバージョンを作成できます...

@Hixieがテーブルにもたらす疑問のいくつかを共有します。 一方で、フックには明らかな利点があり、かなりの数の開発者がそれを気に入っているようです。
@timsneathが提案したパッケージアプローチに関する私の問題は、フックを使用したコードが、フックを使用しないコードとは劇的に異なるように見えることです。 彼らが彼らを公式のカノンに入れないと、Flutterのカノンをたどっただけでは読めないFlutterコードになってしまいます。
パッケージがフレームワークの応答性であるはずのものを実装し始めると、新しいコードベースの学習を困難にするさまざまなFlutter方言が得られます。 だから私にとっては、Flutterの一部になった瞬間にフックを使い始めるでしょう。
これは、フリーズされたパッケージに関する私の現在の見方とよく似ています。 私はこの機能が大好きですが、UnionとデータクラスがDartの一部でない限り、コードベースに含めたくありません。コードが読みにくくなるからです。

@escamoteurわかりましたが、ウィジェットの動作を根本的に変えることを提案していますか？ それとも、特定の新しい能力があるべきだと提案していますか？ コアフレームワークを変更せずにフックや上記のプロパティ提案のようなことがどのように可能であるかを考えると、実際に何を変更したいかは私にはわかりません。

提案された変更自体についての会話とは直交していますが、 @ escamoteur 、 @ rrousselGitなどからここや他の場所で聞いたことは、フレームワークであることが特定の正当性を確立するための重要な方法として認識されていることだと思いますアプローチ。 同意しない場合は訂正してください。

私はその考え方を理解しています-フレームワークに含まれることから生じることがたくさんあるので（たとえば、DartPadは現在サードパーティのパッケージをサポートしていないため、一部の顧客はNPMで書き込まれた後に依存するパッケージの数に不安を感じています、それはより「公式」に感じます、それはnull-safetyのような変更で前進することが保証されています）。

ただし、含めるにはかなりのコストもかかります。特に、アプローチとAPIが必要になります。 そのため、特に全会一致の合意がない場合（状態管理を参照）、進化の可能性がある場合、またはパッケージと同じくらい簡単に何かを追加できる場合は、追加するものに対して非常に高い基準を保持します。

パッケージファーストの哲学を文書化する必要があるのではないかと思いますが、ここでも、状態ロジックの再利用を改善するために何を変更したいかについての議論とは別のものです。

パッケージポリシーはここに記載されています： https ：

私はパッケージファーストのアプローチを完全に理解しており、それが重要なことであることに同意します。
しかし、私はまた、いくつかの問題はパッケージではなくコアで解決する必要があると信じています。

そのため、 providerをFlutterにマージする必要があるとは主張していませんが、この問題は、Flutterがネイティブに解決する必要がある問題を説明していると考えています（もちろん、必ずしもフックを使用する必要はありません）。

プロバイダーとともに、Flutterはこの種の問題を解決するための組み込みプリミティブであるAttachedWidgetsを出荷します。
プロバイダーは、それを「より良い」ものにするために、上部に意見のあるレイヤーを追加するだけです。

フックが違います。 それらはプリミティブです。 これらは、特定の問題に対する非ピニオンの低レベルのソリューションです。複数の状態にわたってロジックを再利用します。
それらは最終製品ではありませんが、カスタムパッケージを構築するために人々が使用することが期待されているものです（私がhooks_riverpodで行ったように）

上で落書きしたプロパティアプローチがフックとどのように比較されるかについて誰かが詳細なレビューを提供できれば（ここでの欲求やフックが満たすニーズなどを理解するという点で）私にとって役立ちます。 （プロパティのアイデアに関する私の目標は、フレームワークの上に意見を重ねて、複数の状態でロジックを再利用する方法の問題を解決することです。）

プロパティの提案では、この問題の主要な目標を解決できないと思います。状態ロジックは、パラメーターがどこから来て、どのような状況で更新されているかを気にする必要はありません。

この提案は、すべてのロジックを1つの場所に再グループ化することにより、ある程度読みやすさを向上させます。 しかし、再利用性の問題を解決することはできません

具体的には、以下を抽出することはできません。

Property(
  initState: (_) => fetchUser(widget.userId),
  didUpdateWidget: (oldWidget) {
    if (oldWidget.userId != widget.userId)
      return fetchUser(widget.userId);
  }
)

ロジックはExampleとinitState + didUpdateWidgetバインドされているため、 _ExampleStateから取り出して別のウィジェットで再利用します

フックでどのように見えるでしょうか？

Rustコミュニティで似たようなものを見た後、 @ timsneathに同意します。 コアから何かを抽出するのは非常に困難です。BLoCパターンはプロバイダーが登場する前に指定されていましたが、現在はプロバイダーが推奨バージョンです。 おそらく、flutter_hooksは同じように「祝福された」バージョンである可能性があります。 将来、人々が思いついたフックに改善が見られるかもしれないので、私はこれを言います。 Reactは、今フックを持っていたので、実際にフックを変更したり、フックから抜け出したりすることはできません。 それらはコアにあるため、クラスコンポーネントと同じように、本質的に永久にサポートする必要があります。 したがって、私はパッケージ哲学に同意します。

問題は、採用が少なく、人々が自分に合ったものを使用することだと思われます。 これは、私が言うように、flutter_hooksの使用を推奨することで解決できます。 多くの人がプロバイダーを使用している場合でも、状態管理ソリューションがいくつあるかを同様に見れば、これは大きな問題ではないかもしれません。 また、構成可能で再利用可能なライフサイクルロジックの優れたソリューションを作成するために対処する必要のある、他のフレームワークでのいくつかの問題と「落とし穴」を経験しました。

フックでどのように見えるでしょうか？

React / flutter_hooksによって出荷されたプリミティブフックを使用せずに、次のことができます。

class FetchUser extends Hook<AsyncSnapshot<User>> {
  const FetchUser(this.userId);
  final int userId;

  <strong i="8">@override</strong>
  _FetchUserState createState() => _FetchUserState();
}

class _FetchUserState extends HookState<AsyncSnapshot<User>, FetchUser> {
  Future<User> userFuture;

  <strong i="9">@override</strong>
  void initHook() {
    userFuture = fetchUser(hook.userId);
  }  

  void didUpdateHook(FetchUser oldHook) {
    if (oldHook.userId != hook.userId)
      userFuture = fetchUser(hook.userId);
  }


  <strong i="10">@override</strong>
  User build() {
    return useFuture(userFuture);
  }
}

次に使用：

class Example extends HookWidget {
  const Example({Key key, this.userId}) : super(key: key);

  final int userId;

  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    AsyncSnapshot<User> user = use(FetchUser(userId));

    if (!user.hasData)
      return CircularProgressIndicator();
    return Text(user.data.name);
  }
}

この状況では、ロジックはExampleおよびStatefulWidgetのライフサイクルから完全に独立しています。
したがって、 userId異なる方法で管理する別のウィジェットで再利用できます。 たぶん、他のウィジェットは、そのuserId内部で管理するStatefulWidgetなるでしょう。 多分それは代わりにヘリケードウィジェットからuserIdを取得するでしょう。

この構文は、フックが独自のライフサイクルを持つ独立したStateオブジェクトのようなものであることを明確にする必要があります。

補足として、パッケージファーストアプローチの1つの欠点は、次のとおりです。パッケージの作成者は、問題を解決するためにフックに依存するパッケージを公開する可能性が低くなります。

たとえば、プロバイダーユーザーが直面する一般的な問題の1つは、プロバイダーが使用されなくなったときにプロバイダーの状態を自動的に破棄したいということです。
問題は、プロバイダーユーザーは、冗長なConsumer(builder: ...) / Selector(builder:...)構文とは対照的に、 context.watch / context.select構文も非常に気に入っていることです。
しかし、この素晴らしい構文とフックなしで前述の問題を解決することはできません（またはhttps://github.com/flutter/flutter/pull/33213、拒否されました）。

問題は：
プロバイダーは、この問題を解決するためにflutter_hooksに依存することはできません。
プロバイダーの人気が高いため、フックに依存するのは無理でしょう。

だから結局、私は以下を選びました：

• フォークプロバイダー（ Riverpodのコードネームで）
• 結果として「Flutterfavorite」/ Googleの推奨事項を自発的に失う
• この問題（およびその他）を解決する
• フックへの依存関係を追加して、 context.watchを楽しむ人々が望む構文を提供します。

私は、プロバイダーよりも大幅に改善されていると思うので、私が思いついたものに非常に満足しています（これにより、GeneratedWidgetsはコンパイルセーフになります）。
しかし、そこにたどり着く方法は私に悪い後味を残しました。

フックバージョンとプロパティバージョンの違いは、基本的に3つあります。

• フックバージョンはもっと多くのバッキングコードです
• プロパティバージョンは、より多くの定型コードです
• フックバージョンにはビルドメソッドに問題があり、フックを間違った順序で呼び出すと問題が発生し、コードからすぐにそれを確認する方法が実際にはありません。

ボイラープレートコードは本当に大したことですか？ つまり、プロパティを簡単に再利用できるようになり、コードがすべて1か所にまとめられました。 したがって、これは実際には冗長性の議論にすぎません。

良い解決策は、それを知っている他のパッケージに依存すべきではないと思います。 フレームワーク内にあるかどうかは関係ありません。 それを使わない人は問題にならないはずです。 それを使用していない人が問題である場合、それは、IMHOがAPIの危険信号です。

つまり、プロパティを簡単に再利用できるようになり、コードがすべて1か所にまとめられました。

コードが1つの場所にあるからといって、再利用できるわけではありません。
現在_ExampleState内にあるコードを別のウィジェットで再利用するセカンダリウィジェットを作成していただけませんか？
ひねりを加えて：その新しいウィジェットは、次のように、State内でuserIDを内部的に管理する必要があります。

class _WhateverState extends State with PropertyManager {
  // may change over time after some setState calls
  int userId;
}

それを使用していない人が問題である場合、それは、IMHOがAPIの危険信号です。

公式ではないために何かを使用していない人は、APIが悪いという意味ではありません。

これは維持するための余分な作業であるため（バージョン管理、ライセンス、減価償却などのため）、依存関係を追加したくないことは完全に正当です。
私が覚えていることから、Flutterには依存関係をできるだけ少なくする必要があります。

現在広く受け入れられ、ほぼ公式になっているプロバイダー自体でも、「依存関係の追加を避けるために、組み込みのわずかなウィジェットを使用することを好む」と言われるのを目にしました。

現在_ExampleState内にあるコードを別のウィジェットで再利用するセカンダリウィジェットを作成していただけませんか？

問題のコードは、ウィジェットからuserIdを取得し、それをfetchUserメソッドに渡すことに関するものです。 同じオブジェクト内でローカルに変更されるuserIdを管理するためのコードは異なります。 それは大丈夫のようですか？ ここでどのような問題を解決しようとしているのかよくわかりません。

記録のために、私はあなたが説明することをするためにプロパティを使用しません、それはちょうど次のようになります：

class Example extends StatefulWidget {
  Example({ Key key }): super(key: key);

  <strong i="10">@override</strong>
  _ExampleState createState() => _ExampleState();
}

class _ExampleState extends State<Example> with PropertyManager {
  int _userId;
  Future<User> _future;

  void _setUserId(int newId) {
    if (newId == _userId)
      return;
    setState(() {
      _future = fetchUser(_userId);
    });
  }

  // ...code that uses _setUserId...

  <strong i="11">@override</strong>
  Widget build(BuildContext context) {
    return FutureBuilder<User>(
      future: _future.value,
      builder: (context, snapshot) {
        if (!snapshot.hasData) return Text('loading');
        return Text(snapshot.data.name);
      },
    );
  }
}

公式ではないために何かを使用していない人は、APIが悪いという意味ではありません。

同意しました。

人々が悪いものを使用しないという事実は、APIが悪いことを意味します。 「パッケージの作成者は、問題を解決するためにフックに依存するパッケージを公開する可能性が低い」と言うとき、それはフックがあなたに役立つためにそれを使用している他の人々に依存していることを示します。 優れたAPIであるIMHOは、他の誰もそれを採用しなくても悪くなることはありません。 他の誰もそれについて知らなくても、それは持ちこたえるはずです。 たとえば、上記のProperty例は、それ自体が役立つ他のパッケージに依存していません。

現在広く受け入れられ、ほぼ公式になっているプロバイダー自体でも、「依存関係の追加を避けるために、組み込みのわずかなウィジェットを使用することを好む」と言われるのを目にしました。

AliExpressWidgetの使用を好む人の何が問題になっていますか？ 私は人々に解決策を強制したくありません。 彼らは彼らが使いたいものを使うべきです。 あなたは文字通り問題のないことを説明しています。 ヘリテージウィジェットの使用を好む人々への解決策は、邪魔にならないようにして、継承ウィジェットを使用できるようにすることです。

。 優れたAPIであるIMHOは、他の誰もそれを採用しなくても悪くなることはありません。 他の誰もそれについて知らなくても、それは持ちこたえるはずです。 たとえば、上記のプロパティの例は、それ自体が役立つためにそれを使用する他のパッケージに依存していません。

誤解があります。

問題は、一般的にフックを使用していない人々に関するものではありません。
フックは公式ではないのに対し、プロバイダーは公式ではないため、プロバイダーがフックを使用して問題を修正できないということです。

同じオブジェクト内でローカルに変更されるuserIdを管理するためのコードは異なります。 それは大丈夫のようですか？ ここでどのような問題を解決しようとしているのかよくわかりません。

記録のために、私はあなたが説明することをするためにプロパティを使用しません、それはちょうど次のようになります：

これは質問に答えません。 特に、フックとプロパティの間でコードの再利用性を比較するように依頼しました。

フックを使用すると、 FetchUser再利用できます。

class _WhateverState extends State with PropertyManager {
  // may change over time after some setState calls
  int userId;

  Widget build(context) {
    final user = use(FetchUser(userId));
  }
}

フックを使用すると、 FetchUser再利用できます。

なぜこれが望ましいのかわかりません。 FetchUserは興味深いコードはなく、フックからfetchUser関数へのアダプターにすぎません。 fetchUser直接電話してみませんか？ 再利用しているコードは興味深いコードではありません。

フックは公式ではないのに対し、プロバイダーは公式ではないため、プロバイダーがフックを使用して問題を修正できないということです。

IMHOは、コードの再利用の問題に対する優れたソリューションをプロバイダーが採用する必要はまったくありません。 それらは完全に直交する概念になります。 これは、Flutterスタイルガイドが「複雑化を避ける」という見出しの下で話していることです。

なぜこれが望ましいのかわかりません。 FetchUserには興味深いコードはありません。これは、フックからfetchUser関数への単なるアダプターです。 fetchUserを直接呼び出さないのはなぜですか？ 再利用しているコードは興味深いコードではありません。

それは問題ではありません。 コードの再利用性を実証しようとしています。 fetchUserは、たとえばChangeNotifier.addListenerなど、何でもかまいません。

fetchUserに依存せず、暗黙的なデータフェッチを行うためのAPIを提供するだけの代替実装を作成できます。

int userId;

Widget build(context) {
  AsyncSnapshot<User> user = use(ImplicitFetcher<User>(userId, fetch: () => fetchUser(userId));
}

IMHOは、コードの再利用の問題に対する優れたソリューションをプロバイダーが採用する必要はまったくありません。 それらは完全に直交する概念になります。 これは、Flutterスタイルガイドが「複雑化を避ける」という見出しの下で話していることです。

だから私はフックが原始的だと言ったのです

比喩として：
package:animationsはAnimation依存します。 しかし、これはコアプリミティブであるため、これは問題ではありません。
代わりにpackage:animationsがコミュニティによって維持されているAnimationフォークを使用していた場合は別の問題になります

@escamoteurわかりましたが、ウィジェットの動作を根本的に変えることを提案していますか？ それとも、特定の新しい能力があるべきだと提案していますか？ コアフレームワークを変更せずにフックや上記のプロパティ提案のようなことがどのように可能であるかを考えると、実際に何を変更したいかは私にはわかりません。

@Hixie私のポイントは、フックがさらに人気になった場合、Flutterコードがどのように見え、どのように動作するかを共通に理解できるように、フックをフレームワークに含めてすべての人に教えることを
私はあなたの懸念を非常に共有しますが、反対側ではフック付きのウィジェットは本当にエレガントに見えます。
以前のように物事を行うことを禁止することはありません。

以前のように物事を行うことを禁止することはありません。

Flutterチームが「フラッターフックをお勧めしますが、以前と同じようにできる」と言うのは良い考えではないと思います。人々はこれについて混乱するでしょう。 また、Flutterチームが将来フックを推奨する場合は、例として実際のFlutterコードの公開を停止する必要もあります。

人々は常に物事を行う「公式の方法」に従います、そして私はそこにフラッターを使用する2つの公式の方法があるべきではないと思います。

それは問題ではありません。 コードの再利用性を実証しようとしています。 fetchUserは、たとえばChangeNotifier.addListenerなど、何でもかまいません。

もちろん。 それが関数が適していることです。コードを抽象化することです。 しかし、私たちはすでに機能を持っています。 上記のプロパティコードと上記の_setUserIdコードは、フレームワークからの特別な支援を必要とせずに、これらの関数を呼び出すすべてのコードを1か所にまとめることができることを示しています。 これらの関数への呼び出しをラップするためにフックが必要なのはなぜですか？

IMHOは、コードの再利用の問題に対する優れたソリューションをプロバイダーが採用する必要はまったくありません。 それらは完全に直交する概念になります。 これは、Flutterスタイルガイドが「複雑化を避ける」という見出しの下で話していることです。

だから私はフックが原始的だと言ったのです

それらは便利であり、原始的ではありません。 それらが原始的である場合、「問題は何ですか」という質問に答えるのははるかに簡単です。 あなたは「これが私がやりたいことであり、私はそれをすることができない」と言うでしょう。

比喩として：
package:animationsはAnimation依存します。 しかし、これはコアプリミティブであるため、これは問題ではありません。
代わりにpackage:animationsがコミュニティによって維持されているAnimationフォークを使用していた場合は別の問題になります

Animationクラス階層は、基本的なことを行います。それは、ティッカーと、それらを制御してサブスクライブする方法を導入します。 Animationクラス階層がない場合、アニメーションを実行するには、Animationクラス階層のようなものを発明する必要があります。 （理想的にはもっと良いものです。それは私たちの最高の仕事ではありません。）フックは新しい基本的な機能を導入していません。 同じコードを別の方法で記述する方法を提供するだけです。 そのコードは単純であるか、そうでない場合とは異なる因数分解されている可能性がありますが、それはプリミティブではありません。 フックを使用するコードと同じことを行うコードを作成するために、フックのようなフレームワークは必要ありません。

基本的に、この問題で説明されている問題は、フレームワークで修正する必要があるものではないと思います。 それに対処する方法については、人によってニーズが大きく異なります。 これを修正する方法はたくさんあります。このバグではすでにいくつか説明しました。 いくつかの方法は非常に単純で、数分で記述できるため、解決がそれほど難しい問題ではなく、ソリューションを所有および維持するための価値があります。 それぞれの提案には長所と短所があります。 弱点は、いずれの場合も、誰かがそれらを使用するのを妨げるものです。 問題を修正する必要があることに誰もが同意していることすらはっきりしていません。

フック_are_プリミティブ
これはダンからのスレッドです： https ：

より具体的には、 flutter_hooksを動的な状態ミックスインと考えることができます。

それらが原始的である場合、「問題は何ですか」という質問に答えるのははるかに簡単です。 あなたは「これが私がやりたいことであり、私はそれをすることができない」と言うでしょう。

それはOPにあります：

状態ロジックを再利用することは困難です。 最終的に複雑で深くネストされたビルドメソッドになるか、複数のウィジェット間でロジックをコピーして貼り付ける必要があります。
ミックスインや関数を介してそのようなロジックを再利用することはできません。

そのコードは単純であるか、そうでない場合とは異なる因数分解されている可能性がありますが、それはプリミティブではありません。 フックを使用するコードと同じことを行うコードを作成するために、フックのようなフレームワークは必要ありません。

プログラムを書くのにクラスは必要ありません。 ただし、クラスを使用すると、コードを構造化し、意味のある方法で因数分解することができます。
そして、クラスはプリミティブです。

プリミティブでもあるミックスインでも同じです

フックも同じです。

これらの関数への呼び出しをラップするためにフックが必要なのはなぜですか？

このロジックを_one_の場所ではなく、_two_の場所で呼び出す必要がある場合に備えて。

ミックスインや関数を介してそのようなロジックを再利用することはできません。

具体的な例を教えてください。 これまでのところ、私たちが研究したすべての例は、フックのない単純なものです。

これまでのところ、このスレッドでは、状態ロジックを解決して再利用および構成するのを容易にする@rrousselGitフック以外の解決策を見たことがありません。

確かに、私は最近ダーツやフラッターをあまり行っていないので、上記のプロパティソリューションコードサンプルに何かが欠けている可能性がありますが、解決策はありますか？ 再利用の代わりにコピーペーストを必要としない今日のオプションは何ですか？
@rrousselGitの質問に対する答えは何ですか：

現在_ExampleState内にあるコードを別のウィジェットで再利用するセカンダリウィジェットを作成していただけませんか？
ひねりを加えて：その新しいウィジェットは、その状態の内部でそのユーザーIDを管理する必要があります

上記のプロパティソリューションでこのような簡単な状態ロジックを再利用できない場合、他のオプションは何ですか？
答えは、フラッターで簡単に再利用できるようにするべきではないということですか？ これはまったく問題ありませんが、少し悲しい私見です。

ところで、SwiftUIは新しい/他の刺激的な方法でそれを行いますか？ それとも、同じ状態ロジックの再利用性が欠けているのでしょうか。 私自身はswiftuiをまったく使用していません。 多分それはあまりにも異なっていますか？

基本的にすべてのビルダー。 現時点では、ビルダーが状態を再利用する唯一の方法です。
フックにより、ビルダーは読みやすく、作成しやすくなります

これは、私または一部のクライアントが先月さまざまなプロジェクトのために作成したカスタムフックのコレクションです。

• useQuery –これは前に与えたImplicitFetcherフックと同等ですが、代わりにGraphQLクエリを作成します。
• useOnResumeは、 AppLifecycleState.resumedに対してカスタムアクションを実行するためのコールバックを提供します。
  WidgetsBindingObserverを作成する際の問題に移動します
• useDebouncedListenerは、リスナブル（通常はTextFieldまたはScrollController）をリッスンしますが、リスナーでデバウンスします
• useAppLinkServiceこれにより、ウィジェットはAppLifecycleState.resumedと同様のカスタムイベントでいくつかのロジックを実行できますが、ビジネスルールがあります
• useShrinkUIForKeyboardは、キーボードの外観をスムーズに処理します。 UIが下部のパディングに適応する必要があるかどうかを示すブール値を返します（これはfocusNodeのリッスンに基づいています）
• useFilter 、 useDebouncedListenerとuseState （単一のプロパティを宣言するプリミティブフック）を組み合わせて、検索バーのフィルターを公開します。
• useImplicitlyAnimated<Int/Double/Color/...> –フックとしてのTweenAnimationBuilder相当

アプリはまた、さまざまなロジックに多くの低レベルのフックを使用します。

たとえば、次の代わりに：

Whatever whatever;

initState() {
  whatever = doSomething(widget.id);
}

didUpdateWidget(oldWidget) {
  if (oldWidget.id != widget.id)
    whatever = doSomething(widget.id);
}

彼らはします：

Widget build(context) {
  final whatever = useUnaryEvent<Whatever, int>(widget.id, (int id) => doSomething(id));
}

これにより、 initState / didUpdateWidget / didChangeDependencies間の重複が回避されます。

また、 RiverpodのuseProvider大量に使用します。そうでない場合は、 StreamBuilder / ValueListenableBuilder

重要なのは、ウィジェットが「1つのフック」を使用することはめったにないということです。
たとえば、ウィジェットは

class ChatScreen extends HookWidget {
  const ChatScreen({Key key}) : super(key: key);

  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    final filter = useFilter(debounceDuration: const Duration(seconds: 2));
    final userId = useProvider(authProvider).userId;
    final chatId = useProvider(selectedChatProvider);
    final chat = useQuery(ChatQuery(userId: userId, chatId: chatId, filter: filter.value));

    return Column(
      children: [
        Searchbar(onChanged: (value) => filter.value = value),
        Expanded(
          child: ChatList(chat: chat),
        ),
      ],
    );
  }
}

簡潔で非常に読みやすいです（もちろん、APIの基本的な知識があることを前提としています）。
すべてのロジックは上から下に読み取ることができます。コードを理解するためにメソッド間をジャンプする必要はありません。
そして、ここで使用されるすべてのフックは、コードベースの複数の場所で再利用されます

フックなしでまったく同じことを行うとしたら、次のようになります。

class ChatScreen extends StatefulWidget {
  const ChatScreen({Key key}) : super(key: key);

  <strong i="20">@override</strong>
  _ChatScreenState createState() => _ChatScreenState();
}

class _ChatScreenState extends State<ChatScreen> {
  String filter;
  Timer timer;

  <strong i="21">@override</strong>
  void dispose() {
    timer?.cancel();
    super.dispose();
  }

  <strong i="22">@override</strong>
  Widget build(BuildContext context) {
    return Consumer<Auth>(
      provider: authProvider,
      builder: (context, auth, child) {
        return Consumer<int>(
          provider: selectedChatProvider,
          builder: (context, chatId, child) {
            return GraphQLBuilder<Chat>(
              query: ChatQuery(
                userId: auth.userId,
                chatId: chatId,
                filter: filter.value,
              ),
              builder: (context, chat, child) {
                return Column(
                  children: [
                    Searchbar(
                      onChanged: (value) {
                        timer?.cancel();
                        timer = Timer(const Duration(seconds: 2), () {
                          filter = value;
                        });
                      },
                    ),
                    Expanded(
                      child: ChatList(chat: chat),
                    ),
                  ],
                );
              },
            );
          },
        );
      },
    );
  }
}

これはかなり読みにくくなります。

• 10レベルのインデントがあります–フィルターロジックを再利用するためにFilterBuilderを作成すると12レベルになります
• フィルタロジックは、現状では再利用できません。
  
  
  
  • 誤ってtimerをキャンセルするのを忘れる可能性があります
  
  
• buildメソッドの半分は読者には役に立ちません。 ビルダーは重要なことから私たちの気をそらします
• 括弧がないためにコードがコンパイルされない理由を理解しようとして、5分を失いました

私自身flutter_hooksユーザーとして、私は自分の意見を投稿します。 フックを使用する前は、Flutterに満足していました。 私はそのようなものの必要性を見ませんでした。 それについて読んで、それについてのユーチューブビデオを見た後、私はまだ確信していませんでした、それはクールに見えました、しかし私はそれを本当に動機づけるためにいくつかの練習または例が必要でした。 しかし、それから私は何かに気づきました。 私はステートフルなウィジェットを絶対に避けていました。ボイラープレートがたくさん含まれていて、クラスをスキップして物事を見つけようとしていました。 そのため、一時的な状態のほとんどを、アプリの残りの状態とともに状態管理ソリューションに移行し、ステートレスウィジェットを使用していました。 ただし、これにより、 Navigator 、またはInheritedWidget s / ProvidersにアクセスするためのBuildContext取得に依存するため、ビジネスロジックはFlutterにすばやく依存します。木。 それが良い状態管理アプローチであるとは言わないが、そうではなかったことを私は知っている。 しかし、UIの状態管理について心配する必要がないように、できることは何でもしました。

しばらくの間フックを使用した後、私は自分自身がはるかに生産的で、Flutterを使用してはるかに幸せであり、アプリの状態ではなく、一時的な状態を（UIとともに）適切な場所に配置しました。

私にとって、それは一時的な状態/コントローラーのガベージコレクターのようなものです。 UIですべてのサブスクリプションを破棄することを覚えておく必要はありませんが、これがflutter_hooksが私のために行うことであるという事実をまだ非常に意識しています。 また、コードの保守とリファクタリングが非常に簡単になります。 私の大学院の研究と楽しみのために、過去1年間に最大10個のアプリを書いたことから話しています。

他の人と同じように、FlutterSDK自体にそれを含めることの主な動機は正確にはわかりません。 しかし、ここにその主題に関する2つの考えがあります。

1. ときどき、初期化/破棄する必要のあるコントローラーを含むパッケージを使いやすくするためにフックを作成します。 （たとえば、 golden_layout 、またはzefyr ）。 flutter_hooksを使用している他のユーザーは、このようなパッケージの恩恵を受けると思います。 ただし、文字通り1〜3個の関数を含むパッケージを公開することを正当化することはできないようです。 別の方法は、私が使用するさまざまなパッケージのフックをたくさん含むキッチンシンクパッケージを作成することです。その後、git依存関係を使用できますが、それらの他のパッケージ+ flutter_hooksを使用する人は誰でも私のgitに依存する必要があります。利益を得るために（これは発見されにくく、気にしないパッケージへの依存関係が含まれている可能性があります）、または3つの関数を含むパッケージに依存するか、ガーデンシンクパッケージをpub.devに公開します。 すべてのアイデアはばかげているようで、あまり発見できません。 flutter_hooksの他のユーザーは、これらの関数を簡単にコピーしてコードに貼り付けたり、ロジック自体を理解しようとしたりできますが、コード/パッケージを共有するという点を完全に見逃しています。 関数は、一部の「拡張パッケージ」ではなく、元のパッケージに入れる方がはるかに優れています。 flutter_hooksがフレームワークの一部である場合、またはcharactersようにフレームワークから使用またはエクスポートされたパッケージでさえある場合、元のパッケージの作成者は単純なフックのプルリクエストを受け入れる可能性がはるかに高くなります。関数であり、1〜3個の関数パッケージが混乱することはありません。
   flutter_hooksがFlutterに採用されていない場合、pub.devの検索結果が1〜3個の関数パッケージで乱雑になると予想されます。 これらのパッケージが非常に小さいという事実は、これがプリミティブであるという@rrousselGitに本当に同意します。 flutter_hooksリポジトリの1228の星が、 @ rrousselGitによって言及された問題を解決していることを示していない場合、私は何であるかわかりません。

2. Flutterリポジトリへの貢献についてのYouTubeビデオを見ていたのは、私が何ができるかを知りたいと思っていたからです。 私が見ていると、新しいプロパティに追加されたビデオを作成する人はかなり簡単ですが、 dispose 、 didUpdateWidget 、およびdebugFillPropertiesの更新の面倒を見るのをほとんど忘れていました。 ステートフルウィジェットのすべての複雑さをもう一度見て、何かを見逃しやすいことで、私は再びそれらを信用できなくなり、メインのFlutterリポジトリに貢献することにそれほど興奮しなくなりました。 それが完全に私を思いとどまらせたとは言えませんが、私はまだ貢献することに興味がありますが、維持とレビューが難しい定型コードを作成するように感じます。 それは、コードを書くことの複雑さではなく、コードを読んで、あなたが適切に処分し、一時的な状態を処理したことを確認することの複雑さです。

長い間対応して申し訳ありませんでしたが、私は時々この問題を検討しており、Flutterチームからの回答に多少戸惑っています。 両方の方法でアプリを試してみて、違いを自分で確認するのに時間がかかっていないようです。 追加の依存関係を維持したり、フレームワークに過度に統合したりしたくないという願望を理解しています。 ただし、 flutter_hookフレームワークのコア部分は、十分に文書化された500行のコードのみです。 繰り返しになりますが、これが会話に正接している場合は申し訳ありません。2セントを与えて発言したことで誰かを怒らせないことを願っています。 @rrousselGitが非常に良い点を示しており、明確であると感じたので、私は以前に発言しませんでした。

長い間対応して申し訳ありませんでしたが、私は時々この問題を検討しており、Flutterチームからの回答に多少戸惑っています。 両方の方法でアプリを試してみて、違いを自分で確認するのに時間がかかっていないようです。

公平を期すために、これは信じられないほど長いスレッドであり、フレームワークの創設者は、いくつかの解決策で毎日数回積極的に貢献し、それらに関するフィードバックを要求し、それらに関与し、要求されているものを理解するために取り組んできました。 私は正直に言って、メンテナが役立つというより明確な例を考えるのに苦労しています。

これがこの問題についてもう少し忍耐強くなればいいのですが、このスレッドを読んだ後のフックは、使い捨ての寿命を州に結び付ける別の方法である以外は、これ以上深く理解していません。 私はそのアプローチをスタイル的に好まないので、その位置が「パラダイムでまったく新しいアプリを書くのに時間をかけるだけで、フレームワークに組み込まれる必要がある理由を理解できるのであれば、根本的に欠陥があると感じます！ ' -このスレッドでReactエンジニアが指摘したように、Flutterには実際にはお勧めできません。また、このスレッドで説明されている利点は、再配線の種類のコストと比較して小さいため、利点を確認するにはまったく新しいコードベースが必要です。

私は正直に言って、メンテナが役立つというより明確な例を考えるのに苦労しています。

同意しました。 ヒックソンがこの議論に参加するために時間を割いてくれたことに感謝します。

このスレッドを読んだ後、フックがもう深く理解できません

公平を期すために、この問題はフックについて具体的に話すことを明確に避けようとしています。
これは、解決策ではなく、問題を説明しようとすることに関するものです

あなたはそれが失敗したと思いますか？

私はここで両方（ @rrousselGitと@Hixie）を感じることができ、Flutterフレームワークの（私の）使用面/観点からいくつかのフィードバックを残したいと思いました。

flutter_hooksアプローチは、ボイラープレートを大幅に削減し（このような状態構成を再利用できるため、ここに示す例から）、リソースの初期化/破棄について積極的に考える必要がないため、複雑さが軽減されます。 一般的に言えば、Flutter自体の「コア」に（主観的に）うまく適合していなくても、開発フロー/速度を改善およびサポートするのに適しています。

私が書いたコードの少なくとも95％を超えると、buildメソッドは宣言型のみになり、返されたウィジェットサブツリーの外部にローカル変数や呼び出しはありません。すべてのロジック部分は、リソースを初期化、割り当て、破棄し、追加するための状態関数の内部にあります。リスナー（私の場合はMobXの反応）とそのような論理的なもの。 これはFlutter自体の大部分のアプローチでもあるため、非常にネイティブな感じがします。 そうすることで、開発者は常に明示的で、あなたがしていることについてオープンになる機会が得られます-そのようなウィジェットを常にStatefulWidgetに変換し、initState / disposeで同様のコードを書くことを強制しますが、それはまた常に、使用されているウィジェットで直接実行しようとしていることを正確に書き留めることになります。 個人的には、 @ Hixieがすでに述べたように、この種の定型コードを書くことはまったく気にならず、開発者として、 flutter_hooksようなものに頼るのではなく、それを正しく処理する方法を決定できます。 flutter_hooksを使用すると、フックとして記述して再利用する価値のある状態の種類について考える必要があります。フレーバーが異なると、さまざまな「使い捨て」フックが発生するか、フックがまったくなくなる可能性があります。構成を頻繁に再利用することはありませんが、より多くのカスタム構成を作成する傾向があります。

誤解しないでください。このようなフックでのアプローチは非常に素晴らしく便利に思えますが、私にとっては、これを処理する方法のコアコンセプトを変更する非常に基本的なコンセプトのように感じます。 開発者が「ネイティブに」それを行う方法に満足していない場合にこの種のアプローチを使用する機会を開発者に与えることは、パッケージ自体として非常に良いと感じますが、それをFlutterフレームワーク自体の一部にすることは、少なくともクリーンである必要があります/統一された結果、Flutterの大部分を書き直してこの概念を利用するか（多くの作業）、将来の/選択されたものに使用します（このような混合アプローチでは混乱する可能性があります）。

それがFlutterフレームワーク自体に統合され、サポートされている/積極的に使用されている場合、私は明らかにこれに飛びつきます。 私は現在のアプローチを理解し、気に入っており、これをネイティブに実装するために必要な（可能な）アクションを確認しているので、ためらいや実行すべきでない理由を理解し、パッケージとして保持することができます。

私が間違っている場合は訂正してください。ただし、このスレッドは、複数のウィジェットで状態ロジックを読みやすく構成可能な方法で再利用する問題に関するものです。 特にフックしません。 このスレッドは、解決策がどうあるべきかについてのオープンなアプローチで問題について議論したいという理由で開かれたと思います。

フックは1つの解決策であるため言及されていますが、 @ rrousselGitはここで

そうは言っても、現時点ではスレッドがどこに向かっているのかわかりません。
問題は本当に存在すると思います。 それとも私たちはこれについて議論していますか？
今日、フラッターのコアを持つ複数のウィジェットで状態ロジックを構成可能な方法で再利用するのが難しいことに全員が同意している場合、コアソリューションとなる可能性のあるソリューションはありますか？ ビルダーは本当に（引用するために）

かなり読みにくい

プロパティソリューションはそれほど簡単に再利用できないようです。または、次の目的で使用する方法についての回答がなかったため、間違った結論を導き出しました（？）。

別のウィジェットの_ExampleState内に現在配置されているコードを再利用するセカンダリウィジェットを作成しますか？
ひねりを加えて：その新しいウィジェットは、その状態の内部でそのユーザーIDを管理する必要があります

@timsneathが提案したように、

現時点では、デザインドキュメントを作成するというアイデアにはかなり懐疑的です。
今のところ、 @ HixieがFlutter内でこの問題を直接解決することに反対していることは明らかです。

私には、問題の重要性とその問題を解決する上でのGoogleの役割について意見が分かれているように見えます。
双方がこれに同意しない場合、解決策が何であれ、この問題に取り組む方法について生産的な議論を行う方法がわかりません。

この号のスレッドは非常に興味深い読み物であり、意見交換が市民的なものであり続けていることを嬉しく思います。 しかし、私は現在の行き詰まりに少し驚いています。

フックに関しては、Flutterは@rrousselGitによって提示された特定のフックソリューションを必ずしも必要としないが、彼はそう言っていないというのが私の見解です。 Flutterには、Remiや他の支持者が言及しているすべての理由から、フックと同様の利点を提供するソリューションが必要です。 @ emanuel-lundmanは上記の議論を要約しており、私は彼の見解に同意します。

同じ機能を提供する他の実行可能な提案がなく、フックがReactで十分に証明された実績を持っているという事実と、Flutterのベースとなる可能性のある既存のソリューションがあることを考えると、そうなるとは思いません。そうするのは悪い選択です。 Flutter SDK（またはそれ以下）にも含まれているプリミティブとしてのフックの概念が、Flutterから何かを奪うことはないと思います。 私の意見では、それはそれを豊かにし、Flutterで保守可能で楽しいアプリを開発することをさらに簡単にするだけです。

フックはその恩恵を享受したい人のためのパッケージとして利用可能であるという議論は有効なポイントですが、フックのようなプリミティブには最適ではないと感じています。 これが理由です。

内部で再利用可能なパッケージを作成する場合でも、Dart + Flutter SDKにのみ依存するという意味で、パッケージを「純粋」にする必要があるかどうか、または他のパッケージを許可するかどうかについて議論することがよくあります。もの。 プロバイダーでさえ「純粋な」パッケージを求めていますが、多くの場合、より高いレベルのパッケージを求めています。 アプリの場合、どのパッケージが問題ないか、どのパッケージが問題ないかという同じ議論が常にあります。 プロバイダーは緑色ですが、フックのようなものはまだパッケージとして疑問符です。

ソリューションのようなフックがSDKの一部である場合、それが提供する機能を使用することは明らかな選択です。 フックを使用して、パッケージとしてすでに許可したいのですが、それがFlutterコードスタイルを作成し、それを使用していないFlutter開発者にはなじみのない概念を導入することも懸念しています。 SDKでサポートされていない状態でこのパスをたどると、道路の分岐点のように感じます。 小規模な個人プロジェクトの場合、フックを使用するのは簡単な選択です。 Riverpodと一緒に試すことをお勧めします。

（私たちのパッケージの保守性は、過去にパッケージによって焼き付けられたり、他のパッケージマネージャーに依存したりすることから来ていると思いますが、おそらく一意ではありません。）

これまでに実証された唯一の解決策であっても、フックが現在の問題を解決する唯一の方法であると言っているわけではありません。 ソリューションにコミットする前に、より一般的なレベルでオプションを調査することは、確かに興味深く、有効なアプローチである可能性があります。 そのためには、Flutter SDKが_現在、簡単に再利用可能な状態ロジックに関して欠陥がある_という認識が必要です。これは、詳細な説明にもかかわらず、現在はそうではないようです。

私にとって、フックをコアフレームワークに入れるだけではない主な理由は2つあります。 1つ目は、APIに危険なトラップが含まれていることです。 主に、どういうわけか間違った順序でフックを呼び出すことになった場合、物事は壊れます。 これは私には致命的な問題のように思えます。 私は、規律とドキュメントに従うことでそれを回避できることを理解していますが、私見では、このコード再利用の問題に対する優れた解決策にはその欠陥はありません。

2つ目は、この問題を解決するためにフック（または別のライブラリ）を使用できない理由は実際にはないはずです。 さて、人々が議論したように、フックを使用すると、特にそれは機能しません。フックを書くことは、無関係のライブラリがフックをサポートすることを人々が望むほど負担が大きいからです。 しかし、私はこの問題の良い解決策はそれを必要としないだろうと思います。 優れたソリューションはスタンドアロンであり、他のすべてのライブラリがそれについて知る必要はありません。

最近、RestorablePropertiesをフレームワークに追加しました。 それらがここで何らかの形で活用できるかどうかを確認するのは興味深いでしょう...

アナライザーまたはリンターが解決する必要がある隠れた問題があるAPIについて@Hixieに同意します。 私たちは、参加したい人と同じように、再利用可能なライフサイクル管理の問題について、おそらく設計ドキュメントの提案を通じて、またはその他の方法で、さまざまな解決策を検討する必要があると思います。 理想的には、Flutter固有であり、Flutter APIを活用しながら、フックAPIが行う問題も解決します。 Vueバージョンは、フックの呼び出し順序に依存しないため、前述したように、最初から始めるのに適したモデルだと思います。 他に私と一緒に調査することに興味がある人はいますか？

@Hixieですが、ウィジェット間で構成可能な方法で状態ロジックを再利用する良い方法がないという問題に同意しますか？ だから、どういうわけかResuablePropertiesを活用することを考え始めたのですか？

私にとって、フックをコアフレームワークに入れるだけではない主な理由は2つあります。 1つ目は、APIに危険なトラップが含まれていることです。 主に、どういうわけか間違った順序でフックを呼び出すことになった場合、物事は壊れます。 これは私には致命的な問題のように思えます。 私は、規律とドキュメントに従うことでそれを回避できることを理解していますが、私見では、このコード再利用の問題に対する優れた解決策にはその欠陥はありません。

フックを使ったり、フックを使っている他の人と一緒に働いたりしたことから、これは私見ではそれほど大きな問題ではありません。 そして、彼らがテーブルにもたらすすべての大きな利益（開発速度、再利用性、構成可能性、および読みやすいコードの大きな利益）とはまったく比較されません。
フックは、クラスが単なる関数ではなくクラスであるようにフックであり、条件付きで使用することはできません。 あなたはそれを速く学びます。 また、編集者はこの問題についても支援できます。

2つ目は、この問題を解決するためにフック（または別のライブラリ）を使用できない理由は実際にはないはずです。 さて、人々が議論したように、フックを使用すると、特にそれは機能しません。フックを書くことは、無関係のライブラリがフックをサポートすることを人々が望むほど負担が大きいからです。 しかし、私はこの問題の良い解決策はそれを必要としないだろうと思います。 優れたソリューションはスタンドアロンであり、他のすべてのライブラリがそれについて知る必要はありません。

フックを書くのは面倒ではありません。
現在利用可能なソリューションよりもまだ簡単です（そのフレーズをもう一度使用する😉）。
多分私はあなたが書いているものを誤解しています。 しかし、私は誰もそれを言ったとは思わないのですか？
私は、フックソリューションがテーブルにもたらすすべての利点を人々が本当に感謝し、どこでもそれを使用できることを望んでいるようにそれを読みました。 すべてのメリットを享受する。 フックは再利用可能であるため、サードパーティの開発者が、全員が独自のラッパーを作成しなくても、自信を持って独自のフックをコーディングして出荷できれば素晴らしいと思います。 状態ロジックの再利用性のメリットを享受します。
@rrousselGitと@gaearonはすでに原始的なことを説明していると思います。 だから私はそれには入りません。
たぶん、このスレッドで人々が書いたものの良い要約であることがわからないので、私はこの声明を受け取らないでしょう。 ごめんなさい。

前進する方法があることを願っています。 しかし、少なくともこれが問題であることに同意し、フックがテーブルにさえないように見えるので、より良い代替ソリューションを考え出す時が来たと思います。
または、フラッターコアの問題の修正をスキップすることを決定します。

誰が前進するかを決めるのですか？
次のステップは何ですか？

これは私には致命的な問題のように思えます。 私は、規律とドキュメントに従うことでそれを回避できることを理解していますが、私見では、このコード再利用の問題に対する優れた解決策にはその欠陥はありません。

Reactでは、これをリンター（静的分析）で解決します。 私たちの経験では、この欠陥は大規模なコードベースでも重要ではありませんでした。 欠陥と見なされる可能性のある問題は他にもありますが、永続的な呼び出し順序への依存は人々が直感的に問題になると考えるものですが、実際にはバランスがかなり異なることを指摘したいと思います。

私がこのコメントを書いている本当の理由は、Flutterがコンパイルされた言語を使用しているからです。 「リンティング」はオプションではありません。 したがって、ホスト言語とUIフレームワークの間に整合性がある場合、「条件付き」問題が静的に発生しないように強制することは間違いなく可能です。 ただし、これは、UIフレームワークが言語の変更を動機付けることができる場合にのみ機能します（例：Compose + Kotlin）。

@Hixieですが、ウィジェット間で構成可能な方法で状態ロジックを再利用する良い方法がないという問題に同意しますか？ だから、どういうわけかResuablePropertiesを活用することを考え始めたのですか？

それは確かに人々が育ててきたものです。 それは私が内臓の経験を持っているものではありません。 Flutterを使って自分のアプリを書くときに問題だと感じたものではありません。 しかし、それは一部の人々にとってそれが本当の問題ではないという意味ではありません。

フックは再利用可能であるため、サードパーティの開発者が、全員が独自のラッパーを作成しなくても、自信を持って独自のフックをコーディングして出荷できれば素晴らしいと思います。

私のポイントは、ここでの優れたソリューションでは、ラッパーを作成する必要がないということです。

次のステップは何ですか？

次のステップはたくさんあります。例：

• ここで説明していないFlutterに特定の問題がある場合は、問題を報告して問題を説明してください。
• この問題の問題をフックよりも優れた方法で解決する方法について良いアイデアがある場合は、そうするパッケージを作成してください。
• フックを改善するためにできることがある場合は、そうしてください。
• フックが最大限の可能性を発揮できないような問題がFlutterにある場合は、それらを新しい問題として提出してください。
  NS。

この号のスレッドは非常に興味深い読み物であり、意見交換が市民的なものであり続けていることを嬉しく思います。

その時、私は非市民の糸がどのように見えるかを見たくありません。 このスレッドには共感がほとんどないので、傍観者から読んだりフォローしたりするのは困難でした

私のポイントは、ここでの優れたソリューションでは、ラッパーを作成する必要がないということです。

ただし、ラッパーを作成する必要はありません。 しかし、慣れ親しんだ独自のコードで、メリットと再利用性を享受したい場合があります。 確かに、ライブラリをそのまま使用することはできます。 フックラッピングを書く場合（可能であれば）、それはおそらく負担だと思っているからではなく、他の方法よりも優れているということです。

これは実際には正当な理由であり、このスレッドの問題の解決策がコアで優れている理由が述べられています。 コア内の再利用可能な構成可能な状態ロジックソリューションは、依存関係を追加せずにすべてのパッケージで安全に出荷できるため、ラッパーを作成する必要がないことを意味します。

コア内の再利用可能な構成可能な状態ロジックソリューションは、依存関係を追加せずにすべてのパッケージで安全に出荷できるため、ラッパーを作成する必要がないことを意味します。

私が言いたいのは、IMHOの優れたソリューションでは、そのロジックを作成するために_誰も_を必要としないということです。 再利用する冗長なロジックはありません。 たとえば、前の「fetchUser」の例を見ると、「fetchUser」関数を呼び出すためにフックまたはそれに相当するものを作成する必要はなく、「fetchUser」関数を直接呼び出すだけです。 同様に、「fetchUser」はフック（または私たちが使用するもの）について何も知る必要はなく、フック（または私たちが使用するもの）は「fetchUser」について何も知る必要はありません。 フックの場合のように、書くロジックを簡単に保ちながらすべて。

現在の制限は、フックが言語制限に加えてパッチであるという事実によって引き起こされています。

一部の言語では、フックは次のような言語構造です。

state count = 0;

return RaisedButton(
  onPressed: () => count++,
  child: Text('clicked $count times'),
)

これは、非同期/ sync関数の変形であり、呼び出し全体でいくつかの状態を保持できます。

言語の一部として、各変数をタイプではなく行番号で区別できるため、無条件で使用する必要がなくなりました。

フックの制限は--track-widget-creationの制限に似ていることを付け加えておきます。

このフラグは、ウィジェットのconstコンストラクターの正規化を解除します。 しかし、ウィジェットは宣言型であるため、これは問題ではありません。

その意味で、フックは同じです。 制限は宣言的に操作されるため、実際には重要ではありません。
他のフックを読まないと、1つの非常に具体的なフックを取得することはできません。

たぶん、fetchuserの例は理想的な例ではありません。
ただし、useStream、useAnimstion、またはuseStreamCintrollerを使用すると、ウィジェットツリーがよりクリーンになり、破棄を忘れたり、dudChangeDependencuesを処理したりするのを防ぐことができます。
したがって、現在の方法には、巻き込まれる可能性のあるトラップがあります。したがって、呼び出しシーケンスの潜在的な問題は、それらほど大きな問題ではないと思います。
自分でフックを書き始めるかどうかはわかりませんが、フレームワーク内で使用できるように、頻繁に必要となるコレクションを用意しておくと便利です。
それはそれらに対処するための代替方法にすぎません。

@Hixie 、あなたが説明しようとしていることを理解できなくて本当に申し訳ありません、私はここで夜遅くだと非難しますが、おそらくそれは私だけです😳..しかし、あなたが説明する良い解決策では、州の価値はどこにありますか？問題の解決策が簡単に構成可能でウィジェット間で共有できるようにラップ/カプセル化する状態のビジネスロジックとライフタイムイベントロジックが存在しますか？ 良い解決策が何をするのか、そしてそれが理想的にどのように機能するのかについて少し詳しく説明していただけますか？

この議論の礼儀正しさについての言及があるのを見て、ここで少し介入するだけです。 私は個人的に、ここの誰もが非市民的であるとは感じていません。

とはいえ、これはあらゆる面で人々が深く関心を持っているトピックであることは注目に値すると思います。

• @rrousselGitは、StackOverflowおよびpackage:provider課題追跡システムでの状態管理に関する初心者の質問に何年も回答してきました。 私はこれらの消防ホースの後者だけをフォローしており、レミの勤勉さと忍耐を尊重しているだけです。
• Flutterチームの@Hixieとその他のメンバーは、FlutterのAPI、その安定性、表面性、保守性、および読みやすさに深く
• Flutter開発者は、状態管理に深く関心を持っています。これは、状態管理が開発時間のかなりの部分を行っているためです。

この議論のすべての当事者が、彼らが何をしているのかについて議論する正当な理由があることは明らかです。 メッセージを伝えるのに時間がかかることも理解できます。

ですから、ここか他の形で議論が続けられれば幸いです。 正式なドキュメントのように、なんらかの形でサポートできる場合は、お知らせください。

一方、ここでの議論が手に負えなくなっていると人々が考える場合は、一時停止して、より良いコミュニケーション方法があるかどうかを確認しましょう。

（これとは別に、このディスカッションに参加してくれた@gaearonに一言お願いします。この点でのReactの経験は非常に貴重です。）

@ emanuel-lundman

しかし、あなたが説明する優れたソリューションでは、問題のソリューションが簡単に構成可能でウィジェット間で共有できるようにラップ/カプセル化する状態値、状態ビジネスロジック、およびライフタイムイベントロジックはどこにありますか？ 良い解決策が何をするのか、そしてそれが理想的にどのように機能するのかについて少し詳しく説明していただけますか？

残念ながら、わからないので詳しく説明できません。 :-)

@escamoteur

たぶん、fetchuserの例は理想的な例ではありません。
ただし、useStream、useAnimstion、またはuseStreamCintrollerを使用すると、ウィジェットツリーがよりクリーンになり、破棄を忘れたり、dudChangeDependencuesを処理したりするのを防ぐことができます。

この問題の難しさの1つは、問題が記述されている「ゴールポストの移動」でした。その後、問題が分析されると、問題は実際の問題ではないとして却下され、新しい問題が記述されます。 本当に役立つかもしれないのは、いくつかの標準的な例を考え出すことです。たとえば、問題の実際の例を含むデモFlutterアプリケーションは、説明のために過度に単純化されていません。 次に、フックやその他の提案を使用してそれを再実装し、具体的に相互に評価することができます。 （問題が何であるかを正確に理解していない場合を除いて、私は自分でこれを行います。したがって、フックを支持する誰かがそれを行うのがおそらく最善です。）

本当に役立つかもしれないのは、いくつかの標準的な例を考え出すことです。たとえば、問題の実際の例を含むデモFlutterアプリケーションであり、説明のために過度に単純化されていないものです。

私がここで挙げた例についてどう思いますか？ https://github.com/flutter/flutter/issues/51752#issuecomment -669626522

これは実際のコードスニペットです。

それは素晴らしいスタートになると思います。 フックを使用しないバージョンと使用するバージョンで、スタンドアロンアプリとして実行できる状態にすることはできますか？

申し訳ありませんが、私はアプリではなく、コードスニペットを意味していました。

「デモフラッターアプリケーション」のアイデアの問題の1つは、このスレッドで作成された例が非常に現実的であるということだと思います。
それらは単純化されすぎていません。
デバウンス、イベントハンドラー、サブスクリプション、暗黙的な副作用などのマイクロ状態を因数分解する場合のフックの主な使用例–これらを組み合わせてより有用なロジックを実現します。

https://marvel.riverpod.dev/#/などのRiverpodに関するいくつかの例があります。ここで、ソースコードは次のとおりです。https ：
しかし、それはこれまでに言及されたものとそれほど変わらないでしょう。

@Hixie

なぜこれが問題なのか理解するのに本当に苦労しています。 Flutterアプリケーションをたくさん書いたのですが、それほど問題にはならないようです。 最悪の場合でも、プロパティを宣言し、初期化し、破棄し、デバッグデータに報告するのは4行です（通常、初期化したのと同じ行で宣言できるため、通常は少なくなります。アプリは一般的にデバッグプロパティに状態を追加することを心配する必要はありません。これらのオブジェクトの多くには、破棄する必要のある状態がありません）。

私は同じ船に乗っています。
確かに、ここで説明されている問題もよくわかりません。 再利用可能である必要がある、人々が参照する「状態ロジック」が何であるかさえ理解していません。

ステートフルフォームウィジェットがたくさんあり、その中には数十のフォームフィールドがあるものもあり、テキストコントローラーとフォーカスノードを自分で管理する必要があります。 ステートレスウィジェットのライフサイクルメソッドでそれらを作成して破棄します。 非常に面倒ですが、同じ量のコントローラー/ focusNodeを使用するウィジェットや同じユースケースを使用するウィジェットはありません。 それらの間の唯一の共通点は、ステートフルであり、フォームであるという一般的な概念です。 パターンだからといって、コードが繰り返されるわけではありません。
つまり、コードの多くの部分で配列をループする必要があり、アプリの繰り返しコード全体で「for（varthing inthings）」を実行することはありません。

ライフサイクルAPIのシンプルさから生まれるStatefulWidgetのパワーが大好きです。 これにより、1つのことを実行し、アプリの他の部分から分離して実行するStatefulWidgetsを作成できます。 ウィジェットの「状態」は常にプライベートであるため、ウィジェットの再利用は問題ではなく、コードの再利用も問題ではありません。

ここで取り上げた例にはいくつか問題がありますが、それはあなたの主張とある程度一致しています。

• まったく同じ「状態ロジック」で複数のステートフルウィジェットを作成することは、まったく間違っているように思われ、ウィジェットを自己完結型にするという考えに反します。 しかし、繰り返しになりますが、私は人々が一般的な「状態論理」によって何を意味するのかについて混乱しています。
• フックは、プレーンダーツと基本的なプログラミングの概念（関数など）を使用して、私がまだ実行できないことを何も実行していないようです。
• 問題は、特定のプログラミングスタイル、つまり「再利用可能なグローバル状態」を支持しているように見えるスタイルに関連しているか、または引き起こされているようです。
• 数行のコードを抽象化すると、「時期尚早のコード最適化」の臭いがし、フレームワークとはほとんど関係のない問題や、人々の使用方法に関係するすべての問題を解決するために複雑さが増します。

これはかなり読みにくくなります。

• 10レベルのインデントがあります–フィルターロジックを再利用するためにFilterBuilderを作成すると12レベルになります

• フィルタロジックは、現状では再利用できません。

  • 誤ってtimerをキャンセルするのを忘れる可能性があります
• buildメソッドの半分は読者には役に立ちません。 ビルダーは重要なことから私たちの気をそらします
• 括弧がないためにコードがコンパイルされない理由を理解しようとして、5分を失いました

あなたの例は、FlutterのStatelessWidgetとStateライフサイクルAPIの実際の問題ではなく、プロバイダーがどれほど冗長であり、すべてにAliExpressWidgetsを悪用することが悪いことである理由のショーケースです。

@rrousselGitはっきりしなかったらごめんなさい。 私が上で行った提案は、現実的で、説明している問題を示すバニラFlutterアプリケーション（StatefulWidgetなどを使用）を作成することでした。これにより、実際の完全なアプリケーションに基づいて提案を行うことができます。 ここで説明した「fetchUser」の例などの具体的な例は、常に「このようなケースを処理でき、単純でフックを必要としない」という方針で議論されてきました。 「まあ、それは単純化されすぎています。現実の世界ではフックが必要です」。 つまり、私のポイントは、フックが本当に必要な実世界の例を作成しましょう。これは、過度に単純化されておらず、コードの再利用の難しさを示しています。これにより、新しいコードを使用せずにこれらの問題を回避できるかどうかを確認できます。 、または新しいコードが必要な場合、そして後者の場合、フックのような形にする必要があるかどうか、またはさらに良い解決策を見つけることができるかどうか。

再利用可能である必要がある、人々が参照する「状態ロジック」が何であるかさえ理解していません。

けっこうだ
状態ロジックと並行するのは、UIロジックと、ウィジェットがテーブルにもたらすものです。

ウィジェットレイヤーを技術的に削除することができます。 その場合、残っているのはRenderObjectsです。

たとえば、ミニマリストカウンターを作成できます。

var counter = 0;

final counterLabel = RenderParagraph(
  TextSpan(text: '$counter'),
  textDirection: TextDirection.ltr,
);

final button = RenderPointerListener(
  onPointerUp: (_) {
    counter++;
    counterLabel.text = TextSpan(text: '$counter');
  },
  child: counterLabel,
);

それは必ずしも複雑ではありません。 しかし、それはエラーが発生しやすいです。 counterLabelレンダリングに重複があります

ウィジェットを使用すると、次のことができます。

class _CounterState exends State {
  int counter = 0;

  Widget build(context ) {
    return GestureDetector(
      onTap: () => setState(() => counter++);
      child: Text('$counter'),
    );
  }
}

これが行った唯一のことは、宣言型にすることによってTextロジックを因数分解することです。
ミニマリストの変更です。 しかし、大規模なコードベースでは、これは大幅な簡素化です。

フックはまったく同じことをします。
ただし、 Text代わりに、状態ロジックのカスタムフックを取得します。 これには、リスナー、デバウンス、HTTPリクエストの作成などが含まれます。

あなたの例は、FlutterのStatelessWidgetとStateライフサイクルAPIの実際の問題ではなく、プロバイダーがどれほど冗長であり、すべてにAliExpressWidgetsを悪用することが悪いことである理由のショーケースです。

これはプロバイダーとは関係ありません（このコードは結局プロバイダーを使用しません）。
どちらかといえば、プロバイダーはcontext.watch代わりにConsumer context.watch持っているので、より良いです。

標準的な解決策は、 ConsumerをValueListenableBuilderに置き換えることです。これにより、まったく同じ問題が発生します。

@Hixieに同意します。フラッターだけの場合とフックを使用した場合の有効性を判断するには、2つ並べて比較する必要があると思います。 これは、フックが優れているかどうかを他の人に納得させるのにも役立ちます。バニラアプリがこの3番目のソリューションで構築されている場合は、別のソリューションがさらに優れている可能性があります。 このバニラアプリのコンセプトはしばらく前から存在しており、

@satvikpendem
喜んでお手伝いさせていただきます。
flutter_hooksリポジトリのサンプルアプリは、おそらくいくつかの異なるフックと、それらが簡単にするもの/それらが解決する問題を示していると思います。これは良い出発点になるでしょう。

また、この号で紹介されているいくつかの例とアプローチも使用できると思います。

更新：コードはこちら、 https：//github.com/TimWhiting/local_widget_state_approaches
リポジトリの適切な名前がわからないので、それが私たちが解決しようとしている問題であると思い込まないでください。 ステートフルとフックで基本的なカウンターアプリを作成しました。 今夜はあまり時間がありませんが、問題の可能性をより具体的に示すユースケースをさらに追加しようと思います。 貢献したい方は、アクセスをリクエストしてください。

ここで説明した「fetchUser」の例などの具体的な例は、常に「このようなケースを処理でき、単純でフックを必要としない」という方針で議論されてきました。 「まあ、それは単純化されすぎています。現実の世界ではフックが必要です」。

同意しません。 私はそのような「あなたはこのようなケースを扱うことができる」を見たことがないと思い、結果のコードがフックバリアントよりも優れていることに同意しました。

ずっと私のポイントは、私たちが別の方法で物事を行うことはできますが、結果として得られるコードはエラーが発生しやすく、および/または読みにくくなるということでした。
これはfetchUserも当てはまります

フックはまったく同じことをします。
ただし、 Text代わりに、状態ロジックのカスタムフックを取得します。 これには、リスナー、デバウンス、HTTPリクエストの作成などが含まれます。

いいえ、この一般的な状態ロジックがどうあるべきかはまだわかりません。 つまり、「initState / didUpdateDependency」メソッドでデータベースから読み取るウィジェットがたくさんありますが、まったく同じクエリを実行する2つのウィジェットが見つからないため、「ロジック」は同じではありません。

HTTPリクエストの作成例を使用します。 一部のウィジェットが使用する必要のある「makeHTTPRequest（url、paramters）」がサービスクラスのどこかにあるとすると、必要なときにメソッドを直接呼び出すのではなく、フックを使用するのはなぜですか？ この場合、フックの使用はプレーンメソッド呼び出しとどのように異なりますか？

リスナー。 同じことを聞いているウィジェットはありません。 私の各ウィジェットは、必要なものをすべてサブスクライブし、サブスクライブを解除する責任があります。 フックはほとんどの場合構文糖衣構文である可能性がありますが、私のウィジェットはオブジェクトの同じ組み合わせをリッスンしないため、フックは何らかの方法で「パラメーター化」する必要があります。 繰り返しますが、フックは昔ながらの関数とどう違うのですか？

これはプロバイダーとは関係ありません（このコードは結局プロバイダーを使用しません）。
どちらかといえば、プロバイダーはcontext.watch代わりにConsumer context.watch持っているので、より良いです。

は？ 「ChatScreen」HookWidgetが解決することになっていることに対する反例は次のとおりです。

<strong i="19">@override</strong>
  Widget build(BuildContext context) {
    return Consumer<Auth>(
      provider: authProvider,
      builder: (context, auth, child) {
        return Consumer<int>(
          provider: selectedChatProvider,
          builder: (context, chatId, child) {

これはプロバイダーとどのように関係がありませんか？ よくわかりません。 私はプロバイダーの専門家ではありませんが、これは間違いなくプロバイダーを使用したコードのようです。

この問題は複雑な国家に関するものではないという事実を主張したいと思います。
これは、コードベース全体に適用できる小さな増分です。

ここに示した例の値に同意できない場合、StatefulWidgetで実行できないフックで実行できることは何もないため、アプリケーションは会話に何ももたらしません。

代わりに、 ImplicitFetcherようなマイクロスニペットを並べて比較し、測定可能なメトリックを使用してどのコードが優れているかを_客観的に_判断し、さまざまな小さなスニペットに対してそれを行うことをお勧めします。

これはプロバイダーとどのように関係がありませんか？ よくわかりません。 私はプロバイダーの専門家ではありませんが、これは間違いなくプロバイダーを使用したコードのようです。

このコードはプロバイダーからのものではなく、AttachedWidgetsを使用しない別のプロジェクトからのものです。
プロバイダーのConsumerはproviderパラメーターがありません。

そして、私が述べたように、 Consumer -> ValueListenableBuilder / StreamBuilder / BlockBuilder / Observer / ..を置き換えることができます。

「initState / didUpdateDependency」メソッドにありますが、まったく同じクエリを実行する2つのウィジェットが見つからないため、「ロジック」は同じではありません。

再利用したい状態ロジックは、「クエリを作成する」ではなく、「xが変更されたときに何かを実行する」です。 「何かをする」は変わるかもしれませんが、「xが変わるとき」は一般的です

具体例：
ウィジェットが受け取るIDが変更されるたびに、ウィジェットがHTTPリクエストを行うようにしたい場合があります。
また、 package:asyncのCancelableOperationを使用して、保留中のリクエストをキャンセルしたいと思います。

これで、まったく同じことを実行したいが、HTTPリクエストが異なる2つのウィジェットがあります。
最後に、次のようになります。

CancelableOperation<User> pendingUserRequest;

initState() {
  pendingUserRequest = fetchUser(widget.userId);
}

didUpdateWidget(oldWidget) {
  if (widget.userId != oldWidget.userId) {
      pendingUserRequest.cancel();
      pendingUserRequest = fetchUser(widget.userId);
  }
}

dispose() {
  pendingUserRequest.cancel();
}

VS：

CancelableOperation<Message> pendingMessageRequest;

initState() {
  pendingMessageRequest = fetchMessage(widget.messageId);
}

didUpdateWidget(oldWidget) {
  if (widget.userId != oldWidget.messageId) {
      pendingMessageRequest.cancel();
      pendingMessageRequest = fetchMessage(widget.messageId);
      message = pendingMessageRequest.value;
  }
}

dispose() {
  pendingMessageRequest.cancel();
}

唯一の違いは、 fetchUserをfetchMessageです。 それ以外のロジックは100％同じです。 ただし、再利用できないため、エラーが発生しやすくなります。

フックを使用すると、これをuseUnaryCancelableOperationフックに分解できます。

つまり、同じ2つのウィジェットを使用すると、代わりに次のようになります。

Widget build(context) {
  Future<User> user = useUnaryCancelableOperation(userId, fetchUser);
}

VS

Widget build(context) {
  Future<Message> message = useUnaryCancelableOperation(messageId, fetchMessage);
}

このシナリオでは、リクエストの作成とキャンセルに関連するすべてのロジックが共有されます。 fetchUserとfetchMessageという意味のある違いだけが残っています。
このuseUnaryCancelableOperationからパッケージを作成することもでき、今では誰もが自分のアプリでそれを再利用できます。

ここに示した例の値に同意できない場合、StatefulWidgetで実行できないフックで実行できることは何もないため、アプリケーションは会話に何ももたらしません。

それが本当なら、私たちはこのバグを閉じるべきだと思います。なぜなら、ここで与えられた例についてはすでに議論していて、それらは説得力がないからです。 しかし、私は本当に状況をよりよく理解したいと思います。このバグの以前のコメントから、利点はアプリケーションレベルにあるように聞こえたので、アプリケーションの例を検討することをお勧めします。

唯一の違いは、 fetchUserをfetchMessageです。 それ以外のロジックは100％同じです。 ただし、再利用できないため、エラーが発生しやすくなります。

エラーが発生しやすいものと、再利用できるものは何ですか？ 抽象化とクラス階層のまったく新しいレイヤーを実装することで、クラスに3つのメソッドを実装する必要がなくなり、やり過ぎになります。

繰り返しますが、何かが一般的なパターンであるからといって、それに対して新しい機能を作成する必要があるという意味ではありません。 さらに、この場合に繰り返し発生するコードを減らしたい場合は、StatefulWidget *クラスを拡張し、initstate / didUpdateWidgetメソッドを共通ビットでオーバーライドできます。

フックを使用すると、これをuseUnaryCancelableOperationフックに分解できます。

つまり、同じ2つのウィジェットを使用すると、代わりに次のようになります。

Widget build(context) {
  Future<User> user = useUnaryCancelableOperation(userId, fetchUser);
}

VS

Widget build(context) {
  Future<Message> message = useUnaryCancelableOperation(messageId, fetchMessage);
}

このシナリオでは、リクエストの作成とキャンセルに関連するすべてのロジックが共有されます。 fetchUserとfetchMessageという意味のある違いだけが残っています。
このuseUnaryCancelableOperationからパッケージを作成することもでき、今では誰もが自分のアプリでそれを再利用できます。

申し訳ありませんが、それは私からは間違いなく大したことではありません。 わずかなコード冗長性しか節約できないという事実を除けば、概念的に「initState」および「update」ライフサイクルメソッドに属するコードをビルドメソッドに「ファクタリング」することは大したことではありません。

私のビルドメソッドは、レイアウトのみをビルドし、他には何もビルドしないことを期待しています。 依存関係の設定と破棄は、buildメソッドには絶対に属していません。同じタイプのコードを明示的に書き直して、将来の自分や他の人にウィジェットの動作を明示的にする必要があることを非常に嬉しく思います。 そして、buildメソッドにすべてを貼り付けないようにしましょう。

それが本当なら、私たちはこのバグを閉じるべきだと思います

@Hixieしないでください。 人々はこの問題を気にします。 私は同じことについてredditであなたと話しましたが、SwiftUIのコンテキストで： https ：

それはフックではなく、ステートフルウィジェットを何らかの形で改善することです。 人々は単に定型文を書くことを嫌います。 ビューのセマンティクスをRAIIおよびコピーすることに慣れているSwiftUIコードを作成する開発者にとって、ディスポーザブルを手動で管理することは、まったく問題のように思われます。

だから私はフラッターチームに少なくともこれを問題と見なし、代替の解決策/改善について考えることをお勧めします。

私のビルドメソッドは、レイアウトのみをビルドし、他には何もビルドしないことを期待しています。 依存関係の設定と破棄は、ビルドメソッドに含まれていません。
それが重要なポイントです。 ビルドメソッドは純粋である必要があります。 それでも私は私たちが困難なしで利点を得ることができればいいのにと思いました

私はここでもっと多くの例を推し進めることを本当に理解していません。 それはその顔に明らかです。

フックによって解決される問題は単純明快であり、コードをDRYに保ちます。 これの利点は、明らかなもの、コードの減少==バグの減少、メンテナンスの容易さ、バグを隠す場所の減少、全体的な行数の減少、読みやすさの向上、ジュニアプログラマーの断熱性の向上などです。

実際のユースケースについて話している場合、これは、12の異なるビューで12のアニメーターコントローラーを毎回セットアップおよび破棄し、dispose（）呼び出しを見逃したり、一部をオーバーライドしたりするアプリです。他のライフサイクル方法。 次に、それを他の数十のステートフルインスタンスに適用すると、数百または数千の無意味なコード行を簡単に確認できます。

Flutterは、小さなオブジェクトの状態を絶えず繰り返し、設定し、破棄する必要があるこれらのケースでいっぱいです。これにより、存在する必要のないバグのあらゆる種類の機会が生まれますが、現在、このロートセットアップ/ティアダウン/同期ロジックを共有します。

この問題は、セットアップとティアダウンのフェーズがある、または常に結び付ける必要のあるライフサイクルフックがある、文字通り_any_状態で確認できます。

私自身、ウィジェットを使用するのが最善のアプローチだと思います。たとえば、セットアップ/ティアダウンが非常に煩わしく、冗長でバグが発生しやすいため、AnimatorControllerを使用することはめったにありません。代わりに、可能な限りTweenAnimationBuilderを使用します。 ただし、このアプローチには、特定のビューでステートフルオブジェクトの数が増えると制限があり、実際には何も必要とされない場所にネストと冗長性が強制されます。

@szotp私はしていません...解決策を評価できるように、問題を示す1つ以上のベースラインアプリを確立したいと思います。 私は自分でやろうと思っていますが、私たちが何を解決しようとしているのか正確にはわからないので、私はそれをするのは間違った人です。

@escamoteurベースラインアプリは、問題のないソリューションを設計するのに役立ちます。

@esDotDevこれまでこのバグでこのようなケースについて説明してきましたが、フック以外のソリューションは、ソリューションが対処した例に含まれていない問題を解決しないため、毎回却下されます。 したがって、問題の簡単な説明では、完全な範囲を把握するのに十分ではないようです。 たとえば、「12個のアニメーターコントローラー」の場合は、アニメーションコントローラーの配列とDartの機能機能によって解決できる可能性があります。 TweenAnimationBuilderは別の解決策かもしれません。 それらのどちらもフックを含みません。 しかし、私が提案した場合、誰かが私が見逃したことを指摘し、「それは...のために機能しない」と言って、その（例の文脈では新しい）問題を提起すると確信しています。 したがって、私たち全員が同意するベースラインアプリの必要性は、問題の完全な広がりをカバーします。

誰かがこれを前進させたいのなら、私はそれを行うための最良の方法は私が上で説明したものだと本当に思います（https://github.com/flutter/flutter/issues/51752#issuecomment-670249755とhttps://github.com / flutter / flutter / issues / 51752＃issuecomment-670232842）。 それは私たち全員が解決しようとしている問題の範囲を表すことに同意できる出発点を私たちに与えるでしょう。 そして、私たちはソリューションを設計することができ、そのアドレスのアドレスすべての欲望（例えば@rrousselGitの再利用のための必要性、@Rudiksz「クリーンビルド方法についての必要性、など）、そして、最も重要なのは我々がこれらのソリューションを評価できるという方法でこれらの問題ベースラインアプリのコンテキスト。

私たちは皆、彼の問題にかなり簡単に同意できると思います。
_Streams、AnimatorControllersなどに関連するセットアップ/ティアダウンタスクを共有するエレガントな方法はありません。これにより、不要な冗長性、バグの可能性、読みやすさの低下につながります。_

誰かがそれに同意しませんか？ そこから始めて、解決策を探して前進することはできませんか？ それが最初に中心的な問題であることに同意する必要がありますが、まだそうではないようです。

私がそれを書いているとき、私は問題の名前と完全に一致していることに気づきました。それは自由形式であり、議論の余地があります。
「状態ロジックの再利用は、冗長すぎるか、難しすぎる」

私にとって、それは非常に明白な問題であり、私たちはすぐに討論の段階を過ぎて、何がうまくいくかについてブレインストーミングに移るべきです。 再利用可能なマイクロステートが必要です...何かを理解できると確信しています。 それは本当に一日の終わりに多くのFlutterビューをクリーンアップし、それらをより堅牢にするでしょう。

@Hixieしないでください。 人々はこの問題を気にします。 私は同じことについてredditであなたと話しましたが、SwiftUIのコンテキストで： https ：

SwiftUIの例は、StatefulWidgetクラスを拡張するだけで、数行のコードでdartに複製できます。

通知機能をサブスクライブしたり、外部呼び出しを行ったりしないStatefulWidgetsがありますが、実際、それらのほとんどはそのようなものです。 私は約100個のカスタムウィジェットを持っています（すべてがステートフルというわけではありませんが）。おそらく15個は、ここの例で説明されているように、あらゆる種類の「共通状態ロジック」を持っています。

長期的には、不必要なオーバーヘッドを回避するために、数行のコード（ボイラープレートとも呼ばれます）を記述することは小さなトレードオフです。 繰り返しになりますが、initState / didUpdateメソッドを実装する必要があるというこの問題は、かなり誇張されているようです。 ここで説明するパターンのいずれかを使用するウィジェットを作成する場合、ライフサイクルメソッドの「実装」に最初の5〜10分を費やし、次にライフサイクルメソッドに触れずにウィジェット自体を実際に作成して磨くのに数日を費やします。 いわゆるボイラープレートのセットアップ/分解コードの記述に費やす時間は、私のアプリコードと比較してごくわずかです。

私が言ったように、StatefulWidgetsが何のために使用されるかについてほとんど仮定をしないという事実は、それらを非常に強力で効率的にするものです。

この特定のユースケースのためにStatefulWidgetをサブクラス化する（またはしない）新しいタイプのウィジェットをFlutterに追加することは問題ありませんが、StatefulWidget自体にベイクしないでください。 「フック」システムやマイクロステートに伴うオーバーヘッドを必要としないウィジェットがたくさんあります。

@esDotDev私はそれが一部の人々が直面している問題であることに同意します。 私はこの号の前半でいくつかの解決策を提案しました（GitHubがすべてのコメントを表示することを好まないため、 Propertyクラスのさまざまなバージョンを検索してください。 難しいのは、これらの提案が特定の問題を解決しなかったために却下されたことです（たとえば、ある場合にはホットリロードを処理せず、別の場合にはdidUpdateWidgetを処理しませんでした）。 それで私はさらに提案をしました、しかしそれからそれらは他の何かを処理しなかったので再び却下されました（私は何を忘れていますか）。 そのため、問題の解決策を見つけることができるように、問題全体を表すことに同意するある種のベースラインを用意することが重要です。

目標は変わっていません。 提案された解決策には柔軟性が欠けているという批判があります。 それらのどれも、それらが実装されたスニペットの外で動作し続けません。

これが、この号のタイトルが「難しい」と言及している理由です。現在、問題を解決する方法に柔軟性がないためです。

それを見る別の方法は次のとおりです。

この問題は基本的に、状態ロジック用にウィジェットレイヤーを実装する必要があると主張しています。
提案された解決策は「しかし、RenderObjectsでそれを行うことができます」です。

_長期的には、数行のコード（ボイラープレートとも呼ばれます）を書くことは、不必要なオーバーヘッドを回避するための小さなトレードオフです。_

この声明とのカップルのニット：

1. 実際には数行ではありません。角かっこ、行間隔@overidesなどをacctに入れると、単純なアニメーターコントローラーの10〜15行以上を見ることができます。 それは私の心の中で自明ではありません...自明を超えた方法のように。 これを行うための3行は私を悩ませます（UnityではThing.DOTween() ）。 15はばかげています。

1. それは苦痛ですが、それはタイピングについてではありません。 それは50ラインクラスを持つことの愚かさについてです、そこでそれの30ラインは腐った定型文です。 その難読化。 ボイラープレートを_しない_場合、警告などはなく、バグを追加しただけであるという事実についてです。
2. フックのようなものと話し合う価値のあるオーバーヘッドは見当たりません。 オブジェクトの配列について話しているのですが、それぞれに少数のfxnsがあります。 ダートでは、非常に高速です。 これは赤ニシンのイモです。

@esDotDev

私にとって、それは非常に明白な問題であり、私たちはすぐに討論の段階を過ぎて、何がうまくいくかについてブレインストーミングに移るべきです。

ウィジェットの拡張。 ValueNotifierがChangeNotifierを拡張して一般的な使用パターンを単純化する方法と同様に、誰もが特定のユースケースに合わせて独自のStatelessWidgetsを作成できます。

はい、私はそれが効果的なアプローチであることに同意しますが、それは望ましいものを残します。 アニメーターが1人いる場合は、TweenAnimationBuilderを使用できます。 かっこいい、それはまだ5行のコードのようなものですが、何でもです。 それは動作します...それほど悪くはありません。 しかし、私が2つまたは3つ持っている場合はどうなりますか？ 今、私は地獄に入れ子になっています。何らかの理由でcplの他のステートフルオブジェクトがある場合、それはすべてちょっとインデントの混乱になるか、セットアップ、更新、分解のランダムなコレクションをカプセル化する非常に特殊なウィジェットを作成しています論理。

ウィジェットの拡張。 ValueNotifierがChangeNotifierを拡張して一般的な使用パターンを単純化する方法と同様に、誰もが特定のユースケースに合わせて独自のStatelessWidgetsを作成できます。

一度に拡張できる基本クラスは1つだけです。 それはスケーリングしません

ミックスインは次の論理的な試みです。 しかし、OPが言及しているように、それらもスケーリングしません。

@esDotDev

または、セットアップ、更新、およびティアダウンロジックのランダムなコレクションをカプセル化する非常に特殊なウィジェットを作成しています。

3〜4種類のAnimationControllerを設定する必要がある種類のウィジェットは、非常に特殊なユースケースのように聞こえます。設定/分解ロジックのランダムな収集をサポートすることは、フレームワークの一部であってはなりません。 実際、initState / didUpdateWidgetメソッドが最初に公開されているのはそのためです。そのため、思いのままにセットアップをランダムに収集できます。

私の最長のinitStateメソッドは5行のコードであり、ウィジェットは過度のネストに悩まされることはないので、私たちは間違いなくさまざまなニーズとユースケースを持っています。 または別の開発スタイル。

@esDotDev

3.フックのようなものと話し合う価値のあるオーバーヘッドは見当たりません。 オブジェクトの配列について話しているのですが、それぞれに少数のfxnsがあります。 ダートでは、非常に高速です。 これは赤ニシンのイモです。

提案された解決策がflutter_hooksパッケージのようなものである場合、それはまったく真実ではありません。 はい、概念的には関数を含む配列ですが、実装は簡単でも効率的でもありません。

つまり、私は間違っているかもしれませんが、HookElementは、独自のビルドメソッドで自分自身を再構築する必要があるかどうかをチェックしているようです。
また、すべてのウィジェットビルドでフックを初期化、再初期化、または破棄する必要があるかどうかを確認することは、かなりのオーバーヘッドのように思われます。 気分が悪いので、間違っているといいのですが。

比較のためのベースアプリとして@brianeganのアーキテクチャの例の1つを取ることは理にかなっていますか？

ここで介入するかもしれませんが、これがすでに言われたかどうかはわかりません。 しかし、Reactでは、フックを使用したライフサイクルについてはあまり考えていません。コンポーネント/ウィジェットの構築に慣れていると怖いように聞こえるかもしれませんが、ライフサイクルがそれほど重要ではない理由はここにあります。

ほとんどの場合、小道具に基づいて実行する状態またはアクションを使用してコンポーネント/ウィジェットを構築している場合、その状態/小道具が変更されたときに何かが発生する必要があります（たとえば、このスレッドで説明したように、再実行する必要があります-userIdプロパティが変更されたときにユーザーの詳細をフェッチします）。 通常、ウィジェットのすべての小道具が変更されたときに発生するものではなく、userIdの変更の「効果」と考える方がはるかに自然です。

クリーンアップについても同じですが、通常、「すべてのプロップ/状態が変更されたときにXをクリーンアップすることを忘れないでください。コンポーネント全体が破壊されたとき」。

私はしばらくFlutterを書いていなかったので、このアプローチが現在のFlutterの考え方に与える現在の気候や制限を知っているように聞こえようとはしていません。私は、さまざまな意見を受け入れています。 私の考え方がライフサイクルパラダイムに深く根付いていたので、Reactフックに精通していない多くの人々が私が彼らに紹介されたときと同じ混乱を抱えていると思います。

@escamoteur @Rudiksz @Hixie私たちはこれらの例を作成し始めているところに招待されたことを@TimWhitingによって作成されたGitHubのプロジェクトがありました。 各個人/グループは、事前定義された問題をどのように解決するかを作成できます。 これらは本格的なアプリではなく、ページのようなものですが、より複雑な例を示すのに役立つ場合は、アプリを追加することもできます。 次に、問題について話し合い、より優れたAPIを作成できます。 @TimWhitingは、私が推測する興味のある人なら誰でも招待できます。

https://github.com/TimWhiting/local_widget_state_approaches

Jetpackcomposeもフックに似ています。これはました。

@satvikpendem @TimWhitingそれは素晴らしいです！ ありがとうございました。

@esDotDev
非常に具体的なユースケースであり、セットアップ/ティアダウンロジックのランダムな収集をサポートすることは、フレームワークの一部であってはなりません。

これは、フックが頭に当たる釘です。 各タイプのオブジェクトは、独自のセットアップと分解を担当します。 アニメーターは、ストリームなどと同様に、自分自身を作成、更新、破棄する方法を知っています。 フックは、ビュー全体に散在する状態スキャフォールディングの「ランダムコレクション」のこの問題を具体的に解決します。 これにより、ビューコードの大部分がビジネスロジックとレイアウトのフォーマットに集中できるようになります。 すべてのプロジェクトで同じである一般的な定型文を非表示にするだけで、カスタムウィジェットを作成する必要はありません。

私の最長のinitStateメソッドは5行のコードであり、ウィジェットは過度のネストに悩まされることはないので、私たちは間違いなくさまざまなニーズとユースケースを持っています。 または別の開発スタイル。

あまりにも私のもの。 しかし、それはinitState（）+ dispose（）+ didUpdateDependancies（）であり、最後の2つのいずれかが欠落しているとバグが発生する可能性があります。

正規の例は次のようになると思います。1つのストリームコントローラーと2つのアニメーターコントローラーを使用するビューを記述します。

私が見る限り、3つのオプションがあります。

1. クラスに30行程度の定型文といくつかのミックスインを追加します。 これは冗長であるだけでなく、最初に従うのはかなり難しいです。
2. ビューコードに到達する前に、2つのTweenAnimationBuildersとStreamBuilderを約15のインデントレベルで使用します。それでも、Streamの定型文はたくさんあります。
3. build（）の先頭に6行のインデントされていないコードを追加して、3つのステートフルサブオブジェクトを取得し、カスタムの初期化/破棄コードを定義します

SingleStreamBuilderDoubleAnimationWidgetである4番目のオプションがあるかもしれませんが、これは開発者にとっては単なる作業であり、一般的にはかなり面倒です。

また、3の認知的負荷は、新しい開発者にとって他の2つよりも大幅に低いことにも注意してください。 ほとんどの新しい開発者は、TweenAnimationBuilderが存在することすら知りません。また、SingleTickerProviderの概念を学ぶことは、それ自体がタスクです。 「アニメーターをください」と言うだけで、より簡単で堅牢なアプローチになります。

今日は何かをコーディングしてみます。

2.ビューコードに到達する前に、2つのTweenAnimationBuildersとStreamBuilderを約15のインデントレベルで使用します。それでも、Streamの定型文はたくさんあります。

右。 15レベルのインデントを使用するコードの実際の例を示してください。

ライブラリ内の30行のコードを6行+数百行に置き換えると、認知的負荷がどのように軽減されますか？ ええ、私はライブラリが行う「魔法」を無視することはできますが、そのルールは無視できません。 たとえば、フックパッケージは、フックはビルドメソッドでのみ使用する必要があることを不確かな用語で通知します。 これで、心配する必要のある追加の制約があります。

15k行のコードを含むプロジェクトには、フォーカスノード、テキストコントローラー、シングルティッカープロバイダー、またはステートフルウィジェットのさまざまなライフサイクルメソッドを含む200行未満のコードが含まれている可能性があります。 あなたはどのような認知的過負荷について話しているのですか？

@Rudikszは受動的攻撃的であることをやめてください。
私たちは戦わずに反対することができます。

フックの制約は私の心配の中で最も少ないです。

特にフックについて話しているのではなく、問題について話している。
必要に応じて、別の解決策を考え出すことができます。

重要なのは私たちが解決したい問題です。

さらに、ウィジェットはビルド内で無条件にのみ使用できます（または、ツリーの深さを変更することはできません）。

これはフックの制約と同じですが、人々がそれについて不満を言っているとは思いません。

さらに、ウィジェットはビルド内で無条件にのみ使用できます（または、ツリーの深さを変更することはできません）。

これはフックの制約と同じですが、人々がそれについて不満を言っているとは思いません。

いいえ、同じではありません。 ここに示されている問題は、ウィジェットが（再）構築される前に_prepares_するコードに関連しているようです。 状態、依存関係、ストリーム、コントローラーなどを準備し、ツリー構造の変更を処理します。 単一の関数呼び出しの背後に隠されている場合でも、これらはいずれもbuildメソッドに含めるべきではありません。
そのロジックのエントリポイントは、buildメソッドに含めることはできません。

ビルドメソッドに任意の種類の初期化ロジックを強制的に配置することは、ビルドメソッドでウィジェットツリーを作成するように強制することと同じではありません。 buildメソッドの全体的な理由は、既存の状態（変数のセット）を取得し、ウィジェットツリーを生成してからペイントすることです。

逆に、initState / didUpdateWidgetメソッド内にウィジェットを構築するコードを追加するように強制することにも反対します。

現在のように、statefulwidgetライフサイクルメソッドには非常に明確な役割があり、まったく異なる懸念を持つコードを非常に簡単かつ簡単に分離できます。

概念的にはここで説明されている問題を理解し始めていますが、それでも実際の問題とは見なされていません。 たぶん、いくつかの実際の例（カウンターアプリではない）が私の考えを変えるのに役立つかもしれません。

ちなみに、私の最新の実験である

たとえば、次のことを解決します。

Consumer(
  provider: provider,
  builder: (context, value) {
    return Consumer(
      provider: provider2,
      builder: (context, value2) {
        return Text('$value $value2');
      },
    );
  },
)

持っていることによって：

Consumer(
  builder (context, watch) {
    final value = watch(provider);
    final value2 = watch(provider2);
  },
)

watchを条件付きで呼び出すことができる場合：

Consumer(
  builder: (context, watch) {
    final value = watch(provider);
    if (something) {
      final value2 = watch(provider2);
    }
  },
)

カスタムのStatelessWidget / StatefulWidget基本クラスを使用することで、 Consumer完全に取り除くこともできます。

class Example extends ConsumerStatelessWidget {
  <strong i="21">@override</strong>
  Widget build(ConsumerBuildContext context) {
    final value = context.watch(provider);
    final value2 = context.watch(provider2);
  }
}

主な問題は、これは1種類のオブジェクトに固有であり、オブジェクトインスタンスが再構築全体で一貫したhashCodeを持っているという事実に依存して機能することです。

ですから、フックの柔軟性にはまだほど遠いです

@rrousselGit StatelessWidget / StatefulWidgetクラスを拡張して、ConsumerStatelessWidgetのようなものを作成しなくても、 BuildContext拡張メソッドを使用して、 context.watchようなものを作成できると思います。クラスとプロバイダーに、AttachedWidgetsを使用して監視関数を提供させます。

それは別のトピックです。 しかし、tl; dr、この問題の解決策としてAliExpressWidgetsに依存することはできません： https ：

この問題を解決するには、 https：//github.com/flutter/flutter/issues/12992とhttps://github.com/flutter/flutter/pull/33213が原因で、 AliExpressWidgetsを使用するとブロックされます。

概念的にはここで説明されている問題を理解し始めていますが、それでも実際の問題とは見なされていません。

FlutterをSwiftUIと比較すると、実際に問題があることは明らかです。むしろ、物事はそれほど大きくはありません。

Flutterや他の人がそれを回避するために一生懸命働いたので、見づらいかもしれません：AnimatedBuilder、StreamBuilder、Consumer、AnimatedOpacityなどの特定のケースごとにラッパーがあります。StatefulWidgetはこれらの小さな再利用可能なユーティリティを実装するのに最適ですが、レベルが低すぎます再利用できないドメイン固有のコンポーネントの場合。テキストコントローラー、アニメーション、またはビジネスロジックが必要とするものが多数ある可能性があります。 通常の解決策は、弾丸を噛んでその定型文をすべて書くか、慎重に構築されたプロバイダーとリスナーのツリーを作成することです。 どちらのアプローチも満足のいくものではありません。

@rrousselGitが言うように、昔（UIKit）では、
ステートフルであるため、問題は非常に似ています。自動化できるのは、退屈でエラーが発生しやすい作業です。

そして、ちなみに、フックはこれをまったく解決しないと思います。 フラッターの内部を変更せずに可能な唯一のアプローチはフックだけです。

StatefulWidgetは、これらの小さな再利用可能なユーティリティを実装するのに最適ですが、再利用できないドメイン固有のコンポーネントには低レベルであり、多数のテキストコントローラ、アニメーション、またはビジネスロジックが必要とするものがあります。

再利用できないドメイン固有のコンポーネントを構築するには、高レベルのウィジェットが必要だと言うと、私は混乱します。 通常、それは正反対です。

AnimatedBuilder、StreamBuilder、Consumer、AnimatedOpacityはすべて、特定のユースケースを実装するウィジェットです。 これらの高レベルのウィジェットを使用できないほど特定のロジックを持つウィジェットが必要な場合は、低レベルのAPIにドロップダウンして、独自の特定のユースケースを作成できるようにします。 いわゆるボイラープレートは、私の独自のウィジェットがストリーム、ネットワークコール、コントローラーなどの独自の組み合わせを管理する方法を実装しています。

フック、フックのような動作、または単に「自動化」を提唱することは、いわゆるボイラープレートコードを記述せずに、誰もが欲しがる高レベルの再利用不可能なロジックを処理できる低レベルのウィジェットが必要だと言っているようなものです。

ステートフルであるため、問題は非常に似ています。自動化できるのは、退屈でエラーが発生しやすい作業です。

また。 __ "再利用不可能なドメイン固有のコンポーネントを自動化する必要があります。この場合、多数のテキストコントローラ、アニメーション、またはビジネスロジックが必要とするものは何でも" __？！

@rrousselGitが言うように、昔（UIKit）では、

私は6〜7年前（Androidがマテリアルデザインに切り替えた頃）にiOSとAndroidの開発を行いましたが、この管理とリサイクルのビューが問題になっていることを覚えていません。Flutterは良くも悪くも見えません。 現在の状況について話すことはできません。SwiftとKotlinがリリースされたときに辞めました。

StatefulWidgetsに書き込むことを余儀なくされている定型文は、コードベースの約1％です。 エラーが発生しやすいですか？ コードのすべての行がバグの潜在的な原因であるため、必ず確認してください。 面倒ですか？ 15000の200行のコードがありますか？ 私は本当にそうは思いませんが、それは私の意見です。 Flutterのテキスト/アニメーションコントローラーであるfocusnodeにはすべて改善可能な問題がありますが、冗長であることは1つではありません。

人々が何を開発しているのか、非常に多くの定型文が必要なのか、私は本当に興味があります。

ここでコメントのいくつかを聞くと、1行ではなく5行のコードを管理するのが5倍難しいように聞こえます。 そうではありません。

たとえば、各AnimationControllerに対してinitStateを設定して破棄する代わりに、一度実行してそのロジックを再利用するよりもエラーが発生しやすいことに同意しませんか？ 関数の使用と同じ原理、再利用性。 ビルド関数にフックを配置するのは問題があることに同意しますが、間違いなくより良い方法があります。

ここで問題を認識している人と認識していない人の違いは、前者はReact、Swift、Kotlinなどの以前にフックのような構造を使用したことがあり、後者は純粋なJavaでの作業などを使用していないことです。またはAndroid。 私の経験では、確信する唯一の方法は、フックを試して、標準的な方法に戻ることができるかどうかを確認することだと思います。 多くの場合、私の経験では、多くの人が再びそうすることができません。 あなたがそれを使うとき、あなたはそれを知っています。

そのために、小さなプロジェクトにflutter_hooksを使用して、それがどのように機能するかを確認してから、デフォルトの方法でやり直すことをお勧めします。 @Hixieの提案のように、アプリのバージョンを作成して読むだけでは

@Hixieの提案のように、アプリのバージョンを作成して読むだけでは

私はプロバイダーを試すのに何日も無駄にし、ブロックを試すのにさらに多くの日を費やしましたが、どちらも良い解決策であるとは思いませんでした。 それがあなたのために働くなら、素晴らしい。

私もあなたが持っていることを問題にあなたの提案されたソリューションをしようとするためには、あなたはその利点を実証する必要があります。 フラッターフックを使用した例とその実装を確認しました。 いいえ。

フレームワークに追加される定型的な削減コードが何であれ、ステートフル/ステートレスウィジェットは変更されないままにしておくことを望みます。 この会話に追加できるものはこれ以上ありません。

フックについて話さずにダートを変更できる架空の世界で、もう一度始めましょう。

議論されている問題は次のとおりです。

Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}

このコードは読み取り可能ではありません。

構文を次のように変更する新しいキーワードを導入することで、読みやすさの問題を修正できます。

Widget build(context) {
  final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);
  final value2 = keyword StreamBuilder(stream: someStream);
  final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

  return Text('$value $value2 $value3');
}

このコードは非常に読みやすく、フックとは無関係であり、制限の影響を受けません。
読みやすさの向上は、行数ではなく、フォーマットとインデントです。

しかし、ビルダーがルートウィジェットではない場合はどうでしょうか？

例：

Widget build(context) {
  return Scaffold(
    body: StreamBuilder(
      stream: stream,
      builder: (context, value) {
        return Consumer<Value2>(
          builder: (context, value2, child) {
            return Text('${value.data} $value2');
          },
        );
      },
    ),
  );
}

私たちは持つことができます：

Widget build(context) {
  return Scaffold(
    body: {
      final value = keyword StreamBuilder(stream: stream);
      final value2 = keyword Consumer<Value2>();
      return Text('${value.data} $value2');
    }
  );
}

しかし、これは再利用性の問題とどのように関連していますか？

これが関連している理由は、ビルダーは技術的には状態ロジックを再利用する方法だからです。 しかし、彼らの問題は、このコメントhttps://github.com/flutter/flutter/issues/51752#issuecomment -669626522のように、_many_ビルダーを使用する予定の場合、コードが読みにくくなることです。

この新しい構文で、読みやすさの問題を修正しました。 そのため、ビルダーにさらに多くのものを抽出できます。

したがって、たとえば、このコメントで言及されているuseFilterようになります。

FilterBuilder(
  debounceDuration: const Duration(seconds: 2),
  builder: (context, filter) {
    return TextField(onChange: (value) => filter.value = value);
  }
)

その後、新しいキーワードで使用できます。

class ChatScreen extends HookWidget {
  const ChatScreen({Key key}) : super(key: key);

  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    final filter = keyword FilterBuilder(debounceDuration: const Duration(seconds: 2));
    final userId = keyword Consumer(authProvider).userId;
    final chatId = keyword Consumer(selectedChatProvider);
    final chat = keyword QueryBuilder(ChatQuery(userId: userId, chatId: chatId, filter: filter.value));

    return Column(
      children: [
        Searchbar(onChanged: (value) => filter.value = value),
        Expanded(
          child: ChatList(chat: chat),
        ),
      ],
    );
  }
}

カスタムフック/ビルダーを作成するために、フックで説明した「関数として抽出」についてはどうでしょうか。

関数内のビルダーの組み合わせを抽出することで、このようなキーワードでも同じことができます。

Builder<Chat> ChatBuilder()  {
  final filter = keyword FilterBuilder(debounceDuration: const Duration(seconds: 2));
  final userId = keyword Consumer(authProvider).userId;
  final chatId = keyword Consumer(selectedChatProvider);
  final chat = keyword QueryBuilder(ChatQuery(userId: userId, chatId: chatId, filter: filter.value));

  return Builder(chat);
}

class ChatScreen extends HookWidget {
  const ChatScreen({Key key}) : super(key: key);

  <strong i="21">@override</strong>
  Widget build(BuildContext context) {
    final chat = keyword ChatBuilder();

    return Column(
      children: [
        Searchbar(onChanged: (value) => filter.value = value),
        Expanded(
          child: ChatList(chat: chat),
        ),
      ],
    );
  }
}

明らかに、そのような構文のすべての意味についてはあまり考えられていませんでした。 しかし、それが基本的な考え方です。

フックはこの機能です。
フックには、言語機能ではなくパッケージとして実装されるため、制限があります。

そして、キーワードはuse 、 keyword StreamBuilderはuse StreamBuilder 、最終的にはuseStreamとして実装されます。

このコードは非常に読みやすくなっています

これは意見の問題だと思います。 私は、あなたがより読みやすいと説明するバージョンの方が優れていると考える人がいることに同意します。 個人的には、もっと明確な魔法のないバージョンが好きです。 しかし、私は2番目のスタイルを可能にすることに異論はありません。

そうは言っても、次のステップは@TimWhitingのアプリ（https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/stateful/counter.dart）で作業して、すべての問題があるものにすることです。解決したいこと。

https://github.com/flutter/flutter/issues/51752#issuecomment -670959424は、Hooks inReactのインスピレーションとほぼ同じです。 Builderパターンは、Reactで一般的だったRender Propsパターンと同じように見えます（ただし、同様に深いツリーになりました）。 その後、 @ trueadmはレンダリングプロップのシンタックスシュガーを提案し、その後、フックにつながりました（不要なランタイムオーバーヘッドを削除するため）。

`Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}`

読みやすさとインデントが問題である場合、これは次のように書き直すことができます。

  <strong i="8">@override</strong>
  Widget build(context) {
    return ValueListenableBuilder<String>(
      valueListenable: someValueListenable,
      builder: (context, value, _) => buildStreamBuilder(value),
    );
  }

  StreamBuilder<int> buildStreamBuilder(String value) => StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) => buildTweenAnimationBuilder(value, value2),
      );

  Widget buildTweenAnimationBuilder(String value, AsyncSnapshot<int> value2) =>
      TweenAnimationBuilder<double>(
        duration: Duration(milliseconds: 500),
        tween: Tween(),
        builder: (context, value3, _) => Text('$value $value2 $value3'),
      );

関数があなたのものではない場合、または再利用性が必要な場合は、ウィジェットとしてそれらを抽出します

class NewWidget extends StatelessWidget {
  var someValueListenable;

  var someStream;

  <strong i="12">@override</strong>
  Widget build(context) {
    return ValueListenableBuilder<String>(
      valueListenable: someValueListenable,
      builder: (context, value, _) {
        return MyStreamedWidget(value, someStream);
      },
    );
  }
}

class MyStreamedWidget extends StatelessWidget {
  const MyStreamedWidget(
    this.value,
    this.someStream, {
    Key key,
  }) : super(key: key);

  final String value;
  final Stream someStream;

  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: someStream,
      builder: (context, value2) => MyAnimatedWidget(value, value2),
    );
  }
}

class MyAnimatedWidget extends StatelessWidget {
  final String value;
  final AsyncSnapshot<int> value2;

  const MyAnimatedWidget(
    this.value,
    this.value2, {
    Key key,
  }) : super(key: key);

  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    return TweenAnimationBuilder<double>(
      tween: Tween(),
      builder: (context, value3, _) {
        return Text('$value $value2 $value3');
      },
    );
  }
}

あなたの例には、新しいキーワードや機能を保証するものは何もありません。

私はあなたが何を言おうとしているのか知っています。 'value'変数は、すべてのウィジェット/関数呼び出しを通過する必要がありますが、これは、アプリケーションの設計方法の結果にすぎません。 ユースケースに応じて、「ビルド」メソッドとカスタムウィジェットの両方を使用してコードを分割し、同じ変数を3つの呼び出しのチェーンに渡す必要はありません。

再利用可能なコードは、外部の副作用（DependentWidgetsや（半）グローバル状態など）にできるだけ依存しない場合に再利用できます。

@Rudikszここでの議論に何も追加していないと思います。 私たちは一日中それらを行っているので、これらの問題を軽減するための戦略を認識しています。 問題がないと思われる場合は、そのまま使用し続けることができますが、まったく影響はありません。

明らかに、これを根本的な問題点と見なしている人はたくさんいます。前後にサイクリングするだけでは意味がありません。 あなたは、さまざまな議論を通して、彼らが望むものを望まないことを人々に納得させたり、ここで誰かの心を変えたりするつもりはありません。 この議論の誰もが明らかに彼らのベルトの下でFlutterに数百または数千時間を持っています、そして私たち全員が物事に同意するべきであるとは期待されていません。

これは意見の問題だと思います。 私は、あなたがより読みやすいと説明するバージョンの方が優れていると考える人がいることに同意します。 個人的には、もっと明確な魔法のないバージョンが好きです。 しかし、私は2番目のスタイルを可能にすることに異論はありません。

それが意見の問題であるならば、私はそれが一方向にかなり偏っていると思います。

1. どちらにも魔法があります。 これらのビルダーが内部で何をしているのか、必ずしもわかりません。 非魔法のバージョンは、これらのビルダー内に実際の定型文を書き込んでいます。 SingleAnimationTIckerProviderミックスインを使用することは、Flutter開発者の95％にとっても魔法です。
2. 1つは、ツリーの後半で使用される非常に重要な変数名（ value1とvalue2 ）をわかりにくくし、もう1つは、ビルドの上部の前面と中央に配置します。 これは明確な構文解析/メンテナンスの勝利です。
3. 1つはウィジェットツリーが始まる前に6レベルのインデンドを持ち、もう1つは0を持っています
4. 1つは5本の垂直線、もう1本は15本です
5. 1つは実際のコンテンツを目立つように表示し（Text（））、もう1つはそれを非表示にしてネストし、ツリーのずっと下に配置します。 もう1つの明確な構文解析の勝利。

一般的な意味で、これはおそらく好みの問題であることがわかりました。 しかし、Flutterには、一般的に、回線数、インデンデーション、および信号：ノイズ比に特に問題があります。 私はDartコードで宣言的にツリーを形成する機能を絶対に_大好き_ですが、特にラップされたビルダーの複数のレイヤーに依存している場合は、非常に読めない/冗長なコードにつながる可能性があります。 したがって、この戦いを継続的に戦っているFlutter自体のコンテキストでは、この種の最適化は、この一般的な冗長性のやや蔓延している問題と戦うための非常に優れたツールを提供するため、キラー機能です。

TL; DR-Flutterに固有の行数とインデントが一般的に多いため、Flutterのインデントと行数を大幅に削減したものはすべて二重に価値があります。

@Rudikszここでの議論に何も追加していないと思います。 私たちは一日中それらを行っているので、これらの問題を軽減するための戦略を認識しています。 問題がないと思われる場合は、そのまま使用し続けることができますが、まったく影響はありません。

それがコアフレームワークの変更である場合を除いて、それは私に影響を与えますね？

明らかに、これを根本的な問題点と見なしている人はたくさんいます。前後にサイクリングするだけでは意味がありません。 あなたは、さまざまな議論を通して、彼らが望むものを望まないことを人々に納得させたり、ここで誰かの心を変えたりするつもりはありません。 この議論の誰もが明らかに彼らのベルトの下でFlutterに数百または数千時間を持っています、そして私たち全員が物事に同意するべきであるとは期待されていません。

そうです、この馬はすでに何度も殴られて死んでしまったので、これ以上コメントに答える罠にはまりません。

ビルダーは、技術的には状態ロジックを再利用する方法です。 しかし、彼らの問題は、コードがあまり読みにくくなることです。

これはそれを完全に述べています。 Flutterの用語で考えると、単一行のビルダーが必要です。

数十のタブと行を必要としないが、ウィジェットのライフサイクルにカスタムボイラープレートをフックできるビルダー。

「すべてがウィジェットである」というマントラは、ここでは特に良いことではありません。 ビルダーの関連コードは通常、セットアップの小道具と、ビルドfxnが必要とするステートフルなものです。 すべての改行とタブは基本的に無意味です。

それがコアフレームワークの変更である場合を除いて、それは私に影響を与えますね？

@Rudikszステートフルウィジェットを変更することを提案している人はいないと思います。 必要に応じて、いつでも現在の形式で使用できます。 私たちが思いつく解決策が何であれ、変更​​のないステートフルウィジェットを使用するか、別のタイプのウィジェットを完全に使用します。 ステートフルウィジェットが悪いと言っているのではなく、より構成可能なウィジェット状態を可能にする別のタイプのウィジェットが必要なだけです。 これは、関連付けられた1つの状態オブジェクトの代わりに複数の状態オブジェクトと、別個であるがそれらの状態オブジェクトにアクセスできる1つのビルド関数を含むステートフルウィジェットと考えてください。 このようにして、共通の状態のビットを（その状態に関連付けられた状態ロジックとともに）再利用でき、それらのinitStateとdisposeすでに実装されています。 本質的によりモジュール化された状態であり、さまざまな状況でさまざまな方法で構成できます。 繰り返しますが、これは具体的な提案ではありませんが、おそらく別の考え方です。 たぶんそれはもっとflutterような解決策になるかもしれませんが、私にはわかりません。

そうは言っても、次のステップは@TimWhitingのアプリ（https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/stateful/counter.dart）で作業して、すべての問題があるものにすることです。解決したいこと。

この問題は本質的に千カットによる死の1つであるため、これは注意が必要です。 それは単に肥大化を追加し、コードベース全体の可読性を低下させます。 その影響は、クラス全体が100行未満で、その半分がアニメーターコントローラーの管理に費やされている小さなウィジェットで最もひどく感じられます。 したがって、これらの例のうち30を見ると何が表示されるかわかりませんが、1つは表示されません。

それは本当にこれの違いです：

<strong i="10">@override</strong>
  Widget build(BuildContext context) {
    final controller = get AnimationController(vsync: this, duration: widget.duration);
    //do stuff
  }

この：

  AnimationController _controller;

  <strong i="14">@override</strong>
  void initState() {
    super.initState();
    _controller = AnimationController(vsync: this, duration: widget.duration);
  }

  <strong i="15">@override</strong>
  void didUpdateWidget(Example oldWidget) {
    super.didUpdateWidget(oldWidget);
    if (widget.duration != oldWidget.duration) {
      _controller.duration = widget.duration;
    }
  }

  <strong i="16">@override</strong>
  void dispose() {
    _controller.dispose();
    super.dispose();
  }

  <strong i="17">@override</strong>
  Widget build(BuildContext context) {
    //Do Stuff
  }

これ以上に説明するのに良い方法はありません。 このユースケースは、任意のコントローラータイプのオブジェクトに拡張できます。 AnimatorController、FocusController、およびTextEditingControllerは、おそらく、日常の使用で管理するのに最も一般的で煩わしいものです。 今、ちょうど写真50、またはこれらの100が私のコードベース全体に散らばっています。

• 消える可能性のある約1000〜2000行があります。
• おそらく、オーバーライドまたは別のオーバーライドが欠落しているために存在する必要がなかった、数十のバグとRTE（開発のさまざまなポイント）があります。
• 冷たい目で見たときに一目で理解するのがはるかに難しいウィジェットがあります。 私はこれらのオーバーライドのそれぞれを読む必要があります、私はそれらが定型文であると単純に仮定することはできません。

もちろん、これをカスタムコントローラーに拡張することもできます。 コントローラーを使用するという概念全体は、Flutterではあまり魅力的ではありません。これは、コントローラーをこのようにブートストラップ、管理、および破棄する必要があるためです。これは、煩わしく、バグが発生しやすいものです。 これにより、独自の作成を避け、代わりにカスタムのStatefulWidgets / Builderを作成することができます。 ビルダーには読みやすさの問題があるため（または、少なくとも、冗長で空白が多いため）、コントローラータイプのオブジェクトが使いやすく、堅牢であると便利です。

これはトリッキーです

はい、APIの設計には注意が必要です。 私の生活へようこそ。

したがって、これらの例のうち30を見ると何が表示されるかわかりませんが、1つは表示されません。

役立つのは30の例ではなく、「確かに、この例では機能しますが、実際の例ではありません」と言うような方法で単純化できないほど精巧な1つの例です。

役立つのは30の例ではなく、「確かに、この例では機能しますが、実際の例ではありません」と言うような方法で単純化できないほど精巧な1つの例です。

すでに何度か言いましたが、そのようなフックの判断は不公平です。
フックは、以前は不可能だった何かを可能にすることではありません。 この種の問題を解決するための一貫したAPIを提供することです。

単純化できないものを表示するアプリケーションを要求することは、木に登る能力によって魚を判断することです。

私たちはフックを判断しようとしているだけでなく、さまざまなソリューションを評価して、すべての人のニーズに対応するソリューションがあるかどうかを確認しようとしています。

（実際に各提案にアプリケーションを作成して比較するのではなく、ここでさまざまな提案をどのように評価するのか興味があります。代わりにどの評価指標を提案しますか？）

この問題の解決策を判断する適切な方法は、アプリケーションではありません（APIの個々の使用法は、ここでの例のように却下されるため）。

提案された解決策を判断する必要があるのは次のとおりです。

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
  
  
  • それはもっと読みやすいですか？
  
  
  • 書くのは簡単ですか？
  
  
• コードはどの程度再利用可能ですか？
• このAPIで解決できる問題はいくつありますか？
  
  
  
  • 特定の問題でいくつかのメリットが失われますか？
  
  

このグリッドで評価すると、 Property / addDispose提案は、「結果のコードの方が優れているか」という点で優れている可能性があります。 スコアは付けられますが、再利用性と柔軟性の両方に対して評価が不十分です。

それぞれの提案を実際に実際に見ずに、これらの質問に答える方法がわかりません。

どうして？

Propertyを使用してアプリケーションを作成する必要はありません

既存の* Builderを使用して、提案されたソリューションを使用してそれらを再実装することができます。
このスレッドにリストされているフック、またはReactコミュニティで作成されたいくつかのフックを再実装することもできます（オンラインで利用できるフックのコンパイルは多数あります）。

Propertyを使用してアプリケーションを作成する必要はありません

残念ながら、ここではあなたの本能を共有しません（プロパティ（https://github.com/flutter/flutter/issues/51752#issuecomment-667737471）が値を処理する必要があると言うまで、うまく機能したと思ったという事実によって示されています）ウィジェットと同じAPIを使用するローカル状態の両方から、それを起動するまで制約であることに気づいていませんでした）。 その問題も解決するバージョンのPropertyを提供した場合、それは間違いなく問題ないのでしょうか、それともカバーされていない新しい問題があるのでしょうか。 目標がなければ、私たち全員が目標であることに同意します。私たちが何のためにソリューションを設計しているのかわかりません。

既存の* Builderを使用して、提案されたソリューションを使用してそれらを再実装することができます。

明らかに_any_ではありません。 たとえば、OPで1つ提供しましたが、最初のプロパティの提案（https://github.com/flutter/flutter/issues/51752#issuecomment-664787791）を行ったときに、元のビルダー。

このスレッドにリストされているフック、またはReactコミュニティで作成されたいくつかのフックを再実装することもできます（オンラインで利用できるフックのコンパイルは多数あります）。

どこから始めてもかまいません。 問題を説明していると思われる特に良い例があり、フックを使用している場合は、それを@TimWhitingのリポジトリに追加しましょう。 重要なのは、同じことを複数の異なる方法で実装することです。アイデアがどこから来たのかは気にしません。

役立つのは30の例ではなく、「確かに、この例では機能しますが、実際の例ではありません」と言うような方法で単純化できないほど精巧な1つの例です。

読めないビルダーやバグが発生しやすいライフサイクルの定型文なしで、AnimatorController（または考えられる他の再利用可能なステートフルコンポーネント）を使用したいという単純な願望ほど手の込んだものはありません。

要求された読みやすさと堅牢性の利点に、汎用的な方法で対処するソリューションは提案されていません。

この問題は「ビルダーにはシンタックスシュガーが必要」に名前が変更され、同じ議論につながる可能性があるため、私は_any_ビルダーが行うという事実を主張します。

行われた他のすべての引数（ AnimationController作成や破棄など）は、それらもビルダーに抽出できることに基づいて行われます。

Widget build(context) {
  return AnimationControllerBuilder(
    duration: Duration(seconds: 2),
    builder: (context, animationController) {

    }
  );
}

結局のところ、完璧な例は、StreamBuilder全体を再実装し、さまざまなシナリオでテストすることだと思います。

• ストリームはWidgetから来ます
• // GeneratedWidgetから
• 地方の州から

そして、「ストリームは時間とともに変化する可能性がある」に対して個々のケースをテストします。

• 新しいストリームでdidUpdateWidget
• 継承されたウィジェットが更新されました
• setStateと呼びました

これは現在、 PropertyまたはonDispose解決できません。

@esDotDev 「要求された読みやすさと堅牢性の利点」を列挙できますか？ 誰かがこれらの読みやすさと堅牢性の利点を備えたAnimationControllerを処理する提案をした場合、ここで完了ですか？

@rrousselGitプロパティは問題を解決しないと前に言ったように、私はプロパティを支持していません。 しかし、誰かがStreamBuilderが行うすべてのことを、インデントなしで実行するソリューションを作成したとしたら、それはそれでしょうか？ あなたは幸せになりますか？

しかし、誰かがStreamBuilderが行うすべてのことを、インデントなしで実行するソリューションを作成したとしたら、それはそれでしょうか？ あなたは幸せになりますか？

おそらくそうです

もちろん、このソリューションを他のソリューションと比較する必要があります。 しかし、それは許容レベルに達するでしょう。

@esDotDev 「要求された読みやすさと堅牢性の利点」を列挙できますか？

依存関係とライフサイクルの周りの定型文を完全にカプセル化できるという点での堅牢性。 NS。 毎回fetchUserに通知する必要はありません。おそらく、IDが変更されたときに再構築する必要があり、内部で再構築することを知っています。 親ウィジェットが破棄されるたびに、アニメーションにそれ自体を破棄するように指示する必要はありません（プロパティがこのtbhを実行できるかどうかは完全には理解していません）。 これにより、開発者はコードベース全体でロートタスクを間違えることがなくなります（現在imoを使用するBuilderを使用する主な利点の1つ）

読みやすさは、インデントされていない1行のコードでステートフルなものを取得でき、その変数が持ち上げられてはっきりと見えることです。

@esDotDev誰かが、これらの読みやすさと堅牢性の利点を備えたAnimationControllerを処理する提案をした場合、ここで完了ですか？

特にAnimationControllerを意味する場合はありません。 AnimationController / FocusController / TextEdiitingControllerのようなオブジェクトを意味する場合は、はい。

明確ではない定義された寿命を持つ値を返す関数のようなAPIを持つことは

これは重要な誤解だと思います。 フックは定義上サブステートであるため、フックの存続期間は明確です。 それらは、それらを「使用する」国の存続期間中、常に存在します。 実際にはこれ以上明確にすることはできません。 構文は奇妙でなじみのないものかもしれませんが、確かに明確さを欠いていません。

TweenAnimationBuilder（）の存続期間も明確であるのと同様です。 親がいなくなると消えます。 子ウィジェットと同様に、これらは子の状態です。 これらは完全に独立した状態の「コンポーネント」であり、簡単に組み立てて再利用できます。また、バグではなく機能として宣言された状態に自然にバインドする必要があるため、明示的にライフタイムを管理しません。

@esDotDev

NS

もっと具体的にできますか？ （これが、すべてのベースをカバーするデモアプリケーションを考え出すことを提案した理由です。これを行うには、これが最善の方法だと引き続き考えています。）構成が変更されて自動的に破棄されない限り、イニシャライザーを呼び出す以外に重要な機能はありますか？ホスト要素が破棄されるときに割り当てられたリソース？

TextEdiitingControllerのようなオブジェクト

もっと具体的にできますか？ TextEditingControllerはAnimationControllerよりも何らかの形で複雑ですか？

@rrousselGit

しかし、誰かがStreamBuilderが行うすべてのことを、インデントなしで実行するソリューションを作成したとしたら、それはそれでしょうか？ あなたは幸せになりますか？

おそらくそうです

これは、インデントなしでStreamBuilderが実行するすべてのことを実行するソリューションです。

Widget build(context) {
  var result = Text('result:');
  var builder1 = (BuildContext context, AsyncSnapshot<int> snapshot) {
    return Row(children: [result, Text(snapshot.data)]);
  };
  result = StreamBuilder(stream: _stream1, builder: builder1);
  var builder2 = (BuildContext context, AsyncSnapshot<int> snapshot) {
    return Column(children: [result, Text(snapshot.data)]);
  };
  result = StreamBuilder(stream: _stream2, builder: builder2);
}

ただし、これは他の制約に違反していると思います。 だからこそ、私たち全員が同意できるものが欲しいのです。それは、問題を解決しようとする前に、問題の完全な説明です。

これは、ビルダーが@Hixieに持っているのと同じ制約であり、それ以上のことを誰も求めていません。 ビルダーはwidget.whateverに結び付けることができます。ビルダーは、ウィジェットツリーのコンテキストで必要な内部状態を完全に管理できます。 それはフックができるすべてであり、誰もがマイクロステートまたはあなたがそれを呼びたいものを求めているすべてです。

もっと具体的にできますか？ TextEditingControllerはAnimationControllerよりも何らかの形で複雑ですか？

いいえ。ただし、init / disposeで異なる処理を実行する可能性があります。そうでない場合は、異なるプロパティにバインドされるため、その特定のボイラープレートをカプセル化する必要があります。

@esDotDevでは、ビルダーと同じものが必要ですが、インデントはなく、1行で（おそらくビルダーのコールバック自体を除いて）？ 私が投稿したばかりの例（https://github.com/flutter/flutter/issues/51752#issuecomment-671004483）は、今日のビルダーでそれを行っているので、おそらくそれ以上の追加の制約がありますか？

（FWIW、ビルダー、またはビルダーのようなものではなく、1行で、各データ型に独自のビルダーを作成する必要があるため、良い解決策ではないと思います。その場でビルドするだけの良い方法はありません。 。）

（FWIW、ビルダー、またはビルダーのようなものではなく、1行で、各データ型に独自のビルダーを作成する必要があるため、良い解決策ではないと思います。その場でビルドするだけの良い方法はありません。 。）

これが何を意味するのかわかりません。 言い換えてもらえますか？ 🙏

アニメーション用のAnimationBuilderとストリーム用のStreamBuilderなどを作成する必要があります。 StatefulWidgetを作成するときに、ビルダーを1つだけ持って、「新しいビルダーを取得する方法、破棄する方法、データを取得する方法」などと言う代わりに、

ただし、これは他の制約に違反していると思います。 だからこそ、私たち全員が同意できるものが欲しいのです。それは、問題を解決しようとする前に、問題の完全な説明です。

これは、読み取り可能なコードの要求にかなり明らかに違反していると思います。これが最終的な目標です。そうでない場合は、100万個の特別に型指定されたビルダーを使用し、emを永久にネストして、1日と呼びます。

要求されているのは次のようなものだと思います（私に耐えてください、私はあまり使用しません、Streamsをあまり使用しません）：

Widget build(context) {
   var snapshot1 = get AsyncSnapshot<int>(stream1);
   var snapshot2 = get AsyncSnapshot<int>(stream2);
   return Column(children: [Text(snapshot1.data), Text(snapshot2.data)]);
}

これがすべてのコードです。 ストリームが私たちのために作成され、ストリームが私たちのために破棄され、私たちが足で自分自身を撃つことができず、コードがはるかに読みやすくなるので、これ以上何もありません。

アニメーション用のAnimationBuilderとストリーム用のStreamBuilderなどを作成する必要があります。

それは問題ではないと思います。 RestorableInt vs RestorableString vsRestorableDoubleはすでにあります

そしてジェネリックはそれを解決することができます：

GenericBuilder<Stream<int>>(
  create: (ref) {
    var controller = StreamController<int>();
    ref.onDispose(controller.close);
    return controller.stream;
  }
  builder: (context, Stream<int> stream) {

  }
)

同様に、それが本当に問題である場合、FlutterまたはDartにDisposableインターフェースを含めることができます。

@esDotDev

要求されているのは次のようなものだと思います。

これは、他の人がリストしたかなり合理的な制約（@Rudikszなど）のいくつかに違反します。つまり、buildメソッドの呼び出し中に初期化コードが発生しないことを保証します。

@rrousselGit

それは問題ではないと思います。 RestorableInt vs RestorableString vsRestorableDoubleはすでにあります

そして、AnimationBuilderやStreamBuilderなどがあります。 どちらの場合も残念です。

GenericBuilder

それは私が不動産に提案したものと似ていますが、そこであなたの懸念を理解した場合、あなたは冗長すぎると信じていました。

以前、StreamBuilderが実行するすべてのことを実行するソリューションを誰かが作成したとしても、インデントがなければ、満足するだろうとおっしゃいました。 あなたはそれをやろうとした私の試みについてコメントしていません（https://github.com/flutter/flutter/issues/51752#issuecomment-671004483）。 その解決策に満足していますか？

@esDotDev

要求されているのは次のようなものだと思います。

これは、他の人がリストしたかなり合理的な制約（@Rudikszなど）のいくつかに違反します。つまり、buildメソッドの呼び出し中に初期化コードが発生しないことを保証します。

このコードがビルドされていることは重要ではありません。 重要なのは

1. ツリーをインデントしたり、大量の行を追加したりする必要はありません。
2. これに固有のライフサイクルコードはカプセル化されています。

これは驚くべきことです：

AsyncSnapshot<int> snapshot1 = createLifecycleState(widget.stream1);
AsyncSnapshot<int> snapshot2 = createLifecycleState(widget.stream2);
AniamtorController animator = createLifecycleState(duration: Duration(seconds: 1), (a)=>a.forward());

Widget build(context) {
   return Opacity(opacity: animator.value, child: Column(children: [Text(snapshot1.data), Text(snapshot2.data)]));
}

または、簡潔ではありませんが、ビルダーを使用するよりもはるかに読みやすく、直接実行するよりも冗長でエラーが発生しにくくなります。

AsyncSnapshot<int> stream1;
AsyncSnapshot<int> stream2;
<strong i="18">@override</strong> 
void initState(){
    snapshot1 = createLifecycleState(widget.stream1);
    snapshot2 = createLifecycleState(widget.stream2);
   super.initState();
}

Widget build(context) {
   return Column(children: [Text(snapshot1.data), Text(snapshot2.data)]);
}

なぜ冗長性に戻り続けるのかわかりません。
私は、それは問題ではなく、問題は再利用性、可読性、柔軟性であると何度も明確に述べました。

ソリューションhttps://github.com/flutter/flutter/issues/51752#issuecomment-671000137とテストケースhttps://github.com/flutter/flutter/issues/51752#issuecommentを評価するためのグリッドも作成しました- 671002248

以前、StreamBuilderが実行するすべてのことを実行するソリューションを誰かが作成したとしても、インデントがなければ、満足するだろうとおっしゃいました。 あなたは私の試みについてコメントしていません（＃51752（コメント））。 その解決策に満足していますか？

これは、許容可能な最小レベルの柔軟性に達します。

https://github.com/flutter/flutter/issues/51752#issuecomment -671000137に従って評価すると、次のようになります。

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
    
    _デフォルトの構文（ハッキングなしのStreamBuilder）は、エラーが発生しにくいです。 この解決策は間違いを避けません、それはいくつかを作成します_❌
  
  
  • それはもっと読みやすいですか？
    
    _明らかに読みやすくない_❌
  
  
  • 書くのは簡単ですか？
    
    _書くのは簡単ではありません_❌
  
  
• コードはどの程度再利用可能ですか？
  _StreamBuilderはウィジェット/状態/ライフサイクルに関連付けられていないため、このパス_✅
• このAPIで解決できる問題はいくつありますか？
  _カスタムビルダーを作成し、このパターンを使用できます。 だからこのpass_。 ✅
• 特定の問題でいくつかのメリットが失われますか？
  _いいえ、構文は比較的一貫しています_。 ✅

1. この機能IMOは、たとえばLayoutBuilderを含むすべてのビルダーウィジェットに拡張できます。
2. 10xコントローラーを作成して再構築のためにリーフに渡すことができるように、リスニングを無効にする方法が必要です。または、フラッターは、ツリーのどの部分がビルダーによって取得された値を使用したかを何らかの方法で知る必要があります。
3. これを使用することは、フックするほど冗長であってはなりません。
4. これを適切に処理するには、コンパイラを拡張する必要があります。
5. デバッグヘルパーが必要です。 これを使用するウィジェットの1つにブレークポインを配置するとします。 ビルドメソッド内のブレークポイントに到達すると、ビルダーの1つがトリガーされたため、IDEは使用された各ビルダーの追加情報を表示できました。

Widget build(context) {
   // this builder is not highlighted, but you can hover over it to see how often it rebuilds, how heavy were those rebuilds, and when was the last rebuild
   var snapshot1 = keyword StreamBuilder(stream1);
   // this builder will be highlighted because it triggered the rebuild
   var constraints = keyword LayoutBuilder(); 

   // <-- I had a breakpoint here and parent constraint changed, breakpoints got reached.
   return Column(children: [Text(snapshot1.data), Text(snapshot2.data)]);
}

また、 @ Hixie

これは、他の人がリストしたかなり合理的な制約（@Rudikszなど）のいくつかに違反します。つまり、buildメソッドの呼び出し中に初期化コードが発生しないことを保証します。

* Buildersを使用して、すでに暗黙的にそれを行っています。 それらをデインデントするために必要なのはシンタックスシュガーだけです。 async / awaitやfuturesによく似ていると思います。

@esDotDevあなたが説明することは、私が以前にプロパティで提案したものと非常に似ています（たとえば、https：//github.com/flutter/flutter/issues/51752#issuecomment-664787791またはhttps://github.com/flutter/flutter/を参照してください）。 issues / 51752＃issuecomment-667737471）。 この種のソリューションがパッケージとして作成されるのを妨げるものはありますか？ つまり、この種の機能を使用できるようにするには、コアフレームワークにどのような変更を加える必要がありますか？

@rrousselGit Shawnと同じように、同じことをお願いします。 現在のStreamBuilder機能とニーズを満たすものとの唯一の違いが異なる構文である場合、そのような機能を使用できるようにするためにコア構文に必要なものは何ですか？ 好みの構文を作成してそれを使用するだけでは不十分でしょうか？

私があなたのグリッドで抱えている問題は、これまでのソリューションにそれを適用すると、これが得られるということです。これは、あなたが得るものとは非常に異なると思います。

StatefulWidget

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
    
    _これはデフォルトの構文と同じですが、特にエラーが発生しやすいわけではありません。_🔷
  
  
  • それはもっと読みやすいですか？
    
    _同じなので、同じように読みやすく、適度に読みやすいです。_🔷
  
  
  • 書くのは簡単ですか？
    
    _同じなので、書くのも同じくらい簡単で、かなり簡単です。_🔷
  
  
• コードはどの程度再利用可能ですか？
  _再利用するコードはほとんどありません。_✅
• このAPIで解決できる問題はいくつありますか？
  _これがベースラインです。_🔷
• 特定の問題でいくつかのメリットが失われますか？
  _そのようには見えません。_✅

プロパティのバリエーション

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
    
    _コードを別の場所に移動しますが、間違いの数を特に減らすことはありません。_🔷
  
  
  • それはもっと読みやすいですか？
    
    _初期化コードとクリーンアップコードおよびその他のライフサイクルコードを同じ場所に配置するため、わかりにくくなります。_❌
  
  
  • 書くのは簡単ですか？
    
    _初期化コードとクリーンアップコードおよびその他のライフサイクルコードが混在しているため、記述が困難です。_❌
  
  
• コードはどの程度再利用可能ですか？
  _StatefulWidgetとまったく同じように、さまざまな場所で再利用できます。_✅
• このAPIで解決できる問題はいくつありますか？
  _これはStatefulWidgetのシンタックスシュガーなので、違いはありません。_🔷
• 特定の問題でいくつかのメリットが失われますか？
  _パフォーマンスとメモリ使用量がわずかに低下します。_❌

ビルダーのバリエーション

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
    
    _これは基本的にStatefulWidgetソリューションですが、除外されています。 間違いはほぼ同等でなければなりません。_🔷
  
  
  • それはもっと読みやすいですか？
    
    _ビルドメソッドはより複雑で、残りのロジックは別のウィジェットに移動するため、ほぼ同じです。_🔷
  
  
  • 書くのは簡単ですか？
    
    _最初は書くのが難しく（ビルダーウィジェットを作成する）、その後は少し簡単になるので、ほぼ同じです。_🔷
  
  
• コードはどの程度再利用可能ですか？
  _StatefulWidgetとまったく同じように、さまざまな場所で再利用できます。_✅
• このAPIで解決できる問題はいくつありますか？
  _これはStatefulWidgetの構文糖衣なので、ほとんど違いはありません。 いくつかの側面では、実際には優れています。たとえば、依存関係の変更を処理するときに実行する必要のあるコードの量を減らすことができます。_✅
• 特定の問題でいくつかのメリットが失われますか？
  _そのようには見えません。_✅

フックのようなソリューション

• 結果のコードは、デフォルトの構文よりも客観的に優れていますか？
  
  
  
  • それは間違いを避けますか？
    
    _悪いパターン（例：buildメソッドでの構築）を奨励し、条件付きで誤って使用するとバグのリスクがあります。_❌
  
  
  • それはもっと読みやすいですか？
    
    _ビルド方法を理解するために知っておく必要のある概念の数を増やします。_❌
  
  
  • 書くのは簡単ですか？
    
    _開発者はフックの書き方を学ぶ必要がありますが、これは新しい概念であるため、非常に困難です。_❌
  
  
• コードはどの程度再利用可能ですか？
  _StatefulWidgetとまったく同じように、さまざまな場所で再利用できます。_✅
• このAPIで解決できる問題はいくつありますか？
  _これはStatefulWidgetのシンタックスシュガーなので、違いはありません。_🔷
• 特定の問題でいくつかのメリットが失われますか？
  _パフォーマンスとメモリ使用量が低下します。_❌

なぜ冗長性に戻り続けるのかわかりません。
私は、それは問題ではなく、問題は再利用性、可読性、柔軟性であると何度も明確に述べました。

申し訳ありませんが、プロパティが冗長すぎると言ったのは誰なのかを思い出しませんでした。 そうです、あなたの懸念は、以前にリストされていなかった新しいユースケースがあり、それが処理されなかったということでしたが、プロパティを拡張してそのユースケースも処理するのは簡単だと思います（私は試していませんが、要件が調整されたときに繰り返し繰り返すのではなく、問題を一度に解決できるように、明確なデモアプリができるまで待つ方がよいようです）。

@szotp

1. この機能IMOは、たとえばLayoutBuilderを含むすべてのビルダーウィジェットに拡張できます。

LayoutBuilderは、ほとんどのビルダーであるFWIWとは非常に異なるウィジェットです。 これまでに説明した提案はいずれも、LayoutBuilderのような問題には機能しません。また、コメントの前に説明した要件には、LayoutBuilderが含まれていません。 この新機能を使用してLayoutBuilderを処理する必要がある場合は、知っておくことが重要です。 @TimWhitingを使用して、提案のベースとなるサンプルアプリに、例としてレイアウトビルダーが含まれていることを確認することをお勧めします。

1. 10xコントローラーを作成して再構築のためにリーフに渡すことができるように、リスニングを無効にする方法が必要です。または、フラッターは、ツリーのどの部分がビルダーによって取得された値を使用したかを何らかの方法で知る必要があります。

これが何を意味するのか正確にはわかりません。 私の知る限り、これはリスナーとビルダーを使用して今日行うことができます（たとえば、前に引用したアプリでValueListenableBuilderを使用して、これを正確に実行します）。

これは、他の人がリストしたかなり合理的な制約（@Rudikszなど）のいくつかに違反します。つまり、buildメソッドの呼び出し中に初期化コードが発生しないことを保証します。

* Buildersを使用して、すでに暗黙的にそれを行っています。

私はそれが正確だとは思いません。 ビルダーによって異なりますが、initState、didChangeDependencies、didUpdateWidget、およびビルドロジックを分離するのに非常に苦労するものもあるため、変更内容に基づいて各ビルドを実行するために必要なコードは最小限です。 たとえば、ValueListenableBuilderは最初に作成されたときにのみリスナーを登録し、そのビルダーは、ビルダーの親またはinitStateを再実行せずに再実行できます。 これはフックができることではありません。

@esDotDevあなたが説明することは、私が以前にPropertyで提案したものと非常に似ているように聞こえます（たとえば、 ＃51752（コメント）または＃51752（コメント）を参照）。

私が正しく理解していれば、UserIdのDidDependancyChangeを自動的に処理するUserProperty 、 AnimationProperty 、またはそのタイプのinit / update / disposeを処理するために必要なその他のプロパティを作成できますか？ それなら、これは私にはいいようです。 最も一般的なユースケースはすぐに作成できます。

私を捨てる唯一のものは、ここの未来のビルダーです。 しかし、これはあなたが選んだ例によるものだと思いますか？

たとえば、これを作成できますか？

class _ExampleState extends State<Example> with PropertyManager {
  AnimationProperty animProp1;
  AnimationProperty animProp2;

  <strong i="15">@override</strong>
  void initProperties() {
    super.initProperties();
    anim1= register(anim1, AnimationProperty (
      AnimationController(duration: Duration(seconds: 1)),
      initState: (animator) => animator.forward()
      // Not dealing with updates or dispose here, cause AnimationProperty handles it
    ));
   anim2 = register(anim2, AnimationProperty(
       AnimationController(duration: Duration(seconds: 2))..forward(),
   ));
  }

  <strong i="16">@override</strong>
  Widget build(BuildContext context) {
    return Column(children: [
       FadeTransition(opacity: anim1, child: ...),
       FadeTransition(opacity: anim2, child: ...),
   ])
  }
}

もしそうなら、これは完全にLGTMです！ フレームワークへの追加に関しては、これをファーストクラスの構文的アプローチに昇格させる必要があるか（つまり、1年ほどで一般的になる）、または開発者の1桁の割合のプラグインとして存在するかどうかのケースです。使用する。

より簡潔な構文で、冗長で（わずかに？）エラーが発生しやすい例を更新できるようにするかどうかが問題になります。 プロパティを手動で同期し、手動でdispose（）を実行する必要があると、バグや認知的負荷が発生します。

Imo開発者が、適切なdidUpdate、dispose、debugFillPropertiesを使用してアニメーターを使用できれば、それについて二度考える必要はありません（TweenAnimationBuilderを使用するときとまったく同じように、これが私たちが推奨する主な理由です）。すべての開発者は、デフォルトでアニメーターを手動で管理するよりも使用します）。

もしそうなら、これは完全にLGTMです！ フレームワークへの追加に関しては、これをファーストクラスの構文的アプローチに昇格させる必要があるか（つまり、1年ほどで一般的になる）、または開発者の1桁の割合のプラグインとして存在するかどうかのケースです。使用する。

Propertyがいかに些細なことかを考えると、そのスタイルが好きな人への私の推奨事項は、独自のスタイルを作成し（それが役立つ場合は私のコードから始めて）、適切と思われる場合はアプリで直接使用して調整することです。彼らのニーズに対応するために。 多くの人が気に入ったらパッケージにすることもできますが、些細なことでも、コードにコピーして必要に応じて調整するのと比べて、どれだけ有益かはわかりません。

私を捨てる唯一のものは、ここの未来のビルダーです。 しかし、これはあなたが選んだ例によるものだと思いますか？

@rrousselGitが提供した例に対処しようとしていました。 原則として、それは何にでも機能するように適合させることができます。

たとえば、これを作成できますか？

毎回呼び出すのではなく、AnimationControllerコンストラクターを呼び出されるクロージャーに移動する必要があります。これは、ホットリロード中に新しいクロージャーを取得するためにinitPropertiesが呼び出されるためですが、通常は作成したくないためです。ホットリロード中の新しいコントローラー（アニメーションをリセットするなど）。 しかし、はい、それ以外は問題ないようです。 AnimationControllerコンストラクター引数を取り、それらを使用して正しい処理を行うAnimationControllerPropertyを作成することもできます（たとえば、ホットリロードの期間が変更された場合は更新します）。

Imo開発者が、適切なdidUpdate、dispose、debugFillPropertiesを使用してアニメーターを使用できれば、それについて二度考える必要はありません（TweenAnimationBuilderを使用するときとまったく同じように、これが私たちが推奨する主な理由です）。すべての開発者は、デフォルトでアニメーターを手動で管理するよりも使用します）。

開発者にそれについて考えさせないことについての私の心配は、物事がいつ割り当てられて処分されるかについて考えないと、必ずしも必要ではない多くのものを割り当てたり、必要のないロジックを実行したりする可能性が高くなることです。実行する必要がある、またはコードの効率を低下させる他のことを行う必要があります。 これが、これをデフォルトの推奨スタイルにすることを躊躇する理由の1つです。

AnimationControllerコンストラクター引数を受け取り、それらを使用して正しい処理を行うAnimationControllerPropertyを作成することもできます（たとえば、ホットリロードの期間が変更された場合は更新します）。

@Hixieに感謝し

開発者がこれらのことを決して考えるべきではないことを示唆しているわけではありませんが、99％のユースケースでは、これらのことはほとんどの場合、使用されているStatefulWidgetにバインドされており、それ以外のことを行うと、すでに中間の開発者の領域に移動していると思います。

繰り返しますが、これが生のAnimatorControllerよりもTweenAnimationBuilderを推奨することと根本的にどのように違うのかわかりません。 これは、このようにその単純かつより堅牢にそれを行う、その後、（それが何をしたい通常は）あなたが状態をしたい場合は、完全に含まれている/この他の状態で管理することを基本的な考え方です。

この時点で、電話をかけ、さまざまな利害関係者と話し合う必要があります。
同じ質問に何度も答えているので、この議論は進んでいないからです。

非常に多くの議論がなされたこのような長い議論の後、ビルダーがStatefulWidgetと比較して間違いを回避しない、またはフックが生のStatefulWidgetsよりも再利用可能ではないと主張できる方法がわかりません。

これは、すべての主要な宣言型フレームワーク（React、Vue、Swift UI、Jetpack Compose）がこの問題をネイティブに解決する方法を持っていることを考えると、特にイライラします。
Flutterだけがこの問題の検討を拒否しているようです。

@esDotDev IMHOがAnimationBuilder、TweenAnimationBuilder、またはValueListenableBuilderを使用する主な理由は、ホストウィジェットの残りの部分を再構築せずに、値が変更されたときにのみ再構築するためです。 それはパフォーマンスの問題です。 冗長性やコードの再利用についてではありません。 つまり、これらの理由で役立つと思われる場合は、これらの理由でも使用できますが、少なくとも私にとっては、それが主なユースケースではありません。 それはまた、プロパティ（またはフック）があなたに与えないものでもあります。 これらを使用すると、何かが変更されたときに_entire_ウィジェットを再構築することになり、パフォーマンスに悪影響を及ぼします。

@rrousselGit

Flutterだけがこの問題の検討を拒否しているようです。

私は今週末、文字通り何時間も自分の時間を過ごしました。それ以前のGoogleの時間は言うまでもなく、この問題を検討し、考えられる解決策を説明し、解決しようとしていることを正確に引き出しようとしています。 何が問題なのか理解不足と混同しないでください。 特に、これを前進させるためにできる最善のことをすでに説明した場合（「冗長すぎる、または難しすぎる」すべての状態ロジックを備えたデモアプリを作成し、問題のタイトルを引用し、再利用する）、このバグに関する他の人がタスクとして引き受けており、あなたは参加を拒否しています。

The main reason IMHO to use an AnimationBuilder or TweenAnimationBuilder or ValueListenableBuilder is that they rebuild only when the value changes, without rebuilding the rest of their host widget. It's a performance thing.

面白い。 私たちにとって、このような小さな再構築を保存することによるパフォーマンスの向上を実際に測定または観察したことはありません。 大規模なアプリコードベースでは、コードを簡潔で読みやすく、数週間ごとに数百のクラスファイルをキックアウトするときに発生する可能性のある日常的なエラーがないようにすることがはるかに重要です。

私たちの経験から、RepaintBoundariesを定義することを意図していない限り、ツリー全体に発生するように見えるピクセルの再描画のコストは、部分的なウィジェットレイアウトのコストよりも実際のパフォーマンスの要因として非常に重要です。 特に4Kモニターの範囲に入るとき。

しかし、これは、ビルダーが実際にこの種のことを理解する良い例です。 サブコンテキストを作成したい場合は、ビルダーが理にかなっており、そこに到達するための優れた方法です。

多くの場合、そうしません。この場合、Builderはクラッターを追加しているだけですが、それを受け入れます。代替手段は単なる異なるタイプのクラッターであり、少なくともBuilderでは、多かれ少なかれバグがないことが保証されています。 ビュー全体が再構築される場合、またはビルダーを使用してビューが再構築されるとは限らない場合（TextEditingController、FocusController）はほとんど意味がなく、すべての場合において、ボイラープレートを手動で回転させることは基本的にDRYではありません。

パフォーマンスの問題がしばしばあるように、それは確かに非常に状況固有です。 そのスタイルが好きなら、フックやプロパティのようなものを使うのは理にかなっていると思います。 それは今日可能であり、フレームワークから余分なものを必要としないようです（そして、プロパティが示すように、それは実際には多くのコードを必要としません）。

いいえ。ただし、コミュニティにTweenAnimationBuilderとValueListenableBuilderを構築するように依頼し、構築するStatefulWidgetを提供しないのと少し似ています。

あなたが求めているわけではありませんが、このタイプのアーキテクチャの主な利点の1つは、簡単に共有できる小さな小さなコンポーネントに自然に役立つことです。 小さな基礎部分を1つ配置すると...

StatefulWidgetは、Propertyと比較して、コードの_lot_であり、重要です（ほとんどがグルーコードであるPropertyとは異なります）。 とはいえ、プロパティが広く再利用するのが理にかなっている場合（正確なニーズに基づいてアプリケーションやチームごとにオーダーメイドのバージョンを作成するのではなく）、その使用を支持する人にパッケージを作成してアップロードすることをお勧めしますpub 。 確かに、同じことがフックにも当てはまります。 コミュニティが気に入っているものであれば、プロバイダーと同じように多くの用途があります。 フレームワーク自体にそのようなものを入れる必要がある理由は明らかではありません。

これは本質的に拡張可能だからだと思います。 プロバイダーはそうではありません、それは単なるツールです。 これは、StatefulWidgetと同じように、StatefulComponents用に拡張されるように作成されたものです。 それが比較的些細なことであるという事実は、必ずしもそれに対して保持されるべきではありませんか？

「このスタイルを好む人」についてのメモ。 3つのオーバーライドと15〜30行を節約できれば、ほとんどの場合、読みやすさが向上します。 客観的に言えばイモ。 また、2つのクラス全体のエラー（物を処分するのを忘れる、depsを更新するのを忘れる）を客観的に排除します。

素晴らしい議論をありがとう、これがどこに行くのか見て興奮しています、私は間違いなくここにそれを残します:)

申し訳ありませんが、このスレッドは、私が取り組んでいる別のプロジェクトを終了するときに計画されていたフラッターに戻ることに幻滅しました。 私も欲求不満を感じます

これは、すべての主要な宣言型フレームワーク（React、Vue、Swift UI、Jetpack Compose）がこの問題をネイティブに解決する方法を持っていることを考えると、特にイライラします。

このスレッドで問題が何度も何度も明確に説明されているため、フラッターサンプルアプリの構築に時間を費やすべきではないと思うという点で、
また、アプリを作成するにはソリューションが必要なため、ソリューションを探している場合は、フラッターでアプリを作成することはできません。 この会話のフラッターの人々は少なくともかなりはっきりしているので、彼らはフックが好きではありません。 そして、Flutterには、OPで説明されている問題に対する別の解決策がありません。 どのように書くべきか。

これは（少なくとも私には）真剣に受け止められていないと感じています。@ Hixie 、申し訳ありません。We understand the problem and want to solve itという意味で真剣に受け止められていないということです。 他の宣言型フレームワークと同様に、明らかに実行されたようです。
別の、しかし同じ種類の次のようなものについて：

書くのは簡単ですか？
開発者はフックの書き方を学ぶ必要がありますが、これは新しい概念なので、とても難しいです

私を悲しくさせる。 なぜこれまでに何かを改善または変更するのですか？ 何があっても、いつでもその議論をすることができます。 たとえ新しい解決策が一度学べばはるかに簡単で楽しいものであったとしても。 そのステートメントのフックを多くのものに置き換えることができます。 私の母は30年前にマイクロ波についてそのような文章を使うことができたでしょう。 たとえば、文の「フック」を「フラッター」または「ダーツ」に置き換えても同じように機能します。

書くのは簡単ですか？
同じなので、書くのも同じくらい簡単で、かなり簡単です。

@rrousselGitがis it easier to write? （ブール回答の質問）で意味することは、同じであれば答えはfalse / undefinedはないということではないと思います。

問題があることに同意すらしていないので、どうやってどこかに行くことができるのかわかりません。多くの人がこれを問題だと思っているだけです。 例えば：

それは確かに人々が育ててきたものです。 それは私が内臓の経験を持っているものではありません。 Flutterを使って自分のアプリを書くときに問題だと感じたものではありません。 しかし、それは一部の人々にとってそれが本当の問題ではないという意味ではありません。

そして、多くの人が何度も多くの議論を提供してきましたが、なぜOPのソリューションをコアにする必要があるのか​​。
たとえば、サードパーティが現在ウィジェットを使用および作成するのと同じくらい簡単かつ自然に使用できるようにするには、コアに含める必要があります。 そして、他の複数の理由。 マントラは、パッケージに入れるだけのようです。 しかし、フックの1つとしてすでにパッケージがあります。 それが解決されたのであれば、スレッドを閉じてみませんか。

@rrousselGitを彼の申し出にかけてください。

とにかく、ライブで少し悲しいので、今は購読を解除しています-どこにも行かないので、このスレッドをフォローしてください。 しかし、このスレッドが問題があることに同意する状態になり、OPの可能な解決策に焦点を当てることができるようになることを願っています。 @Hixieがおそらく同意するように、人々が直面している問題を把握していない場合、解決策を提案するのは少し無駄に思えるので、問題のある人々は

人々がそれを望んでいるにもかかわらず、フラッターはコアでこの問題を解決するべきではないとただはっきりと言うことによって、このスレッドを終了することであなたに幸運を祈っています。 または解決策を見つけることによって。 😘

LayoutBuilderは、ほとんどのビルダーであるFWIWとは非常に異なるウィジェットです。 これまでに説明した提案はいずれも、LayoutBuilderのような問題には機能しません。また、コメントの前に説明した要件には、LayoutBuilderが含まれていません。 この新機能を使用してLayoutBuilderを処理する必要がある場合は、知っておくことが重要です。 @TimWhitingを使用して、提案のベースとなるサンプルアプリに、例としてレイアウトビルダーが含まれていることを確認することをお勧めします。

@Hixieはい、確かにいくつかのサンプルが必要です。 私は何かを準備します（しかし、サンプルが不完全である可能性があるため、コンパイラの変更が必要だと思います）。 一般的な考え方は、ビルダーをフラット化し、ビルダーの実装方法を気にしないシンタックスシュガーです。

それでも、Flutterチームの誰もSwiftUIを詳しく調べていないという印象を受けています。そうでなければ、私たちの懸念は理解しやすいと思います。 フレームワークの将来にとって、他のプラットフォームから移行する人々ができるだけスムーズに乗ることが重要であるため、他のプラットフォームについての十分な理解と、賛否両論の知識が必要です。 そして、Flutterの短所のいくつかを修正できるかどうかを確認します。 明らかに、FlutterはReactから多くの優れたアイデアを取り入れており、新しいフレームワークでも同じことができます。

@ emanuel-lundman

これは（少なくとも私には）真剣に受け止められていないと感じています。@ Hixie 、申し訳ありません。We understand the problem and want to solve itという意味で真剣に受け止められていないということです。 他の宣言型フレームワークと同様に、明らかに実行されたようです。

私は問題を理解していないことに完全に同意します。 だから私はこの問題に取り組み続け、理解しようとしています。 そのため、問題をカプセル化したデモアプリを作成することを提案しました。 最終的にフレームワークを根本的に変更するか、フレームワークに小さな機能を追加するか、パッケージによって修正するかどうかは、実際には問題が何であるかによって異なります。

@szotp

それでも、Flutterチームの誰もSwiftUIを詳しく調べていないという印象を受けています。そうでなければ、私たちの懸念は理解しやすいと思います。

私はSwiftUIを研究しました。 Swift UIコードを書くことは、Flutterコードよりも確かに冗長ではありませんが、読みやすさのコストは非常に高くなります。 多くの「魔法」があります（つまり、コンシューマーコードでは明らかではない方法で機能するロジック）。 一部の人が好むスタイルだと完全に信じることができますが、Flutterの強みの1つは、魔法がほとんどないことでもあると思います。 それはあなたが時々より多くのコードを書くことを意味しますが、それはまたそのコードのデバッグが_はるかに_簡単であることを意味します。

フレームワークにはたくさんのスタイルの余地があると思います。 MVCスタイル、Reactスタイル、非常に簡潔な魔法、魔法のない、しかし冗長な... Flutterのアーキテクチャの利点の1つは、移植性の側面がフレームワーク自体から完全に分離されているため、すべてのツールを活用できることです。 -クロスプラットフォームのサポート、ホットリロードなど-しかし、まったく新しいフレームワークを作成します。 （flutter_spritesなどの他のFlutterフレームワークがすでにあります。）同様に、フレームワーク自体は階層化された方法で設計されているため、たとえば、すべてのRenderObjectロジックを再利用できますが、Widgetsレイヤーの代わりになります。ウィジェットが多すぎるので、誰かがそれを置き換える代替フレームワークを作成する可能性があります。 そしてもちろん、パッケージングシステムがあるので、既存のフレームワークコードを失うことなく機能を追加できます。

とにかく、ここでの私の余談のポイントは、これがオールオアナッシングではないということです。 長期的には、あなたを幸せにするソリューションを採用することにならない場合でも、それはあなたが好きな製品の部分から利益を享受し続けることができないという意味ではありません。

この問題に関心のある人は、 @ TimWhitingと様子を示すアプリを作成することをお勧めします（https://github.com/TimWhiting/local_widget_state_approaches）。 これは、ここでコメントしているすべての人々（フックが好きな人と嫌いな人を含む）のニーズに対応する方法でこの問題に対処する方法の提案を作成するのに直接役立ちます。

「_ビルダーをフラット化し、ビルダーの実装方法を気にしないシンタックスシュガー。_」がファーストクラスの機能として開発者に望まれる理由を理解するのはそれほど難しいことではありません。 代替アプローチの問題を何度も概説してきました。

要するに、ビルダーは再利用性の問題を解決しますが、読みやすく、構成するのは困難です。 「問題」は、非常に読みやすいビルダーのような機能が必要なことです。

3つのネストされたビルダーが読みにくいこと、またはビルダーが一般にコードの再利用の目的を実際に果たしていないことに基本的に同意しない場合、アプリはそれをより明確に示すことはできません。 私たちの多くは実際にはネストを減らすのが本当に好きで、アプリケーション全体にコードを複製するのは本当に好きではないので、2つの非理想的なオプションの間に立ち往生していると聞いてさらに重要です。

私は今週末、文字通り何時間も自分の時間を過ごしました。それ以前のGoogleの時間は言うまでもなく、この問題を検討し、考えられる解決策を説明し、解決しようとしていることを正確に引き出しようとしています。

ありがたいです

何が問題なのか理解不足と混同しないでください。

理解が足りなくても大丈夫ですが、現状は絶望的です。
議論の冒頭で指摘された点については、まだ議論中です。

私の観点からは、さまざまな問題を紹介する詳細なコメントを書いたり、質問に答えたりするのに何時間も費やしたような気がしますが、私のコメントは却下され、同じ質問が再度出されました。

たとえば、現在の構文の可読性の欠如が議論の中心にあります。
これを裏付けるために、読みやすさの問題をいくつか分析しました。

• https://github.com/flutter/flutter/issues/51752#issuecomment -669626522
• https://github.com/flutter/flutter/issues/51752#issuecomment -670959424

これらの分析にはかなりの数があります👍そして他の人々は同意しているようです

それでも最近の回答によると、読みやすさの問題はありません： https ：

あなたも提案しました：

Widget build(context) {
  var result = Text('result:');
  var builder1 = (BuildContext context, AsyncSnapshot<int> snapshot) {
    return Row(children: [result, Text(snapshot.data)]);
  };
  result = StreamBuilder(stream: _stream1, builder: builder1);
  var builder2 = (BuildContext context, AsyncSnapshot<int> snapshot) {
    return Column(children: [result, Text(snapshot.data)]);
  };
  result = StreamBuilder(stream: _stream2, builder: builder2);
}

これが読めないことを知っている

これらの2つのコメントから、次のように結論付けることができます。

• 読みやすさの問題があることに同意しません
• 読みやすさがこの問題の範囲の一部であるかどうかはまだ不明です

フックの唯一の目的がビルダーの構文を改善することであることを考えると、これは聞いてがっかりします。ビルダーは再利用性のピークにありますが、読みやすさや書き込み性が劣っています。
そのような基本的な事実に同意しないと、私たちに何ができるかわかりません。

@Hixieありがとう、これはあなたの視点を理解するのに大いに役立ちます。 私は彼らがコードマジックで行き過ぎたかもしれないことに同意します、しかし私は彼らが正しかったことは少なくともいくつかあると確信しています。

そして、私はFlutterのレイヤードアーキテクチャがとても好きです。 ウィジェットも使い続けたいです。 したがって、おそらく答えは、Dart＆Flutterの拡張性を改善することです。これは私にとっては次のようになります。

コード生成をよりシームレスにします-DartでSwiftUIマジックを実装することは可能かもしれませんが、必要な通常のセットアップは大きすぎて遅すぎます。

コード生成の使用がパッケージのインポートといくつかの注釈の平手打ちのように単純である場合、議論された問題を抱えている人々はそれを行うだけで文句を言うのをやめます。 残りは、古き良きStatefulWidgetsを直接使用し続けます。

編集： flutter generateは良い方向への一歩だったと思います、それが削除されたことを残念に思います。

これは、次のFlutter DeveloperSurveyで尋ねる非常に興味深い質問になると思います。

それは良いスタートになるでしょう。 この問題をさまざまな部分/質問に分けて、これがFlutter開発者が解決したい本当の問題であるかどうかを確認してください。

それが明確になると、この会話はより流暢で豊かになります

私の観点からは、さまざまな問題を紹介する詳細なコメントを書いたり、質問に答えたりするのに何時間も費やしたような気がしますが、私のコメントは却下され、同じ質問が再度出されました。

同じ質問をしているのは、答えがわからないからです。

たとえば、以前のコメント（https://github.com/flutter/flutter/issues/51752#issuecomment-670959424）に戻ります。

議論されている問題は次のとおりです。

Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}

このコードは読み取り可能ではありません。

私はそれについて読めないものが本当にわかりません。 それは何が起こっているのかを正確に説明しています。 4つのウィジェットがあります。3つのウィジェットにはビルダーメソッドがあり、1つには文字列があります。 個人的には型を省略しませんが、変数が何なのかわからないので読みづらくなると思いますが、大きな問題ではありません。

なぜこれが読めないのですか？

明確にするために、明らかにあなたはそれが読めないことに気づきます、私はあなたが間違っていると言っているのではありません。 理由がわかりません。

構文を次のように変更する新しいキーワードを導入することで、読みやすさの問題を修正できます。

Widget build(context) {
  final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);
  final value2 = keyword StreamBuilder(stream: someStream);
  final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

  return Text('$value $value2 $value3');
}

このコードは非常に読みやすく、フックとは無関係であり、制限の影響を受けません。

確かに冗長ではありません。 少なくとも私にとっては、これ以上読みやすいかどうかはわかりません。 より多くの概念があります（現在、ウィジェットとこの「キーワード」機能の両方があります）。 より多くの概念はより多くの認知的負荷を意味します。 （これらのオブジェクトがどれだけ独立しているかによっては、効率が低下する可能性もあります。たとえば、アニメーションが常にリッスン可能な値とストリームよりも頻繁に変更される場合、通常はトリガーされないにもかかわらず、ValueListenableBuilderとStreamBuilderを再構築しています。 ;また、初期化ロジックを入力して、ビルドごとにスキップする必要があります。）

冗長性は問題ではないとおっしゃっていたので、簡潔であることが読みやすい理由ではないと思います（ただし、問題のタイトルとに「冗長すぎる」と入力したため、これについても混乱しています。問題の元の説明）。 インデントを減らしたいとおっしゃいましたが、インデントなしでビルダーを使用するバージョンも判読できないと説明したので、おそらく問題はオリジナルのインデントではありません。

ビルダーは再利用性のピークであり、別の構文が必要だと言いますが、提案した提案はビルダーのようなものではないため（ウィジェットや要素を作成しません）、特にビルダーの側面ではありません。探している。

あなたはあなたが好きな解決策（フック）を持っています、それは私が知る限りうまくいきます、しかしあなたは人々がフックを使うようにフレームワークで何かを変えたいですか？ 私も理解していません。なぜなら、人々がフックをパッケージとして使用するのに十分なほど好きではない場合、それはおそらくフレームワークにとっても良い解決策ではないからです（一般的に、私たちはパッケージ、さらには機能を使用する方向に進んでいますFlutterチームは、その価値のために作成します）。

コードをより簡単に再利用したいという要望があることを理解しています。 それが何を意味するのかわかりません。

以下は、読みやすさにおいて上記の2つのバージョンとどのように比較されますか？

Widget build(context) {
  return
    ValueListenableBuilder(valueListenable: someValueListenable, builder: (context, value, _) =>
    StreamBuilder(stream: someStream, builder: (context, value2) =>
    TweenAnimationBuilder(tween: Tween(...), builder: (context, value3) =>
    Text('$value $value2 $value3'),
  )));
}

@szotp現在のcodegenソリューションにあまりにも多くの摩擦がある場合は、そこで改善を求めるバグを提出することを躊躇しないでください。

@jamesblasco人々が解決したい本当の問題がここにあることに疑いの余地はないと思います。 私にとっての問題は、まさにその問題が何であるかということです。そうすれば、解決策を設計することができます。

フックの欠陥やコードに含めたいという懸念に答えることはできましたが、今はそれを重視すべきではないと思います。

まず、問題が何であるかについて合意する必要があります。 そうしないと、他のトピックについてどのように合意できるかわかりません。

私はそれについて読めないものが本当にわかりません。 それは何が起こっているのかを正確に説明しています。 4つのウィジェットがあります。3つのウィジェットにはビルダーメソッドがあり、1つには文字列があります。 個人的には型を省略しませんが、変数が何なのかわからないので読みづらくなると思いますが、大きな問題ではありません。

ここでの問題の大部分は、コーディングの方法がほとんどの人のコーディング方法と大幅に異なることだと思います。

たとえば、Flutterとあなたが両方を与えたアプリの例：

• dartfmtを使用しないでください
• always_specify_typesを使用する

これらの2つのポイントだけで、それがコミュニティの1％以上を占めるとしたら、私は驚きます。

そのため、読み取り可能と評価するものは、ほとんどの人が読み取り可能と考えるものとは大きく異なる可能性があります。

私はそれについて読めないものが本当にわかりません。 それは何が起こっているのかを正確に説明しています。 4つのウィジェットがあります。3つのウィジェットにはビルダーメソッドがあり、1つには文字列があります。 個人的には型を省略しませんが、変数が何なのかわからないので読みづらくなると思いますが、大きな問題ではありません。

なぜこれが読めないのですか？

私の推奨は、特定のものを検索するときにあなたの目がどこを見ているか、そしてそこに到達するために何ステップかかるかを分析することです。

実験してみましょう：
2つのウィジェットツリーを提供します。 1つは線形構文を使用し、もう1つはネストされた構文を使用します。
また、そのスニペットで探す必要のある具体的な事項についても説明します。

線形構文またはネストされた構文を使用することに対する答えを見つけるのは簡単ですか？

質問：

• このビルドメソッドによって返される非ビルダーウィジェットは何ですか？
• 誰が変数barを作成しますか？
• ビルダーはいくつありますか？

ビルダーの使用：

ウィジェットビルド（コンテキスト）{
 ValueListenableBuilderを返します（（
 valueListenable：someValueListenable、
 ビルダー：（context、foo、_）{
 StreamBuilderを返す（（
 ストリーム：someStream、
 ビルダー:(コンテキスト、baz）{
 TweenAnimationBuilderを返す（（
 トゥイーン：トゥイーン（...）、
 ビルダー:(コンテキスト、バー）{
 Container（）;を返します。
 }、
 ）;
 }、
 ）;
 }、
 ）;
 }

ウィジェットビルド（コンテキスト）{
 最終的なfoo =キーワードValueListenableBuilder（valueListenable：someValueListenable）;
 最終バー=キーワードStreamBuilder（stream：someStream）;
 最終的なbaz =キーワードTweenAnimationBuilder（tween：Tween（...））;

 Image（）;を返す
 }

Widget build(context) {
  return ValueListenableBuilder(
      valueListenable: someValueListenable,
      builder: (context, value, _) => StreamBuilder(
          stream: someStream,
          builder: (context, value2) => TweenAnimationBuilder(
                tween: Tween(),
                builder: (context, value3) => Text('$value $value2 $value3'),
              )));
}

Widget build(context) {
  final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);
  final value2 = keyword StreamBuilder(stream: someStream);
  final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

  return Text('$value $value2 $value3');
}

Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}

なぜこれが読めないのですか？

ネスティングがあるため、ネスティングを使用すると、無視できる部分と、何が起こっているのかを理解するために不可欠な部分をすばやくスキャンして知ることが難しくなります。 コードは本質的に「シーケンシャル」ですが、ネストはこれを隠します。 ネストはまた、それを操作するのを難しくします-2つのものを並べ替えたいと想像してください-または2つの間に新しいものを注入します-真のシーケンシャルコードでは簡単ですが、ネストを操作する必要がある場合は困難です。

これはasync / awaitsugarと生のFutureAPIでの作業に非常に似ており、その下に継続ベースの概念があります（そして賛成と反対の議論も非常に似ています）-はいFuture APIは直接使用でき、何も隠しませんが、読みやすさと保守性確かに良くありません-async / awaitが勝者です。

私の推奨は、特定のものを検索するときにあなたの目がどこを見ているか、そしてそこに到達するために何ステップかかるかを分析することです。

私は25年間、10以上の異なる言語でプログラミングを行ってきましたが、それはコードを読みやすくするものを評価するためのより悪い方法です。 ソースコードの読みやすさは注意が必要ですが、「私の目がどこを見ているか」や使用するコードの行数ではなく、プログラミングの概念とロジックをどれだけうまく表現するかが重要です。

むしろ、皆さんは読みやすさに重点を置きすぎて、保守性に重点を置いていないようです。

コードの__intent__がわかりにくく、同じ場所にさまざまな懸念事項が隠されていると、保守が難しくなるため、例は読みにくくなります。

final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);

価値は何でさえありますか？ ウィジェット？ 文字列変数？ 私はそれが内部で使用されていることを意味します
return Text('$value $value2 $value3');

基本的に必要なのは、ウィジェットBのbuildメソッドで変数Aを参照することにより、Aの値が変更されるたびにBを再構築する必要があるということです。 それは文字通りmobxが行うことであり、適切な量の魔法/ボイラープレートで正確に行います。

final value2 = keyword StreamBuilder(stream: someStream);

これは何を返す必要がありますか？ ウィジェット？ ストリーム？ 文字列値？

繰り返しますが、文字列値のように見えます。 したがって、buildメソッドでストリームを単純に参照し、ストリームが値を発行するたびにそのウィジェットを再構築し、発行された値にアクセスできるようにし、ウィジェットが作成/更新されるたびにストリームを作成/更新/破棄できるようにする必要があります。 /破壊されました？ 1行のコードで？ ビルドメソッドの内部？

はい、mobxを使用すると、ビルドメソッドを「より読みやすい」例とまったく同じように見せることができます（オブザーバブルを参照する場合を除く）。 フックの場合と同じように、すべての作業を実行する実際のコードを作成する必要があります。 実際のコードは約10行で、どのウィジェットでも再利用できます。

final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

文字列を返す「TweenAnimationBuilder」というクラス？！ なぜこれがひどい考えなのか、私は近づいていません。

以下の間でインデント/読みやすさに違いはありません。

Future<double> future;

AsyncSnapshot<double> value = keyword FutureBuilder<double>(future: future);

と：

Future<double> future;

double value = await future;

どちらもまったく同じことを行います。オブジェクトをリッスンし、その値をアンラップします。

私はそれについて読めないものが本当にわかりません。 それは何が起こっているのかを正確に説明しています。 4つのウィジェットがあります。3つのウィジェットにはビルダーメソッドがあり、1つには文字列があります。 個人的には型を省略しませんが、変数が何なのかわからないので読みづらくなると思いますが、大きな問題ではありません。

同じ議論がPromise / Futureチェーンにも当てはまります。

foo().then(x =>
  bar(x).then(y =>
    baz(y).then(z =>
      qux(z)
    )
  )
)

vs

let x = await foo();
let y = await bar(x);
let z = await baz(y);
await qux(z);

最初の書き方では、Promiseが内部で作成されていること、およびチェーンがどのように正確に形成されているかが明確になっていると言えます。 あなたがそれを購読しているのか、それともPromisesが構文に値するという点でBuildersとは根本的に異なると考えているのだろうか。

文字列を返す「TweenAnimationBuilder」というクラス？！ なぜこれがひどい考えなのか、私は近づいていません。

Promises / Futuresについても同じ議論をすることができ、 awaitはPromiseを返すという事実を覆い隠していると言うことができます。

構文を介して物事を「アンラップ」するという考えは、ほとんど新しいものではないことに注意する必要があります。 はい、主流の言語ではasync / awaitを介して提供されていましたが、たとえば、F＃には、一部のハードコアFP言語のdo表記に似た計算式があります。 そこでは、それははるかに強力であり、特定の法則を満たす任意のラッパーで動作するように一般化されています。 モナドをダートに追加することを提案しているわけではありませんが、非同期呼び出しに必ずしも対応しないものを「アンラップ」するためのタイプセーフな構文の前例があることは間違いなくあると思います。

一歩後退して、ここの多くの人々が（私自身も含めて）苦労していることの1つは、読みやすさについてのこの質問だと思います。 @rrousselGitが述べたように、現在のBuilderベースのアプローチでは、この可読性の問題のスレッド全体に多くの例があります。 私たちの多くにとって、これは自明のようです。

Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}

これよりも大幅に読みにくくなります。

Widget build(context) {
  final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);
  final value2 = keyword StreamBuilder(stream: someStream);
  final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

  return Text('$value $value2 $value3');
}

しかし、 @ Hixieと@Rudikszは、2番目の方が最初の方より読みやすいという考えに納得していない（または積極的に反対している）ため、明らかに自明ではありません。

したがって、2番目のコードブロックが最初のコードブロックよりも読みやすい理由についての私の内訳は次のとおりです（少しでも価値があります）。

1.最初のコードボックは2番目のコードボックよりも大幅にインデントされています

私の経験では、インデントは通常、非同期性、分岐、またはコールバックと同等であり、これらはすべて、インデントされていない線形コードよりも多くの認知的負荷を必要とします。 最初のコードブロックにはいくつかのインデントの層があり、そのため、ここで何が起こっているのか、そして最終的に何がレンダリングされているのか（単一のText ）を処理するのに取るに足らない時間がかかります。 たぶん、他の人々は彼らの心の中でそのくぼみを通して働くのが上手です。

2番目のコードブロックには、問題を軽減するインデントはありません。

2.最初のコードブロックは、その意図を表現するためにより多くの構文を必要とします

最初のコードブロックには、3つのreturnステートメント、3つのビルダーステートメント、3つのラムダヘッダー、3つのコンテキスト、そして最後に3つの値があります。 最終的に私たちが気にするのは、これら3つの価値観です。残りは、私たちをそこに導くための定型文です。 私は実際、これがこのコードブロックの最も難しい部分であると感じています。 非常に多くのことが起こっており、私が実際に気にかけている部分（ビルダーから返される値）は非常に小さいので、実際に必要な部分に集中するのではなく、精神的なエネルギーのほとんどをボイラープレートに費やしています（繰り返しますが、値）。

2番目のコードブロックでは、ボイラープレートが大幅に削減されているため、関心のある部分に焦点を当てることができます。これも値です。

3.最初のコードブロックは、ネストの最深部にあるbuildメソッドの最も重要な部分を非表示にします。

このbuildメソッドのすべての部分が重要であることを認識していますが、このスタイルの宣言型UIコードを読んでいるときに、私が通常探しているのは、表示されるものすべてです。ユーザー。この場合は、最も深いネストされたビルダーに埋め込まれたTextウィジェットです。 そのTextウィジェットは、前面と中央に配置されるのではなく、インデント、構文、および意図の複数のレイヤーに埋め込まれています。 これらのレイヤーの1つにColumnまたはRowをスローすると、さらに深くネストされ、その時点では、最もインデントされたセクションまでトレースするだけのメリットはありません。 。

2番目のコードブロックでは、返される実際のレンダリング可能なWidgetは関数の下部にあり、これはすぐにわかります。 さらに、OPが提案する構文のようなものがある場合、視覚的なWidget常に関数の下部にあることを期待できるため、コードがはるかに予測可能で読みやすくなります。

ネスティングに関しては、_tree_を表現するネスティングと_sequence_を表現するネスティングには違いがあります。

通常のView -> Textネスティングなどの場合、ネスティングは画面上の親子関係を表すため、重要です。 コンテキスト（Flutterにあるかどうかはわかりません）などの機能の場合、コンテキストのスコープを表します。 したがって、ネスト自体はそのような場合に重要な意味的意味を持ち、無視することはできません。 親と子の場所を入れ替えて、結果が同じになると期待することはできません。

ただし、ビルダーのネスト（Reactでは「レンダリングプロップ」とも呼ばれます）またはPromisesのネストでは、ネストは一連の変換/拡張を伝達ABuilder -> BBuilder -> CBuilderネストする場合、それらの親子関係は追加の意味を伝えません。

以下のスコープで3つの値すべてが使用可能である限り、それらのツリー構造は実際には関係ありません。 これは概念的に「フラット」であり、ネストは構文のアーティファクトにすぎません。 もちろん、それらは互いの値を使用する場合があります（この場合、順序が重要です）が、これはシーケンシャル関数呼び出しの場合にも当てはまり、ネストせずに実行できます。

これがasync/awaitが魅力的な理由です。 低レベルのメカニズムを説明する追加情報（Promisesの親子関係）を削除し、代わりに高レベルのインテント（シーケンスを説明する）に集中できるようにします。

ツリーはリストよりも柔軟な構造です。 しかし、各親に子が1つしかない場合、それは病理学的ツリー、

以前に「これは定型文ではない」と言ったので、これは実際には興味深いものですが、今では自分自身と矛盾しているように見えます。 ここには2つのことがあると思います。

ビルダー（または少なくともReactのレンダリングプロップ）は、それ自体が「再利用可能なロジック」問題の解決策（AFAIK）です。 それらをたくさん使用すると、人間工学的ではないというだけです。 インデントによって、同じコンポーネントで4つまたは5つ以上を使用することは当然お勧めできません。 次の各レベルは読みやすさのヒットです。

したがって、私には解決されていないように思われる部分は、ネストのリーダーコストを削減することです。 そして、その引数はasync / await場合とまったく同じ引数です。

次の理由により、読みにくくなっています。

• 空白の過度の使用はうまくスケーリングしません。 モニターには非常に多くの行しかありません。スクロールを強制すると、読みやすさが低下し、集中的な負荷が増加します。 すでに60行のウィジェットツリーがあり、ビルダーのためにさらに15行を強制したと想像してください。理想的ではありません。
• これはHzスペースを浪費しますが、これは余分なラッピングにつながることに制限されており、ラインスペースをさらに浪費します。
• それは、葉のノード、別名コンテンツを左側からさらに押し込み、一目で見つけるのが難しいツリーに押し込みます。
• 「主要なプレーヤー」または「非定型文」を一目で識別することは非常に困難です。 私の推論が始まる前に、私は「重要なものを見つける」必要があります。

これを確認するもう1つの方法は、ボイラープレート以外のコードを強調表示することです。これは、目で簡単に楽しむためにグループ化されているのか、目でスキャンする必要があるためにどこにでも散らばっているのかを示します。

強調表示すると、これは非常に簡単に推論できます。 それがないと、誰が何をどこで使用しているかを把握する前に、冗長性のチャンク全体を読み取る必要があります。

これと比較すると、強調表示は基本的に冗長です。私の目が他に行く場所がないためです。

おそらく、読みやすさと可読性に不一致があることは注目に値します。 @Hixieは、モノリシッククラスファイルに時間を費やしている可能性があります。そこでは、大規模なツリーを常に読んで理解する必要がありますが、通常のアプリ開発者は、何百もの小さなクラスを構築することに

参考までに、ReactのContextに相当するものは、放棄されたウィジェット/プロバイダーです。

それらの唯一の違いは、フックの前に反応する場合、Builderパターンを使用してコンテキスト/継承ウィジェットを使用する必要があったことです。

一方、Flutterには、単純な関数呼び出しで再構築をバインドする方法があります。
したがって、AttachedWidgetsを使用してツリーをフラット化するためのフックは必要ありません。これはBuilderの問題を回避する種類です。

ビルダーが必要になる頻度が少ないため、これがおそらく議論が難しい理由の1つです。

しかし、フックのようなソリューションを導入すると、 https：//github.com/flutter/flutter/issues/30062の両方が解決されることに言及する価値があり
およびhttps://github.com/flutter/flutter/issues/12992

また、Flutterは基本的にすべてツリーであり、私の意見では他の言語よりもはるかに多いため、 @ Hixieは深いネストされたツリーの読み取りに慣れているようです。 もちろん、Flutter自体の主要な開発者の1人として、彼はそれについてはるかに多くの経験を持っているでしょう。 Flutterは基本的に、 @ HixieがHTML5仕様を作成した経験があると思う、HTMLのように、深いネストを備えた左から右のフレームワークと考えることができます。 つまり、コードブロックの右端のポイントは、メインロジックと戻り値が存在する場所です。

しかし、ほとんどの開発者はそうではありません、またはロジックは再び、むしろ、ネストされた樹木に比べて、上から下に読んで、ここで、下の言語上から来ます。 これは、コードブロックの最下部にあります。 したがって、彼が読めるものは、他の多くの開発者にとって必ずしもそうではありません。そのため、ここで読みやすさに関する意見の二分法が見られる可能性があります。

それを見る別の方法は、私の脳が視覚的に編集するために必要なコードの量です。 私にとって、これは、ツリーから返されるものを解析する前に、脳が実行しなければならない「うなり声」を正確に表しています。

簡単に言えば、ビルダーバージョンは、文字通り追加の情報やコンテキストを追加せずに、垂直方向のフットプリントが4倍高く、コードをはるかにまばらな/分散した方法でパックします。 私の考えでは、それはオープンとシャットのケースであり、その理由だけで客観的に読みにくく、インデントの周りの追加の認知的負荷や、私たち全員がフラッターで扱ってきた中括弧を並べることさえ考慮していません。

私の目を空腹のCPUと考えてください。これは、処理用にさらに最適化されていますか？ :)

通常のView -> Textネスティングなどの場合、ネスティングは画面上の_親子関係_を表すため重要です。 コンテキスト（Flutterにあるかどうかはわかりません）などの機能の場合、コンテキストのスコープを表します。 したがって、ネスト自体はそのような場合に重要な意味的意味を持ち、無視することはできません。 親と子の場所を入れ替えて、結果が同じになると期待することはできません。

完全に同意し、私はこれについて先に述べました。 状態を持つ追加の非ビジュアルコントローラーを使用しているため、ビジュアル表示ツリーに追加のコンテキストレイヤーを作成することは意味がありません。 5つのアニメーターを使用して、ウィジェットの深さは5層になりましたか？ その高いレベルだけでも、現在のアプローチはちょっと臭いがします。

ここで私に飛び出す2つの問題があります。

1. 高価なリソースを使用する場合、それがどれほど難しい/明示的であるかについて、いくつかの意見の相違があるのではないかと思います。 Flutterの哲学は、開発者がそれらをいつどのように使用するかを真剣に考えるように、より困難/明示的にする必要があるというものです。 ストリーム、アニメーション、レイアウトビルダーなどは、簡単すぎると非効率的に使用される可能性のある重要なコストを表しています。

2. ビルドは同期ですが、アプリ開発者として扱う最も興味深いものは非同期です。 もちろん、ビルドを非同期にすることはできません。 Stream / Animation / FutureBuilderのようなこれらの便利な機能を作成しましたが、開発者が必要とするものに対して常に十分に機能するとは限りません。 おそらく、フレームワークでStreamやFutureBuilderをあまり使用していないことを示しています。

もちろん、非同期操作を操作するときは、常にカスタムレンダリングオブジェクトを作成するように開発者に指示するのが解決策ではないと思います。 しかし、このバグで私が見ている例では、非同期と同期の作業が混在しているため、待ちきれません。 ビルドは、すべての呼び出しで何かを生成する必要があります。

fwiw、Reactチームは、読みやすさの問題を1つの動機として再利用することに取り組みました。
フックの動機：コンポーネント間でステートフルロジックを再利用するのは難しい
Reactは、再利用可能な動作をコンポーネントに「アタッチ」する方法を提供していません...これを解決しようとするパターンに精通しているかもしれません...。 ただし、これらのパターンでは、コンポーネントを使用するときにコンポーネントを再構築する必要があります。これは、煩雑で、コードを追跡するのが難しくなる可能性があります。

これは、Flutterが現在ネイティブに「状態を構成する」方法を提供していない方法と非常によく似ています。 また、私たちビルダーがレイアウトツリーを変更し、操作がより面倒になり、「従うのが難しくなる」と、エコーが発生します。

@dnfield build毎回呼び出す必要がある場合は、フックをbuildメソッドに含まないようにして、ビルドが常に同期されるようにすることができます。つまり、 initStateクラス内にフックを配置します。 disposeはです。 フックを書く人から、そうすることに問題はありますか？

Promises / Futuresについても同じ議論をすることができ、 awaitはPromiseを返すという事実を覆い隠していると言うことができます。

いいえ、しません。 Awaitは、文字通り1つの機能の単なる構文糖衣です。 冗長なFuturesまたは宣言型構文を使用する場合、コードの__intent__は同じです。

ここでの要求は、まったく異なる懸念に対処するソースコードを同じ傘の下に移動し、あらゆる種類の異なる動作を1つのキーワードの背後に隠し、何らかの形で認知的負荷を軽減すると主張することです。

これは完全に誤りです。そのキーワードを使用するたびに、結果が非​​同期操作を実行したり、不要な再構築をトリガーしたり、長期間有効なオブジェクトを初期化したり、ネットワーク呼び出しを行ったり、ディスクからファイルを読み取ったり、静的な値を返したりするのかどうか疑問に思う必要があります。 。 これらはすべて非常に異なる状況であり、使用しているフックのフレーバーに精通している必要があります。

ここでのほとんどの開発者は、実装の詳細を気にせずにこれらの「フック」を使用できるため、このような詳細に煩わされることを嫌い、簡単な開発を望んでいることを議論から理解しています。
このいわゆる「フック」を完全な意味を理解せずに意地悪に使用すると、非効率的で悪いコードにつながり、人々が自分の足を撃ち殺す原因になります。したがって、「初心者開発者の保護」の問題さえ解決しません。

ユースケースが単純な場合は、そうです、フックを気ままに使用できます。 ビルダーは好きなだけ使用してネストできますが、アプリが複雑になり、コードの再利用が困難になるため、独自のコードとアーキテクチャにもっと注意を払う必要があると思います。 潜在的に数百万人のユーザー向けのアプリを作成している場合、重要な詳細を抽象化する「魔法」を使用することを非常に躊躇します。 今のところ、FlutterのAPIは非常に単純なユースケースには単純であり、誰でも非常に効率的な方法であらゆる種類の複雑なロジックを実装できる柔軟性を備えています。

@Rudiksz繰り返しますが、誰もあなたにフックへの移動を強制していません。 現在のスタイルは引き続き存在します。 この知識に直面してあなたの議論は何ですか？

とにかく、複数のフックが何らかの形でアプリをブロックしていることを確認した後でも、効率的なコードを記述できます。 現在のスタイルの場合と同じように、プロファイリングしたり、アプリを実行したりすると表示されます。

@Rudiksz繰り返しますが、誰もあなたにフックへの移動を強制していません。 現在のスタイルは引き続き存在します。 この知識に直面してあなたの議論は何ですか？

ああ、この同じ議論は、フレームワークの問題について不平を言っている人々にも当てはまります。 フックパッケージを使用しないように強制している人は誰もいません。

私はここで非常に鈍くなります。
この問題は、フック、ステートフルウィジェット、および誰が何を使用するかに関するものではなく、5行少ないコードを記述できるようにするために数十年のベストプラクティスを元に戻すことに関するものです。

あなたの議論は実際には機能しません。 この問題が発生した理由は、現在のモデルがすでにフレームワークにネイティブに存在しているため、flutter_hooksパッケージがフレームワークに何かを含めることで可能なすべてのことを実行しないためです。 議論は、flutter_hooksの機能をフレームワークにネイティブに移動することです。 あなたの議論は、私が現在のモデルでできることは何でも、フックパッケージでもできると仮定していますが、これは真実ではありません。この議論の他の人からのようです。 それらが真である場合、それは機能します。これは、フックがネイティブにフレームワークにあることも意味します。したがって、フックと非フックは同等であるため、フックベースと同様に現在のモデルを使用できます。モデル、それは私が主張していたものです。

コードを読みやすくすることがベストプラクティスであり、過度のネストはアンチパターンであることがわかっているため、ベストプラクティスがどこから来ているのかわかりません。 どのベストプラクティスを正確に参照していますか？

fwiw、Reactチームは、読みやすさの問題を1つの動機として再利用することに取り組みました。
フックの動機：コンポーネント間でステートフルロジックを再利用するのは難しい
Reactは、再利用可能な動作をコンポーネントに「アタッチ」する方法を提供していません...これを解決しようとするパターンに精通しているかもしれません...。 ただし、これらのパターンでは、コンポーネントを使用するときにコンポーネントを再構築する必要があります。これは、煩雑で、コードを追跡するのが難しくなる可能性があります。

FlutterがReactよりもはるかに素晴らしいことについてみんなが絶賛しているのを聞いています。 たぶんそれはReactのようにすべてを行うわけではないからですか？ 両方の方法を使用することはできません。FlutterがReactよりもはるかに進んでいるとは言えません。また、Reactとまったく同じようにすべてを実行するように依頼することもできません。

Flutterが特定の問題に使用することを決定したソリューションは、それ自体のメリットに基づいている必要があります。 私はReactに精通していませんが、どうやら私はいくつかの本当に素晴らしいテクノロジーを見逃しているようです。 ：/

FlutterがReactのようなすべてを行うべきだと主張している人はいないと思います。

しかし実際には、FlutterのウィジェットレイヤーはReactから大きく影響を受けています。 それは公式文書に記載されています。
その結果、ウィジェットにはReactコンポーネントと同じ利点と同じ問題の両方があります。

これは、Reactがこれらの問題に対処する上でFlutterよりも多くの経験を持っていることも意味します。
それは彼らにもっと長く直面し、彼らをよりよく理解しました。

したがって、Flutter問題の解決策がReact問題の解決策と類似していることは驚くべきことではありません。

@Rudiksz FlutterのユーザーAPIは、内部APIが異なる場合でも、Reactのクラスベースモデルと非常によく似ています（異なるかどうかはわかりませんが、内部APIに実際に

それらの類似性を考えると、上記のように、問題の解決策が類似しているように見えるのは当然のことです。

どうか、お互いに戦わないように頑張りましょう。

戦いが私たちを導く唯一のことは、この議論を殺し、解決策を見つけられないことです。

FlutterがReactよりもはるかに素晴らしいことについてみんなが絶賛しているのを聞いています。 たぶんそれはReactのようにすべてを行うわけではないからですか？ 両方の方法を使用することはできません。FlutterがReactよりもはるかに進んでいるとは言えません。また、Reactとまったく同じようにすべてを実行するように依頼することもできません。

Reactチームがフックを思いついたときに同様の動機を持っていたことを指摘し、ここで表明している懸念を検証します。 このタイプのコンポーネントベースのフレームワーク内で共通のステートフルロジックを再利用および結合する際に問題があることを確かに検証します。また、可読性、ネスト、およびビューの「クラッター」に関する一般的な問題に関する議論もある程度検証します。

私はReactで働いたことがなく、Flutterが大好きです。 ここで問題を簡単に確認できます。

@Rudiksz実践するまで、それが実際にパフォーマンスを発揮するかどうかは

@Hixieこれは、 HookWidgetとStatefulWidget両方でuserIdからユーザーのニックネームを表示するウィジェットを実装するために一般的なフラッターユーザーが持つ可能性のある旅の例です。

__フックウィジェット__

String useUserNickname(Id userid) {
  final name = useState("");
  useEffect(async () {
    name.value = "Loading...";
    name.value = await fetchNicknames()[userId;
  }, [userId]);
  return name.value;
}

class UserNickname extends HookWidget {

  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    return Text(nickname);
  }
}

__ステートフルウィジェット__

class UserNickname extends Widget {
  final userId;
  // ... createState() ...
}

class UserNicknameState extends State {

  String nickname= "";

   initState() {
     super.initState();
     fetchAndUpdate();
   }

   fetchAndUpdate() async {
      setState(() { this.nickname = "Loading..." });
      final result = await fetchNicknames()[widget.userId];
      setState(() { this.nickname = result });
    }


 void didUpdateWidget(oldWidget) { 
     if (oldWidget.userId != widget.userId) {
        fetchAndUpdate();
     }
   }

  Widget build(BuildContext context) {
    return Text(this.nickname);
  }
}

これまでのところ興味深いものは何もありません。 どちらのソリューションもかなり受け入れられ、簡単でパフォーマンスが高いです。
今、私たちは利用したいUserNickname内部でListView 。 ご覧のとおり、fetchNicknamesは、1つのニックネームだけでなく、ニックネームのマップを返します。 したがって、毎回呼び出すのは冗長です。 ここで適用できるいくつかのソリューション：

• fetchNicknames()ロジックの呼び出しを親ウィジェットに移動し、結果を保存します。
• キャッシュマネージャーを使用します。

最初の解決策は受け入れられますが、2つの問題があります。
1- UserNicknameはテキストウィジェットにすぎないため、役に立たなくなります。別の場所で使用する場合は、親ウィジェット（ ListView ）で行ったことを繰り返す必要があります。 。 ニックネームを表示するためのロジックはUserNickname属していますが、個別に移動する必要があります。
2-他の多くのサブツリーでfetchNicknames()を使用する可能性があるため、アプリケーションの一部だけでなく、すべてのアプリに対してキャッシュすることをお勧めします。

したがって、キャッシュマネージャーを選択し、 CacheManagerクラスにInheritedWidgetsまたはProviderます。

キャッシュのサポートを追加した後：

__フックウィジェット__

String useUserNickname(Id userid) {
  final context = useContext();
  final cache = Provider.of<CacheManager>(context);
  final name = useState("");
  useEffect(async () {
    name.value = "Loading...";
    var cachedValue = cache.get("nicknames");
    if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        cache.set("nicknames", result );
        cachedValue = result ;
    }
    final result = cachedValue[widget.userId];
    name.value = result ;
  }, [userId]);
  return name.value;
}

class UserNickname extends HookWidget {

  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    return Text(nickname);
  }
}

__ステートフルウィジェット__

class UserNickname extends Widget {
  final userId;
  // ... createState() ...
}

class UserNicknameState extends State {

  String nickname= "";
  CacheManager cache;

   initState() {
     super.initState();
     fetchAndUpdate();
     this.cache = Provider.of<CacheManager>(context);
   }

   fetchAndUpdate() async {
      setState(() { this.nickname = "Loading..." });
      var cachedValue = this.cache.get("nicknames");
      if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        this.cache.set("nicknames", result );
        cachedValue = result ;
      }
      final result = cachedValue [widget.userId];
      setState(() { this.nickname = result });
    }


 void didUpdateWidget(oldWidget) { 
     if (oldWidget.userId != widget.userId) {
        fetchAndUpdate();
     }
   }

  Widget build(BuildContext context) {
    return Text(this.nickname);
  }
}

ニックネームが変更されたときにクライアントに通知するソケットサーバーがあります。

__フックウィジェット__

String useUserNickname(Id userid) {
  final context = useContext();
  final cache = Provider.of<CacheManager>(context);
  final notifications = Provider.of<ServiceNotifications>(context);
  final name = useState("");

  fetchData() async {
    name.value = "Loading...";
    var cachedValue = cache.get("nicknames");
    if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        cache.set("nicknames", result );
        cachedValue = result ;
    }
    final result = cachedValue[widget.userId];
    name.value = result ;
   }

  useEffect(() {
     final sub = notifications.on("nicknameChanges", fetchData);
     return () => sub.unsubscribe();
   }, [])

  useEffect(fetchData, [userId]);
  return name.value;
}

class UserNickname extends HookWidget {

  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    return Text(nickname);
  }
}

__ステートフルウィジェット__

class UserNickname extends Widget {
  final userId;
  // ... createState() ...
}

class UserNicknameState extends State {

  String nickname= "";
  CacheManager cache;
  ServerNotification notifications;
  CancelableOperation sub;

   initState() {
     super.initState();
     fetchAndUpdate();
     this.cache = Provider.of<CacheManager>(context);
     this.notifications = Provider.of<ServerNotification>(context);
     this.sub = notifications.on("nicknameChanges", fetchAndUpdate);
   }

   dispose() {
      super.dispose();
      this.sub.unsubscribe();
   }

   fetchAndUpdate() async {
      setState(() { this.nickname = "Loading..." });
      var cachedValue = this.cache.get("nicknames");
      if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        this.cache.set("nicknames", result );
        cachedValue = result ;
      }
      final result = cachedValue [widget.userId];
      setState(() { this.nickname = result });
    }


 void didUpdateWidget(oldWidget) { 
     if (oldWidget.userId != widget.userId) {
        fetchAndUpdate();
     }
   }

  Widget build(BuildContext context) {
    return Text(this.nickname);
  }
}

これまでのところ、両方の実装は受け入れ可能であり、良好です。 統計的なもののIMOボイラープレートはまったく問題ありません。 この問題は、ユーザーのニックネームとアバターの両方を持つUserInfoようなウィジェットが必要な場合に発生します。 また、「Welcome [username]」のような文で表示する必要があるため、 UserNicknameウィジェットを使用することはできません。

__フックウィジェット__

useFetchUserNickname(userId) // old code
useUserAvatar(userId) // implementation like `useFetchUserNickname`

class UserNickname extends HookWidget {
  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    final avatar = useUserAvatar(userId);
    return Row(
      children: [Image.network(avatar), Text(nickname)],
    );
  }
}

しかし、__ステートフルウィジェット__の場合、作成したロジックだけを使用することはできません。 ロジックをクラス（提案したPropertyなど）に移動する必要がありますが、それでも新しいウィジェットでプロパティクラスを使用してウィジェットの接着剤を再度作成する必要があります。

最初の3つの例で変更が見られた場合、必要な変更は状態ロジックのみであり、変更を行った場所はすべて状態ロジックであったため、ウィジェット自体はまったく変更していません。
これにより、どこでも使用できる、クリーンな（意見のある）構成可能で完全に再利用可能な状態ロジックが得られました。

IMHOの唯一の問題は、 useUserNickname呼び出すことです。これは、1つの関数でこれだけのことができるためです。
しかし、本番環境にある2つのアプリ（フックを多用している）でflutter_hooksを反応させて使用した長年の経験から、適切な状態管理が行われていないことがわかります（MobXやその他の状態管理ソリューションも試しましたがウィジェットの接着剤は常にそこにあります）ははるかに怖いです。 フロントエンドアプリの画面ごとに5ページのドキュメントを作成する必要はありません。アプリのページがどのように機能するかを理解するために、最初のリリースから数か月以内に小さな機能を追加する必要がある場合があります。 アプリがサーバーを呼び出しすぎますか？ 簡単なタスク関連するフックに移動して変更すると、アプリ全体がそのフックを使用するため、アプリ全体が修正されます。 優れた抽象化を備えたフックを使用しなくても、アプリで同様のことを行うことができますが、私が言っているのは、フックはその優れた抽象化であるということです。

@gaearonは私よりもうまく

上記の例を見ると、上記のメソッド（ステートフルウィジェットとフックウィジェット）のどれも、他のメソッドよりもパフォーマンスが優れていません。 しかし、要点は、それらの1つが、パフォーマンスの高いコードを書くことを人々に奨励しているということです。

また、次のような更新（アニメーションなど）が多すぎる場合は、 StreamBuilderように更新する必要があるサブツリーのみを更新することもできます。

1- HookWidgetとStatefulWidget/StatelessWidget両方で完全に実行可能なオプションである新しいウィジェットを作成するだけです
2-親ウィジェットと子ウィジェットのデータが非常に緊密に結合されているため、 flutter_hooksパッケージでHookWidgetBuilderに類似したものを使用します。

補足：このトピックについて議論し、この問題にこれほど多くのエネルギーを注いでくれた@Hixieと@rrousselGitに本当に感謝しています。 これらの会談の結果を心から楽しみにしています。

@Hixieの出発点に基づいて、私はかなりクールでエレガントなものを考えています。 まだ共有する準備が整っていませんが、かなりまともなコードサンプルを作成できるので、非常に異質に見えるフックよりもapples：applesを比較する方が簡単だと思います。

したがって、次の署名を持つStatefulWidgetがあると想像してください。

class ExampleSimple extends StatefulWidget {
  final Duration duration1;
  final Duration duration2;
  final Duration duration3;

  const ExampleSimple({Key key, this.duration1, this.duration2, this.duration3}) : super(key: key);

  <strong i="9">@override</strong>
  _ExampleSimpleState createState() => _ExampleSimpleState();
}

バニラアニメーターコントローラーを使用して状態を実装すると、次のようになります。

class _ExampleSimpleVanillaState extends State<ExampleSimpleVanilla> with SingleTickerProviderStateMixin {
  AnimationController _anim1;
  AnimationController _anim2;
  AnimationController _anim3;

  <strong i="13">@override</strong>
  void initState() {
    _anim1 = AnimationController(duration: widget.duration1, vsync: this);
    _anim1.forward();
    _anim2 = AnimationController(duration: widget.duration2, vsync: this);
    _anim2.forward();
    _anim3 = AnimationController(duration: widget.duration3, vsync: this);
    _anim3.forward();
    super.initState();
  }

  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      margin: EdgeInsets.symmetric(vertical: _anim2.value * 20, horizontal: _anim3.value * 30,),
      color: Colors.red.withOpacity(_anim1.value),
    );
  }

  <strong i="15">@override</strong>
  void didUpdateWidget(ExampleSimpleVanilla oldWidget) {
    if (oldWidget.duration1 != widget.duration1) {
      _anim1.duration = widget.duration1;
    }
    if (oldWidget.duration2 != widget.duration2) {
      _anim1.duration = widget.duration1;
    }
    if (oldWidget.duration3 != widget.duration3) {
      _anim1.duration = widget.duration1;
    }
    super.didUpdateWidget(oldWidget);
  }

  <strong i="16">@override</strong>
  void dispose() {
    _anim1.dispose();
    _anim2.dispose();
    _anim3.dispose();
    super.dispose();
  }
}

StatefulPropertyを使用して作成すると、次のようになります。

class _ExampleSimpleState extends State<ExampleSimple> with StatefulPropertyManager {
  StatefulAnimationProperty _anim1;
  StatefulAnimationProperty _anim2;
  StatefulAnimationProperty _anim3;

  <strong i="6">@override</strong>
  void initStatefulProperties({bool firstRun = false}) {
    _anim1 = initProperty(_anim1, StatefulAnimationProperty(duration: widget.duration1, playOnInit: true));
    _anim2 = initProperty(_anim2, StatefulAnimationProperty(duration: widget.duration2, playOnInit: true));
    _anim3 = initProperty(_anim3, StatefulAnimationProperty(duration: widget.duration3, playOnInit: true));
    super.initStatefulProperties(firstRun: firstRun);
  }

  <strong i="7">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      margin: EdgeInsets.symmetric(vertical: _anim2.controller.value * 20, horizontal: _anim3.controller.value * 30,),
      color: Colors.red.withOpacity(_anim1.controller.value),
    );
  }
}

ここでの違いに関するいくつかの注意：

1. 上から、1つは20行、もう1つは45です。1つは1315文字、もう1つは825です。このクラスでは3行と200文字のみが重要であるため（ビルドで何が起こっているか）、これはすでに信号の大幅な改善です。
2. バニラオプションには、バグが発生する可能性のある複数のポイントがあります。 破棄するのを忘れたり、didChangeの処理を忘れたり、didChangeを間違えたりすると、コードベースにバグが発生します。 複数のタイプのコントローラーが使用されている場合、これはさらに悪化します。 次に、すべての異なるタイプのオブジェクトを破棄する単一の関数があります。これらのオブジェクトには、このように順番に名前が付けられることはありません。 それは厄介になり、間違いを犯したり、エントリを見逃したりするのは非常に簡単です。
3. バニラオプションは、playOnInitのような一般的なパターンやロジックを再利用するメソッドを提供しないため、このロジックを複製するか、アニメーターを使用する非常に単一のクラスでカスタム関数を作成する必要があります。
4. ここでSingleTickerProviderMixinを理解する必要はありません。これは「魔法」であり、ティッカーが何ヶ月も私にとって何であるかを難読化します（後から考えると、クラスを読むだけでよいのですが、すべてのチュートリアルには「この魔法のミックスインを追加する」と書かれています）。 ここでは、StatefulAnimationPropertyのソースコードを直接確認し、アニメーションコントローラーがティッカープロバイダーを直接およびコンテキストでどのように使用するかを確認できます。

代わりに、StatefulPropertyManagerの機能を理解する必要がありますが、これは一度学習してあらゆるタイプのオブジェクトに適用することが重要です。SingleTickerProviderMixinは、主にAnimator Controllerの使用に固有であり、すべてのコントローラーに独自のミキシングがあり、使用が簡単になり、面倒になります。 これらすべてを知っている個別の「StatefulObjects」を持っているだけで（ビルダーと同じように！）、はるかにクリーンで拡張性が高くなります。

StatefulAnimationPropertyのコードは次のようになります。

class StatefulAnimationProperty extends BaseStatefulProperty<StatefulAnimationProperty> implements TickerProvider {
  final Duration duration;
  final TickerProvider vsync;
  final bool playOnInit;

  StatefulAnimationProperty({<strong i="7">@required</strong> this.duration, <strong i="8">@required</strong> this.vsync, this.playOnInit = false});

  AnimationController get controller => _controller;
  AnimationController _controller;

  Ticker _ticker;

  <strong i="9">@override</strong>
  Ticker createTicker(onTick) {
    _ticker ??= Ticker((elapsed)=>handleTick(elapsed, onTick));
    return _ticker;
  }

  handleTick(Duration elapsed, TickerCallback onTick) {
    managerWidget.buildWidget(); //TODO: This just calls setState() on the host widget. Is there some better way to do this?
    onTick(elapsed);
  }

  <strong i="10">@override</strong>
  void init(StatefulAnimationProperty old) {
    _controller = old?.controller ??
        AnimationController(
          duration: duration ?? Duration(seconds: 1),
          vsync: vsync ?? this,
        );
    if (playOnInit && old?.controller == null) {
      _controller.forward();
    }
    super.init(old);
  }

  <strong i="11">@override</strong>
  void update(StatefulAnimationProperty old) {
    if (duration != old.duration) {
      _controller.duration = duration;
    }
    if (vsync != old.vsync) {
      _controller.resync(vsync);
    }
    super.update(old);
  }

  <strong i="12">@override</strong>
  void dispose() {
    _controller?.dispose();
    _ticker?.dispose();
    super.dispose();
  }
}

最後に、注目に値するのは、拡張機能を使用すると読みやすさがさらに向上するため、次のようなものにすることができます。

  void initStatefulProperties({bool firstRun = false}) {
    _anim1.init(duration: widget.duration1, playOnInit: true);
    _anim2.init(duration: widget.duration2, playOnInit: true);
    _anim3.init(duration: widget.duration3, playOnInit: true);
    super.initStatefulProperties(firstRun: firstRun);
  }

[編集]私自身の主張をするかのように、私のバニラの例にはバグがあります。 didUpdateWidgetの各アニメーターに正しい期間を渡すのを忘れました。 コードレビューで誰も気づかなかったとしたら、そのバグを実際に見つけるのにどれくらいの時間がかかりましたか？ 読んでいるときに誰かがそれを見つけませんでしたか？ それをそのままにしておくことは、現実の世界で起こっていることの完璧な例です。

これが鳥瞰図で、ボイラープレートが赤でマークされています。

これが純粋な定型文であればそれほど悪くはなく、コンパイラーはそれが欠落しているとあなたに怒鳴りました。 しかし、それはすべてオプションです！ また、省略した場合、バグが発生します。 したがって、これは実際には非常に悪い習慣であり、DRYではありません。 これがビルダーの出番ですが、単純なユースケースにのみ適しています。

これについて私が非常に興味深いと思うのは、100行とStateへの単純なミックスインが、既存のクラスの束を冗長にする方法です。 たとえば、TickerProviderMixinsを使用する必要はほとんどありません。 サブコンテキストを実際に作成したい場合を除いて、TweenAnimationBuilderを使用する必要はほとんどありません。 フォーカスコントローラーやtextInputコントローラーの管理など、従来の多くの問題点は大幅に緩和されています。 Streamsを使用すると、はるかに魅力的で不器用になります。 コードベース全体で、ビルダーの使用を一般的に減らすことができます。これにより、より簡単に樹木を取得できるようになります。

また、前述のFetchUserの例のように、独自のカスタム状態オブジェクトを_非常に_簡単に作成できます。これには、現在基本的にビルダーが必要です。

これは、次のFlutter DeveloperSurveyで尋ねる非常に興味深い質問になると思います。

それは良いスタートになるでしょう。 この問題をさまざまな部分/質問に分けて、これがFlutter開発者が解決したい本当の問題であるかどうかを確認してください。

それが明確になると、この会話はより流暢で豊かになります

各コメントの下の絵文字の反応は、コミュニティがこれを問題と見なしているかどうかについて明確な考えを示しています。 この問題について250以上の長いコメントを読んだ開発者の意見は、多くの私見を意味します。

@esDotDevこれは私が

私が苦労している主なことは、これを効率的な方法で行う方法です。 たとえば、ValueListenableBuilderは、パフォーマンスを測定可能に向上させるために使用できる子引数を取ります。 プロパティアプローチでそれを行う方法がわかりません。

@Hixie
このようなアプローチによる効率の低下は避けられないように思われることを理解しています。 しかし、コードをプロファイリングした後の最適化というFlutterの考え方が好きです。 プロパティアプローチの明確さと簡潔さから恩恵を受けるアプリケーションはたくさんあります。 コードをプロファイリングし、ビルダーにリファクタリングしたり、ウィジェットの一部を独自のウィジェットに分離したりするオプションは常にあります。

ドキュメントは、ベストプラクティスを反映し、トレードオフを明確にする必要があります。

私が苦労している主なことは、これを効率的な方法で行う方法です。 たとえば、ValueListenableBuilderは、パフォーマンスを測定可能に向上させるために使用できる子引数を取ります。 プロパティアプローチでそれを行う方法がわかりません。

うーん、プロパティの全体的なポイントは非視覚的なオブジェクトのためだと思います。 何かがツリーにコンテキストスロットを持ちたい場合、それはビルダーである必要があります（実際、これらは今私が思うビルダーである必要がある唯一のものですか？）

したがって、ビュー全体をバインドするだけの場合にほとんどの場合に使用するStatefulValueListenablePropertyがあります。 次に、ツリーのサブセクションを再構築する必要がある場合に備えて、ValueListenableBuilderも用意します。

ビルダーをリーフノードとして使用することは、ウィジェットツリーの上部に2つまたは3つをネストするほど読みやすさを損なうことはないため、これはネストの問題にも対処します。

@TimWhiting Flutterの設計哲学の大部分は、人々を正しい選択に導くことです。 パフォーマンスを向上させるために離れなければならないスタイルに従うように人々を奨励することは避けたいと思います。 一度にすべてのニーズに対応する方法はないかもしれませんが、私たちは間違いなくそれを試してみる必要があります。

@Hixie
ビルダーにとってこのようなものはどうですか？

class _ExampleSimpleState extends State<ExampleSimple> with StatefulPropertyManager {
  StatefulAnimationProperty _anim1;
  StatefulAnimationBuilderProperty _anim2;

  <strong i="7">@override</strong>
  void initStatefulProperties({bool firstRun = false}) {
    _anim1 = initProperty(_anim1, StatefulAnimationProperty(duration: widget.duration1, playOnInit: true));
    _anim2 = initProperty(_anim3, StatefulAnimationBuilderProperty(duration: widget.duration3, playOnInit: true));
    super.initStatefulProperties(firstRun: firstRun);
  }

  <strong i="8">@override</strong>
  Widget build(BuildContext context) {
    return Container(
      color: Colors.red.withOpacity(_anim1.controller.value),
      child: _anim2(child: SomeChildWidget()),
    );
  }
}

詳細を教えていただけますか？ 提案がよくわかりません。

彼は、StatefulPropertyが、視覚的なコンポーネントを持つプロパティにオプションのビルドメソッドを提供できると言っていると思います。

return Column(
   children: [
      TopContent(),
      _valueProperty.build(SomeChildWidget()),
   ]
)

これはかなり🔥imo、

はい、それが機能するかどうかはわかりませんが、buildメソッドは、ビルダーの他のプロパティがプロパティによって設定されることを除いて、通常のビルダーと同じように子を取ります。
ビルダーからのコンテキストが必要な場合、buildメソッドはコンテキストを提供するビルダー引数を受け入れます。

内部的には、メソッドは指定されたプロパティを使用して通常のビルダーを作成し、子引数を通常のビルダーに渡してそれを返す場合があります。

あなたがこのコードを持っていたとしましょう：

Widget build(BuildContext context) {
  return ExpensiveParent(
    child: ValueListenableBuilder(
      valueListenable: foo,
      child: ExpensiveChild(),
      builder: (BuildContext context, value, Widget child) {
        return SomethingInTheMiddle(
          value: value,
          child: child,
        );
      }
    ),
  );
}

...それをどのように変換しますか？

@esDotDevプロパティ自体をティッカープロバイダーにするというあなたのアイデアが好きですが、私はそれを考慮していませんでした。

このフックスタイルのアプローチの最も強力な側面の1つは、ステートフルロジックを_完全に_カプセル化できることです。 したがって、これらの場合、ACの完全なリストは次のとおりです。

1. ACを作成する
2. ティッカーを与える
3. ウィジェットの変更を処理する
4. ACとティッカーのクリーンアップを処理する
5. ティックでビューを再構築する

現在、開発者が1、3、4を手動で繰り返し処理する（または処理しない）ことと、2と5を処理する半魔法のSingleTickerProviderMixin（「this」をvsyncとして渡すことで、何ヶ月も混乱しました！ ）。 また、SingleTickerProviderMixin自体は、明らかにこのタイプの問題の修正を試みたものです。それ以外の場合は、クラスごとにTickerProviderを実装するだけでなく、はるかに明確になります。

あなたがこのコードを持っていたとしましょう：

Widget build(BuildContext context) {
  return ExpensiveParent(
    child: ValueListenableBuilder(
      valueListenable: foo,
      child: ExpensiveChild(),
      builder: (BuildContext context, value, Widget child) {
        return SomethingInTheMiddle(
          value: value,
          child: child,
        );
      }
    ),
  );
}

...それをどのように変換しますか？

class _ExampleSimpleState extends State<ExampleSimple> with StatefulPropertyManager {
  StatefulValueListenableBuilder _fooBuilder;

  <strong i="10">@override</strong>
  void initStatefulProperties({bool firstRun = false}) {
    _fooBuilder = initProperty(StatefulValueListenableProperty(valueListenable: widget.foo)); 
    super.initStatefulProperties(firstRun: firstRun);
  }

  <strong i="11">@override</strong>
  Widget build(BuildContext context) {
    return ExpensiveParent(
      child: SomethingInTheMiddle(
        _fooBuilder.value,
        _fooBuilder.builder(childBuilder: () => ExpensiveChild()),
      ),
    );
  }
}

@Hixie
例をありがとう。 私はそれにベストショットを与えました。 私は何かを逃したかもしれません。

注意すべき重要な点は、ビルダーが子をキャッシュすることです。 問題は、いつ実際に子供を再建する必要があるのか​​ということです。 それがあなたが提起しようとしていた質問だったと思います。

@Hixieはhttps://github.com/flutter/flutter/issues/51752#issuecomment-671104377を見たことがあり
本当に良い点がいくつかあると思います。
私は今日、たくさんのValueListenableBuilderを使って何かを構築していますが、読むのは良くないとしか言​​えません。

@Hixie
例をありがとう。 私はそれにベストショットを与えました。 私は何かを逃したかもしれません。

プロパティは定義されている状態にバインドされるため、これが機能するとは思わないため、ExpensiveParentは常にここで再構築されます。 次に、子のキャッシュも問題があると思います。Builderの例では、親の状態が構築されたときにのみ子を再構築することがわかっていますが、このメソッドでは、プロパティはキャッシュを無効にするタイミングを認識していません（ただし、これはおそらくこれです）解決可能ですか？）

しかし、tbh、これは、新しいコンテキストを導入したい場合のビルダーの完璧なユースケースです。 StatefulProperties（純粋な状態）とStatefulWidgets（状態とレイアウトの組み合わせ）のコンテキストを持つことは非常にエレガントだと思います。

意図的にサブコンテキストを作成するときはいつでも、定義上、ツリーのさらに下で作成します。これは、ビルダーの主な欠点の1つ（ツリー全体での強制的なネスト）と戦うのに役立ちます。

@escamoteur （そしてそのコメントを書いた@sahandevs ）ええ私は以前にそれを勉強していました。 それは確かに人々が削除したい種類の論理を示すのに役立つと思います。 ただし、例自体は少し疑わしいと思います。ほとんどのロジック（たとえば、キャッシュに関するすべて）がアプリ状態のビジネスロジックにあり、ウィジェットの近くにはないと予想します。 また、ホットリロードを中断せずに、そのコメントで提案されているほど簡潔な構文を取得するための良い方法もわかりません（たとえば、使用しているフックの数を変更した場合、リロード全体でステートフルに保つ方法が明確ではありません）。

そうは言っても、上記の@esDotDevと@TimWhitingの作業は非常に興味深いものであり、これらの問題を解決できると思います。 フックほど短くはありませんが、信頼性は高くなります。 そのようなものをパッケージ化することは完全に理にかなっていると思います。うまく機能すれば、FlutterFavoriteになる可能性もあります。 プロパティの構築に関する複雑さとパフォーマンスへの影響、およびさまざまな人々がさまざまなスタイルをどのように好むかを考慮すると、改善はそれほど重要ではないため、コアフレームワーク機能として意味があるかどうかはわかりません。 結局のところ、さまざまな人々がさまざまなスタイルを使用することは問題ないはずですが、コアフレームワークに複数のスタイルを持たせたくないので、新しい開発者にとっては誤解を招くだけです。

Flutterを学ぶ正しい方法は、構文を抽象化するのではなく、最初にウィジェットを理解し、次にウィジェットを抽象化するツール（フックなど）を学ぶことであるという議論もあります。 そうしないと、システムがどのように機能するかについての重要な要素が欠落しているため、パフォーマンスの高いコードを書くという点で迷う可能性があります。

また、ホットリロードを中断せずに、そのコメントで提案されているほど簡潔な構文を取得するための良い方法もわかりません（たとえば、使用しているフックの数を変更した場合、リロード全体でステートフルに保つ方法が明確ではありません）。

フックは問題なくホットリロードで動作します。
一致しないruntimeTypeを持つ最初のフックにより、後続のすべてのフックが破棄されます。

これは、追加、削除、および並べ替えをサポートします。

現在存在する部分的な抽象化よりも完全な抽象化の方が望ましいという議論があると思います。

プロパティのコンテキストでアニメーターがどのように機能するかを理解したい場合は、それを完全に無視するか、飛び込んでください。それはすべて問題なく、自己完結型で一貫性があります。

StatefulWidgetのコンテキストでAnimatorControllerがどのように機能するかを理解したい場合は、基本的なライフサイクルフックを理解する必要がありますが、基礎となるティックメカニズムがどのように機能するかを理解する必要はありません。 これはある意味で両方の世界の中で最悪です。 それを「正しく機能させる」には十分な魔法ではありませんが、新しいユーザーを混乱させ、いくつかのミックスイン（それ自体はほとんどの新しい概念です）と魔法のvsyncプロパティを盲目的に信頼するように強制するのに十分です。

コードベースの他の例はわかりませんが、これは、StatefulWidgetにいくつかのヘルパーミックスインが提供されている状況に当てはまりますが、常に実行する必要のある他のブートストラップがいくつかあります。 Dev'sはブートストラップ（退屈な部分）を学習し、Mixin（興味深い/複雑なビット）を無視します

そうは言っても、上記の@esDotDevと@TimWhitingの作業は非常に興味深いものであり、これらの問題を解決できると思います。 フックほど短くはありませんが、より信頼性があります

これはどのように信頼性が高くなりますか？

悪い状態になる可能性があるため、条件付きまたはライフサイクル外でプロパティを作成/更新することはできません。 たとえば、条件付きでプロパティを呼び出すと、条件がfalseの場合にプロパティが破棄されません。
また、すべてのプロパティは、再構築のたびに再評価されます。

ただし、NNBD後のすべての場所でユーザーに!使用を強制したり、更新前にユーザーにプロパティへのアクセスを許可したりするなど、複数の問題が発生します。

たとえば、誰かがdidUpdateWidget内のプロパティを読み取った場合はどうなりますか？

• initPropertiesはライフサイクルの前に実行されましたか？ ただし、これは、ビルドごとにプロパティを複数回更新する必要がある可能性があることを意味します。
• initPropertiesはdidUpdateWidgetの後に実行されましたか？ 次に、didUpdateWidget内のプロパティを使用すると、古い状態になる可能性があります

したがって、最終的には、フックのすべての問題が発生しますが、次のようになります。

• `StatelessWidget内でプロパティを使用することはできません。 したがって、StreamBuilder / ValueListenableBuilder / ...の読みやすさは依然として問題であり、これが主な懸念事項でした。
• 多数のエッジケースがあります
• カスタムプロパティを作成するのは難しいです（関数にプロパティの束を抽出するだけでは不十分です）
• 再構築を最適化するのは難しい

結局、与えられた例は、以下と動作に違いはありません。

class Example extends StatelessWidget {
  <strong i="29">@override</strong>
  Widget build(context) {
    final value1 = keyword TweenAnimationBuilder(tween: Tween(begin: 0, end: 1));
    final value2 = keyword TweenAnimationBuilder(tween: Tween(begin: 0, end: 1));
    final value3 = keyword TweenAnimationBuilder(tween: Tween(begin: 0, end: 1));

    return Container(
     margin: EdgeInsets.symmetric(vertical: value2 * 20, horizontal: value3 * 30),
     color: Colors.red.withOpacity(value1),
      child: _anim2(child: SomeChildWidget()),
    );
  }
}

ただし、この構文は次のような多くのことをサポートします。

早期返品：

class Example extends StatelessWidget {
  <strong i="34">@override</strong>
  Widget build(context) {
    final value1 = keyword TweenAnimationBuilder(tween: Tween(begin: 0, end: 1));

    if (condition) {
      return Container();
    }

    final value2 = keyword TweenAnimationBuilder(tween: Tween(begin: 0, end: 1));

    ...
  }
}

conditionがfalseに切り替わると、 value2 condition破棄されます

ビルダーのバンドルを関数に抽出します。

Widget build(context) {
  final foo = keyword FooBuilder();
  final bar = keyword BarBuilder();

  return Text('$foo $bar');
}

次のように変更できます。

Builder<String> LabelBuilder() builder* {
  final foo = keyword FooBuilder();
  final bar = keyword BarBuilder();

  return '$foo $bar';
}

Widget build(context) {
  final label = keyword LabelBuilder();

  return Text(label);
}

再構築を最適化する

childパラメーターは引き続き実行可能です。

Widget build(context) {
  final value = keyword StreamBuilder();

  return Builder(
    builder: (context, child) {
      final value2 = keyword TweenAnimationBuilder();
      final value = keyword ValueListenableBuilder();

      return Whatever(child: child);
    },
    child: ExpensiveChild()
  );
}

言語の一部として、これのためのシンタックスシュガーを持つことさえできます：

Widget build(context) {
  return Scaffold(
    body: {
      final value = keyword TweenAnimationBuilder();
      final value2 = keyword ValueListenableBuilder();

      return Text();
    },
  );
}

ボーナス：言語機能として、条件付き呼び出しがサポートされています

言語の一部として、次のようなシナリオをサポートできます。

Widget build(context) {
  String label;

  if (condition) {
    label = keyword LabelBuilder();
  } else {
    label = keyword AnotherBuilder();
  }

  final value2 = keyword WhateverBuilder();

  return ...
}

あまり便利ではありませんが、サポートされています。構文がコンパイルされているため、他の方法では利用できないメタデータに依存することで、 keyword各使用法を区別できます。

ビルダーの読みやすさに関して、これは前の例ですが、ビルダーで行われます。 それは信頼性とコード使用のニーズのすべてを解決しますが、それが私の貧弱なウィジェットツリーに何をしたかを見てください： '（

class _ExampleSimpleBuilderState extends State<ExampleSimpleBuilder> {
  <strong i="6">@override</strong>
  Widget build(BuildContext context) {
    return TweenAnimationBuilder<double>(
        tween: Tween(begin: 0, end: 1),
        duration: widget.duration1,
        builder: (_, value1, __) {
          return TweenAnimationBuilder<double>(
              tween: Tween(begin: 0, end: 1),
              duration: widget.duration2,
              builder: (_, value2, __) {
                return TweenAnimationBuilder<double>(
                    tween: Tween(begin: 0, end: 1),
                    duration: widget.duration3,
                    builder: (_, value3, __) {
                      return Container(
                        margin: EdgeInsets.symmetric(vertical: value2 * 20, horizontal: value3 * 30),
                        color: Colors.red.withOpacity(value1),
                      );
                    });
              });
        });
  }
}

重要なコードを見つけるのは（少なくとも私の目には）はるかに困難です。 また、これを書くときは、どのブラケットがどこにあるのか、セミコロンをどこに置くべきかなど、常に混乱していたので、3回ほどやり直す必要がありました。ネストされたビルダーは、内部で書いたり作業したりするのが面白くありません。 1つの間違ったセミコロンとdartfmtベイルが、すべてを完全に押しつぶします。

これはどのように信頼性が高くなりますか？

これは、これがコアプラグインimoである必要がある理由の完璧な例です。 ここで必要なドメイン知識は_deep_です。 私は、このような単純なキャッシングシステムを実装するためのスクリプトの知識を持っていますが、発生する可能性のあるすべてのエッジケース、または発生する可能性のある悪い状態を知るためのドメイン知識さえ持っていません。 レミ以外にも、Flutterチームの外にこのことを知っている開発者が4人いると思います！ （明らかに誇張しています）。

ステートレスウィジェットのサポートの問題は良い問題です。 一方で、StatefulWidgetsは奇妙なことに冗長です。 一方、ここでは、純粋な冗長性について真に話します。 2つのクラスを定義しなければならないことから発生する可能性のあるバグはなく、それを台無しにする方法はありません。コンパイラーはそれを許可しません。StatelessWidgetでやりたいことは何もありません。 だから私はこれが大きな問題であることに売られていません...確かに持っていればいいのですが、それは最後の5％imoであり、行き詰まるものではありません。

一方、キーワードをサポートするremiの構文は、絶対に美しく、めちゃくちゃ柔軟で強力です。 そして、それがあなたに無料でStatelessWidgetのサポートを提供するなら、それはただ余分です🔥

StatelessWidgetのサポートは大きなIMOです。 オプションですが、それでも非常にクールです。

それは重要ではないことに同意しますが、人々はすでにStatelessWidgetの代わりに関数を使用することをめぐって争っています。
ビルダーを使用するためにStatefulWidgetを使用するように人々に要求することは（ほとんどのビルダーが同等のプロパティを持っている可能性が高いため）、競合を深めるだけです。

それだけでなく、dartで高階関数を作成できる世界（https://github.com/dart-lang/language/issues/418）では、クラスを完全に取り除くことができます。

<strong i="9">@StatelessWidget</strong>
Widget Example(BuildContext context, {Key key, String param}) {
  final value = keyword StreamBuilder();

  return Text('$value');
}

その後、次のように使用されます。

Widget build(context) {
  // BuildContext and Key are automatically injected
  return Example(param: 'hello');
}

これは、 function_widgetによってサポートされているものです。これは、関数を記述してクラスを生成するコードジェネレーターであり、 HookWidgetもサポートしています。

違いは、Dartで高階関数をサポートすることで、そのような構文をサポートするためのコード生成の必要性がなくなることです。

@Hixieがより信頼できるとは

しかし、キーワードを使った提案もありません。 新しいキーワードのケースは非常に強いと思います。

• 州に接ぎ木するよりも柔軟で構成可能
• さらに簡潔な構文
• ステートレスで動作します。これは非常に優れたオプションです。

私が気に入らないのは、いくつかの単純なオブジェクトにプロパティを複数回/ビルドで設定するコストについて心配していることですが、基本的に100万レベルのコンテキストと大量のレイアウトコストを作成するソリューションを提唱しています。 私は誤解していますか？

もう1つの欠点は、この魔法の考え方です。 しかし、何か不思議なことをするつもりなら、新しいキーワードはそれを成し遂げるのに効果的な方法だと思います。それは、コミュニティを強調して呼びかけ、それが何であるか、そしてそれがどのように機能するかを説明するのを簡単にするからです。 基本的には、Flutterで次の年に向けて誰もが話し合うことになるでしょうし、そこから生まれるクールなプラグインが爆発的に増えると確信しています。

@Hixieがより信頼できるとは

ただし、フックは静的に分析可能であるため、このような問題は発生しません。したがって、フックを誤用すると、コンパイルエラーが発生する可能性があります。

これは問題ではありません

同様に、カスタムエラーが発生しない場合は、前述したように、プロパティにはまったく同じ問題が発生します。
合理的に書くことはできません：

Property property;

<strong i="12">@override</strong>
void initProperties() {
  if (condition) {
    property = init(property, MyProperty());
  }
}

conditionをtrueからfalseに切り替えても、プロパティは破棄されないためです。

ループで呼び出すこともできません。 これは1回限りの割り当てであるため、実際には意味がありません。 プロパティをループで実行するユースケースは何ですか？

そして、プロパティを任意の順序で読み取ることができるという事実は危険に聞こえます
たとえば、次のように書くことができます。

Property first;
Property second;

<strong i="20">@override</strong>
void initProperties() {
  // The state of first depends on second, but second is updated after first
  // So we could end up in a bad state, similar to how the build method of a Widget should depend
  // on the context.size
  first = init(property, MyProperty(second?.value));

  second = init(property, Whatever());
}

> class _ExampleSimpleBuilderState extends State<ExampleSimpleBuilder> {
>   <strong i="5">@override</strong>
>   Widget build(BuildContext context) {
>     return TweenAnimationBuilder<double>(
>         tween: Tween(begin: 0, end: 1),
>         duration: widget.duration1,
>         builder: (_, value1, __) {
>           return TweenAnimationBuilder<double>(
>               tween: Tween(begin: 0, end: 1),
>               duration: widget.duration2,
>               builder: (_, value2, __) {
>                 return TweenAnimationBuilder<double>(
>                     tween: Tween(begin: 0, end: 1),
>                     duration: widget.duration3,
>                     builder: (_, value3, __) {
>                       return Container(
>                         margin: EdgeInsets.symmetric(vertical: value2 * 20, horizontal: value3 * 30),
>                         color: Colors.red.withOpacity(value1),
>                       );
>                     });
>               });
>         });
>   }
> }

これはとても奇妙な例です。 AnimatedContainerでこれを実行できないのは確かですか？

もちろん。 ここでの例は、「X」を実行するためにいくつかのウィジェットで3つのアニメーションを利用することです。 Xは、ボイラープレートの量を強調するために、例では意図的に簡略化されています。

私がそれらをどのように使用しているかに焦点を当てないでください。 実際の例では、ウィジェットの「コア」は100行程度であり、アニメーション化されたプロパティはそれほど単純ではなく、複数のハンドラーやその他の関数が定義されています。 暗黙のウィジェットの1つで処理されないことをしていると仮定します（AnimatedContainer以外は非常に単一目的であるため、難しくはありません）。

重要なのは、このようなものを構築する場合、ビルダーは最初から読みやすさ（および書き込み可能性）の穴にあなたを突き刺すため、うまく機能しないということです。そのため、単純なユースケースに適しているため、「構成」されません。良い。 2つ以上のものの構成であることを構成します。

私がそれらをどのように使用しているかに焦点を当てないでください。 実際の例では、...

...そして正方形に戻ります。 なぜあなたは、実際の例を持っていませんか？

複雑なアニメーションを使用する実際の例が必要ですか？
https://github.com/gskinnerTeam/flutter_vignettes

任意の複雑なアニメーションを表示しても、例がわかりにくくなるだけです。 言うまでもなく、ウィジェット内で複数のアニメーター（または想像できる他のステートフルオブジェクト）を使用するためのユースケースはたくさんあります

もちろん。 ここでの例は、「X」を実行するためにいくつかのウィジェットで3つのアニメーションを利用することです。 Xは、ボイラープレートの量を強調するために、例では意図的に簡略化されています。

ウィジェットの「コア」は100行か何かになります

別の投稿で、「コア」を覆い隠す定型文の例を投稿しましたが、コアは数百行になるとおっしゃっていますか？ それで、実際には、ボイラープレートはコアと比較してごくわずかでしょうか？ あなたはそれを両方の方法で持つことはできません。
あなたは絶えずあなたの議論を変えています。

私がそれらをどのように使用しているかに焦点を当てないでください。 実際の例では、...

...そして正方形に戻ります。 なぜあなたは、実際の例を持っていませんか？

いろいろなアイデアをいじってみると、実例を作るのに時間がかかるからでしょう。 その意図は、読者が実際の状況でどのように使用できるかを想像することであり、それを回避する方法があることは言うまでもありません。 もちろん、アニメーションコンテナを使用することもできますが、使用できない場合はどうでしょうか。 アニメーション化されたコンテナだけで作成するには複雑すぎる場合はどうなりますか。

さて、作家は良いか悪いかを示すことができる本当に実際の例を使用していないので、私はそれについて意見はありません、私はこのスレッドでそうでない問題の改善をもたらす傾向についてコメントしているだけです手元の問題を完全に解決します。 これは、フックの支持者と反対者の間の混乱の主な原因のようです。それぞれがある程度別の話をしているように見えるので、反対者が「実際の」例が示されておらず、提案者は、現実世界のシナリオを単に想像する必要があるとは言えません。

半分が定型文である100行のクラスを持つのはばかげていると私は言ったと思います。 これはまさに私がここで説明していることです。 コアは、どんなに大きくても、多数のノイズによって難読化されるべきではありません。これは、複数のビルダーを使用している場合に確かに起こります。

その理由は、大規模なコードベース全体でのスキャン機能、可読性、およびメンテナンスです。 それは線の書き込みではありませんが、ビルダーでの書き込みは、中括弧の地獄に入る傾向があるため、生産性を失うimoです。

別の投稿で、「コア」を覆い隠す定型文の例を投稿しましたが、コアは数百行になるとおっしゃっていますか？ それで、実際には、ボイラープレートはコアと比較してごくわずかでしょうか？ あなたはそれを両方の方法で持つことはできません。
あなたは絶えずあなたの議論を変えています。

繰り返しますが、この問題は定型文ではなく、読みやすさと再利用性に関するものです。
100行でも構いません。
重要なのは、これらの行がどれだけ読み取り可能/保守可能/再利用可能かということです。

議論が定型文についてであったとしても、同じことを表現するのに十分に同等の方法を考えると、なぜ私、ユーザーはそのような定型文を容認する必要がありますか？ プログラミングとは、抽象化を作成し、作業を自動化することです。さまざまなクラスやファイルで同じことを何度もやり直す意味はあまりありません。

複雑なアニメーションを使用する実際の例が必要ですか？
https://github.com/gskinnerTeam/flutter_vignettes

確かに、私があなたのプロジェクト全体を掘り下げることを期待することはできません。 どのファイルを正確に見る必要がありますか？

任意の複雑なアニメーションを表示しても、例がわかりにくくなるだけです。

正反対です。 既存の解決策では解決できない任意の複雑なアニメーションを表示することが例であり、それがヒックソンが求め続けていることだと私は信じています。

gifをスキャンして、そのようなものをどのように作成するかを想像し始めてください。 そのリポジトリは実際には17のスタンドアロンアプリです。 また、複雑なアニメーションが存在する可能性があることを証明するためだけに、私が任意のアニメーションを作成することを期待することはできません。 私はFlashから始めて20年間それらを構築してきましたが、どれも前回とは異なります。 とにかくアニメーションに固有のものではありません。アニメーションは、より大きなポイントを説明するための最も単純で最も馴染みのあるAPIにすぎません。

ご存知のように、アニメーターを使用する場合、毎回6つのことを行う必要がありますが、ライフサイクルフックも必要ですか？ さて、それを毎回6つのステップが必要なものに拡張します...そして2か所で使用する必要があります。 または、一度に3つ使用する必要があります。 それは明らかに問題です。他に何を追加して説明できるかわかりません。

プログラミングとは、抽象化を作成し、作業を自動化することです。さまざまなクラスやファイルで同じことを何度もやり直す意味はあまりありません。

__全て__？ では、パフォーマンス、保守性は関係ありませんか？

労働を「自動化」することと労働を「行う」ことは同じである場合があります。

皆さん、実際の例を作成する時間や傾向がなければ問題ありませんが、問題を説明する例を作成することに興味がない場合は、人々が問題を解決することを強いられていると感じてはいけません（これは、問題を示すための例を作成するよりもはるかに多くの作業です）。 ここでは誰も誰かのために何かをする必要はありません。それは私たち全員が互いに助け合うことを試みているオープンソースプロジェクトです。

@TimWhiting https://github.com/TimWhiting/local_widget_state_approachesリポジトリにライセンスファイルを入れて

同じことを表現するのに十分に同等の方法がある必要がありますか？

はい、もちろん保守性とパフォーマンスは重要です。 つまり、同等の解決策がある場合は、定型文が少なく、読みやすく、再利用しやすいものを選択する必要があります。 たとえば、フックのパフォーマンスを測定していないので、フックが答えであるとは限りませんが、私の経験では、フックの方が保守しやすくなっています。 フックのような構造がFlutterコアに配置された場合、それがあなたの作業にどのように影響するかについてのあなたの議論についてはまだわかりません。

gifをスキャンして、そのようなものをどのように作成するかを想像し始めてください。

gifをスキャンしました。 私はビルダーウィジェットを使用しません。
アニメーションの多くは非常に複雑なので、高レベルのビルダーを使用して実装したことがわかっている場合は、おそらくパッケージを使用しません。

とにかく、この議論はより個人的な意見の不一致で手に負えなくなっているようです。 手元の主なタスクに焦点を当てる必要があります。 先に述べたように、提起された問題を真に解決しない改善を相手が見つけた場合、フックの支持者がどのように小さな例を示すことができるかはわかりません。 今のところ、 @ TimWhitingのリポジトリに貢献する必要があると思います。

既存の解決策では解決できない任意の複雑なアニメーションを表示することが例であり、それがヒックソンが求め続けていることだと私は信じています。

今日不可能なことの例を示すことは、この問題の範囲外です。
この問題は、今日は不可能ないくつかのことのブロックを解除するのではなく、すでに実現可能なものの構文を改善することに関するものです。

今日不可能なものを提供するという要求は、トピックから外れています。

@TimWhiting https://github.com/TimWhiting/local_widget_state_approachesリポジトリにライセンスファイルを入れて

終わり。 申し訳ありませんが、例に取り組む時間があまりありませんでしたが、おそらく今週中にそれを実現するでしょう。

既存の解決策では解決できない任意の複雑なアニメーションを表示することが例であり、それがヒックソンが求め続けていることだと私は信じています。

今日不可能なことの例を示すことは、この問題の範囲外です。
この問題は、今日は不可能ないくつかのことのブロックを解除するのではなく、すでに実現可能なものの構文を改善することに関するものです。

今日不可能なものを提供するという要求は、トピックから外れています。

私が言ったことを言い換えさせてください。

アニメーションや状態など、記述がパフォーマンスに影響を与えることなく大幅に改善できる、任意の複雑な

ボイラープレートを減らし、再利用性を高め、魔法を増やすことの推進を理解しています。 私もコードを少なくするのが好きで、より多くの作業を行う言語/フレームワークは非常に食欲をそそります。
これまで、ここで紹介する例とソリューションの組み合わせはどれも、コードを大幅に改善するものではありませんでした。 つまり、何行のコードを記述しなければならないかだけでは不十分です。

皆さん、実際の例を作成する時間や傾向がなければ問題ありませんが、問題を説明する例を作成することに興味がない場合は、人々が問題を解決することを強いられていると感じてはいけません（これは、問題を示すための例を作成するよりもはるかに多くの作業です）。 ここでは誰も誰かのために何かをする必要はありません。それは私たち全員が互いに助け合うことを試みているオープンソースプロジェクトです。

@TimWhiting https://github.com/TimWhiting/local_widget_state_approachesリポジトリにライセンスファイルを入れて

これらのさまざまな例とコードスニペットの作成に約6時間を費やしました。 しかし、複雑なアニメーションの具体的な例を提供して、それらが存在できることを証明するだけでは、まったく意味がありません。

要求は基本的にこれをAnimatedContainerで処理できないものに変えることです：

Container(margin: EdgeInsets.symmetric(vertical: value2 * 20, horizontal: value3 * 30), color: Colors.red.withOpacity(value1));

これは、問題にほとんど意図的に鈍感になるという点で非常に些細なことです。 いくつかのパルスボタン、いくつかの粒子の移動、スケーリング中にフェードインするいくつかのテキストフィールド、または反転するいくつかのカードがあるかもしれないと想像するのはとても難しいですか？ 15本の独立したバーを備えたサウンドバーを作成しているのかもしれません。メニューをスライドさせているのかもしれませんが、個々のアイテムをスライドさせて戻す機能も必要です。 そして、そして、そして、そして、そして。 そして、これはアニメーション専用です。 これは、ウィジェットのコンテキストで煩わしいすべてのユースケースに適用されます。

私は、両方のビルダーとバニラ状態の再利用に関する問題の優れた標準的な例を提供したと思います。
https://github.com/flutter/flutter/issues/51752#issuecomment -671566814
https://github.com/flutter/flutter/issues/51752#issuecomment -671489384

これらのインスタンスの多くを想像するだけで（毒を選ぶ）、1000以上のクラスファイルのプロジェクト全体に広範囲に広がり、回避しようとしている可読性と保守性の問題を完全に把握できます。

@esDotDevが提供したサンプル画像は、ネストによってコードが読みにくくなり、 @ Rudikszにとって十分ではないことを@ rrousselGitはビルダーよりもパフォーマンスが

@esDotDev重要なのは、すべてのライフサイクル管理ソリューションを比較できる単一の標準的な例を

それは私には理にかなっていますが、なぜそれが単一のページよりも大きくなければならないのか理解できません。

複数のアニメーションを管理することは、一般的で、大量の定型文を必要とし、エラーが発生しやすく、現在、適切な解決策がないことの完璧な例です。 それが意味をなさない場合、アニメーションがどのように複雑になるかさえ理解していないと人々が言うなら、明らかに、アーキテクチャの問題ではなく、ユースケースのコンテキストのためにすべてのユースケースがノックダウンされます説明しようとしています。

確かに、@ TimWhitingのリポジトリには本格的なアプリはありません。あなたが言うように、例として単一のページがあります。他の人がソリューションを実装できるリポジトリのアニメーションの標準的な例を作成できれば、それは機能します。

また、巨大なアプリなどは必要ないと思いますが、TodoMVCと同様に十分な複雑さが必要です。 基本的には、対戦相手が「こんな風にもっと上手くやれる」と言えない程度に十分である必要があります。

@Hixieアプローチを比較するための実際のアプリのリクエストには欠陥があります。

2つの欠陥があります：

• あなたが自分でそれを理解していないと言ったので、私たちはまだ問題に同意していません
• 欠品があるため、実際の生産条件で例を実装することはできません。

たとえば、次を使用してアプリケーションを作成することはできません。

final snapshot = keyword StreamBuilder();

これは実装されていないためです。

これはPOCと本番コードを比較しているため、パフォーマンスを判断することもできません。

誤用があったときにエラーを指摘するコンパイラ統合がないため、「フックを条件付きで呼び出すことができない」などのようなものがエラーを起こしやすいかどうかを評価することはできません。

設計のパフォーマンスの判断、APIの使いやすさの評価、実装前の実装...これらはすべてAPI設計の一部です。 私の仕事へようこそ。 ：-）（フラッタートリビア：dart：uiを作成する前に、RenderObjectとRenderBoxなどの最初の数千行が実装されていることをご存知ですか？）

それはあなたが不可能を要求しているという事実を変えません。

ここで行われた提案の一部は、言語またはアナライザーの一部です。 コミュニティがそれを実装することは不可能です。

他のフレームワークや言語が常にAPI設計を行っているかどうかはわかりません。ここではそれほど違いはないと思います。また、Flutterには他の言語とのAPI設計の大きな違いや難しさがあります。 のように、コンパイラやアナライザのサポートなしでそれを行います。これらは概念実証にすぎません。

3つのアニメーションをうまく利用し、ボイラープレートとクラフトがかなりロードされた「複雑な」アニメーションシナリオの例をまとめました。

開始位置へのハードスナップバック（すべての暗黙のウィジェットを削除）、z軸での回転、単一軸でのスケール、またはIWでカバーされていないその他のユースケースを必要とするアニメーションを実行できた可能性があることに注意してください。 それらが真剣に受け止められないのではないかと心配したので（私のデザイナーは一日中このようなものを私に渡してくれますが）、私はもっと「現実の世界」を作りました。

これが単純な足場です。スライドして開閉する3つのパネルがあります。 離散状態の3つのアニメーターを使用します。 この場合、AnimatorControllerの完全な制御は実際には必要ありません。TweenAnimationBuilderは問題ありませんが、結果としてツリーにネストされることは非常に望ましくありません。 パネルは相互の値に依存しているため、TABをツリーの下にネストすることはできません。 AnimatedContainerは、各パネルが画面からスライドする必要があるため、ここではオプションではありません。「スキッシュ」しません。
https://i.imgur.com/BW6M3uM.gif

class _SlidingPanelViewState extends State<SlidingPanelView> with TickerProviderStateMixin {
  AnimationController leftMenuAnim;
  AnimationController btmMenuAnim;
  AnimationController rightMenuAnim;

  <strong i="12">@override</strong>
  void initState() {
    // Here I have to pass vsync to AnimationController, so I have to include a SingleTickerProviderMixin and somewhat magically pass 'this' as vsync.
    leftMenuAnim = AnimationController(duration: widget.slideDuration, vsync: this);
    btmMenuAnim = AnimationController(duration: widget.slideDuration, vsync: this);
    rightMenuAnim = AnimationController(duration: widget.slideDuration, vsync: this);
    // Here I have to call forward 3 times, cause there's no way to automate this common setup behavior
    leftMenuAnim.forward();
    btmMenuAnim.forward();
    rightMenuAnim.forward();
    // Here I have to manually bind to build, cause there is encapsulate this common setup behavior
    leftMenuAnim.addListener(() => setState(() {}));
    btmMenuAnim.addListener(() => setState(() {}));
    rightMenuAnim.addListener(() => setState(() {}));
    super.initState();
  }

  // Following 2 fxn are a blind spot as far as compiler is concerned.
  // Things may, or may not be implemented correctly, no warnings, no errors.
  <strong i="13">@override</strong>
  void dispose() {
    btmMenuAnim.dispose();
    leftMenuAnim.dispose();
    rightMenuAnim.dispose();
    super.dispose();
  }

  <strong i="14">@override</strong>
  void didUpdateWidget(SlidingPanelView oldWidget) {
    if (leftMenuAnim.duration != widget.slideDuration) {
      leftMenuAnim.duration = widget.slideDuration;
      btmMenuAnim.duration = widget.slideDuration;
      rightMenuAnim.duration = widget.slideDuration;
    }
    super.didUpdateWidget(oldWidget);
  }

  // End error-prone blind spot without a single line of unique code
  // ~50 lines in we can start to see some unique code

  void _toggleMenu(AnimationController anim) {
    bool isOpen = anim.status == AnimationStatus.forward || anim.value == 1;
    isOpen ? anim.reverse() : anim.forward();
  }

  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    double leftPanelSize = 320;
    double leftPanelPos = -leftPanelSize * (1 - leftMenuAnim.value);
    double rightPanelSize = 230;
    double rightPanelPos = -rightPanelSize * (1 - rightMenuAnim.value);
    double bottomPanelSize = 80;
    double bottomPanelPos = -bottomPanelSize * (1 - btmMenuAnim.value);
    return Stack(
      children: [
        //Bg
        Container(color: Colors.white),
        //Content Panel
        Positioned(
          top: 0,
          left: leftPanelPos + leftPanelSize,
          bottom: bottomPanelPos + bottomPanelSize,
          right: rightPanelPos + rightPanelSize,
          child: ChannelInfoView(),
        ),
        //Left Panel
        Positioned(
          top: 0,
          left: leftPanelPos,
          bottom: bottomPanelPos + bottomPanelSize,
          width: leftPanelSize,
          child: ChannelMenu(),
        ),
        //Bottom Panel
        Positioned(
          left: 0,
          right: 0,
          bottom: bottomPanelPos,
          height: bottomPanelSize,
          child: NotificationsBar(),
        ),
        //Right Panel
        Positioned(
          top: 0,
          right: rightPanelPos,
          bottom: bottomPanelPos + bottomPanelSize,
          width: rightPanelSize,
          child: SettingsMenu(),
        ),
        // Buttons
        Row(
          children: [
            Button("left", ()=>_toggleMenu(leftMenuAnim)),
            Button("btm", ()=>_toggleMenu(btmMenuAnim)),
            Button("right", ()=>_toggleMenu(rightMenuAnim)),
          ],
        )
      ],
    );
  }
}

//Demo helpers
Widget Button(String lbl, VoidCallback action) => FlatButton(child: Text(lbl), onPressed: action, color: Colors.grey);
Widget ChannelInfoView() => _buildPanel(Colors.red);
Widget ChannelMenu() => _buildPanel(Colors.pink);
Widget SettingsMenu() => _buildPanel(Colors.blue);
Widget NotificationsBar() => _buildPanel(Colors.grey);
Widget _buildPanel(Color c) => Container(color: c, child: Container(color: Colors.white.withOpacity(.5)), padding: EdgeInsets.all(10));

したがって、その本体の100行程度のうち、約40％が純粋な定型文です。 特に15行は、欠落しているものや入力ミスがあると、見つけにくいバグを引き起こす可能性があります。

StatefulPropertyのようなものを使用すると、ボイラープレートが15％程度に削減されます（約25行節約できます）。 重要なことに、これは卑劣なバグと重複するビジネスロジックの問題を完全に解決しますが、特にStatefulWidgetが必要なため、まだ少し冗長です。これは、すぐに10行ヒットします。

'keyword'のようなものを使用する場合、定型文の行を基本的に0％に減らします。 クラスの全体の焦点は、（一意の）ビジネスロジックとビジュアルツリー要素にある可能性があります。 一般に、StatefulWIdgetsの使用ははるかにまれになり、ビューの大部分は10％または20％少なくなり、より焦点が絞られます。

また、上記のPanelシナリオは現実の世界であり、現実の世界では明らかにこのアプローチはあまり良くないため、使用しませんでした。コードベースには表示されません。 また、ネストされたビルダーを使用しないので、それらが粗く見えるので、それも表示されません。

IsOpenプロパティを取得し、それ自体を開いたり閉じたりする専用のSlidingPanelウィジェットを作成しました。 これは通常、特定の動作が必要なこれらのユースケースのすべてのソリューションであり、ステートフルロジックを特定のウィジェットに移動し、それを使用します。 基本的に、独自のImplicitlyAnimatedWidgetを作成します。

これは通常は問題なく機能しますが、それでも時間と労力がかかります。文字通り、アニメーションを使用するのが非常に難しいためです（ステートフルコンポーネントを再利用するのは一般的に非常に難しいためです）。 たとえば、UnityやAIRでは、パネルを1つの軸上で移動するためだけに専用のクラスを作成するのではなく、開いたり閉じたりするのは1行のコードであり、専用のウィジェットで行うことは何もありません。 Flutterでは、専用のウィジェットを作成する必要があります。これは、AnimatorControllerのブートストラップとティアダウンをカプセル化するための文字通り唯一の合理的な方法です（TABでネスト、ネスト、ネストする場合を除く）

ここでの私の主なポイントは、この種のことは、実際の例を見つけるのが非常に難しい理由です。 開発者として、これらのものをコードベースにあまり存在させることはできないため、理想的ではありませんが効果的な回避策で回避します。 次に、コードベースを見ると、これらの回避策が有効になっていることがわかり、すべてが正常に見えますが、チームが望んでいたものではない可能性があり、そこに到達するまでに20％長くかかった可能性があり、合計であった可能性がありますデバッグするのが面倒ですが、コードを一瞥しただけでは明らかではありません。

完全を期すために、これはビルダーで作成された同じユースケースです。 行数が大幅に削減され、バグの可能性がなく、外国の概念RE TickerProviderMixinを学ぶ必要がありません...しかし、その入れ子は悲しみであり、さまざまな変数がツリー全体に散らばる方法（動的終了値、値1、値2など） ）ビジネスロジックが必要以上に読みにくくなります。

`` `ダーツ
クラス_SlidingPanelViewStateはStateを拡張します{{
bool isLeftMenuOpen = true;
bool isRightMenuOpen = true;
bool isBtmMenuOpen = true;

@オーバーライド
ウィジェットビルド（BuildContextコンテキスト）{
TweenAnimationBuilderを返す（（
トゥイーン：トゥイーン（開始：0、終了：isLeftMenuOpen？1：0）、
期間：widget.slideDuration、
ビルダー：（_、leftAnimValue、__）{
TweenAnimationBuilderを返す（（
トゥイーン：トゥイーン（開始：0、終了：isRightMenuOpen？1：0）、
期間：widget.slideDuration、
ビルダー：（_、rightAnimValue、__）{
TweenAnimationBuilderを返す（（
トゥイーン：トゥイーン（開始：0、終了：isBtmMenuOpen？1：0）、
期間：widget.slideDuration、
ビルダー：（_、btmAnimValue、__）{
double leftPanelSize = 320;
double leftPanelPos = -leftPanelSize *（1-leftAnimValue）;
double rightPanelSize = 230;
double rightPanelPos = -rightPanelSize *（1-rightAnimValue）;
double bottomPanelSize = 80;
double bottomPanelPos = -bottomPanelSize *（1-btmAnimValue）;
スタックを返す
子供達： [
// Bg
コンテナ（色：Colors.white）、
//メインコンテンツエリア
ポジショニング（
上：0、
左：leftPanelPos + leftPanelSize、
下：bottomPanelPos + bottomPanelSize、
右：rightPanelPos + rightPanelSize、
子：ChannelInfoView（）、
）、
//左パネル
ポジショニング（
上：0、
左：leftPanelPos、
下：bottomPanelPos + bottomPanelSize、
幅：leftPanelSize、
子：ChannelMenu（）、
）、
//下部パネル
ポジショニング（
左：0、
右：0、
下：bottomPanelPos、
高さ：bottomPanelSize、
子：NotificationsBar（）、
）、
//右パネル
ポジショニング（
上：0、
右：rightPanelPos、
下：bottomPanelPos + bottomPanelSize、
幅：rightPanelSize、
子：SettingsMenu（）、
）、
//ボタン
行（
子供達： [
Button（ "left"、（）=> setState（（）=> isLeftMenuOpen =！isLeftMenuOpen））、
Button（ "btm"、（）=> setState（（）=> isBtmMenuOpen =！isBtmMenuOpen））、
Button（ "right"、（）=> setState（（）=> isRightMenuOpen =！isRightMenuOpen））、
]、
）
]、
）;
}、
）;
}、
）;
}、
）;
}
}

最後の1つは興味深いです...私は当初、ビルダーがスタックではなく配置ウィジェットの周りにあるべきであることを提案しようとしていました（そして私はまだ左と右のパネルのためにそれを提案します）が、それから私は一番下のものが影響することに気づきました3つすべてで、 ContainerとRow両方を一定に保ちたいので、ビルダーがchild引数を1つだけ与えるだけでは実際には十分ではないことに気付きました。ビルドします。 最初のビルダーの上に作成できると思います。

ここでの私の主なポイントは、この種のことは、実際の例を見つけるのが非常に難しい理由です。 開発者として、これらのものをコードベースにあまり存在させることはできないため、理想的ではありませんが効果的な回避策で回避します。 次に、コードベースを見ると、これらの回避策が有効になっていることがわかり、すべてが正常に見えますが、チームが望んでいたものではない可能性があり、そこに到達するまでに20％長くかかった可能性があり、合計であった可能性がありますデバッグするのが面倒ですが、コードを一瞥しただけでは明らかではありません。

記録として、これは偶然ではありません。 これは非常に仕様によるものです。 これらのウィジェットを独自のウィジェットにすることで、パフォーマンスが向上します。 私たちは、これが人々がFlutterをどのように使用するかということを非常に意図していました。 これは、「Flutterの設計哲学の大部分は、人々を正しい選択に導くことです」と述べたときに私が上で言及したものです。

私は当初、ビルダーがスタックではなく、Positionedウィジェットの周りにあるべきだと提案しようとしていました（そして、左右のパネルについても提案します）

簡潔にするために実際には省略しましたが、通常はここにContentコンテナーが必要であり、3つのメニューすべてのサイズを使用して独自の位置を定義します。 つまり、3つすべてがツリーの最上位にある必要があり、再構築する場合は、ビュー全体を再構築する必要があり、回避する必要はありません。 これは基本的にあなたの古典的なデスクトップスタイルの足場です。

もちろん、ツリーを分解し始めることもできます。常にオプションです。大きなウィジェットによく使用しますが、実際に一目でグローカビリティが向上することは一度も見たことがありません。読者がそれを行うために必要な追加の認知ステップがあります。点。 あなたが木をバラバラにした瞬間、私は突然、変数の割り当てのパンくずの跡をたどって、ここで何が渡されているのか、そして全体がどのように組み合わされているのかを理解しました。 消化可能な木として木を提示することは、私の経験から常に推論するのが簡単です。

おそらく、専用のRenderObjectの良いユースケースです。

または、ウィジェットのライフサイクルに自分自身をフックできる3つの簡単に管理できるAnimatorObjects：D

これらのウィジェットを独自のウィジェットにすることで、パフォーマンスが向上します。

ここで具体的に説明します。この場合、これは足場であるため、すべてのサブビューはすでに独自のウィジェットになっています。この男は、子のレイアウトと翻訳を担当します。 子はBottomMenu（）、ChannelMenu（）、SettingsView（）、MainContent（）などになります

この場合、自己完結型ウィジェットの束を、自己完結型ウィジェットの別のレイヤーでラップして、ウィジェットの移動に関する定型文を管理します。 これがパフォーマンスの勝利だとは思いませんか？ この場合、私たちは、フレームワークが実際にやりたいことではなく、私たちがやりたいことを_考えている_ことに押し込まれています。それは、より簡潔で首尾一貫した方法で同等のパフォーマンスのビューを書くことです。

[編集]このコンテキストを追加するために例を更新します

専用のRenderObjectを提案する理由は、レイアウトが改善されるためです。 アニメーションの側面がステートフルウィジェットにあることに同意します。スタック計算を行う代わりに、3つの0..1ダブル（value1、value2、value3）をレンダーオブジェクトに渡すだけです。 しかし、それは主にこの議論のサイドショーです。 これを実行している時点でも、フックなどのステートフルウィジェットで提供される単純化を実行する必要があります。

より関連性の高いメモとして、 @ TimWhitingのプロジェクトのデモを作成する際に亀裂がありました： https ：
フックバージョンがどのようになるのか興味があります。 特にパフォーマンス特性を維持する（またはそれらを改善する、現在最適ではない場所を示すコメントがあります）、それを単純化するための良い方法を見つけることができるかどうかはわかりません。

（これが、単純化する方法を見つけた場合にここで実行されるようなものなのか、それとも完了する前に解決する必要のある重要なことが欠落しているのか、非常に興味があります。）

この例では、復元が重要ですか？ そのせいでフォローするのに苦労していて、RestorationMixinが何をしているのか本当にわかりません。 私はそれが...私のためにこれを理解するのに少し時間がかかるだろうと思います。 レミは4秒でフックバージョンをクランクアウトすると確信しています:)

使用して復元APIを使用してHookWidgetではなくStatefulHookWidget現時点ではサポートされていません。

理想的には私たちは変えることができるはずです

final value = useState(42);

の中へ：

final value = useRestorableInt(42);

ただし、現在の復元APIは実際にはフックを念頭に置いて設計されていないため、ある程度の考慮が必要です。

補足として、Reactフックには「キー」機能が付属しており、通常は次のように使用されます。

int userId;

Future<User> user = useMemo(() => fetchUser(id), [id]);

このコードは、「コールバックの結果をキャッシュし、配列内の何かが変更されるたびにコールバックを再評価する」ことを意味します。

Flutter_hooksはこれを1対1で再実装しました（これは単なるポートであるため）が、Flutterに最適化されたコードに対してこれを実行したいとは思いません。

私たちはおそらく欲しいでしょう：

int userId;

Future<User> user = useMemo1(id, (id) => fetchUser(id));

これは同じことをしますが、リストの割り当てを避け、関数のティアオフを使用することでメモリの負荷を取り除きます

この段階では重要ではありませんが、例としてflutter_hooksを使用する予定がある場合は言及する価値があります。

@Hixieアニメーションの例をフックに移植しました

それは興味深い例でした、それについて考えたことに対する称賛です！
これは、デフォルトで「アクティブ」と「期間」の実装がいたるところにある（そして相互に依存している）という点で良い例です。
ポイントまで、多数の「if（アクティブ）」/「controller.repeat」呼び出しがありました

一方、フックを使用すると、すべてのロジックが宣言的に処理され、重複することなく1か所に集中します。

この例では、フックを使用してオブジェクトを簡単にキャッシュする方法も示しています。これにより、ExpensiveWidgetの再構築が頻繁に発生する問題が修正されました。
constコンストラクターの利点はありますが、動的パラメーターで機能します。

また、より優れたホットリロードが得られます。 背景色のTimer.periodic期間を変更すると、変更の効果をすぐに確認できます。

@rrousselGitリンクはありますか？ @TimWhitingのリポジトリに新しいものは何もありませんでした。

使用して復元APIを使用してHookWidgetではなくStatefulHookWidget現時点ではサポートされていません。

どんな解決策を思いついたとしても、最後のすべてのミックスインについて知る必要がないことを確認する必要があります。 TickerProviderStateMixinやRestorationMixinのようなミックスインを導入する他のパッケージと組み合わせて私たちのソリューションを使用したい場合は、そうすることができるはずです。

https://github.com/TimWhiting/local_widget_state_approaches/pull/3

同意しましたが、私はそれについて心配していません。 useAnimationControllerは、たとえば、ユーザーがSingleTickerProviderを気にする必要はありません。

AutomaritKeepAliveは同じ治療の恩恵を受ける可能性があります。
私が考えていたことの1つは、「useKeepAlive（bool）」フックを持つことです。

これにより、ミックスインと「super.build（context）」の両方が回避されます（後者は非常に混乱します）

もう1つの興味深い点は、リファクタリング中に必要な変更です。

たとえば、生のアプローチとフックのTickerModeを実装するために必要な変更の違いを比較できます。

• StatefulWidget https://github.com/TimWhiting/local_widget_state_approaches/pull/2/commits/0cb7bf60143ead59131b5729044cb51344ffd3fb
• フックhttps://github.com/TimWhiting/local_widget_state_approaches/pull/3/commits/b955aab9e5fb02736106732dac9d2398579515ad

他のいくつかのことがdiffで混同されていますが、それから次のことがわかります。

• ロジックを完全に異なるライフサイクルに移行するために必要なStatefulWidget
• フックの変更は純粋に付加的なものです。 既存の行は編集/移動されませんでした。

Imoこれは非常に重要であり、このスタイルの自己完結型の状態オブジェクトからの重要な勝利です。 ツリー内のネストされたコンテキストに基づいてすべてを持つことは、リファクタリングと変更が基本的に難しく、複雑になります。これは、プロジェクトの過程で、コードベースの最終品質に目に見えないが明確な影響を及ぼします。

同意しました！
これにより、コードレビューが非常に読みやすくなります。

final value = useSomething();
+ final value2 = useSomethingElse();

return Container(
  color: value.color,
-  child: Text('${value.name}'),
+  child: Text('${value.name} $value2'),
);

対：

return SomethingBuilder(
  builder: (context, value) {
-    return Container(
-      color: value.color,
-      child: Text('$value'),
+    return SomethingElseBuilder(
+      builder: (context, value2) {
+        return Container(
+          color: value.color,
+          child: Text('${value.name} $value2'),
+        );
+      }
    );
  },
);

2番目の差分では、 Containerが変更されておらず、 Textのみが変更されていることは明らかではありません。

@rrousselGitキーワードサポートでどのように見えるかを表すバージョンを試してみるのは理にかなっていると思いますか？ 専用の「use」キーワードを持つフックと実質的に似ていますか、それともフォローしやすくなりますか？ フックアプローチを均等な足場で比較するのは難しいので、useEffect、useMemoなどの外国の概念が非常に多く、それが実際よりも魔法のように見えると思いますか？

もう1つ注意すべき点は、これがすべて実際に家に帰るのは、複数のウィジェットがある場合、すべてがこの「カラーステッピング」ロジックを共有する必要があるが、結果の色をまったく異なる方法で使用することです。 フックスタイルのアプローチでは、再利用するのに意味のあるロジックをバンドルするだけで、それを使用するだけです。 私たちが強いられる建築上のコーナーはありません。それは本当に不可知論的で柔軟性があります。

ステートフルアプローチでは、

• ロジックをコピーして貼り付ける（非常に保守不可能）
• ビルダーを使用する（特にネスティングを使用する場合は、読みにくくなります）
• ミキシング（うまく構成されないため、異なるミックスインが共有状態で競合するのは非常に簡単です）

私が思う重要なことは、後者では、すぐにアーキテクチャの問題が発生するということです。これをツリーのどこに配置すればよいですか、これをカプセル化するにはどうすればよいですか、ビルダーにする必要がありますか、それともカスタムウィジェットにする必要がありますか？ 前者の場合、再利用されたロジックのこのチャンクをどのファイルに保存するかが唯一の決定であり、ツリーへの影響はまったくありません。 これは、これらのロジックカプセル化のいくつかを一緒に使用したり、階層内で上下に移動したり、兄弟ウィジェットに移動したりする場合に、アーキテクチャ的に非常に便利です。

私は決して専門家の開発者ではありません。 しかし、ロジックを

私は長い間Vue.jsを使用していませんが、次のバージョン用に独自のAPI（Hooksからインスピレーションを得たもの）を持っているので、一見の価値があるかもしれません。

• Vue3コンポジションAPI
• Vue3コンポジションAPIとReactフックの比較

そしてCMIIWは、reactフックのルール（条件付きを使用しない）はCompositionAPIには適用されないと思います。 したがって、ルールを適用するためにリンターを使用する必要はありません。

ここでも、動機付けのセクションでOPを強力に強化しています。

動機
複雑なコンポーネントのコードは、機能が時間の経過とともに大きくなるにつれて、推論するのが難しくなります。 これは特に、開発者が自分で作成していないコードを読んでいるときに発生します。
[ありました]複数のコンポーネント間でロジックを抽出して再利用するためのクリーンでコストのかからないメカニズムの欠如。

「クリーン」と「無料」というキーワードがあります。 Mixinは無料ですが、クリーンではありません。 ビルダーはクリーンですが、読みやすさの意味でも、ウィジェットのアーキテクチャの意味でも、ツリー内を移動したり、階層の観点から推論したりするのが難しいため、コストがかかりません。

また、これは読みやすさの議論で注意することが重要だと思います。「特に開発者が自分で書いたのではないコードを読んでいるときに起こります」。 もちろん、ネストされたビルダーは読みやすいかもしれません。そこに何があるかを知っていて、快適にスキップできます。大規模なプロジェクトで行うように、他の誰かのコードや、数週間/数か月前の独自のコードを読んでいます。これらのものを解析およびリファクタリングするのが面倒/難しい。

他のいくつかの特に関連するセクション。

単にコンポーネントを用意するだけでは不十分な理由：

...コンポーネントを作成すると、インターフェイスの繰り返し可能な部分とその機能を組み合わせて、再利用可能なコードに抽出できます。 これだけでも、保守性と柔軟性の点でアプリケーションをかなり遠くまで到達させることができます。 ただし、私たちの集合的な経験から、特にアプリケーションが非常に大きくなっている場合は、これだけでは不十分である可能性があることが証明されています。数百のコンポーネントを考えてみてください。 このような大規模なアプリケーションを扱う場合、コードの共有と再利用が特に重要になります。

論理的な断片化を減らし、物事をより強力にカプセル化することがなぜ勝利であるかについて：

断片化は、複雑なコンポーネントを理解して維持することを困難にするものです。 オプションの分離は、根底にある論理的な懸念を覆い隠します。 さらに、単一の論理的な懸念事項に取り組む場合、関連するコードのオプションブロックを常に「ジャンプ」する必要があります。 同じ論理的な懸念に関連するコードを併置できれば、はるかに良いでしょう。

私が提出したもの以外に、私たちが改善しようとしている標準的な例について他の提案があるかどうか知りたいです。
それが人々が使いたい出発点であるなら、それは素晴らしいことです。 ただし、現時点での最大の問題は冗長性です。 その例で再利用するコードはあまりありません。 したがって、OPで説明されているように、それが問題の適切な表現であるかどうかは私にはわかりません。

個人的に求めている特性をソリューションで表現する方法をもう少し考えていたところ、現在のフックの提案で見られる大きな問題のひとつに気づきました。それが私がそうしない理由の1つです。それをFlutterフレームワークにマージしたい：ローカリティとカプセル化、またはむしろその欠如。 フックの設計では、グローバル状態を使用します（たとえば、現在構築されているウィジェットを追跡するための静的状態）。 私見これは避けるべき設計上の特徴です。 一般に、APIを自己完結型にしようとしているため、1つのパラメーターを使用して関数を呼び出す場合、そのパラメーター以外の値では何も実行できないことを確信する必要があります（これが、BuildContextを渡す理由です） 、 useContext相当するものではなく）。 これが誰もが必然的に望んでいる特性だと言っているのではありません。 もちろん、問題がなければフックを使用することもできます。 それは私がFlutterでもっとやらないようにしたいことです。 グローバルな状態（バインディングなど）が発生するたびに、後悔することになります。

フックはおそらくコンテキスト上のメソッドである可能性がありますが（初期バージョンだったと思います）、正直なところ、現在のようにフックをマージすることにはあまり価値がありません。 マージには、パフォーマンスの向上や特定のデバッグツールのフックなど、パッケージを分離するためのいくつかの利点が必要になります。 そうしないと、混乱が増えるだけです。たとえば、リスニング可能なものを聞くには、AnimatedBuilder、StatefulWidget、useListenableの3つの公式な方法があります。

だから私にとって、行く方法はコード生成を改善することです-私はいくつかの変更を提案しました： https ：

これらの提案が実際に実装された場合、アプリで魔法のSwiftUIのようなソリューションが必要な人は、パッケージを作成するだけで、他の人に迷惑をかけることはありません。

フックの有効性について議論することは、私が知る限り、まだ問題に同意していないため、この段階ではトピックから外れています。

この号で数回述べたように、他にも多くの解決策があり、その複数は言語機能です。
フックは、最も基本的な形式で実装するのが比較的安価な、別の技術からの既存のソリューションの単なる移植版です。

この機能は、SwiftUIやJetpack Composeのように、フックとはまったく異なるパスを取る可能性があります。 「名前付きミックスイン」プロポーザル、またはBuildersプロポーザルのシンタックスシュガー。

私は、この問題の核心がStreamBuilderのようなパターンの単純化を求めているという事実を主張します。

• StreamBuilderは、ネストされているため、読みやすさや書き込み性が劣っています。
• ミックスインと関数はStreamBuilderの可能な代替手段ではありません
• すべてのStatefulWidgetsにStreamBuilderの実装をコピーして貼り付けるのは合理的ではありません

これまでのすべてのコメントでは、さまざまな動作（使い捨てオブジェクトの作成、HTTPリクエストの作成など）またはさまざまな構文の提案の両方について、StreamBuilderの代替案について言及していました。

他に何を言うべきかわからないので、どうすればこれ以上進むことができるかわかりません。
この声明@Hixieであなたが理解していない/同意していないこれは何ですか？

@rrousselGitこれを示す

• StreamBuilderは、ネストされているため、読みやすさや書き込み性が劣っています。

冗長性は問題ではないと既におっしゃいました。 ネストは、冗長であることのもう1つの側面です。 ネストが本当に問題になる場合は、Padding、Expanded、Flexible、Center、SizedBox、および実際の理由なしにネストを追加する他のすべてのウィジェットを追跡する必要があります。 ただし、ネストは、モノリシックウィジェットを分割することで簡単に解決できます。

すべてのStatefulWidgetsにStreamBuilderの実装をコピーして貼り付けるのは合理的ではありません

StatefulWidgetsが作成および破棄する必要のあるストリームを作成および破棄するコード行をコピーして貼り付けることを意味しますか？ はい、それは絶対に合理的です。

独自のストリームを作成/破棄する必要のある数百の_different_カスタムStatefulWidgets（フックの用語で「使用」）を10または神が禁止している場合、「ロジック」の再利用またはネストよりも大きな問題が発生します。心配します。そもそもなぜ私のアプリが非常に多くの異なるストリームを作成しなければならないのかについて。

公平を期すために、特定のパターンが自分のアプリでは合理的ではないと誰かが考えるのは問題ないと思います。 （これは必ずしもフレームワークがそれをネイティブにサポートする必要があることを意味するわけではありませんが、少なくともパッケージがそれを解決できるようにするのは良いことです。）誰かがstream.listenまたはStreamBuilder(stream)どちらも使用したくない場合

公平を期すために、特定のパターンが自分のアプリでは合理的ではないと誰かが考えるのは問題ないと思います。

私はあなたと同じページに100％います。
確かに、人々は自分のアプリでやりたいことを何でもすることができます。 私が得ようとしているのは、このスレッドで説明されているすべての問題と困難は、悪いプログラミング習慣の結果であり、実際にはDartやFlutterとはほとんど関係がないということです。 それは私の意見のようなものですが、あちこちで数十のストリームを作成するアプリを書いている人がいる場合は、フレームワークの「改善」を依頼する前に、アプリのデザインを確認する必要があります。

たとえば、サンプルリポジトリに組み込まれたフックの実装。

  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    final value = useAnimation(animation);

    final screenHeight = MediaQuery.of(context).size.height;
    final textHeight =
        useMemoized(() => math.sqrt(screenHeight), [screenHeight]);

    return Text(
      'Change Duration',
      style: TextStyle(fontSize: 10.0 + value * textHeight),
    );
  }

私はこれについて悪い気持ちを持っているので、私はいくつかの内部をチェックし、何が起こっているのかをチェックするためにいくつかのデバッグプリントを追加しました。
以下の出力から、Listenableフックがアニメーションティックごとに更新された天気をチェックしていることがわかります。 のように、そのリスナブルを「使用する」ウィジェットは更新されましたか？ 期間は変更されましたか？ インスタンスは置き換えられましたか？
メモ化されたフック、私はそれとの取引が何であるかさえ知りません。 おそらくオブジェクトをキャッシュすることを意図していますが、ビルドごとにウィジェットはオブジェクトが変更されたかどうかをチェックしますか？ 何？ どうして？ もちろん、ステートフルウィジェット内で使用され、ツリーの上の他のウィジェットが値を変更する可能性があるため、変更をポーリングする必要があります。 これは文字通りのポーリング動作であり、「リアクティブ」プログラミングとは正反対です。

さらに悪いことに、「new」フックと「old」フックはどちらも同じインスタンスタイプを持ち、どちらも同じ値を持ちますが、関数は値を繰り返し処理して、値が変更されたかどうかを確認します。 _すべての単一のアニメーションティック_。

これは私が得る出力です、無限に。

/flutter (28121): Use hook:_ListenableHook
I/flutter (28121): Is this the current hook:false
I/flutter (28121): 1: --- inside shouldPreserveState ----
I/flutter (28121): Hook1:Instance of '_ListenableHook'
I/flutter (28121): Hook1 keys:null
I/flutter (28121): Hook2 :Instance of '_ListenableHook'
I/flutter (28121): Hook2 keys:null
I/flutter (28121): 2. Shoud we preserve the  state of _ListenableHook:true
I/flutter (28121): 3: --------------
I/flutter (28121): checking if the listenable did change
I/flutter (28121): Did the listenable change?false
I/flutter (28121): Use hook:_MemoizedHook<double>
I/flutter (28121): Is this the current hook:false
I/flutter (28121): 1: --- inside shouldPreserveState ----
I/flutter (28121): Hook1:Instance of '_MemoizedHook<double>'
I/flutter (28121): Hook1 keys:[1232.0]
I/flutter (28121): Hook2 :Instance of '_MemoizedHook<double>'
I/flutter (28121): Hook2 keys:[1232.0]
I/flutter (28121): iterating over the hooks keys
I/flutter (28121): 2. Shoud we preserve the  state of _MemoizedHook<double>:true
I/flutter (28121): Use hook:_ListenableHook
I/flutter (28121): Is this the current hook:false
I/flutter (28121): 1: --- inside shouldPreserveState ----
I/flutter (28121): Hook1:Instance of '_ListenableHook'
I/flutter (28121): Hook1 keys:null
I/flutter (28121): Hook2 :Instance of '_ListenableHook'
I/flutter (28121): Hook2 keys:null
I/flutter (28121): 2. Shoud we preserve the  state of _ListenableHook:true

このすべての作業は、すべてのアニメーションティックで実行されます。 「finalcolor = useAnimation」のような別のフックを追加すると（animationColor）; "、色もアニメーション化するために、ウィジェットは更新されているかどうかを_2_回チェックするようになりました。

私はここに座って、アプリの状態やウィジェット、ウィジェットツリーを変更せずにテキストが前後にアニメーション化されるのを見ていますが、それでもフックはツリー/ウィジェットが更新されたかどうかを常にチェックしています。 これらの特定のフックを「使用する」すべてのウィジェットにこのポーリング動作を実行させるのは悪いことです。

buildメソッド内で状態オブジェクトの初期化/更新/破棄ロジックを処理するのは悪い設計です。 再利用性、ホットリロード、またはコグニティブロードで得られた改善の量は、パフォーマンスへの影響を正当化するものではありません。
繰り返しますが、私の意見では。 フックはパッケージであるため、利益がオーバーヘッドを正当化すると考える場合は、誰でもフックを使用できます。

また、ビルドプロセス内のすべてを抽象化しようとすると、言語機能、コンパイラマジック、または抽象化によって、このような不要なチェックを防ぐことができるとは思いません。 したがって、StatefulWidgetを拡張するなどの代替手段が残されています。 すでにできることで、何度も却下されました。

@Hixieあなたは質問に答えていません。 上記の箇条書きで理解していない/同意していないことは何ですか？

あなたが私に何を示してほしいかを知らずに例を作ることはできません。

@Rudiksz確かに、実際に検討するソリューションは、状況を悪化させないように、プロファイリングとベンチマークを行う必要があります。 @TimWhitingに送信した

@rrousselGitこれは非常に主観的であるため、私はこれについて雑草に

• まず、一般的にストリームの使用は避けます。 ValueListenableは、多かれ少なかれ同じユースケースに対してはるかに優れたパターンです。
• StreamBuilderの読み取りや書き込みは特に難しいとは思いません。 しかし、 @ satvikpendemが以前に
• ミックスインと関数がStreamBuilderの可能な代替手段であるかどうかについては、フックは関数を使用してストリームを確実にリッスンできることをかなりよく示していると思います。ミックスインはここでクラスが実行できることをすべて明確に実行できるため、なぜそうしないのかわかりません。解決策にもなりません。
• 最後に、コピー貼り付けの実装に関しては、それは主観的な問題です。 ロジックを個人的にコピーしてinitState / didUpdateWidget / dispose / buildに貼り付けるのではなく、毎回新しく作成しますが、ほとんど問題ないようです。 それが「制御不能」になったとき、私はそれをStreamBuilderのようなウィジェットに分解します。 したがって、ここでも私の意見はおそらく関係ありません。

原則として、私があなたが見ている問題を経験するかどうかは関係ありません。 あなたの経験は私の意見に関係なく有効です。 たとえ私がそれらの問題を感じなくても、私はあなたが経験する問題の解決策を見つけることに取り組んでうれしいです。 私自身が問題を経験していないことの唯一の影響は、この議論で見たように、私が問題をよく理解するのが難しいということです。

私があなたに示してほしいのは、受け入れられないと思うコーディングパターン

問題は、あなたが私にとって「自明」の領域にある何かの例を求めているということです。

いくつか例を挙げてもかまいませんが、あなたが理解していないことを理解していないので、あなたが何を期待しているのかわかりません。

私はすでに私が言わなければならなかったすべてを言いました。
あなたが理解していないことを理解せずに私ができる唯一のことは、自分自身を繰り返すことです。

ここでいくつかのスニペットを実行することができますが、それは自分自身を繰り返すことと同じです。
スニペットが役に立たなかった場合、それを実行できると何が変わるのかわかりません。

ミックスインと関数がStreamBuilderの可能な代替手段であるかどうかについては、フックは関数を使用してストリームを確実にリッスンできることをかなりよく示していると思います。ミックスインはここでクラスが実行できることをすべて明確に実行できるため、なぜそうしないのかわかりません。解決策にもなりません。

フックは機能と見なされるべきではありません。
これらは、Iterable / Streamに似た新しい言語構造です。

関数はフックが行うことを行うことができません—ウィジェットを再構築させる状態または機能がありません。

ミックスインの問題はOPで示されています。 TL; DR：変数で名前が衝突し、同じミックスインを複数回再利用することはできません。

@rrousselGitええと、いくつかの例を作成してもかまわないので、そして私が求めている例は明白なので、これらの明白な例のいくつかから始めて、そこから繰り返しましょう。

例が明白であるとは言いませんでしたが、問題はあります。
つまり、新しい例を作成することはできません。 私が言わなければならないことはすべて、すでにこのスレッドにあります：

• https://github.com/flutter/flutter/issues/51752#issue -573649367
• https://github.com/flutter/flutter/issues/51752#issuecomment -666333721
• https://github.com/flutter/flutter/issues/51752#issuecomment -667609783
• https://github.com/flutter/flutter/issues/51752#issuecomment -667646824
• https://github.com/flutter/flutter/issues/51752#issuecomment -669626522
• https://github.com/flutter/flutter/issues/51752#issuecomment -670250393
• https://github.com/flutter/flutter/issues/51752#issuecomment -670263627
• https://github.com/flutter/flutter/issues/51752#issuecomment -670959424
• https://github.com/flutter/flutter/issues/51752#issuecomment -671038875
• https://github.com/flutter/flutter/issues/51752#issuecomment -671054362
• https://github.com/flutter/flutter/issues/51752#issuecomment -671057882
• https://github.com/flutter/flutter/issues/51752#issuecomment -671060201
• https://github.com/flutter/flutter/issues/51752#issuecomment -671563514
• https://github.com/flutter/flutter/issues/51752#issuecomment -672389946

これらの例に追加するものは何も考えられません。

しかし、FWIWRiverpodを使用したオープンソースの天気アプリに取り組んでいます。 終わったらここにリンクします。

私はツイッターで世論調査を行い、ここで説明されている問題に関連するビルダーについていくつか質問しました。

https://twitter.com/remi_rousselet/status/1295453683640078336

投票はまだ保留中ですが、現在の数値は次のとおりです。

200人の86％が、ネストを伴わないビルダーを作成する方法を望んでいるという事実は、それ自体を物語っています。

明確にするために、私はこの問題に対処すべきではないと提案したことはありません。 対処すべきではないと思ったら、問題は解決します。

リンクしたスニペットを使用した例を作成しようと思います。

リンクされたスニペットに基づいて例を作成するのを手伝うことができますが、これらのスニペットが十分ではなかった理由を知る必要があります
それ以外の場合、私にできることはこれらのスニペットをコンパイルすることだけですが、それがあなたの望むことではないかと思います。

たとえば、ここに多数のValueListenableBuilder + TweenAnimationBuilderhttps ： //gist.github.com/rrousselGit/a48f541ffaaafe257994c6f98992fa73に関する要点があり

たとえば、ここに多数のValueListenableBuilder + TweenAnimationBuilderhttps ： //gist.github.com/rrousselGit/a48f541ffaaafe257994c6f98992fa73に関する要点があり

FWIW、この1つの特定の例は、mobxでより簡単に実装できます。
実際には、フックの実装よりも短いです。

MobxのオブザーバブルはステロイドのValueNotifiersであり、そのObserverウィジェットはFlutterのValueListenableBuilderの進化形です-複数のValueNotifierをリッスンできます。
ValueNotifier / ValueListenableBuilderコンボのドロップイン置換であるということは、慣用的なFlutterコードを作成することを意味します。これは、実際には重要な要素です。

Flutterに組み込まれているTweenビルダーを引き続き使用しているため、新しいウィジェット/フックを学習/実装する必要はなく（つまり、新しい機能は必要ありません）、フックのパフォーマンスへの影響はありません。

import 'package:flutter/material.dart';
import 'package:flutter_mobx/flutter_mobx.dart';
import 'counters.dart';

void main() {
  runApp(MyApp());
}

class MyApp extends StatelessWidget {
  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    return MaterialApp(
      home: Home1(),
    );
  }
}

var counters = Counters();

class Home1 extends StatelessWidget {
  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    return Scaffold(
      body: Center(
        child: Column(
          mainAxisAlignment: MainAxisAlignment.center,
          children: [
            Observer(
              builder: (context) => TweenAnimationBuilder<int>(
                duration: const Duration(seconds: 5),
                curve: Curves.easeOut,
                tween: IntTween(end: counters.firstCounter),
                builder: (context, value, child) {
                  return Text('$value');
                },
              ),
            ),
            RaisedButton(
              onPressed: () => counters.firstCounter += 100,
              child: Text('+'),
            ),
            // Both counters have voluntarily a different Curve and duration
            Observer(
              builder: (context) => TweenAnimationBuilder<int>(
                duration: const Duration(seconds: 2),
                curve: Curves.easeInOut,
                tween: IntTween(end: counters.secondCounter),
                builder: (context, value, child) {
                  return Text('$value');
                },
              ),
            ),
            RaisedButton(
              onPressed: () => counters.secondCounter += 100,
              child: Text('+'),
            ),
            const Text('total:'),
            // The total must take into account the animation of both counters
            Observer(
              builder: (context) => TweenAnimationBuilder<int>(
                duration: const Duration(seconds: 5),
                curve: Curves.easeOut,
                tween: IntTween(
                    end: counters.firstCounter + counters.secondCounter),
                builder: (context, value, child) {
                  return Text('$value');
                },
              ),
            ),
          ],
        ),
      ),
    );
  }
}

Counters.dartは...と同じくらい単純です

part 'counters.g.dart';

class Counters = _Counters with _$Counters;
abstract class _Counters with Store {
  <strong i="18">@observable</strong>
  int firstCounter = 0;

  <strong i="19">@observable</strong>
  int secondCounter = 0;
}

これは、animationbuilderを必要としない別の実装です。 ウィジェットのビルドメソッドは、セマンティックhtmlファイルのように...テンプレートのように、可能な限り純粋です。

https://gist.github.com/Rudiksz/cede1a5fe88e992b158ee3bf15858bd9

@Rudiksz 「合計」フィールドの動作はスニペットで壊れています。 これは、両方のカウンターが一緒にアニメーション化する可能性があるが、異なる時間に異なる曲線でアニメーション化を終了する例とは一致しません。
同様に、この例がValueListenableBuilderバリアントに何を追加するのかわかりません。

最後の要点として、 TickerProviderはTickerModeサポートしていないため壊れています。また、リスナーが削除されたり、コントローラーが破棄されたりすることもありません。

そして、Mobxはおそらくトピックから外れています。 アンビエント状態/ ValueListenable vs Stores vs Streamsを実装する方法については説明していませんが、ローカル状態/ネストされたビルダーを処理する方法について説明しています。これはMobxでは解決されません。

––––

また、フックの例では、 useAnimatedIntパッケージに抽出できる/抽出する必要があり、個々のテキストアニメーションと合計の間に期間/曲線の重複がないことに注意してください。

パフォーマンスに関しては、フックでは1つの要素のみを再構築しますが、ビルダーでは2〜4個のビルダーを再構築します。
したがって、フックは非常に高速になる可能性があります。

「合計」フィールドの動作は、スニペットで壊れています。 これは、両方のカウンターが一緒にアニメーション化する可能性があるが、異なる時間に異なる曲線でアニメーション化を終了する例とは一致しません。

あなたは明らかに、例を実行しようとさえしませんでした。 コードとまったく同じように動作します。

最後の要点として、TickerProviderはTickerModeをサポートしていないため、壊れています。

これが何を意味するのかわかりません。 TickerModeを使用しない_your_の例をリファクタリングしました。 再び要件を変更しています。

パフォーマンスに関しては、フックでは1つの要素のみを再構築しますが、ビルダーでは2〜4個のビルダーを再構築します。 したがって、フックは非常に高速になる可能性があります。

いいえ、いいえ。 フックウィジェットは、ビルドごとに変更を常にポーリングします。 valuelistenablesに基づくビルダーは「リアクティブ」です。

同様に、この例がValueListenableBuilderバリアントに何を追加するのかわかりません。

そして、Mobxはおそらくトピックから外れています。 アンビエント状態/ ValueListenable vs Stores vs Streamsを実装する方法については説明していませんが、ローカル状態/ネストされたビルダーを処理する方法について説明しています。これはMobxでは解決されません。

冗談でしょう。 私はあなたの例を取り上げ、ネストされたValueListenableBuilders *とトゥイーンビルダーで「取引」しましたか？！ あなたが特に問題として提起した点。
しかし、ここでのこの文は、この議論に対するあなたの全体的な態度を説明しています。 フックでない場合は「トピック外」ですが、解決策として使用されるのがフックであるかどうかは気にしないと言います。
ちょっと休憩してください。

あなたは明らかに、例を実行しようとさえしませんでした。 コードとまったく同じように動作します。

そうではありません。 最初のカウンターは5秒以上、2番目のカウンターは2秒以上アニメーションし、どちらも異なるカーブを使用します。

私が提供した両方のスニペットを使用すると、両方のカウンターを同時にインクリメントでき、アニメーションのすべてのフレームで「合計」が正しくなります。 最初のカウンターがまだアニメーションしている間に2番目のカウンターがアニメーションを停止した場合でも

一方、実装では2つのTweenAnimationBuilderが1つにマージされているため、このケースは考慮されていません。
それを修正するには、次のように書く必要があります。

Observer(
  builder: (context) {
    return TweenAnimationBuilder<int>(
      duration: const Duration(seconds: 5),
      curve: Curves.easeOut,
      tween: IntTween(end: counters.firstCounter),
      builder: (context) {
        return Observer(
          valueListenable: secondCounter,
          builder: (context, value2, child) {
            return TweenAnimationBuilder<int>(
              duration: const Duration(seconds: 2),
              curve: Curves.easeInOut,
              tween: IntTween(end: counters.secondCounter),
              builder: (context, value2, child) {
                return Text('${value + value2}');
              },
            );
          },
        );
      },
    );
  },
)

2つのTweenAnimationBuildersは、両方のカウンターが個別にアニメーション化できるという事実を尊重するために必要です。 また、最初のObserverはcounters.secondCounter監視できないため、2つのObserverが必要です。

いいえ、いいえ。 フックウィジェットは、ビルドごとに変更を常にポーリングします。 valuelistenablesに基づくビルダーは「リアクティブ」です。

Element機能を無視しています。これは、フックの機能と同じです。runtimeTypeとキーを比較し、新しい要素を作成するか、既存の要素を更新するかを決定します。

私はあなたの例を取り上げ、ネストされたValueListenableBuilders *とトゥイーンビルダーで「取引」しました

合計数の問題が修正されたとすると、どのネストが削除されましたか？

Observer(
  builder: (context) => TweenAnimationBuilder<int>(
    duration: const Duration(seconds: 5),
    curve: Curves.easeOut,
    tween: IntTween(end: counters.firstCounter),
    builder: (context, value, child) {
      return Text('$value');
    },
  ),
),

と違いはありません：

ValueListenableBuilder<int>(
  valueListenable: firstCounter,
  builder: (context, value, child) => TweenAnimationBuilder<int>(
    duration: const Duration(seconds: 5),
    curve: Curves.easeOut,
    tween: IntTween(end: value),
    builder: (context, value, child) {
      return Text('$value');
    },
  ),
),

入れ子の観点から。

あなたがあなたの要点に言及しているなら、私が前に述べたように、このアプローチはTickerProvider / TickerMode破ります。 vsyncは、 SingleTickerProviderClientStateMixinを使用して取得する必要があります。そうしないと、ミューティングロジックがサポートされないため、パフォーマンスの問題が発生する可能性があります。
私の記事でこれを説明しました： https ：

そして、このアプローチでは、元々TweenAnimationBuilderが必要なすべての場所にTweenロジックを再実装する必要があります。 これは、特にロジックがそれほど簡単ではないことを考えると、重大な重複につながります

私が提供した両方のスニペットを使用すると、両方のカウンターを同時にインクリメントでき、アニメーションのすべてのフレームで「合計」が正しくなります。 最初のカウンターがまだアニメーションしている間に2番目のカウンターがアニメーションを停止した場合でも

一方、実装では2つのTweenAnimationBuilderが1つにマージされているため、このケースは考慮されていません。

はい、それは私が喜んで行ったトレードオフです。 アニメーションが変化が起こったときの視覚的なフィードバックにすぎず、精度が重要ではない場合は簡単に想像できます。 それはすべて要件に依存します。

しかし、私はあなたが反対するだろうと思ったので、コードをさらにクリーンにしながら、この正確な問題を解決する2番目のバージョン。

あなたがあなたの要点を参照しているなら、私が前に述べたように、このアプローチはTickerProvider / TickerModeを壊します。 vsyncは、SingleTickerProviderClientStateMixinを使用して取得する必要があります。そうしないと、パフォーマンスの問題を引き起こす可能性のあるミューティングロジックをサポートしません。

したがって、ウィジェットでティッカープロバイダーを作成し、それをカウンターに渡します。 アニメーションコントローラーも処分しませんでした。 これらの詳細は実装するのが非常に簡単で、例に何かを追加するような気がしませんでした。 しかし、ここで私たちはそれらをあざ笑っています。

私はCounter（）クラスを実装して、あなたの例が行うことだけを実行しました。

そして、このアプローチでは、元々TweenAnimationBuilderが必要なすべての場所にTweenロジックを再実装する必要があります。 これは、特にロジックがそれほど簡単ではないことを考えると、重大な重複につながります

何？ どうして？ Pleasaeは、Counterクラスのインスタンスを複数作成して、さまざまなウィジェットで使用できないのはなぜですか？

@Rudikszあなたの解決策が実際に述べられた問題を解決しているかどうかは

私はCounter（）クラスを実装して、あなたの例が行うことだけを実行しました。

それでも

はい、それは私が喜んで行ったトレードオフです。 アニメーションが変化が起こったときの視覚的なフィードバックにすぎず、精度が重要ではない場合は簡単に想像できます。 それはすべて要件に依存します。

したがって、ウィジェットでティッカープロバイダーを作成し、それをカウンターに渡します。 アニメーションコントローラーも処分しませんでした。 これらの詳細は実装するのが非常に簡単で、例に何かを追加するような気がしませんでした。 しかし、ここで私たちはそれらをあざ笑っています。

表面上は@rrousselGitのフックバージョンと同等のコードを提供しましたが、フックバージョンに含まれる部分を@TimWhitingのリポジトリを作成する理由です。 すべての要件を満たしていると思われる場合は、そこにソリューションを送信できます。

あなたは明らかに、例を実行しようとさえしませんでした。 コードとまったく同じように動作します。

いいえ、いいえ。

冗談でしょう。 私はあなたの例を取り上げ、ネストされたValueListenableBuilders *とトゥイーンビルダーで「取引」しました

このような非難はご遠慮ください。根本的な問題を解決せずに、このスレッドを活気に満ちたものにするだけです。 このスレッドで私が見たコメントの結果である、相手を非難したり、蔑称したり、怒ったりすることなく、あなたはあなたの主張をすることができます。私はあなたに対する他の人からのそのような行動を見ません。 また、自分の投稿に絵文字を反応させる効果もわかりません。

@rrousselGit

リンクされたスニペットに基づいて例を作成するのを手伝うことができますが、これらのスニペットが十分ではなかった理由を知る必要があります
それ以外の場合、私にできることはこれらのスニペットをコンパイルすることだけですが、それがあなたの望むことではないかと思います。

スニペットだけでなく、より複雑なアプリを求めている理由は、スニペットの1つを処理する例を投稿したときに、それ以外のケースも処理しなかったため、それでは不十分だと言ったからです。スニペットに含まれていません（たとえば、didUpdateWidgetを処理しなかった、これらのスニペットを2つ並べて処理しなかった、またはその他の完全に合理的な処理を行いませんでした）。 より精巧なアプリで十分に精巧にできることを望んでいます。解決策があれば、処理が必要な新しい問題が発生する「落とし穴」の瞬間はありません。 もちろん、処理が必要なものを見逃してしまう可能性はありますが、その可能性を最小限に抑えることが目的です。

最近のあまり歓迎されていない投稿については、小さな例で前後に戦うのではなく、 @ TimWhitingのリポジトリで例を作成することに焦点を当てましょう。 すでに説明したように、小さな例は、代替案が実際にうまく機能することを証明するのに十分な代表となるほど精巧なものになることは決してありません。

すべての要件を満たしていると思われる場合は、そこにソリューションを送信できます。

要件は事後に変更されました。 私は2つの解決策を提供しました。 妥協するもの（非常に合理的なもの）と、提供された例の正確な動作を実装するもの。

表面上は@rrousselGitのフックバージョンと同等のコードを提供しましたが、実際には同等ではありません。

「フックソリューション」は実装しませんでした。特に「ネストの問題」に焦点を当てて、ValueListenableBuilderの例を実装しました。 フックが行うすべてのことを実行するわけではありません。別のソリューションを使用して、不満の箇条書きリストの1つの項目を簡略化する方法を紹介しました。

外部パッケージをディスカッションに持ち込むことが許可されている場合は、私もそうです。

再利用性：以下のリポジトリの例をご覧ください
https://github.com/Rudiksz/cbl_example

ノート：

• これは、ウィジェットの外部に「ロジック」をカプセル化し、無駄のない、ほぼhtmlのようなウィジェットを作成する方法のショーケースとして意図されています。
• フックがカバーするすべてをカバーするわけではありません。 それは重要ではありません。 フックパッケージではなく、ストックのFlutterフレームワークの代替案について話し合っていると思いました。
• すべてのマーケティングチームが思いつく可能性のあるすべてのユースケースを網羅しているわけではありません
• ただし、Counterオブジェクト自体は非常に柔軟性があり、さまざまなカウンターの合計を計算したり、リアクティブにしたり、ユーザー入力に応答したりする必要がある複雑なウィジェットの一部として、スタンドアロンで使用できます（AppBarタイトルを参照）。
• 使用するカウンターの量、初期値、期間、アニメーションタイプをカスタマイズするのは、消費するウィジェット次第です。
• アニメーションの処理方法の詳細には、欠点がある場合があります。 Flutterチームが、ウィジェットの外部でアニメーションコントローラーとトゥイーンを使用すると、どういうわけかフレームワークが壊れると言った場合は、再考します。 間違いなく改善すべきことがあります。 私が使用しているカスタムティッカープロバイダーを、消費ウィジェットのミックスインによって作成されたものに置き換えるのは簡単です。 私はそれをしていません。
• これは、「ビルダー」パターンのもう1つの代替ソリューションです。 Builderを使用する必要がある、または使用したい場合は、これは当てはまりません。
• それでも、実際には、追加機能なしでコードを単純化する方法があります。 気に入らない場合は購入しないでください。 私はこれをフレームワークにすることを主張していません。

編集：この例にはバグがあります。変更がアニメーション化されているときに「インクリメント」を開始すると、カウンターがリセットされ、現在の値からインクリメントされます。 これらの「カウンター」に対する正確な要件がわからないため、意図的に修正しませんでした。 この問題を修正するために、インクリメント/デクリメント方法を変更するのは簡単です。

以上です。

@Hixie私の例（https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/hooks/animated_counter.dart）が十分ではないという言い方として、あなたのコメントを解釈する必要がありますか？

また、Zoom / Googleのミートコールはありますか？

また、自分の投稿に絵文字を反応させる効果もわかりません。

何もない。 それは何にも全く無関係です。 なぜそれを育てたのですか？

@rrousselGitそれが十分かどうかを知ることができるのはあなただけです。 その例をリファクタリングして、クリーンで短く、重複するコードがないようにする方法を見つけたら、満足しますか？ または、このバグを満たすために処理する必要がある、その例では処理されない、サポートする必要があると思われるものはありますか？

それが十分かどうかを知ることができるのはあなただけです

私はその判断を下すことはできません。 そもそも、有限のアプリケーションを使って問題を捉えることができるとは思いません。

私はあなたが私に望んでいるように働いてもかまいませんが、それが私たちをどのように進歩させるか理解していないので、私は指導が必要です。

私たちの視点から問題を示す大量のコードスニペットを提供したと思います。 示されているものがそれをしていない場合、私は本当により多くのコード例を通してより明確になるとは思いません。

たとえば、読むのが恐ろしいネストされたビルダーが複数ある場合や、バグの可能性が高い50行の純粋な定型文が問題を十分に示していない場合、どこにも行きません。

ミックスインを提供するのは非常に奇妙であり、関数がここでの解決策であり、ask全体がカプセル化された状態である

私にとって、私たちは地球に2ポイントを打ち負かしたと思います、そして私はどちらかと真剣に議論することはできないと思います。

1. ネストされたビルダーは本質的に読みにくいです
2. ネストされたビルダー以外に、ウィジェットのライフサイクルフックを持つ状態をカプセル化して共有する方法はありません。

何度も述べられているように、そしてRemiの世論調査でも、簡単に言えば、次のように言います。ビルダーの冗長性やネストされたクロージャーなしで、ビルダーの機能が必要です。 それは完全に要約していませんか？ ここに進むためにさらにコード例が必要な理由は完全に混乱しています。

Remiの世論調査では、Flutter開発者の約80％が、可能な場合はコード内のネストされたビルダーを回避するための何らかの機能を好むことが示されています。 これは本当にそれ自体がimoです。 コミュニティの感情が非常に明確な場合は、このスレッドで私たちからそれを取得する必要はありません。

私の見解では、問題は明確であり、ここで理論的根拠を説明するために段落を捧げる競合するフレームワークを見ると、問題はさらに明確になります。 Vue、React、Flutterはすべていとこであり、すべてReactから派生しており、ウィジェットのライフサイクルに結び付けなければならない状態を再利用するというこの問題に直面しています。 それらはすべて、なぜこのようなものを実装したのかを詳細に説明しています。 大丈夫です。 それはすべて関連しています。

@rrousselGit複数のフックがある例を挙げて

List<AnimationController> controllers = [];
int numAnimationControllers = 50;

<strong i="7">@override</strong>
void initState() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers.add(AnimationController(...));
}

<strong i="8">@override</strong>
void dispose() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers[i].dispose();
}

しかし、フックを使用すると、ループ内でuseAnimationControllerを呼び出すことはできません。 これは些細な例だと思いますが、このタイプのユースケースの解決策はどこにも見つかりませんでした。

@satvikpendem

本番環境にある私のアプリのいくつかの例（ページ付けを使用してリクエストを送信するなどのフックの一部は、単一のフックにマージ/リファクタリングできますが、ここでは関係ありません）：

ページ付けを使用した単純なデータフェッチ：

    final selectedTab = useState(SelectedTab.Wallet);
    final isDrawerOpen = useValueNotifier(false);
    final pageNo = useValueNotifier(0);
    final generalData = useValueNotifier(initialData);
    final services = useXApi();
    final isLoading = useValueNotifier(false);
    final waybillData = useValueNotifier<List<WaybillResponseModel>>([]);
    final theme = useTheme();
    final router = useRouter();

    fetchNextPage() async {
      if (isLoading.value || selectedTab.value != SelectedTab.Wallet) return;
      isLoading.value = true;
      final request = WaybillRequestModel()..pageNo = pageNo.value;
      final result = await services.waybillGetList(model: request);
      if (result.isOk && result.data.length > 0) {
        pageNo.value += 1;
        waybillData.value = [...waybillData.value, ...result.data];
      }
      isLoading.value = false;
    }

    // first fetch
    useEffect(() {
      fetchNextPage();
      return () {};
    }, []);

フォームロジック（電話番号の確認とタイマーの再送信を伴うログインフォーム）：

    final theme = useTheme();
    final loginState = useValueNotifier(LoginState.EnteringNumber);
    final error = useValueNotifier<String>(null);
    final phoneNumberController = useTextEditingController(text: "");
    final phoneNumberFocusNode = useMemoized(() => FocusNode(), []);
    final otpFocusNode = useMemoized(() => FocusNode(), []);
    final otpController = useTextEditingController(text: "");
    final appState = Provider.of<AppStateController>(context);
    final services = useXApi();
    final router = useRouter();
    final resendTimerValue = useValueNotifier(0);
    useEffect(() {
      var timer = Timer.periodic(Duration(seconds: 1), (t) async {
        if (resendTimerValue.value > 0) resendTimerValue.value--;
      });
      return () => timer.cancel();
    }, []);

    final doLogin = () async {
      // login
      loginState.value = LoginState.LoggingIn;
      final loginResult = await services.authLoginOrRegister(
        mobileNumber: phoneNumberController.text,
      );
      if (loginResult.isOk) {
        loginState.value = LoginState.EnteringOtpCode;
        WidgetsBinding.instance.addPostFrameCallback((_) {
          FocusScope.of(context).requestFocus(otpFocusNode);
        });
        resendTimerValue.value = 30;
      } else {
        error.value = loginResult.errorMessage;
        loginState.value = LoginState.EnteringNumber;
        WidgetsBinding.instance.addPostFrameCallback((_) {
          FocusScope.of(context).requestFocus(phoneNumberFocusNode);
        });
      }
    };

アニメーションについては、 @ rrousselGitがすでに十分な例を提供していると思います。

フックの構成可能な性質により、上記のコードのリファクタリングがはるかに簡単で、再利用可能で、クリーンになる方法については説明したくありませんが、必要に応じて、リファクタリングされたバージョンを投稿することもできます。

何度も述べられているように、そしてRemiの世論調査でも、簡単に言えば、次のように言います。ビルダーの冗長性やネストされたクロージャーなしで、ビルダーの機能が必要です。 それは完全に要約していませんか？ ここに進むためにさらにコード例が必要な理由は完全に混乱しています。

Remiが提供した例を使用して、冗長性を減らし、ビルダーのネストを回避する方法の例を文字通り提供しました。
私は彼のコードを自分のアプリに貼り付け、実行して書き直しました。 機能性に関する限り、最終結果はほぼ同じでした。コードには要件が付属していなかったため、コードを実行するだけで収集できた限りです。 確かに、エッジケースと潜在的な問題について議論することはできますが、代わりにそれはオフトピックと呼ばれていました。

単純なユースケースではBuilderを使用し、複雑なユースケースではBuilderを使用しません。 ここでの議論は、ビルダーを使用せずに、簡潔で再利用可能なコードを書く簡単な方法はないということです。 暗黙のうちに、それはビルダーが必須であり、Flutterアプリを開発する唯一の方法であることも意味します。 それは明らかに誤りです。

それを実証する、実用的な概念実証コードを示しました。 ビルダーやフックを使用していませんでした。また、この特定のgithubの問題が解決したいと思われる「無限の問題セット」を100％カバーしていません。 それはオフトピックと呼ばれていました。
ちなみに、これは非常に効率的です。ベンチマークがなくても、Builderウィジェットよりも優れていると思います。 間違っていることが判明した場合は、考えを変えることができます。Mobxがパフォーマンスのボトルネックになることがわかった場合は、Mobxを捨てて、ハートビートでバニラビルダーに切り替えます。

ヒックソンはグーグルで働いています、彼はあなたに忍耐強くそして礼儀正しくなければならず、あなたの婚約の欠如についてあなたを呼ぶことはできません。 彼ができる最善のことは、より多くの例を推し進めることです。

私は誰にも名前を呼んだり、個人的な攻撃を加えたりしませんでした。 私はここに提示された議論にのみ反応し、私の意見を共有しました
（私が知っていることは人気がなく、少数派です）そして実際の反例をコードで提示しようとさえしました。 私はもっ​​と多くのことができます。私の例がどこに足りないのかを話し合い、それらを改善する方法を見ていきたいと思いますが、ええ、オフトピックと呼ばれることは一種の不快感です。

おそらく禁止される以外に失うものは何もないので、私はあなたを呼ぶことを本当に気にしません。
経験した問題の解決策はフックだけであり（「Reactがそれを行うため」）、代替案が想像している「無限の問題セット」を100％満たしていない限り、2人がデッドセットになっていることは明らかです。あなたも従事することを検討しません。

それは合理的ではなく、真に関与したいという欲求の欠如を示しています。

もちろん、上記のすべては「私の意見です」。

その例ではフックの有用性がわかりますが、一度に多くのオブジェクトを初期化したいように見える私の場合、この場合はAnimationController sであるが、どのように機能するのか理解できないと思います。実際には何でもかまいません。 フックはこのケースをどのように処理しますか？

基本的にこれを回すフックの方法はありますか

var x1 = useState(1);
var x2 = useState(2);
var x3 = useState(3);

の中へ

var xs = []
for (int i = 0; i < 3; i++)
     xs[i] = useState(i);

フックルールに違反せずに？ 通常のFlutterに同等のものをリストしたからです。 私はFlutterのフックの経験があまりないので、そこで我慢してください。

すべてのinitStateを使用してオンデマンドでフックオブジェクト（AnimationControllersなど）の配列を作成し、既にインスタンス化された状態で破棄したいのですが、フックでどのように機能するかわかりません。

@satvikpendemは、クラスのプロパティのようなフックについて考えます。 それらをループで定義しますか、それとも手動で1つずつ名前を付けますか？

あなたの例では、このように定義しています

var x1 = useState(1);
var x2 = useState(2);
var x3 = useState(3);

このユースケースに役立ちます：

var isLoading = useState(1);
var selectedTab = useState(2);
var username = useState(3); // text field

各useStateが状態ロジックの名前付き部分にどのように関連しているかわかりますか？ （isLoadingのuseStateは、アプリが読み込み状態のときに接続されます）

2番目のスニペットでは、ループでuseStateを呼び出しています。 useStateは、状態ロジックの一部ではなく、値の所有者として考えています。 このリストは、 ListViewのアイテムの束を表示するために必要ですか？ はいの場合、リスト内のすべての項目を個別ではなく状態と見なす必要があります。

final listData = useState([]);

これはuseStateためだけのものであり、条件またはループでいくつかのフックを呼び出すためのいくつかのユースケース（非常にまれだと思います）を見ることができます。 これらの種類のフックには、データのリストを処理するための1つではなく別のフックが必要です。 例えば：

var single = useTest("data");
var list = useTests(["data1", "data2"]);
// which is equivalent to
var single1 = useTest("data1");
var single2 = useTest("data2");

なるほど、フックを使用すると、複数のAnimationControllerなどのアイテムの配列を持つケースを処理するために別のフックを作成する必要があるように見えます。

これは私が最初に持っていたもので、機能していないようです：

  final animationControllers = useState<List<AnimationController>>([]);

  animationControllers.value = List<AnimationController>.generate(
    50,
    (_) => useAnimationController(),
  );

しかし、複数のアイテムを処理するために独自のフックを作成する場合、これは機能するはずですよね？

class _MultipleAnimationControllerHook extends Hook<MultipleAnimationController> {
  const _MultipleAnimationControllerHook({
    this.numControllers,
    this.duration,
    this.debugLabel,
    this.initialValue,
    this.lowerBound,
    this.upperBound,
    this.vsync,
    this.animationBehavior,
    List<Object> keys,
  }) : super(keys: keys);

  /// Take in number of controllers wanted
  /// This hook assumes all `AnimationController`s will have the same parameters
  final int numControllers; 

  final Duration duration;
  final String debugLabel;
  final double initialValue;
  final double lowerBound;
  final double upperBound;
  final TickerProvider vsync;
  final AnimationBehavior animationBehavior;

  <strong i="10">@override</strong>
  _AnimationControllerHookState createState() =>
      _AnimationControllerHookState();
}

class _AnimationControllerHookState
    extends HookState<AnimationController, _AnimationControllerHook> {
  List<AnimationController> _multipleAnimationController; // return a list instead of a singular item

  <strong i="11">@override</strong>
  void initHook() {
    super.initHook();
    for (int i = 0; i < hook.numControllers) // just added loops 
        _multipleAnimationController[i] = AnimationController(
          vsync: hook.vsync,
          duration: hook.duration,
          debugLabel: hook.debugLabel,
          lowerBound: hook.lowerBound,
          upperBound: hook.upperBound,
          animationBehavior: hook.animationBehavior,
          value: hook.initialValue,
        );
  }

  <strong i="12">@override</strong>
  void didUpdateHook(_AnimationControllerHook oldHook) {
      for (int i = 0; i < numControllers; i++) {
        if (hook.vsync != oldHook[i].vsync) {
           _multipleAnimationController[i].resync(hook.vsync);
        }

        if (hook.duration != oldHook[i].duration) {
          _multipleAnimationController[i].duration = hook.duration;
        }
      }
  }

  <strong i="13">@override</strong>
  MultipleAnimationController build(BuildContext context) {
    return _multipleAnimationController;
  }

  <strong i="14">@override</strong>
  void dispose() {
    _multipleAnimationController.map((e) => e.dispose());
  }
}

これは、フックの単一バージョンがある場合、それを複数のアイテムを持つバージョンに使用できず、代わりにロジックを書き直す必要があることを意味しますか？ それとも、これを行うためのより良い方法はありますか？

誰かが私も知りたいフック以外の例を挙げたいのなら、私は再利用性パズルのこのピースについて疑問に思っていました。 この動作を独自のAnimationControllerフィールドを持つクラスにカプセル化する方法があるかもしれませんが、それがループ内で作成された場合、フックもルールに違反します。 おそらく、フック実装の条件やループの影響を受けないVueがどのようにそれを行うかを考えることができます。

@satvikpendem

私のステートメントはAnimationControllerまたはuseAnimationControllerは有効ではないと思います

複数のAnimationControllerがある場合でも、クラスメソッドで使用するために必ずしも配列に格納する必要はないためです。 例えば：

useSingleTickProvider();
final animation1 = useAnimationController();
final animation2 = useAnimationController();
final animation3 = useAnimationController();
// ...
useEffect(() async {
  await animation1.forward();
  await Future.sleep(100);
  await animation1.reverse();
  await animation2.forward();
  await animation3.forward();
}, []);

（リストを作成してanimation[0]ように参照することはありません）

正直なところ、フックを使った反応とフラッターの経験では、ループ内である種のフックを呼び出す必要はめったにありませんでした。 それでも、ソリューションは単純明快で実装が簡単でした。 今考えてみると、IMOが「よりクリーンな」ソリューションであるコンポーネント（ウィジェット）をそれぞれに作成するなど、より良い方法で確実に解決できる可能性があります。

複数のAnimationControllerを処理する簡単な方法がある場合は、質問に答えるために、はい、あります。

final ticker = useTickerProvider();
final controllers = useMemo(() => [AnimationController(ticker), AnimationController(ticker)], []);

useEffect(() {
  controllers.forEach(x => x.resync(ticker));
  return () => controllers.forEach(x => x.dispose());
}, [ticker, controllers]);

• AnimationControllerが動的である場合は、 useState使用することもできます。

（ティッカーが変更されたときにも再同期されます）

@rrousselGit複数のフックがある例を挙げて

List<AnimationController> controllers = [];
int numAnimationControllers = 50;

<strong i="8">@override</strong>
void initState() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers.add(AnimationController(...));
}

<strong i="9">@override</strong>
void dispose() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers[i].dispose();
}

しかし、フックを使用すると、ループ内でuseAnimationControllerを呼び出すことはできません。 これは些細な例だと思いますが、このタイプのユースケースの解決策はどこにも見つかりませんでした。

フックはそれを別の方法で行います。

コントローラのリストはもう作成しませんが、コントローラロジックを次の項目に移動します。

Widget build(context) {
  return ListView(
    children: [
      for (var i = 0; i < 50; i++)
        HookBuilder(
          builder: (context) {
            final controller = useAnimationController();
          },
        ),
    ],
  );
}

まだ50個のアニメーションコントローラーを作成しましたが、それらは別のウィジェットによって所有されています。

なぜそれが必要なのかという例を共有して、フックに変換してティムのリポジトリに追加することができますか？

ヒックソンはグーグルで働いています、彼はあなたに忍耐強くそして礼儀正しくなければならず、あなたの婚約の欠如についてあなたを呼ぶことはできません。 彼ができる最善のことは、より多くの例を推し進めることです。

@Hixie 、それがあなたの気持ちなら、そう言ってください（ここで、または私に個人的に連絡してください）。

Remiが提供した例を使用して、冗長性を減らし、ビルダーのネストを回避する方法の例を文字通り提供しました。

感謝しますが、このロジックをさまざまなユースケースに適用するときに、このコードから共通のパターンを抽出する方法がわかりません。

OPで、私は現在、3つの選択肢があると述べました。

• ビルダーを使用し、ネストされたコードを持っている
• より複雑な状態ロジックにスケーリングされないコードを因数分解しないでください（ StreamBuilderとそのAsyncSnapshotは複雑な状態ロジックであると主張します）。
• mixins / oop / ...を使用していくつかのアーキテクチャを作成してみてください。ただし、問題に固有の解決策になり、_tiny_ビットが異なるユースケースでは書き直しが必要になります。

3番目の選択肢（ PropertyまたはaddDisposeプロポーザルの初期の反復と同じカテゴリにあります）を使用したように見えます。

以前、パターンを判断するための評価グリッドを作成しました。

• https://github.com/flutter/flutter/issues/51752#issuecomment -671000137
• https://github.com/flutter/flutter/issues/51752#issuecomment -671002248

これでバリアントを実行できますか？ 特に、複数回使用した場合にコードを重複させずにStreamBuilderすべての機能を実装

このバグに関するこの時点での私の計画は次のとおりです。

1. https://github.com/flutter/flutter/issues/51752#issuecomment -675285066の例を使用して、純粋なFlutterを使用して、これらのさまざまなユースケースを一緒に示すアプリを作成します。
2. ここで説明したさまざまな主要要件を満たし、設計原則に適合する例のコード再利用を可能にするソリューションを設計してみてください。

誰かがこれらのいずれかを手伝いたいのなら、私は間違いなく助けてくれてうれしいです。 私は最初にNNBD移行に取り組んでいるので、すぐにこれに到達する可能性は低いです。

@rrousselGit確かに、私は多くのウィジェットが画面上を移動できるアプリを作成しています（ Box esと呼びましょう）。ウィジェットは互いに独立して移動できる必要があります（少なくとも、ウィジェットが必要です）。 Boxごとに1つのAnimationController）。 これは、複数のウィジェット間で共有される1つのAnimationControllerだけで作成した1つのバージョンですが、将来的には、カスタムスクロールホイール効果を使用してCupertinoPickerを実装するなどの複雑な変換を行うために、各ウィジェットを個別にアニメーション化する可能性があります。 。

スタックには、FloatingActionButtonをクリックすると上下に移動する3つのボックスがあります。

import 'package:flutter/material.dart';
import 'package:flutter_hooks/flutter_hooks.dart';

void main(List<String> args) => runApp(const App());

class App extends HookWidget {
  const App({Key key});

  static const Duration duration = Duration(milliseconds: 500);
  static const Curve curve = Curves.easeOutBack;

  <strong i="11">@override</strong>
  Widget build(BuildContext context) {
    final AnimationController controller =
        useAnimationController(duration: duration);
    final Animation<double> animation = Tween<double>(
      begin: 0,
      end: 300,
    )
        .chain(
          CurveTween(
            curve: curve,
          ),
        )
        .animate(controller);
    final ValueNotifier<bool> isDown = useState<bool>(false);
    final ValueNotifier<int> numBoxes = useState<int>(3);

    return MaterialApp(
      home: SafeArea(
        child: Scaffold(
          floatingActionButton: FloatingActionButton(
            onPressed: () {
              if (!isDown.value) {
                controller.forward();
                isDown.value = true;
              } else {
                controller.reverse();
                isDown.value = false;
              }
            },
          ),
          body: AnimatedBuilder(
            animation: animation,
            builder: (_, __) => Boxes(
              numBoxes: numBoxes.value,
              animation: animation,
            ),
          ),
        ),
      ),
    );
  }
}

class Boxes extends StatelessWidget {
  Boxes({
    <strong i="12">@required</strong> this.numBoxes,
    <strong i="13">@required</strong> this.animation,
  });

  final int numBoxes;
  final Animation<double> animation;

  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    return Stack(
      children: List<Widget>.generate(
        numBoxes,
        (int index) => Positioned(
          top: (animation.value) + (index * (100 + 10)),
          left: (MediaQuery.of(context).size.width - 100) / 2,
          child: Container(
            width: 100,
            height: 100,
            color: Colors.blue,
          ),
        ),
      ),
      // ],
    );
  }
}

この場合、各ボックスは一斉に移動しますが、たとえば並べ替え関数の視覚化を作成したり、アニメーションリスト内の要素を移動したりするなど、より複雑なシナリオを想像できます。この場合、親ウィジェットは各Box場所に関するデータを認識します。

問題は、AnimationControllerとそれらを使用して動きを駆動するBoxが同じクラスにないため、使用する配列を保持してAnimationControllerを通過する必要があることです。ビルダー、または各Box独自のAnimationControllerを維持させます。

フックを使用して、 Boxと親ウィジェットが同じクラスにない場合、各BoxがAnimationControllerで渡される最初のケースのAnimationControllerのリストを作成するにはどうすればよいですか？ 上記のHookBuilderでの回答に基づくと、これは必要ないようですが、あなたが言うように状態を子ウィジェットに移動し、各Box useAnimationController介して独自のAnimationControllerを持たせることを選択した場合、別の問題が発生しました。作成したAnimationControllerを親クラスに公開して、各子の独立したアニメーションを調整および実行するにはどうすればよいですか？

Vueではemitパターンを介して親にイベントを返すことができるので、Flutterでは、親がグローバル状態を更新し、子がグローバルをリッスンするRiverpodやRxなどのより高度な状態管理ソリューションが必要ですか？州？ 少なくともこのような簡単な例では、すべきではないようです。 混乱を解消してくれてありがとう。

@satvikpendem申し訳ありませんが、はっきりしませんでした。 フックでブロックしている問題ではなく、フックなしでそれを行う方法を示していただけますか？

行き詰まっている場所ではなく、何をしようとしているのかを明確に理解したい

しかし、簡単に推測すると、代わりに間隔曲線を探していて、単一のアニメーションコントローラーがあると思います。

@rrousselGit確かに、ここにあります

import 'package:flutter/material.dart';

void main(List<String> args) => runApp(const App());

class Animator {
  Animator({this.controller, this.animation});
  AnimationController controller;
  Animation<double> animation;
}

class App extends StatefulWidget {
  const App({Key key});

  static const Duration duration = Duration(milliseconds: 500);
  static const Curve curve = Curves.easeOutBack;

  <strong i="7">@override</strong>
  _AppState createState() => _AppState();
}

class _AppState extends State<App> with TickerProviderStateMixin {
  List<Animator> animators = [];
  bool isDown = false;
  int numBoxes = 3;

  <strong i="8">@override</strong>
  void initState() {
    for (int i = 0; i < numBoxes; i++) {
      final AnimationController c = AnimationController(
        duration: App.duration,
        vsync: this,
      );
      animators.add(
        Animator(
          controller: c,
          animation: Tween<double>(
            begin: 0,
            end: 300,
          )
              .chain(
                CurveTween(
                  curve: App.curve,
                ),
              )
              .animate(c),
        ),
      );
    }
    super.initState();
  }

  <strong i="9">@override</strong>
  void dispose() {
    for (int i = 0; i < numBoxes; i++) {
      animators[i].controller.dispose();
    }
    super.dispose();
  }

  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    return MaterialApp(
      home: SafeArea(
        child: Scaffold(
          floatingActionButton: FloatingActionButton(
            onPressed: () {
              if (!isDown) {
                for (final Animator animator in animators) {
                  animator.controller.forward();
                }
                setState(() {
                  isDown = true;
                });
              } else {
                for (final Animator animator in animators) {
                  animator.controller.reverse();
                }
                setState(() {
                  isDown = false;
                });
              }
            },
          ),
          body: Stack(
            children: List<Box>.generate(
              numBoxes,
              (int index) => Box(
                index: index,
                animation: animators[index].animation,
              ),
            ),
          ),
        ),
      ),
    );
  }
}

class Box extends StatelessWidget {
  Box({
    <strong i="11">@required</strong> this.animation,
    <strong i="12">@required</strong> this.index,
  });

  final int index;
  final Animation<double> animation;

  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    return Positioned(
      top: (animation.value) + (index * (100 + 10)),
      left: (MediaQuery.of(context).size.width - 100) / 2,
      child: Container(
        width: 100,
        height: 100,
        color: Colors.blue,
      ),
    );
  }
}

実際には、ウィジェットごとに1つずつ、複数のアニメーションコントローラーが必要です。これらは、独自の継続時間や曲線などを使用して、互いに独立して移動できるためです。上記のコードには、理解できないバグがあるようです。きれいにアニメーション化する必要がありますが、基本的にはボタンをクリックすると上下に3つのボックスをアニメーション化する必要があります。 それぞれが同じ曲線を持つ代わりに、それぞれに異なる曲線を与える、またはそれぞれが前のボックスよりも長いまたは短い期間の100個のボックスを作成する、または偶数のボックスを上げるシナリオを想像できます。奇妙なものは下がる、等々。

通常のFlutterでは、 initStateとdispose両方にループを含めることができますが、フックを使用しているようには見えないので、どうすればそれと戦うことができるのでしょうか。 また、 Boxクラスを親ウィジェット内に配置したくないのは、両方を厳密にカプセル化したくないためです。 親ロジックを同じに保つことができるはずですが、たとえばBoxをBox2と交換します。

ありがとう！
私はあなたの例を@TimWhitingのリポジトリにプッシュしました。フックは同等です。

TL; DR、フック（またはビルダー）を使用すると、必須ではなく宣言的に考えることができます。 したがって、1つのウィジェットにコントローラーのリストを配置するのではなく、コントローラーを強制的に駆動します。これにより、コントローラーがアイテムに移動し、暗黙的なアニメーションが実装されます。

ありがとう@rrousselGit！ フックを使い始めてしばらくの間、このタイプの実装に苦労していましたが、今ではそれがどのように機能するかを理解しています。 上で述べたように、フックがなぜ役立つのかを理解するのにもっと説得力があるかもしれないので、アニメーションコントローラーごとに異なるターゲットを持つバージョンのPRを開いたところです。

それぞれが同じ曲線を持つ代わりに、それぞれに異なる曲線を与える、またはそれぞれが前のボックスよりも長いまたは短い期間の100個のボックスを作成する、または偶数のボックスを上げるシナリオを想像できます。奇妙なものは下がる、等々。

宣言型を作ろうとしていたのですが、 didUpdateWidget/Hookライフサイクルメソッドがわからなかったので、子の小道具が親から変わったときにアニメーションを動かす方法がわかりませんでした。しかし、あなたのコードはそれをクリアしました。

今日、私のコードベースで実際の例に出くわしたので、それを共有したほうがいいと思いました。

したがって、このシナリオでは、Firestoreを使用していて、各StreamBuilderで実行したい定型文があるので、独自のカスタムビルダーを作成しました。 ValueListenableも使用する必要がありますこれにより、ユーザーはリストを並べ替えることができます。 Firestoreに関連する金銭的コストの理由から、これには非常に具体的な実装が必要です（各アイテムは独自の順序を保存できません。代わりに、リストは連結IDのフィールドとして保存する必要があります）。これは、Firestoreが書き込みごとに課金するためです。この方法で多くのお金を節約できる可能性があります。 それは次のようなものを読むことになります：

return ClipRRect(
      borderRadius: BorderRadius.circular(CornerStyles.dialog),
      child: Scaffold(
        backgroundColor: state.theme.scaffoldBackgroundColor,
        body: FamilyStreamBuilder<DocumentSnapshot>(
          stream: state.listRef.snapshots(),
          builder: (context, AsyncSnapshot<DocumentSnapshot> documentSnapshot) {
            //When a list is updated, we need to update the listOrder
            state.updateListOrderFromSnapshot(documentSnapshot);
            return FamilyStreamBuilder<QuerySnapshot>(
                stream: state.itemsCollection.snapshots(),
                builder: (_, AsyncSnapshot<QuerySnapshot> itemsSnapshot) {
                  //Sort the list items by the idField on the list-doc
                  List<DocumentSnapshot> items = itemsSnapshot.data.documents;
                  state.handleDocsSync(items);
                  return ValueListenableBuilder(
                    valueListenable: state.listOrderNotifier,
                    builder: (_, List<String> listOrder, __) {
                      List<DocumentSnapshot> ordered = state.sortItems(items, listOrder);
                     //Set the firstCompleted item if we have one
                      state.firstCompletedItem = ordered
                          ?.firstWhere((element) => element.data[FireParams.kIsComplete] == true, orElse: () => null)
                          ?.documentID;
                      return _buildItemList(items, ordered);
                    },
                  );
                });
          },
        ),
      ),
    );

次のように書くことができれば、推論するのがはるかに簡単になるように感じます。

    DocumentSnapshot list = useFamilyStream(state.listRef.snapshots());
    List<DocumentSnapshot> items = useFamilyStream(state.itemsCollection.snapshots()).data.documents;
    List<String> listOrder = useValueListenable(state.listOrderNotifier);

    //When a list is updated, we need to update the listOrder
    state.updateListOrderFromSnapshot(list);

   //Sort the list items by the idField on the list-doc
    state.handleDocsSync(items);
    List<DocumentSnapshot> ordered = state.sortItems(items, listOrder);

    //Set the firstCompleted item if we have one
    state.firstCompletedItem = ordered
        ?.firstWhere((element) => element.data[FireParams.kIsComplete] == true, orElse: () => null)
        ?.documentID;

    return ClipRRect(
      borderRadius: BorderRadius.circular(CornerStyles.dialog),
      child: Scaffold(
          backgroundColor: state.theme.scaffoldBackgroundColor,
          body: _buildItemList(items, ordered)
      ));

これにより、詳細な再構築に関する最適化が失われますが、すべての視覚要素が最下部のリーフノードにあり、すべてのラッパーが純粋な状態であるため、IRLに違いはありません。

多くの実際のシナリオと同様に、FirebaseにはStreamsという接続方法が1つしかないため、「Xを使用しないでください」というアドバイスは現実的ではありません。このソケットのような動作が必要な場合はいつでもストリームを使用します。 C'est lavie。

これにより、詳細な再構築に関する最適化が失われますが、すべての視覚要素が最下部のリーフノードにあり、すべてのラッパーが純粋な状態であるため、IRLに違いはありません。

それでも違いはあります。 ノードが視覚的であるかどうかは、再構築に費用がかかるかどうかには影響しません。

私はおそらくその例をさまざまなウィジェットに分解します（IDEにはそれを本当に簡単にするためのワンクリックリファクタリングツールがあります）。 _buildItemListは、 FamilyStreamBuilderルートとする部分と同様に、おそらくウィジェットである必要があります。

きめ細かい再構築を実際に失うことはありません。
実際、フックはuseMemoizedを使用してウィジェットインスタンスを簡単にキャッシュできるようにすることで、その側面を改善します。

それを行うTimのリポジトリにはいくつかの例があります。

私はおそらくその例をさまざまなウィジェットに分解します（IDEにはそれを本当に簡単にするためのワンクリックリファクタリングツールがあります）。 _buildItemListは、 FamilyStreamBuilderルートとする部分と同様に、おそらくウィジェットである必要があります。

この観点ではパフォーマンスの問題はまったくないので、私は実際にはこれを実行したくありません。 したがって、100％の時間、このようなマイクロ最適化よりもコードの局所性と一貫性を優先します。 このビューは、ユーザーがアクションを開始したとき（〜avgを10秒に1回）、またはバックエンドデータが変更され、開いているリストを見つめているときにのみ再構築されます（ほとんど発生しません）。 また、それは主にリストである単純なビューであり、リストには内部で行われている独自の最適化がたくさんあります。 build（）は技術的にはいつでも起動できることを理解していますが、実際にはランダムな再構築は非常にまれです。

imoこのすべてのロジックが1つのウィジェットにグループ化されていると、主に将来戻ってきたときに私の生活を楽にするために、このビューの操作とデバッグが非常に簡単になります:)

もう1つの注意点は、穴の3つのクロージャーと16のスペースの内側にツリーを構築し始める方法がなかったため、ネストは基本的にビルドメソッドから「強制的に外された」ことです。

はい、別のウィジェットに移動するのが理にかなっていると言えます。 しかし、なぜビルドメソッドにとどまらないのですか？ ボイラープレートを実際に必要なものに減らすことができれば、2つのファイルに分割するという読みやすさとメンテナンスの手間をかける必要はありません。 （パフォーマンスは問題ではないと仮定しますが、多くの場合、問題ではありません）

このシナリオでは、StreamBuilderを処理するためのカスタムウィジェットを既に作成したことを思い出してください。 今、私はこれらのビルダーの構成を処理するために別のものを作る必要がありますか？ 少し上にあるようです。

このビューではパフォーマンスの問題はまったくないためです

ああ、パフォーマンスのためにウィジェットにリファクタリングするつもりはありません。ビルダーはすでにそれを処理する必要があります。 読みやすさと再利用性のためにリファクタリングします。 それが「正しい」方法だと言っているのではなく、コードをどのように構造化するかを言っているだけです。 とにかく、それはここにもそこにもありません。

穴の3つのクロージャーと16のスペースの中にツリーを構築し始めることはできませんでした

私はあなたよりも広いモニターを持っているかもしれません...：-/

そうすれば、2つのファイルに分割するという読みやすさとメンテナンスの手間をかける必要はありません。

ウィジェットを同じファイルFWIWに配置します。

とにかく、それは良い例であり、より多くのウィジェットを使用するよりも、異なる構文で1つのウィジェットを使用する方がよいと思います。

私はあなたよりも広いモニターを持っているかもしれません...：-/

私は超ワイド：Dを持っていますが、dartfmtは明らかに私たち全員を80に制限しています。したがって、16を失うことは重要です。 主な問題は、私の声明の終わりです。何かが台無しになったとき、この},);});},),),);は本当に面白くありません。 この階層を編集するときは常に細心の注意を払う必要があり、 swap with parentような一般的なIDEヘルパーは機能しなくなります。

ウィジェットを同じファイルFWIWに配置します。

100％ですが、1つのファイルで垂直方向にジャンプするのは維持が難しいことがわかりました。 もちろん避けられないことですが、可能な限り削減し、「物事をまとめる」ように努めています。

重要なのは、メインリストを独自のウィジェットにリファクタリングしたとしても（私は同意しますが、ネストされたビルドメソッドよりも読みやすいです）、親ウィジェットにネストしなくてもはるかに読みやすくなります。 入って、すべてのロジックを一目で理解し、_MyListView（）ウィジェットをはっきりと見て、すぐにそこに飛び込んで、周囲のコンテキストを理解していると確信できます。 また、比較的簡単に依存関係を追加/削除できるため、拡張性が非常に高くなります。

dartfmtは明らかに私たち全員を80に制限します

つまり、これが私が一般的にdartfmtを使用しない理由の1つであり、使用する場合は120文字または180文字に設定します...

ここでのあなたの経験は完全に有効です。

私も実際には、一日中120です:)しかし、pub.devは、80でフォーマットされていないプラグインを積極的にダウンレートしており、この値を変更すると、私（私たち）は少数派であるという印象を受けます。

それはばかげている、私たちはそれを修正する必要があります。

pub.devは、dartfmtを尊重しないプラグインをダウンレートしません。 スコアページにコメントのみが表示されますが、スコアは影響を受けません
しかし、間違いなく、dartfmtには行の長さだけでなく多くの問題があります。

行の長さが長すぎると、次のように、複数の行で読みやすくなり、単一の行になります。

object
  ..method()
  ..method2();

これは次のようになります。

object..method()..method2();

私はこれを見ていますか？

問題のパッケージ： https ：

興味深い–プロバイダーがしばらくdartfmtを使用していなかったため、以前は間違いなくそうではありませんでした。
私は正直に立っています。

うん、それは間違いなく新しい振る舞いです。去年の春に最初に公開したとき、すべてのボックスにチェックマークを付けていることを確認しました。dartfmtは必要ありませんでした。

これらすべての議論の後、フラッターのフックのようなソリューションのネイティブサポートが見られることを願っています。 useHookまたはuse Hookいずれか、またはフラッターチームが自分たちの機能がReactのようではないと感じることができるもの😁🤷‍♂️

final controller = useAnimationController(duration: Duration(milliseconds: 800));ような方法でフックを使用します
kotlin / swiftからコピーされたDartsの新しいプログラム機能_Extension_を使用して、その構文を美しくするのは良いことではありませんか？

次のようなもの： final controller = AnimationController.use(duration: Duration(milliseconds: 800));
このアプローチでは、flutter / dartチームが現在利用可能な構文useHook代わりにuse Hookを追加することを決定した場合、その拡張関数にAnnotationを読み取って、
final controller = use AnimationController(duration: Duration(milliseconds: 800));

また、 constやnewようにconst useキーワードを使用することは理解でき/意味があります。
new Something
const Something
use Something

その推奨事項のボーナスとして、コンストラクター/ジェネレーター関数でさえ、提案されたAnnotationを使用/利用できるようになりました。 次に、いくつかのカスタマイズを行ったdartコンパイラは、 useキーワードをサポートするように変換します。

とても美しく、フラッター/ダーツ特有の機能😉

https://github.com/TimWhiting/local_widget_state_approaches/tree/master/lib/statefulの例が、人々が解決したい問題を代表していると仮定するのは正しいですか？

他の人がどのように感じているかはわかりませんが、問題はそこにある程度表れていると思います（つまり、誰かが表されていないことを指摘する可能性があるため、確信が持てません）。

私はそのリポジトリで中立的な解決策を試みました。 フックのように構成できますが、関数呼び出しの順序やループなどに依存しません。StatefulWidgetsを直接使用します。 これには、ミックスインと、キーによって一意に識別されるステートフルプロパティが含まれます。 私はこれを究極の解決策として宣伝しようとしているのではなく、2つのアプローチの中間点として宣伝しようとしています。

私はこれをlifecycleMixinアプローチと呼んでいます。これは、ここで説明したLatePropertyアプローチに非常に近いものですが、主な違いは、より多くのライフサイクルが実装されており、簡単に構成できることです。 （ライフサイクルの部分では、initState以外のウィジェットライフサイクルを使用していないため、多くの処理を行っていないため、完全に混乱している可能性があります）。

私はこのアプローチが好きです：

1. 実行時のペナルティはほとんどありません。
2. ビルドパスに状態を作成または管理するロジック/関数はありません（ビルドは純粋である可能性があり、状態をフェッチするだけです）。
3. ビルダーを介して再構築を最適化すると、ライフサイクル管理がより明確になります。 （ただし、状態の小さなビットの再利用性と構成可能性を犠牲にすることはありません）。
4. 状態のビットの作成を再利用できるため、ライブラリは、特定の方法で作成および破棄する必要がある共通の状態のビットで作成できるため、独自のコードの定型文が少なくなります。

次の理由から、このアプローチは（フックと比較して）好きではありません。

1. それがフックができるすべてをカバーしているかどうかはわかりません。
2. プロパティを一意に識別するには、キーを使用する必要があります。 （したがって、いくつかの状態を構築するロジックを構成するときは、状態の各部分を一意に識別するためにキーに追加する必要があります-キーを必須の位置パラメーターにすることは役立ちますが、アクセスするための言語レベルのソリューションが大好きです変数の一意のID）。
3. 再利用可能な関数を作成するための拡張機能を多用して、状態の共通ビットを作成します。 また、拡張機能をIDEで自動インポートすることはできません。
4. 異なるウィジェットのライフサイクルを混在させたり、ウィジェットを明示的に正しく管理せずにウィジェット間でアクセスしたりすると、混乱する可能性があります。
5. ビルダーの構文は少し奇妙なので、作成された状態はビルド関数のスコープ内にありますが、ビルド関数は純粋なままです。
6. 私はまだすべての例を実装していないので、カバーできないユースケースがあるかもしれません。

簡単な反例。
アニメーションカウンターの例

フレームワーク
再利用可能な状態構成ロジックの共通ビット

どれだけの時間があったかわかりませんが、大学院の勉強でいつも忙しくしていますが、フィードバックをお待ちしています。 @rrousselGitこれはフックにどれだけ近いですか、再利用性または構成可能性にいくつかの明らかな穴がありますか？

私は自分の解決策を宣伝しようとはしていませんが、中立的な立場で前向きな議論を奨励しています。 何が欠けているのか、この解決策が私たちに何をもたらすのかについて合意できれば、私たちは順調に前進すると思います。

@TimWhitingこのアプローチで私が抱えている主な問題は、堅牢性の欠如です。 ここでの大きな推進力は、簡潔な形でのビルダーの信頼性の必要性です。 魔法のIDとライフサイクルで衝突する機能の両方が、バグが発生するための新しいベクトルを作成します。読むのがかなり厄介であるにもかかわらず、少なくとも100であることがわかっているので、ビルダーを使用することをチームに推奨し続けます。 ％バグフリー。

例に関しては、ウィジェットに関連付けられた期間値を使用して、AnimationControllerを使用するのが完璧な例だと思います。 シンプルで親しみやすいものにします。 それ以上に難解になる必要はありません。再利用可能なボイラープレートの完璧な小さなユースケースであり、ライフサイクルフックが必要です。すべてのソリューションは、いくつかのアニメーションを簡潔に使用できることで簡単に判断できます。

他のすべては、これと同じ使用法「ステートフルコントローラー」のユースケースのバリエーションにすぎません。 XをinitStateで、Yをdispose状態で実行し、依存関係が変更されたときにZを更新したいと思います。 X、Y、Zが何であるかは関係ありません。

@rrousselGitがここで何らかの洞察を提供できるのか、それとも現在最も使用されているフックに関するデータがあるのだろうか。 80％のストリームとアニメーションだと思いますが、実際に人々が何を最も使用しているかを知っておくといいでしょう。

ツリーの一部を再構築することに関しては、ビルダーはとにかくこのタスクに自然に適しています、私たちは彼らにそれをさせるべきです。 ステートフルコントローラーは、必要に応じてステートレスレンダラーに簡単に接続できます（すべてのTransitionクラスにこんにちは）。

私たちがするかもしれないのと同じように：

var anim = get AnimationController();
return Column(
  _someExpensiveBuildMethod(),
  FadeTransition(opacity: anim, child: ...)
)

私たちはいつでもできる：

var foo = get ComplicatedThingController();
return Column(
  _someExpensiveBuildMethod(),
  ComplicatedThing(controller: foo, child: ...)
)

@esDotDev同意します。キーとビルダー構文は、lifecycleMixinアプローチの主な欠点です。 フックスタイルのアプローチとそれに関連する制限を使用するか、変数宣言を状態のビットとライフサイクルに関連付けることができるようにする言語の変更を除いて、それを回避できるかどうかはわかりません。 これが、より良い解決策が得られない限り、フックを使い続け、他の人にステートフルウィジェットを使用させる理由です。 ただし、独自の制限はありますが、フックの制限が気に入らない人にとっては興味深い選択肢だと思います。

https://github.com/TimWhiting/local_widget_state_approaches/tree/master/lib/statefulの例が、人々が解決したい問題を代表していると仮定するのは正しいですか？

正直よくわかりません。
私は_はい_と言います。 しかし、それは本当にこれらの例をどのように解釈するかに依存します。

このスレッドでは、お互いを理解していないという歴史があるので、これが二度と起こらないことを保証することはできません。

そのため、コード例の使用が嫌いで、代わりに一連のルールを抽出することを提案しました。
例は主観的なものであり、複数の解決策がありますが、その中にはより広範な問題を解決できないものもあります。

@rrousselGitがここで何らかの洞察を提供できるのか、それとも現在最も使用されているフックに関するデータがあるのだろうか。 80％のストリームとアニメーションだと思いますが、実際に人々が何を最も使用しているかを知っておくといいでしょう。

とても均質だと思います。

どちらかといえば、 useStreamとアニメーションはおそらく最も使用されていません：

• useStreamは通常、アーキテクチャに応じてより適切な同等物を持っています。 context.watch 、 useBloc 、 useProvider 、..を使用できます
• アニメーションを作るのに時間をかける人はほとんどいません。 これが優先されることはめったになく、 TweenAnimationBuilder他の暗黙的にアニメーション化されたウィジェットがニーズの大部分をカバーします。
  useImplicitlyAnimatedIntフックをflutter_hooksに追加すると、状況が変わるかもしれません。

@esDotDevlifecycleMixinアプローチでキー/ IDの必要性を削除しました。 ビルダーの構文ではまだ少し厄介です。 しかし、おそらくそれも最終的には役立つ可能性があります。 私が直面している問題の1つは、型システムに関するものです。 それは、機能していない特定の方法で物事をキャストしようとします。 しかし、おそらく注意深いキャストまたは型システムの習得が必要です。 ライフサイクルの混合に関しては、アクセスしようとしている特定の状態にウィジェットのライフサイクルからアクセスできない場合に、いくつかの合理的な例外をスローすることで改善できると思います。 または、ライフサイクルビルダー内でビルダーのライフサイクルにのみアクセスする必要があるというリント。

Remiに感謝します。驚いたことに、人々はAnimationを頻繁に使用して、コア内のTransitionウィジェットの大規模なコレクションを駆動すると思いますが、ほとんどの人は、読みやすく、ネストがないため、さまざまなImplicitを使用していると思います。 。

AnimatorControllerは、暗黙的ウィジェットと明示的ウィジェットのスイートで非常にうまく機能しますが、それでも、状態を維持し、ウィジェットのパラメーターとライフサイクルに結び付ける必要があるものの優れた例だと思います。 そして、解決すべき問題の完璧な小さな例として機能します（事実は、1ダースのウィジェットのようにFlutterで完全に解決されます）。これは、コンテンツではなくアーキテクチャについて話し合い、集中することができます。

たとえば、 var anim = AnimationController.use(context, duration: widget.duration ?? _duration);が第一級市民である場合、これらの暗黙的または明示的なアニメーションが実際に存在する必要がないことを考えてみてください。 それらはすべてコアの問題を管理するために作成されているため、冗長になります。ウィジェットのコンテキスト内でステートフルなもの（AnimationController）を簡単に合成できます。 AnimatedBuilder + AnimatorController.use()でも同じことができるので、TABはほとんど無意味になります。

アニメーションの周りに出現した膨大な数のウィジェットを見ると、一般的なユースケースの必要性が実際に示されています。 コアセットアップ/ティアダウンロジックを再利用するのは非常に面倒でバグが発生しやすいため、15以上のウィジェットがすべて非常に特殊なものを処理していますが、それぞれのウィジェットの大部分は、ほんの一握りで同じアニメーションの定型文を繰り返しています多くの場合、一意のコード行。

はい、私たち自身のステートフルロジックを再利用するためにこのことを行うこともできることを示すのに役立ちます：使用法のすべての順列のためのウィジェットを作成します。 しかし、なんと面倒でメンテナンスの頭痛の種です。 lifceycleフックを使用して、小さなステートフルオブジェクトを簡単に作成する方法があると、非常に便利です。レンダリング専用のウィジェットや再利用可能なビルダーを作成する場合は、それらを簡単に上に重ねることができます。