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

상태 논리를 재사용하려는 프레임워크의 많은 예가 있습니다.

• 스트림빌더
• TweenAnimationBuilder
  ...

이것들은 업데이트 메커니즘으로 상태를 재사용하는 방법일 뿐입니다.

그러나 그들은 "빌더"부분에서 언급 한 것과 동일한 문제를 겪고 있습니다.

많은 문제가 발생합니다.
예를 들어 Stackoverflow에서 가장 일반적인 문제 중 하나는 "변경 시 경로 푸시"와 같은 부작용에 대해 StreamBuilder 를 사용하려는 사람들입니다.

그리고 궁극적으로 그들의 유일한 해결책은 StreamBuilder를 "꺼내는" 것입니다.
여기에는 다음이 포함됩니다.

• 위젯을 상태 저장으로 변환
• initState+didUpdateWidget+didChangeDependencies에서 수동으로 스트림을 수신합니다.
• 스트림이 변경될 때 didChangeDependencies/didUpdateWidget에 대한 이전 구독 취소
• 폐기 시 구독 취소

그것은 _많은 작업_이며 효과적으로 재사용할 수 없습니다.

문제

여러 StatefulWidget 에서 State 논리를 재사용하는 것은 해당 논리가 여러 수명 주기에 의존하기 때문에 매우 어렵습니다.

일반적인 예는 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 앱에는 수십 개의 텍스트 필드가 있을 수 있습니다. 즉, 이 논리가 여러 번 복제됩니다.

이 논리를 모든 곳에 복사하여 붙여넣으면 "작동"하지만 코드에 약점이 생깁니다.

• 단계 중 하나를 다시 작성하는 것을 잊어버리기 쉽습니다(예 dispose 호출하는 것을 잊음)
• 코드에 많은 노이즈를 추가합니다.

이것이 왜 문제인지 이해하기가 정말 어렵습니다. 저는 Flutter 애플리케이션을 많이 작성했지만 실제로 그렇게 큰 문제가 되지 않는 것 같습니까? 최악의 경우에도 속성을 선언하고, 초기화하고, 폐기하고, 디버그 데이터에 보고하는 데 4줄이 소요됩니다(실제로는 일반적으로 초기화할 때와 동일한 줄에서 선언할 수 있기 때문에 일반적으로 더 적습니다. 앱은 일반적으로 디버그 속성에 상태를 추가하는 것에 대해 걱정할 필요가 없으며 이러한 객체 중 다수는 폐기해야 하는 상태가 없습니다.

속성 유형별 믹스인이 작동하지 않는다는 데 동의합니다. 빌더 패턴이 좋지 않다는 데 동의합니다(말 그대로 위에서 설명한 최악의 시나리오와 동일한 수의 라인을 사용합니다).

NNBD(특히 late final 하여 초기화자가 this 참조할 수 있도록 )를 사용하면 다음과 같이 할 수 있습니다.

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 를 사용하면 스트림을 수신하기 위한 단위 테스트를 작성할 필요가 없으므로 중복됩니다. 그러나 우리가 항상 수동으로 작성하면 실수를 범할 가능성이 있습니다.
• 한 번에 두 개의 스트림을 수신하는 경우 코드를 오염시키는 매우 유사한 이름을 가진 여러 변수가 있으므로 혼동을 일으킬 수 있습니다.

그들은 무엇을 숨기고 있습니까?

• FutureBuilder/StreamBuilder는 수신 메커니즘을 숨기고 현재 스냅샷이 무엇인지 추적합니다.
  두개의 전환 로직 Future 없는을 고려하여도 매우 복잡 subscription.close() .
• AnimatedContainer는 이전 값과 새 값 사이에 트윈을 만드는 논리를 숨깁니다.
• Listview는 "위젯이 표시되는 대로 마운트"의 논리를 숨깁니다.

앱은 일반적으로 디버그 속성에 상태를 추가하는 것에 대해 걱정할 필요가 없습니다.

그들은 debugFillProperties 메서드를 유지 관리하는 복잡성을 처리하고 싶지 않기 때문에 그렇게 하지 않습니다.
그러나 우리가 개발자들에게 "모든 매개변수와 상태 속성을 Flutter의 devtool에서 사용할 수 있게 하고 싶습니까?"라고 말했습니다. 나는 그들이 예라고 말할 것이라고 확신합니다

많은 사람들이 React의 devtool과 같은 진정한 동등물에 대한 열망을 나에게 표현했습니다. Flutter의 devtool은 아직 없습니다.
React에서 우리는 위젯의 모든 상태와 그 매개변수를 볼 수 있고 아무 것도 하지 않고 편집할 수 있습니다.

마찬가지로 사람들은 provider + 내 다른 패키지를 사용할 때 기본적으로 전체 응용 프로그램 상태가 아무 것도 하지 않고도 볼 수 있다고 말했을 때 매우 놀랐습니다( 이 성가신 devtool 버그 모듈로 ).

나는 FutureBuilder의 열렬한 팬이 아니라는 것을 인정해야 합니다. 사람들이 Future를 트리거할 때를 생각하지 않기 때문에 많은 버그가 발생합니다. 이에 대한 지원을 중단하는 것은 무리가 아니라고 생각합니다. StreamBuilder는 괜찮다고 생각하지만 스트림 자체가 너무 복잡하다고 생각합니다(위의 주석에서 언급했듯이).

Tween 생성의 복잡성에 대해 생각해야 하는 이유는 무엇입니까?

ListView는 위젯이 표시되는 대로 탑재하는 논리를 실제로 숨기지 않습니다. API의 큰 부분입니다.

문제는 줄의 수가 아니라 이 줄이 무엇인지입니다.

나는 여기의 우려를 정말로 이해하지 못한다. 라인은 단순한 상용구처럼 보입니다. 사물을 선언하고 초기화하고 사물을 폐기합니다. 행의 수가 아니라면 무엇이 문제인가?

FutureBuilder가 문제가 있다는 데 동의합니다.

주제에서 조금 벗어나긴 하지만 개발 중에 Flutter가 몇 초마다 가짜 핫 리로드를 트리거해야 한다고 제안합니다. 이것은 FutureBuilder, 키 등의 오용을 강조합니다.

Tween 생성의 복잡성에 대해 생각해야 하는 이유는 무엇입니까?

ListView는 위젯이 표시되는 대로 탑재하는 논리를 실제로 숨기지 않습니다. API의 큰 부분입니다.

우리는 그것에 동의합니다. 내 요점은 후크가 하는 일은 TweenAnimationBuilder / AnimatedContainer /... 하는 것과 완전히 동일하기 때문에 "논리를 숨깁니다"로 후크와 같은 것을 비판할 수 없다는 것입니다.
논리는 숨겨져 있지 않다

결국 애니메이션은 좋은 비교라고 생각합니다. 애니메이션에는 암시적 대 명시적 개념이 있습니다.
암시적 애니메이션은 단순성, 구성 가능성 및 가독성 때문에 사랑받고 있습니다.
명시적 애니메이션은 더 유연하지만 더 복잡합니다.

이 개념을 스트림 수신으로 변환할 때 StreamBuilder 는 _암시적 수신_인 반면 stream.listen 는 _명시적_입니다.

더 구체적으로 말하면 StreamBuilder 를 사용하면 스트림이 변경되는 시나리오를 처리하는 것을 _cannot_ 잊거나 구독을 종료하는 것을 잊습니다.
여러 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와 근본적으로 매우 다릅니다.

이 스타일을 사용하는 패키지를 만드는 사람에게는 문제가 없지만 핵심 flutter API에 포함하고 싶은 종류와 반대되는 스타일입니다.

@Hixie
@rrousselGit 이 말한 것은 그들이 같은 것이지만 라이프 사이클과 관련하여 "동일한 규칙과 동일한 행동"이 있다는 것입니다. 옳은?

그러나 그들은 같은 문제를 해결하지 않습니다.

내가 여기에서 틀렸을 수도 있지만 지난 가을에 flutter를 시도할 때 한 위젯에 세 개의 빌더가 필요했다면 많은 중첩이 되었을 것이라고 생각합니다. 후크 3개(선 3개)에 비해.
또한. 후크는 구성 가능하므로 여러 후크로 구성된 상태 논리를 공유해야 하는 경우 다른 후크와 몇 가지 추가 논리를 사용하는 새 후크를 만들고 하나의 새 후크만 사용할 수 있습니다.

위젯 간에 상태 로직을 쉽게 공유하는 것과 같은 것은 2019년 플러터 가을을 시도할 때 내가 놓친 것이었습니다.

물론 다른 가능한 솔루션이 많이 있을 수 있습니다. 아마도 그것은 이미 해결되었고 나는 문서에서 그것을 찾지 못했습니다.
그러나 그렇지 않다면 일등 시민으로서 이용할 수 있는 동일한 문제에 대한 후크 또는 다른 솔루션과 같은 것이 개발 속도를 크게 높이기 위해 할 수 있는 일이 많이 있습니다.

OP가 언급했듯이 모든 종류의 문제가 있는 빌더 접근 방식을 사용하는 것을 제안하는 것은 아닙니다. 내가 제안하는 것은 initState/dispose를 사용하는 것입니다. 그게 왜 문제인지 잘 이해가 안됩니다.

사람들이 https://github.com/flutter/flutter/issues/51752#issuecomment -664787791의 코드에 대해 어떻게 느끼는지 궁금합니다. 나는 그것이 initState/dispose보다 낫다고 생각하지 않지만 사람들이 후크를 좋아한다면 그것도 좋아합니까? 후크가 더 나은가요? 더 나쁜?

@Hixie Hooks는 수명 주기를 단일 함수 호출로 구분하기 때문에 사용하기 좋습니다. 후크를 사용하면 useAnimationController 와 같이 initState에 대해 생각하고 더 이상 폐기할 필요가 없습니다. 개발자의 책임을 제거합니다. 내가 만든 모든 단일 애니메이션 컨트롤러를 폐기했는지 걱정할 필요가 없습니다.

initState 및 dispose 는 단일 항목에는 적합하지만 여러 이질 유형의 상태를 추적해야 한다고 상상해 보십시오. 후크는 클래스의 수명 주기에 분산되는 대신 논리적 추상화 단위를 기반으로 구성됩니다.

나는 당신이 묻는 것이 매번 수동으로 효과를 처리할 수 있는데 왜 함수가 있는지 묻는 것과 같다고 생각합니다. 완전히 같지는 않지만 대체로 비슷한 느낌이 든다는 점에는 동의합니다. 이전에 후크를 사용하지 않았기 때문에 문제가 너무 명확하지 않은 것 같습니다. 따라서 flutter_hooks 패키지와 함께 후크를 사용하여 중소 규모의 프로젝트를 수행하는 것이 좋습니다. 어떤 느낌인가요. 저는 Flutter 사용자로서 다른 사람들과 마찬가지로 후크가 솔루션을 제공하는 이러한 문제에 부딪쳤습니다. 이러한 문제가 실제로 우리에게 존재한다는 것을 어떻게 확신할 수 있는지 잘 모르겠습니다. 더 나은 방법이 있으면 알려주십시오.

React 관점에서 몇 가지 생각을 추가하겠습니다.
그것들이 관련이 없다면 용서하지만 Hooks에 대해 우리가 어떻게 생각하는지 간략하게 설명하고 싶었습니다.

후크는 확실히 "숨기기"입니다. 또는 어떻게 보느냐에 따라 캡슐화하십시오. 특히, 그것들은 지역 상태와 효과를 캡슐화합니다(저는 우리의 "효과"가 "일회용"과 같은 것이라고 생각합니다). "암시성"은 호출되는 구성 요소에 수명을 자동으로 첨부한다는 점입니다.

이러한 내재성은 모델에 내재되어 있지 않습니다. 모든 호출을 통해 인수가 명시적으로 스레드되는 것을 상상할 수 있습니다. 구성 요소 자체에서 사용자 정의 Hook, 각 기본 Hook에 이르기까지 말입니다. 그러나 실제로 우리는 그것이 시끄럽고 실제로 유용하지 않다는 것을 발견했습니다. 그래서 우리는 현재 실행 중인 Component를 암시적 전역 상태로 만들었습니다. 이것은 VM의 throw errorHandlerFrame 가 코드에서 catch 블록을 위쪽으로 검색하는 것과 유사합니다.

좋습니다. 내부에 암시적 은닉 상태가 있는 함수입니다. 좋지 않은 것 같습니까? 그러나 React에서는 일반적으로 구성 요소도 마찬가지입니다. 이것이 컴포넌트의 요점입니다. 그것들은 (UI 트리의 위치에 해당하는) 수명이 연결된 함수입니다. 구성 요소 자체가 상태와 관련하여 발판이 아닌 이유는 임의의 코드에서 구성 요소를 호출하지 않기 때문입니다. 다른 구성 요소에서 호출합니다. 따라서 UI 코드의 컨텍스트에 남아 있기 때문에 수명이 의미가 있습니다.

그러나 모든 문제가 구성 요소 형태인 것은 아닙니다. 구성 요소는 상태+효과와 나무 위치에 연결된 수명이라는 두 가지 능력을 결합합니다. 그러나 우리는 첫 번째 능력이 그 자체로 유용하다는 것을 발견했습니다. 함수가 코드를 캡슐화할 수 있기 때문에 일반적으로 유용하듯이 트리에 새 노드를 생성하지 않고도 상태+효과 번들을 캡슐화(및 재사용)할 수 있는 기본 요소가 부족했습니다. 그것이 바로 Hooks입니다. 구성 요소 = 후크 + 반환된 UI.

내가 언급했듯이 컨텍스트 상태를 숨기는 임의의 함수는 무섭습니다. 이것이 우리가 린터를 통해 규칙을 시행하는 이유입니다. Hook에는 "색상" 이 있습니다. Hook을 사용하면 함수도 Hook입니다. 그리고 린터는 컴포넌트나 다른 Hooks만이 Hooks를 사용할 수 있도록 강제합니다. 이것은 이제 구성 요소 자체보다 더 암시적이지 않기 때문에 컨텍스트 UI 상태를 숨기는 임의 함수의 문제를 제거합니다.

개념적으로 우리는 Hook 호출을 일반 함수 호출로 보지 않습니다. useState() 는 구문이 있는 경우 use State() 입니다. 그것은 언어 기능이 될 것입니다. 효과 추적 기능이 있는 언어에서 대수 효과가 있는 Hooks와 같은 것을 모델링할 수 있습니다. 그런 의미에서 그것들 은 일반 함수이지만 State를 "사용"한다는 사실은 타입 서명의 일부가 될 것입니다. 그런 다음 React 자체를 이 효과에 대한 "처리자"로 생각할 수 있습니다. 어쨌든 이것은 매우 이론적이지만 프로그래밍 모델의 관점에서 선행 기술을 지적하고 싶었습니다.

실용적인 측면에서 여기에는 몇 가지가 있습니다. 첫째, Hooks가 React의 "추가" API가 아니라는 점에 주목할 가치가 있습니다. 그들은이 시점에서 구성 요소를 작성하기위한 API 반응입니다. 나는 그들이 추가 기능으로서 그다지 매력적이지 않을 것이라는 데 동의할 것이라고 생각합니다. 따라서 틀림없이 다른 전체 패러다임을 가진 Flutter에 대해 그들이 정말로 의미가 있는지 모르겠습니다.

그것들이 허용하는 것에 관해서는, 핵심 기능은 상태+유효 로직을 캡슐화한 다음 일반 함수 구성과 마찬가지로 함께 연결하는 기능이라고 생각합니다. 프리미티브는 구성하도록 설계되었기 때문에 useState() 와 같은 일부 후크 출력을 가져와서 사용자 정의 useGesture(state) 에 대한 입력으로 전달한 다음 이를 여러 사용자 정의 useSpring(gesture) 입력으로 전달할 수 있습니다. 시차 값을 제공하는 데모 와 Hooks가 무엇인지 간략하게 요약한 기사 입니다.

나는 이것이 상용구를 줄이는 것이 아니라 상태 저장 캡슐화된 로직의 파이프라인을 동적으로 구성하는 능력에 관한

이것이 조금이라도 도움이 되었는지는 모르겠지만 프로그래밍 모델에 대한 관점을 조금이라도 벗어나길 바랍니다.
다른 질문에 대답하게 되어 기쁩니다.

OP가 언급했듯이 모든 종류의 문제가 있는 빌더 접근 방식을 사용하는 것을 제안하는 것은 아닙니다. 내가 제안하는 것은 initState/dispose를 사용하는 것입니다. 그게 왜 문제인지 잘 이해가 안됩니다.

사람들이 #51752 (comment) 의 코드에 대해 어떻게 느끼는지 궁금합니다. 나는 그것이 initState/dispose보다 낫다고 생각하지 않지만 사람들이 후크를 좋아한다면 그것도 좋아합니까? 후크가 더 나은가요? 더 나쁜?

late 키워드는 상황을 개선하지만 여전히 몇 가지 문제가 있습니다.

이러한 Property 는 독립적이거나 시간이 지남에 따라 변경될 수 있는 매개변수에 의존하지 않는 상태에 유용할 수 있습니다. 그러나 다른 상황에서는 사용하기 어려울 수 있습니다.
더 정확하게는 "업데이트" 부분이 부족합니다.

예를 들어 StreamBuilder 하면 수신되는 스트림이 시간이 지남에 따라 변경될 수 있습니다. 그러나 객체가 한 번만 초기화되기 때문에 여기에 그러한 것을 구현하는 쉬운 솔루션이 없습니다.

마찬가지로 후크에는 위젯의 Key 와 동일한 기능이 있습니다. 이는 해당 키가 변경될 때 상태 조각이 소멸되고 다시 생성되도록 할 수 있습니다.

예를 들어 useMemo 는 개체 인스턴스를 캐시하는 후크입니다.
키와 결합하여 useMemo 를 사용하여 암시적 데이터 가져오기를 수행할 수 있습니다.
예를 들어 위젯은 메시지 ID를 수신할 수 있습니다. 그런 다음 메시지 세부 정보를 가져오는 데 사용합니다. 그러나 해당 메시지 ID는 시간이 지남에 따라 변경될 수 있으므로 세부정보를 다시 가져와야 할 수도 있습니다.

useMemo 를 사용하면 다음과 같이 보일 수 있습니다.

String messageId;

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

}

이 상태에서 다시 빌드 메소드를 10번 호출해도 messageId 가 변하지 않는 한 데이터 가져오기는 다시 수행되지 않는다.
그러나 messageId 변경되면 새로운 Future 가 생성됩니다.

현재 상태의 flutter_hooks 가 Dart에 대해 정제되지 않았다는 점은 주목할 가치가 있습니다. 내 구현은 본격적인 아키텍처보다 POC에 가깝습니다.
하지만 StatefulWidgets의 코드 재사용성에 문제가 있다고 생각합니다.

어디 있는지 기억나지 않았지만 이상적인 세계의 후크는 async* & sync* 옆에 있는 사용자 정의 함수 생성기가 될 것이라고 제안한 것을 기억합니다. 이는 Dan이 use State 제안한 것과 유사할 수 있습니다. useState

@gaearon

이것은 상용구를 줄이는 것이 아니라 상태 저장 캡슐화된 논리의 파이프라인을 동적으로 구성하는 능력에 관한 것임을 강조하고 싶습니다.

여기서 논의되는 문제는 그것이 아닙니다. 나는 당신이 설명하는 것을 할 수 없다는 것에 대해 이야기하기 위해 별도의 버그를 제출하는 것이 좋습니다. (그것은 매우 다른 문제처럼 들리고 솔직히 여기에 설명된 문제보다 더 설득력이 있습니다.) 이 버그는 특히 일부 논리가 너무 장황한 방법에 관한 것입니다.

아니요, 그가 옳았습니다. 혼란 스러울 수 있습니다.
앞서 언급했듯이 이것은 코드 줄 수가 아니라 코드 줄 자체에 관한 것입니다.

이것은 상태를 인수분해하는 것입니다.

이 버그는 "상태 논리를 재사용하는 것이 너무 장황하고/어렵습니다"라는 문제와 initState에서 선언할 코드가 필요한 속성이 있을 때 상태에 너무 많은 코드가 있다는 문제에 대해 매우 명확합니다. dispose 및 debugFillProperties에서. 관심 있는 문제가 다른 문제인 경우 해당 문제를 설명하는 새 버그를 제출하는 것이 좋습니다.

풀고자 하는 문제를 완전히 이해할 때까지 후크(또는 모든 솔루션)를 잊어버리기를 정말, 정말 강력하게 권장합니다. 문제를 명확하게 이해해야만 새로운 기능에 대해 설득력 있는 주장을 할 수 있습니다. 기능이 해결하는 문제에 대해 기능을 평가해야 하기 때문입니다.

나는 당신이 그 문제에서 내가 말한 것을 오해하고 있다고 생각합니다.

문제는 상용구가 아니라 재사용 가능성에 있습니다.

상용구는 원인이 아니라 재사용성 문제의 결과입니다.

이 문제에서 설명하는 내용은 다음과 같습니다.

상태 논리를 재사용/구성하고 싶을 수 있습니다. 그러나 사용 가능한 옵션은 믹스인, 빌더 또는 재사용하지 않는 것입니다. 모두 고유한 문제가 있습니다.

기존 옵션의 문제는 상용구와 관련이 있을 수 있지만 우리가 해결하려는 문제는 그렇지 않습니다.
빌더의 상용구를 줄이는 것은 하나의 경로(후크가 하는 일)이지만 다른 경로가 있을 수 있습니다.

예를 들어 잠시 동안 제안하고 싶은 것은 다음과 같은 방법을 추가하는 것입니다.

context.onDidChangeDependencies(() {

});
context.onDispose(() {

});

그러나 이것들은 그들만의 문제가 있고 문제를 완전히 해결하지 못합니다. 그래서 저는 하지 않았습니다.

@rrousselGit , 문제를 더 잘 반영하기 위해 여기 맨 위에 있는 원래 문제 설명을 자유롭게 편집하세요. : 또한 설계 문서 작성 주시기 https://flutter.dev/docs/resources/design-docs 문제 문의 소감 가능 박람회에 지금 초점을 @Hixie에서 알 수 있듯이 우리가 다시 함께 (에 반복 할 수 있음을 ). 저는 여러분이 다른 Flutter 엔지니어처럼 힘을 얻었으면 합니다. 여러분은 팀의 일원이므로 함께 반복합시다!

나는 그 문제를 몇 번이고 다시 살펴보았다. 솔직히 어디서부터 오해가 생기는지 이해가 안가서 어떻게 개선해야 할지 감이 안잡히네요.
원래 주석은 재사용성/인수분해에 대한 욕구를 반복해서 언급합니다. 상용구에 대한 언급은 "Flutter는 장황합니다"가 아니라 "일부 논리는 재사용할 수 없습니다"입니다.

디자인 문서 제안이 공정하지 않다고 생각합니다. 그런 문서를 작성하는 데 상당한 시간이 소요되며, 저는 여가 시간에 이 작업을 수행하고 있습니다.
저는 개인적으로 후크에 만족합니다. 나는 내 관심사를 위해 이 문제를 작성하는 것이 아니라 많은 사람들에게 영향을 미치는 문제에 대한 인식을 높이기 위해 작성합니다.

몇 주 전에 저는 기존 Flutter 앱에 대한 아키텍처에 대해 논의하기 위해 고용되었습니다. 아마도 여기에 언급된 내용이 정확히 일치했을 것입니다.

• 여러 위젯에서 재사용해야 하는 몇 가지 논리가 있습니다(로드 상태 처리/일부 위젯이 표시될 때 "메시지"를 읽은 것으로 표시/...)
• 그들은 주요 아키텍처 결함을 일으킨 믹스인을 사용하려고 했습니다.
• 또한 여러 위치에서 해당 논리를 다시 작성하여 "생성/업데이트/처분"을 수동으로 처리하려고 했지만 버그가 발생했습니다.
  어떤 곳에서는 구독을 닫는 것을 잊었습니다. 다른 사람들은 stream 인스턴스가 변경되는 시나리오를 처리하지 않았습니다.

• 일부 위젯이 표시될 때 "메시지"를 읽은 것으로 표시

내 앱 중 하나에서 겪었던 문제와 유사하기 때문에 흥미로운 사례입니다. 그래서 거기에서 코드를 구현한 방법을 살펴보았지만 이 버그가 설명하는 문제는 그다지 많지 않습니다. 문제를 이해하는 데 문제가 있는 이유입니다. 문제의 코드는 다음과 같습니다.

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

실제 문제를 보기 위해 연구할 수 있는 실제 앱의 예가 있습니까?

(BTW, 일반적으로 Streams를 전혀 사용하지 않는 것이 좋습니다. 일반적으로 상황을 악화시키는 것 같습니다.)

(BTW, 일반적으로 Streams를 전혀 사용하지 않는 것이 좋습니다. 일반적으로 상황을 악화시키는 것 같습니다.)

(전심으로 동의합니다. 하지만 커뮤니티는 현재 반대 반응을 보이고 있습니다. Flutter에서 공식 패키지로 ChangeNotifier/Listenable/ValueNotifier를 추출하는 것이 도움이 될 수 있습니다)

실제 문제를 보기 위해 연구할 수 있는 실제 앱의 예가 있습니까?

슬프게도 아니. 다른 사람을 도우면서 겪은 경험을 나눌 수 있을 뿐입니다. 손에 든 앱이 없습니다.

내 앱 중 하나에서 겪었던 문제와 유사하기 때문에 흥미로운 사례입니다. 그래서 거기에서 코드를 구현한 방법을 살펴보았지만 이 버그가 설명하는 문제는 그다지 많지 않습니다. 문제를 이해하는 데 문제가 있는 이유입니다. 문제의 코드는 다음과 같습니다.

구현에서 논리는 수명 주기에 연결되지 않고 _build_ 내부에 배치되므로 문제를 해결하는 방식으로 작동합니다.
특정한 경우에 의미가 있을 수 있습니다. 그 예가 좋은 것인지 잘 모르겠습니다.

더 나은 예는 pull-to-refresh일 수 있습니다.

일반적인 pull-to-refresh에서 우리는 다음을 원할 것입니다:

• 첫 번째 빌드에서 로드/오류 상태 처리
• 새로 고침 시:
  
  
  
  • 화면이 오류 상태인 경우 로딩 화면을 다시 한 번 보여줍니다.
  
  
  • 로딩 중에 새로 고침이 수행된 경우 보류 중인 HTTP 요청을 취소합니다.
  
  
  • 화면에 일부 데이터가 표시되는 경우:
  
  
  • 새 상태가 로드되는 동안 데이터를 계속 표시
  
  
  • 새로 고침이 실패하면 이전에 얻은 데이터를 계속 표시하고 오류가 있는 스낵바를 표시합니다.
  
  
  • 새로 고침이 보류 중인 동안 사용자가 화면을 팝업하고 다시 입력하면 로딩 화면을 표시합니다.
  
  
  • 새로 고침이 보류 중인 동안 RefreshIndicator가 표시되는지 확인하십시오.
  
  

그리고 우리는 모든 리소스와 여러 화면에 대해 이러한 기능을 구현하기를 원할 것입니다. 또한 일부 화면에서는 한 번에 여러 리소스를 새로 고칠 수 있습니다.

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

이 논리는 완전히 독립적입니다. 모든 화면 내의 모든 리소스와 함께 재사용할 수 있습니다.

한 화면에서 여러 리소스를 한 번에 새로 고치려면 다음을 수행할 수 있습니다.

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 내부에 직접 포함될 수도 있습니다.

나는 당신이 당신의 마지막 의견에서 옹호하는 것을 정말로 이해하지 못합니다. 요점은 앞서 인용한 코드에서 알 수 있듯이 위의 새로 고침 표시기 코드처럼 간단한 작업을 수행하기 위해 프레임워크를 변경할 필요가 없다는 것입니다.

새로 고침 표시기뿐만 아니라 애니메이션 등의 경우 이러한 유형의 상호 작용이 많은 경우 앱 상태에 두는 것보다 필요한 곳에 가장 가까운 곳에 캡슐화하는 것이 좋습니다. 앱의 여러 위치에서 필요하지 않은 경우 앱의 모든 단일 상호 작용에 대한 세부 사항을 알 필요가 없습니다.

기능의 복잡성과 재사용성에 동의하지 않는다고 생각합니다.
그러한 기능이 쉽다는 것을 보여주는 예가 있습니까?

위에 제가 작성한 한 앱의 소스를 링크했습니다. 확실히 완벽한 코드는 아니며 다음 릴리스를 위해 일부를 다시 작성할 계획이지만 이 호에서 설명하는 문제는 경험하지 못했습니다.

하지만 당신은 Flutter의 기술 리더 중 한 명입니다.
문제에 직면하더라도 즉시 해결책을 제시할 수 있는 충분한 기술이 있어야 합니다.

그러나 다른 한편으로 상당수의 사람들이 다음 코드의 문제점을 이해하지 못합니다.

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

이 사실은 StackOverflow에서 만든 Q/AI 가 얼마나 인기가 있는지에 의해 입증됩니다.

문제는 재사용 가능하고 강력한 방식으로 상태 논리를 추상화하는 것이 불가능하다는 것이 아닙니다(그렇지 않으면 이 문제를 만들 의미가 없습니다).
문제는 그렇게 하려면 시간과 경험이 모두 필요하다는 것입니다.

공식 솔루션을 제공함으로써 애플리케이션을 유지 관리할 수 없게 될 가능성을 줄여 전반적인 생산성과 개발자 경험을 향상시킵니다.
모든 사람이 귀하의 부동산 제안을 제안할 수 있는 것은 아닙니다. 그러한 것이 Flutter 내부에 구축된다면 문서화되고 가시성을 얻을 수 있으며 궁극적으로 처음에는 그것에 대해 생각하지 못한 사람들에게 도움이 될 것입니다.

문제는 앱이 무엇인지, 상태가 어떻게 생겼는지 등에 따라 달라집니다. 여기서 질문이 "앱 상태를 어떻게 관리합니까?"라면 대답은 후크와 같은 것이 아닙니다. 이를 수행하는 다양한 방법에 대해 이야기하고 다양한 상황에 대해 다른 기술을 권장하는 많은 문서입니다... 기본적으로 이 세트의 문서: https://flutter.dev/docs/development/data-and-backend/state-mgmt

임시 상태와 앱 상태가 있지만 다른 사용 사례도 있는 것 같습니다. 단일 유형의 위젯에만 관련되지만 그럼에도 불구하고 해당 유형의 위젯 간에 공유하려는 상태입니다.

예를 들어 ScrollController 는 일부 유형의 애니메이션을 호출할 수 있지만 모든 앱에서 사용해야 하는 데이터가 아니기 때문에 전역 앱 상태에 넣는 것이 반드시 적절하지는 않습니다. 그러나 여러 ScrollController 가 동일한 논리를 가질 수 있으며 각각의 라이프 사이클 논리를 공유하려고 합니다. 상태는 여전히 ScrollController 전용이므로 전역 앱 상태는 아니지만 논리를 복사하여 붙여넣으면 오류가 발생하기 쉽습니다.

또한 이 로직을 패키징하여 향후 프로젝트뿐만 아니라 다른 프로젝트에서도 더 쉽게 구성할 수 있도록 할 수 있습니다. useHooks 사이트를 보면 특정 일반적인 작업을 구분하는 많은 논리를 볼 수 있습니다. useAuth 를 사용하는 경우 한 번 작성하고 initState 또는 dispose 호출을 놓쳤는지 또는 비동기 함수에 then 가 있는지 여부에 대해 걱정할 필요가 없습니다. catch . 함수는 한 번만 작성되므로 기본적으로 오류의 여지가 사라집니다. 따라서 이러한 종류의 솔루션은 동일한 앱의 여러 부분과 여러 앱 간에 구성할 수 있을 뿐만 아니라 최종 프로그래머에게도 더 안전합니다.

나는 사람들이 후크를 사용하는 것에 반대하지 않습니다. 내가 말할 수 있는 한, 그것을 막는 것은 아무것도 없습니다. (만약 그것을 방해하는 _is_ 경우, 그것에 대한 버그를 신고하십시오.)

이 버그는 후크에 관한 것이 아니라 "상태 논리를 재사용하는 것이 너무 장황하고/어렵습니다"에 관한 것입니다. 저는 이것이 왜 Flutter를 변경해야 하는지 이해하기 위해 고군분투하고 있습니다. 애플리케이션을 어떤 식으로든 구조화하여 장황함을 피하는 방법을 보여주는 많은 예제(훅 포함)가 있었고 이미 이에 대한 많은 문서가 있습니다.

이미 Flutter를 변경하지 않고 빌드된 후크 패키지와 같은 것이 존재하는 경우 후크에 대한 자사 솔루션이 필요한 이유가 무엇입니까? @rrousselGit 이 이에 대해 더 잘 답변할 수 있다고 생각하지만 답변에는 더 나은 지원, 더 통합된 지원 및 더 많은 사람들이 사용하는 것이 포함됩니다.

그 외에도 표면적으로 flutter_hooks 패키지가 이미 존재하기 때문에 후크를 지원하기 위해 Flutter를 근본적으로 변경해야 하는 이유가 무엇인지 혼란스럽습니다.

Flutter를 변경해야 하는 이유를 이해하기 위해 여전히 고심하고 있습니다.

커뮤니티가 패키지를 만들었기 때문에 이 문제가 해결되었다고 말하는 것은 내가 Freezed 를 만들었기 때문에 Dart에 데이터 클래스 + 공용체 유형이 필요하지 않다고 말하는 것과
Freezed는 이 두 가지 문제에 대한 솔루션으로 커뮤니티에서 상당히 좋아할 수 있지만 여전히 더 잘할 수 있습니다.

Flutter 팀은 커뮤니티보다 훨씬 더 많은 영향력을 가지고 있습니다. 전체 스택을 수정할 수 있는 기능이 모두 있습니다. 각 부분의 전문가인 사람들; 그리고 필요한 일을 후원하기 위한 급여.

이 문제는 그것이 필요합니다.
기억하십시오: React 팀의 목표 중 하나는 JSX와 같이 후크가 언어의 일부가 되는 것입니다.

언어 지원이 없더라도 여전히 분석기 작업이 필요합니다. 다트 패드; 플러터/개발도구; Flutter가 수행하는 모든 다양한 작업(예: 암시적 애니메이션, 양식 등)을 단순화하는 많은 후크.

비록 Flutter의 일반적인 철학이 작은 핵심을 갖고 있기는 하지만 좋은 주장입니다. 이러한 이유로 Google, cf 캐릭터 및 애니메이션 이 제공되는 경우에도 패키지로 새로운 기능을 점점 더 추가하고 있습니다. 이는 시간이 지남에 따라 배우고 변화할 수 있는 더 큰 유연성을 제공합니다. 패키지가 충분하지 않은 강력한 기술적 이유가 없는 한(확장 방법을 사용하면 그 어느 때보다 가능성이 낮음) 이 공간에 대해서도 동일한 작업을 수행합니다.

Flutter의 핵심에 무언가를 넣는 것은 까다롭습니다. 한 가지 문제는 직접 경험을 통해 잘 알다시피 상태가 반응형 UI 아키텍처에서 잘 작동하는 것에 대해 더 많이 배우면서 진화하는 영역이라는 것입니다. 2년 전만 해도 승자를 선택해야 했다면 BLoC를 선택했을 수도 있지만 당연히 공급자 패키지가 인수되어 현재 기본 권장 사항입니다.

flutter_hooks 또는 견인력이 있는 유사한 후크 패키지를 지원하는 Google 고용 기여자를 편안하게 생각할 수 있습니다(물론 우리 의 관심을 끌기 위해 경쟁하는 다른 작업 이

흥미로운 주장, @timsneath. Rust 커뮤니티도 비슷한 일을 합니다. 언어나 프레임워크의 핵심 또는 표준 라이브러리에 한 번 도입되면 꺼내기가 매우 어렵기 때문입니다. Rust의 경우 영원히 이전 버전과의 호환성을 유지하기를 원하기 때문에 불가능합니다. 따라서 그들은 패키지가 도착할 때까지 기다렸다가 소수의 승자가 나타날 때까지 서로 경쟁한 다음 이를 언어로 접습니다.

이것은 Flutter와 비슷한 경우일 수 있습니다. React가 클래스에서 후크로 이동해야 했지만 여전히 클래스를 유지해야 하고 사람들이 마이그레이션해야 하는 것처럼 나중에 후크보다 더 나은 것이 있을 수 있습니다. 그러면 코어에 추가되기 전에 경쟁 상태 관리 솔루션을 사용하는 것이 더 나을 수 있습니다. 그리고 아마도 우리 커뮤니티는 후크 위에서 혁신하거나 더 나은 솔루션을 찾아야 할 것입니다.

나는 그 우려를 이해하지만 이것은 상태 관리 솔루션에 관한 것이 아닙니다.

이러한 기능은 Inheritedwidget 및 StatefulWidget에 더 가깝습니다. 이는 언어 기능만큼 낮을 수 있는 낮은 수준의 기본 요소입니다.

후크는 프레임워크와 독립적일 수 있지만 이는 운에 의해서만 가능합니다.
이전에 언급했듯이 이 문제의 또 다른 경로는 다음과 같습니다.

context.onDispose(() {

});

그리고 유사한 이벤트 리스너.
하지만 프레임워크 밖에서 구현하는 것은 불가능합니다.

어떤 팀이 나올지 모르겠습니다.
그러나 우리는 그러한 솔루션이 Element 바로 옆에 있어야 할 가능성을 배제할 수 없습니다.

확장 프로그램이 도움이 됩니까?

(하지만 다른 문제에서 그것에 대해 이야기해야 할 수도 있습니다. 여기서는 주제에서 벗어났습니다. 사람들이 보고 있는 문제당 하나의 문제를 갖고 올바른 장소에서 솔루션을 논의할 수 있다면 정말 좋겠습니다. 그렇지 않습니다. 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 컨텍스트) {
  최종 컨트롤러 = AnimationController(...);
  controller.onDispose(controller.dispose);
  controller.forward();
  무효 리스너() {}
  controller.addListener(청취자);
  context.onDispose(() => controller.removeListener(리스너));
  }
  ...

@우세하다
무효 initState() {
컨트롤러 = someReusableLogic(컨텍스트);
}
```

• 모든 논리가 함께 번들됩니다. 위젯이 300으로 늘어나더라도 controller 의 논리는 여전히 쉽게 읽을 수 있습니다.

이 접근 방식의 문제는 다음과 같습니다.

• context.myLifecycle(() {...}) 은(는) 핫 리로드할 수 없습니다.
• 함수를 위젯 정의에 단단히 연결하지 않고 someReusableLogic 가 StatefulWidget 에서 속성을 읽도록 하는 방법은 불분명합니다.
  예를 들어 AnimationController 의 Duration 는 위젯의 매개변수로 전달될 수 있습니다. 따라서 지속 시간이 변경되는 시나리오를 처리해야 합니다.
• ValueNotifier 에 의존하고 리스너를 다룰 필요 없이 시간이 지남에 따라 변경될 수 있는 객체를 반환하는 함수를 구현하는 방법이 불분명합니다.
  
  
  
  • 이것은 계산된 상태에 특히 중요합니다.
  
  

언어 제안에 대해 생각하겠습니다. 몇 가지 아이디어가 있지만 지금 당장은 이야기할 가치가 없습니다.

앞서 언급했듯이 이 문제는 장황함보다 코드 재사용성에 관한 것입니다.

확인. 새 버그를 신고한 다음 구체적으로 설명하는 버그를 제출해 주시겠습니까? 이 버그는 말 그대로 "상태 논리를 재사용하는 것이 너무 장황하고/어렵습니다"라고 합니다. 자세한 내용이 문제가 아닌 경우 _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에 무엇이 문제입니까?

앞서 언급했듯이 이 문제는 장황함보다 코드 재사용성에 관한 것입니다.

확인. 새 버그를 신고한 다음 구체적으로 설명하는 버그를 제출해 주시겠습니까? 이 버그는 말 그대로 "상태 논리를 재사용하는 것이 너무 장황하고/어렵습니다"라고 합니다. 자세한 정보가 문제가 아니라면 이것은 문제가 아닙니다.

저는 이 토론이 상당히 불편해지기 시작했습니다. 나는 이미 이 점에 대해 다음과 같이 대답했습니다.
이 문제의 주제는 재사용성이며 자세한 내용은 재사용성 문제의 결과로 논의됩니다. 주요 주제가 아닙니다.

자세한 내용을 언급하는 맨 위 댓글에는 단 하나의 글머리 기호만 있으며, 이는 주로 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에 무엇이 문제입니까?

이 구문은 Builders를 사용하지 않아도 되도록 설계되었으므로 원래 문제로 다시 돌아갔습니다.

또한 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에 클로저를 두는 대신 메소드를 사용하는 이유입니다.

계속 이런 말을 해서 미안하고, 답답할 텐데도 우리가 여기서 해결하려는 문제가 무엇인지 아직도 이해가 되지 않습니다. 원래 버그 요약과 원래 설명의 큰 부분에 따라 장황하다고 생각했지만 그게 아니라는 것을 이해합니다. 그래서 문제가 무엇입니까? 여기에는 상호 배타적인 욕망이 많이 있는 것처럼 들립니다. 이 버그의 많은 댓글에 퍼져 있습니다.

• 어떤 것을 어떻게 처분할지 선언하는 것은 그것을 할당한 곳과 같은 곳에서 이루어져야 합니다...
• ... 그리고 그것을 할당하는 장소는 그것을 할당하기 때문에 한 번만 실행하면 됩니다...
• ... 그리고 핫 리로드와 함께 작동해야 합니다(정의상 한 번만 실행되는 코드를 다시 실행하지 않음)...
• ...상태 비저장 위젯(정의상 상태가 없음)과 함께 작동하는 상태를 생성할 수 있어야 합니다...
• ... 그리고 didUpdateWidget 및 didChangeDependencies와 같은 것들에 대한 후킹을 활성화해야 합니다...

우리가 여기서 참여하는 이 반복적인 춤은 일을 끝내는 생산적인 방법이 아닙니다. 내가 전에 말하려고 했던 것처럼 여기에서 무언가를 얻는 가장 좋은 방법은 우리가 이해할 수 있는 방식으로 직면한 문제를 설명하는 것입니다. 모든 요구 사항은 한 곳에서 설명되고 사용 사례와 함께 설명됩니다. 솔루션을 나열하지 않는 것이 좋습니다. 특히 귀하의 요구 사항을 충족하지 않는 것으로 알고 있는 솔루션은 나열하지 않는 것이 좋습니다. 해당 솔루션을 부적절하게 만드는 필요성이 설명에 나열되어 있는지 확인하십시오.

솔직히 말해서 근본적으로 완전히 다른 프레임워크 디자인을 요구하는 것처럼 들립니다. 그것은 완벽하지만 Flutter는 아닙니다. 우리가 다른 프레임워크를 만든다면 그것은 다른 프레임워크가 될 것이고, 우리는 여전히 _this_ 프레임워크에서 해야 할 일이 많습니다. 사실, 당신이 설명하는 많은 부분이 Jetpack Compose가 설계된 방식과 매우 유사합니다. 나는 컴파일러 마법이 필요하기 때문에 그 디자인의 열렬한 팬이 아닙니다. 그래서 무슨 일이 일어나고 있는지 디버깅하는 것은 정말 어렵지만 아마도 당신의 골목에 더 가깝습니까?

여기에는 상호 배타적인 욕망이 많이 있는 것처럼 들립니다. 이 버그의 많은 댓글에 퍼져 있습니다.

그것들은 상호 배타적이지 않습니다. 후크는 이 모든 작업을 수행합니다. 솔루션에 초점을 맞추고 싶지 않기 때문에 세부 사항에 대해 설명하지 않겠지만 모든 확인란을 선택합니다.

내가 전에 말하려고 했던 것처럼 여기에서 무언가를 얻는 가장 좋은 방법은 우리가 이해할 수 있는 방식으로 직면한 문제를 설명하는 것입니다. 모든 요구 사항은 한 곳에서 설명되고 사용 사례와 함께 설명됩니다.

나는 아직도 그 최고 댓글이 어떻게 그렇게 하지 못하는지 이해하지 못합니다.
다른 사람들에게는 명확하지 않은 것이 나에게는 명확하지 않습니다.

사실, 당신이 설명하는 많은 부분이 Jetpack Compose가 설계된 방식과 매우 유사합니다. 나는 컴파일러 마법이 필요하기 때문에 그 디자인의 열렬한 팬이 아닙니다. 그래서 무슨 일이 일어나고 있는지 디버깅하는 것은 정말 어렵지만 아마도 당신의 골목에 더 가깝습니까?

나는 그것에 익숙하지 않지만 빠른 검색으로 나는 _yes_라고 말할 것입니다.

그것들은 상호 배타적이지 않습니다.

위에 나열한 모든 글머리 기호가 여기에서 해결하려는 문제의 일부입니까?

하지만 그들은 모든 상자를 확인합니다

상자를 나열할 수 있습니까?

나는 아직도 그 최고 댓글이 어떻게 그렇게 하지 못하는지 이해하지 못합니다.

예를 들어 OP는 문제가 StatefulWidgets에 관한 것이라고 명시적으로 밝혔지만 이 문제에 대한 최근 의견 중 하나는 특정 제안이 StatelessWidgets에서 작동하지 않기 때문에 좋지 않다고 말했습니다.

OP에서 당신은 말합니다 :

State 로직을 재사용하는 것은 어렵습니다. 복잡하고 깊이 중첩된 build 메서드로 끝나거나 여러 위젯에 논리를 복사하여 붙여넣어야 합니다.

따라서 요구 사항에는 다음이 포함된다고 가정합니다.

• 솔루션은 깊이 중첩되어서는 안 됩니다.
• 솔루션은 상태를 추가하려는 위치에 유사한 코드를 많이 요구하지 않아야 합니다.

첫 번째 요점(중첩에 대한)은 괜찮아 보입니다. 깊이 내포된 일을 해야 한다고 제안하려는 것은 절대 아닙니다. (즉, 우리는 깊이 중첩된 항목에 대해 동의하지 않을 수 있습니다. 이는 여기에 정의되어 있지 않습니다. 나중에 다른 주석은 빌더가 깊이 중첩된 코드를 유발한다는 것을 암시하지만, 이전에 인용한 코드에서 볼 수 있듯이 제 경험상 빌더는 꽤 좋습니다.)

두 번째 요점은 우리가 장황하지 않아야 한다는 요구 사항을 똑바로 보여주는 것 같습니다. 그러나 당신은 이것이 장황한 것에 관한 것이 아니라고 여러 번 설명했습니다.

OP가 문제를 설명하는 다음 진술은 다음과 같습니다.

여러 StatefulWidget 에서 State 논리를 재사용하는 것은 해당 논리가 여러 수명 주기에 의존하는 한 매우 어렵습니다.

솔직히 이게 무슨 뜻인지 잘 모르겠습니다. 나에게 "어려움"은 일반적으로 이해하기 어려운 복잡한 논리가 많이 포함되어 있지만 수명 주기 이벤트를 할당, 처리 및 대응하는 것은 매우 간단하다는 것을 의미합니다. 문제를 제공하는 다음 문장(여기서는 "복잡하지 않음"으로 명시적으로 설명되어 있으므로 문제에 대한 설명이 아닐 수 있음)은 다음과 같습니다.

문제는 해당 접근 방식을 확장할 때 시작됩니다.

이것은 "매우 어렵다"는 것이 "매우 장황하다"를 의미하고 유사한 코드가 많이 발생하는 데서 어려움이 생긴다는 것을 암시했습니다. " 예제를 확장한 결과는 말 그대로 동일한 코드가 여러 번 발생한다는 것입니다(예: 장황함, 상용구 코드).

이것은 문제를 설명하는 다음 문장에 의해 더욱 뒷받침됩니다.

이 논리를 모든 곳에 복사하여 붙여넣으면 "작동"하지만 코드에 약점이 생깁니다.

• 단계 중 하나를 다시 작성하는 것을 잊어버리기 쉽습니다(예 dispose 호출하는 것을 잊음)

코드를 복사하여 붙여넣을 때 장황한 표현으로 인해 실수를 하기 쉽기 때문에 아마도 매우 어려울 것입니다. 그러나 다시 말하지만, 내가 "장황함"으로 설명할 이 문제를 해결하려고 했을 때, 당신은 문제가 장황한 것이 아니라고 말했습니다.

• 코드에 많은 노이즈를 추가합니다.

다시 이것은 나에게 장황함/보일러플레이트를 말하는 것처럼 들리지만, 다시 당신은 그것이 아니라고 설명했습니다.

나머지 OP는 당신이 좋아하지 않는 솔루션을 설명할 뿐이므로 문제를 설명하지 않는 것 같습니다.

이것은 OP가 문제를 설명하지 못하는 방법을 설명합니까? 실제로 문제를 설명하는 OP의 모든 항목은 자세한 내용을 설명하는 것처럼 보이지만 그것이 문제라고 제안할 때마다 당신은 그렇지 않고 또 다른 문제가 있다고 말합니다.

나는 그 오해가 단어의 의미로 귀결된다고 생각한다.
예를 들어:

코드에 많은 노이즈를 추가합니다.

다시 이것은 나에게 장황함/보일러플레이트를 말하는 것처럼 들리지만, 다시 당신은 그것이 아니라고 설명했습니다.

이 요점은 controller.dispose() 의 숫자가 아니라 이러한 코드 행이 독자에게 제공하는 가치입니다.
그 선은 항상 있어야 하며 항상 동일합니다. 따라서 독자에 대한 값은 거의 null입니다.

중요한 것은 이 선의 존재가 아니라 그것의 부재이다.

문제는 이러한 controller.dispose() 가 많을수록 dispose 메서드에서 실제 문제를 놓칠 가능성이 더 높다는 것입니다.
1개의 컨트롤러와 0개의 Dispose가 있으면 쉽게 잡을 수 있습니다.
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 빌드를 포함하는 경우

두 번째 스니펫에는 다음이 포함됩니다.

• 1 클래스 인스턴스화
• 1 익명 함수
• 수명주기 없음. 1 빌드를 포함하는 경우

이는 ValueListenableBuilder를 _간단하게_ 만듭니다.

이 행에는 다음과 같은 내용이 없습니다.
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)');
          },
        );
      },
    );
  },
);

이것은 분명히 이상적이지 않습니다. build 메서드를 오염시키기 위해 initState / dispose 내부의 오염을 제거했습니다.

(예시를 위해 Listenable.merge 는 무시합시다. 여기서는 중요하지 않습니다. 구성에 관한 것입니다.)

Builders를 광범위하게 사용했다면 이 정확한 시나리오에서 우리 자신을 쉽게 볼 수 있습니다. Listenable.merge 해당하는 것은 없습니다.

• 사용자 정의 빌더를 작성하는 것은 지루합니다.

  빌더를 만드는 쉬운 솔루션은 없습니다. 리팩토링 도구는 여기에서 우리를 도울 수 없습니다. 우리는 "빌더로 추출"할 수 없습니다.
  또한, 반드시 직관적일 필요는 없습니다. 사용자 정의 빌더를 만드는 것은 사람들이 가장 먼저 생각할 일이 아닙니다. 특히 많은 사람들이 상용구에 반대할 것이기 때문에(저는 아닙니다).

  사람들은 맞춤형 상태 관리 솔루션을 만들고 잠재적으로 잘못된 코드로 끝날 가능성이 더 큽니다.

• Builders의 트리를 조작하는 것은 지루합니다.

  이전 예에서 ValueListenableBuilder 를 제거하거나 새 것을 추가하고 싶다고 가정해 보겠습니다. 이는 쉽지 않습니다.
  우리 코드가 컴파일되지 않는 이유를 이해하기 위해 몇 분 동안 () 및 {}를 세는 데 시간을 할애할 수 있습니다.

후크는 방금 언급한 빌더 문제를 해결하기 위한 것입니다.

이전 예제를 후크로 리팩토링하면 다음과 같이 됩니다.

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

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

이전 동작 과 동일 하지만 이제 코드에 선형 들여쓰기가 있습니다.
이는 다음을 의미합니다.

• 코드가 훨씬 더 읽기 쉽습니다.
• 편집하기가 더 쉽습니다. (){}를 두려워할 필요가 없습니다. 새 줄을 추가합니다.

provider 이(가) 좋아하는 주요 중 하나입니다. 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의 기본 설계 목표 중 일부를 위반합니다.

앞서 제안한 Property 솔루션 또는 그에서 파생된 솔루션은 모든 코드를 한 곳에서 유지하는 것에 대해 설명한 목표를 계속 달성하면서 컴파일러의 마법을 피하는 것처럼 보입니다. 나는 이것이 왜 작동하지 않는지 정말로 이해하지 못합니다. (분명히 그것은 완전한 솔루션이 되도록 didChangeDependencies 등에 연결하도록 확장될 것입니다.) (우리는 이것이 우리의 성능 요구 사항을 위반할 것이기 때문에 이것을 기본 프레임워크에 넣지 않을 것입니다.)

바로 당신이 말했듯이 발생할 수 있는 버그로 인해 후크가 조건부로 호출되지 않아야 하는 이유입니다. 자세한 내용은 ReactJS의 Rules of Hooks 문서를 참조하세요. 기본 요점은 구현 시 호출 순서로 추적되기 때문에 조건부로 사용하면 호출 순서가 깨져 올바르게 추적할 수 없다는 것입니다. 후크를 제대로 사용하려면 조건 논리 없이 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와 같은 다른 것들을 쉽게 처리하도록 만들 수 있습니다). 핫 리로드를 지원합니다(속성 및 핫 리로드를 등록하는 코드를 변경할 수 있으며 올바른 작업을 수행합니다). 명시적 유형이 필요하지 않고 유형이 안전합니다(추론에 의존). 속성 선언과 사용법을 제외하고 모든 것이 한 곳에 있으며 성능은 합리적으로 좋아야 합니다(더 자세한 작업 방식만큼 좋지는 않지만).

속성/속성 관리자:

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

편의를 위해 AnimationController 등과 같은 것에 대해 준비된 Property 하위 클래스를 만들 수 있습니다.

State.build 메소드에서도 작동하는 버전을 만들 수 있습니다...

@Hixie 가 테이블에 가져오는 몇 가지 의심을 공유합니다. 다른 한편으로는 Hooks가 가지고 있는 분명한 장점을 보았고 꽤 많은 개발자들이 그것을 좋아하는 것 같습니다.
@timsneath가 제안한 패키지 접근 방식에 대한 내 문제는 Hooks를 사용하는 코드가 Hooks가 없는 코드와 크게 다르게 보인다는 것입니다. 그들이 공식 카논에 포함되지 않는다면 우리는 Flutter 카논을 따르는 사람들이 읽을 수 없는 Flutter 코드로 끝날 것입니다.
패키지가 프레임워크의 응답 가능성이 되어야 하는 것을 구현하기 시작하면 새로운 코드 기반을 배우기 어렵게 만드는 다양한 Flutter 방언을 얻게 됩니다. 그래서 저는 아마도 Flutter의 일부가 되는 순간 후크를 사용하기 시작할 것입니다.
그것은 동결된 패키지에 대한 나의 현재 견해와 매우 유사합니다. 나는 그 기능을 좋아하지만 Union과 데이터 클래스가 Dart의 일부가 아닌 한 사람들이 내 코드를 읽기 어렵게 만들기 때문에 내 코드 기반에 포함하고 싶지 않습니다.

@escamoteur 그냥 이해하는데, 위젯이 작동하는 방식을 근본적으로

제안된 변경 자체에 대한 대화와 직교하지만 @escamoteur , @rrousselGit 및 여기와 다른 곳에서 들은 것은 프레임워크에 있는 것이 특정 변경의 합법성을 확립하는 중요한 방법으로 인식된다는 것입니다. 접근하다. 동의하지 않으면 저를 수정하십시오.

나는 그 생각을 이해합니다. 프레임워크에서 많은 것이 나오기 때문에(예: DartPad는 오늘날 타사 패키지를 지원하지 않기 때문에 일부 고객은 NPM으로 구운 후 의존하는 패키지 수에 대해 걱정합니다. 더 '공식적'인 느낌이 들며 null-safety와 같은 변경으로 앞으로 나아갈 것이 보장됩니다.

그러나 포함하는 데에는 상당한 비용이 소요됩니다. 특히 접근 방식과 API를 골화시킵니다. 그렇기 때문에 우리 둘 다 우리가 추가하는 것에 대해 매우 높은 기준을 가지고 있습니다. 특히 만장일치로 동의하지 않은 경우(국가 관리 참조), 진화의 가능성이 있는 경우 또는 패키지처럼 쉽게 무언가를 추가할 수 있는 경우에 그렇습니다.

패키지 우선 철학을 문서화해야 하는지 궁금합니다. 하지만 다시 _어디에_가는 것은 상태 논리 재사용을 개선하기 위해 변경할 수 있는 _무엇_에 대한 논의와 별개입니다.

패키지 정책은 https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#deciding -where-to-put-code에 문서화되어 있습니다.

나는 패키지 우선 접근 방식을 충분히 이해하고 그것이 중요한 일이라는 데 동의합니다.
그러나 일부 문제는 패키지가 아니라 핵심에서 해결해야 한다고 생각합니다.

이것이 내가 provider 를 Flutter에 병합해야 한다고 주장하는 것이 아니라 이 문제가 Flutter가 기본적으로 해결해야 하는 문제를 설명한다고 믿는 이유입니다(물론 후크가 있어야 하는 것은 아님).

Provider와 함께 Flutter는 이러한 종류의 문제를 해결하기 위해 기본 제공되는 기본 제공되는 InheritedWidgets를 제공합니다.
공급자는 상단에 의견이 있는 레이어만 추가하여 ""더 멋지게"" 만듭니다.

후크가 다릅니다. 그들은 원시적입니다. 특정 문제에 대한 의견이 없는 저수준 솔루션입니다. 여러 상태에서 논리를 재사용합니다.
그것들은 최종 제품이 아니지만 사람들이 사용자 정의 패키지를 빌드하는 데 사용할 것으로 예상되는 것입니다(예: 내가 hooks_riverpod에서 했던

위에서 내가 낙서한 속성 접근 방식이 후크와 어떻게 비교되는지에 대한 자세한 검토를 누군가가 제공할 수 있다면 (여기에서 원하는 바를 이해하고 후크가 충족하는 요구 사항 등을 이해하는 측면에서) 도움이 될 것입니다. (Property 아이디어에 대한 나의 목표는 여러 상태에서 논리를 재사용하는 방법의 문제를 해결하기 위해 프레임워크 위에 의견을 쌓는 것입니다.)

속성 제안이 이 문제의 핵심 목표를 해결하는 데 실패했다고 생각합니다. 상태 논리는 매개변수가 어디에서 오고 어떤 상황에서 업데이트되는지 신경쓰지 않아야 합니다.

이 제안은 모든 논리를 한 곳에서 재그룹화하여 어느 정도 가독성을 높입니다. 그러나 재사용성 문제를 해결하는 데 실패합니다.

보다 구체적으로 다음을 추출할 수 없습니다.

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

_ExampleState 에서 논리가 Example 및 initState + didUpdateWidget 바인딩되므로 다른 위젯에서 재사용합니다.

후크를 사용하면 어떻게 될까요?

Rust 커뮤니티에서 비슷한 것을 본 후 @timsneath에 동의합니다. 일단 코어에서 무언가를 추출하는 것은 매우 어렵습니다. BLoC 패턴은 provider가 나오기 전에 지정되었지만 지금은 provider가 권장 버전입니다. 아마도 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 다르게 관리하는 다른 위젯에서 재사용할 수 있습니다. 어쩌면 다른 위젯이 될 것이라는 StatefulWidget 의 관리하는 userId 내부적으로. 대신 InheritedWidget에서 userId 를 얻을 수도 있습니다.

이 구문은 후크가 자체 수명 주기를 가진 독립적인 State 개체와 같다는 것을 분명히 해야 합니다.

참고로 패키지 우선 접근 방식의 한 가지 단점은 다음과 같습니다. 패키지 작성자는 문제를 해결하기 위해 후크에 의존하는 패키지를 게시할 가능성이 적습니다.

예를 들어, Provider 사용자가 직면한 한 가지 일반적인 문제는 더 이상 사용되지 않을 때 해당 상태를 자동으로 폐기하려는 것입니다.
문제는 Provider 사용자가 장황한 Consumer(builder: ...) / Selector(builder:...) 구문과 달리 context.watch / context.select 구문도 상당히 좋아한다는 것입니다.
그러나 우리는 이 멋진 구문을 _그리고_ 후크 없이 이전에 언급한 문제를 해결할 수 없습니다(또는 거부된 https://github.com/flutter/flutter/pull/33213).

문제는:
공급자는 이 문제를 해결하기 위해 flutter_hooks 에 의존할 수 없습니다.
Provider의 인기 때문에 후크에 의존하는 것은 비합리적입니다.

그래서 결국 다음을 선택했습니다.

• 분기 공급자( Riverpod 의 코드명으로)
• 결과적으로 "Flutter 즐겨찾기"/Google 추천을 자발적으로 잃게 됩니다.
• 이 문제를 해결하십시오.
• context.watch 를 즐기는 사람들이 원하는 구문을 제공하기 위해 후크에 대한 종속성을 추가하십시오.

나는 그것이 Provider에 비해 상당한 개선을 가져온다고 생각하기 때문에 내가 생각해낸 것에 상당히 만족합니다(그것은 InheritedWidgets를 컴파일 안전하게 만듭니다).
그러나 거기에 가는 길은 나에게 나쁜 뒷맛을 남겼습니다.

후크 버전과 속성 버전 사이에는 기본적으로 세 가지 차이점이 있습니다.

• Hooks 버전은 훨씬 더 많은 백업 코드입니다.
• 속성 버전은 훨씬 더 많은 상용구 코드입니다.
• Hooks 버전은 잘못된 순서로 후크를 호출하면 상황이 나빠지고 코드에서 즉시 볼 수 있는 방법이 없는 빌드 메서드에 문제가 있습니다.

상용구 코드가 실제로 그렇게 큰 문제입니까? 내 말은, 이제 속성을 쉽게 재사용할 수 있습니다. 코드가 모두 한 곳에 있습니다. 그래서 지금은 정말 _유일한_ 장황한 주장입니다.

나는 좋은 솔루션이 그것에 대해 알고 있는 다른 패키지에 의존해서는 안 된다고 생각합니다. 프레임워크에 있는지 여부는 중요하지 않습니다. 그것을 사용하지 않는 사람들은 문제가되어서는 안됩니다. 사람들이 그것을 사용하지 않는 것이 문제라면 IMHO는 API에 대한 위험 신호입니다.

내 말은, 이제 속성을 쉽게 재사용할 수 있습니다. 코드가 모두 한 곳에 있습니다.

코드가 한 곳에 있다고 해서 재사용할 수 있는 것은 아닙니다.
현재 _ExampleState 내부에 있는 코드를 다른 위젯에서 재사용하는 보조 위젯을 만들어 주시겠습니까?
비틀기: 새 위젯은 다음과 같이 State 내부에서 내부적으로 사용자 ID를 관리해야 합니다.

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

사람들이 그것을 사용하지 않는 것이 문제라면 IMHO는 API에 대한 위험 신호입니다.

공식이 아니기 때문에 사람들이 사용하지 않는다고 해서 API가 나쁘다는 것은 아닙니다.

(버전 관리, 라이선스, 감가상각 및 기타 사항으로 인해) 유지 관리해야 하는 추가 작업이기 때문에 추가 종속성을 추가하지 않는 것은 완전히 합법적입니다.
내가 기억하는 바에 따르면 Flutter에는 가능한 한 적은 종속성이 있어야 한다는 요구 사항이 있습니다.

현재 널리 받아들여지고 거의 공식화된 Provider 자체를 사용하더라도 "나는 종속성을 추가하는 것을 피하기 위해 내장된 InheritedWidgets를 사용하는 것을 선호합니다"라고 말하는 사람들을 보았습니다.

현재 _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 예제는 그것을 사용하는 다른 패키지에 의존하지 않고 그 자체로 유용합니다.

현재 널리 받아들여지고 거의 공식화된 Provider 자체를 사용하더라도 "나는 종속성을 추가하는 것을 피하기 위해 내장된 InheritedWidgets를 사용하는 것을 선호합니다"라고 말하는 사람들을 보았습니다.

InheritedWidget을 사용하는 것을 선호하는 사람들의 문제는 무엇입니까? 나는 사람들에게 해결책을 강요하고 싶지 않습니다. 그들은 그들이 사용하고 싶은 것을 사용해야 합니다. 당신은 말 그대로 문제가 없는 것을 설명하고 있습니다. InheritedWidget 사용을 선호하는 사람들에 대한 해결책은 방해가 되지 않고 InheritedWidget을 사용하도록 하는 것입니다.

. 좋은 API인 IMHO는 다른 사람이 채택하더라도 나쁘지 않습니다. 다른 사람이 알지 못하는 경우에도 유지되어야 합니다. 예를 들어, 위의 Property 예제는 자체적으로 유용하게 사용하는 다른 패키지에 의존하지 않습니다.

오해가 있습니다.

문제는 일반적으로 후크를 사용하지 않는 사람들에 관한 것이 아닙니다.
후크는 공식적이지 않지만 Provider는 공식이기 때문에 Provider가 후크를 사용하여 문제를 해결할 수 없다는 것입니다.

동일한 객체에서 로컬로 변경되는 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 에는 흥미로운 코드가 없으며 Hooks에서 fetchUser 함수로의 어댑터일 뿐입니다. fetchUser 직접 호출하지 않는 이유는 무엇입니까? 재사용 중인 코드는 흥미로운 코드가 아닙니다.

후크는 공식적이지 않지만 Provider는 공식이기 때문에 Provider가 후크를 사용하여 문제를 해결할 수 없다는 것입니다.

코드 재사용 문제에 대한 IMHO의 좋은 솔루션은 공급자가 전혀 채택할 필요가 없습니다. 그것들은 완전히 직교하는 개념일 것입니다. 이것은 Flutter 스타일 가이드가 "완료를 피하십시오"라는 제목으로 설명하는 것입니다.

이게 왜 바람직한지 이해가 안됩니다. FetchUser에는 흥미로운 코드가 없으며 Hooks에서 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 hooks를 권장하지만 여전히 이전처럼 할 수 있습니다"라고 말하는 것은 좋은 생각이 아닐 것이라고 생각합니다. 사람들이 이것에 대해 혼란스러워할 것입니다. 또한 Flutter 팀이 향후 후크를 권장한다면 실제 Flutter 코드를 예제로 게시하는 것을 중단해야 합니다.

사람들은 항상 "공식적인 방법"을 따르고 Flutter를 사용하는 두 가지 공식적인 방법이 있어서는 안 된다고 생각합니다.

그것은 중요하지 않습니다. 우리는 코드 재사용성을 보여주려고 합니다. fetchUser 는 무엇이든 될 수 있습니다(예 ChangeNotifier.addListener .

확신하는. 이것이 바로 함수가 좋은 이유입니다. 코드를 추상화하는 것입니다. 그러나 우리는 이미 기능을 가지고 있습니다. 위의 속성 코드와 위의 _setUserId 코드는 프레임워크의 특별한 도움 없이 해당 기능을 호출하는 모든 코드를 한 곳으로 가져올 수 있음을 보여줍니다. 이러한 함수에 대한 호출을 래핑하기 위해 Hook이 필요한 이유는 무엇입니까?

코드 재사용 문제에 대한 IMHO의 좋은 솔루션은 공급자가 전혀 채택할 필요가 없습니다. 그것들은 완전히 직교하는 개념일 것입니다. 이것은 Flutter 스타일 가이드가 "완료를 피하십시오"라는 제목으로 설명하는 것입니다.

이것이 내가 후크가 원시적이라고 언급한 이유입니다.

그것들은 편리함이며 원시적이지 않습니다. 그들이 원시적이라면 "문제가 무엇입니까?"라는 질문에 대답하기가 훨씬 쉬울 것입니다. 당신은 "여기 내가 하고 싶은 일이 있는데 할 수 없다"고 말할 것입니다.

은유로:
package:animations 는 Animation 에 따라 다릅니다. 그러나 이것이 핵심 프리미티브이기 때문에 문제가 되지 않습니다.
package:animations 가 커뮤니티에서 유지 관리하는 Animation 의 포크를 대신 사용한다면 다른 문제가 될 것입니다.

Animation 클래스 계층 구조는 기본적인 작업을 수행합니다. 티커와 이를 제어하고 구독하는 방법을 소개합니다. Animation 클래스 계층 구조가 없으면 애니메이션을 수행하려면 Animation 클래스 계층 구조와 같은 것을 발명해야 합니다. (이상적으로는 더 나은 것입니다. 우리의 최선은 아닙니다.) Hooks는 새로운 기본 기능을 도입하지 않습니다. 동일한 코드를 다르게 작성하는 방법을 제공합니다. 코드가 더 간단하거나 그렇지 않은 경우와 다르게 인수분해될 수 있지만 기본 요소는 아닙니다. Hooks를 사용하는 코드와 동일한 작업을 수행하는 코드를 작성하기 위해 Hooks와 유사한 프레임워크가 필요하지 않습니다.

기본적으로 이 문제에 설명된 문제는 프레임워크에서 수정해야 할 문제가 아니라고 생각합니다. 사람들마다 그것을 해결하는 방법에 대한 요구 사항이 매우 다를 것입니다. 고칠 수 있는 방법은 많이 있습니다. 이 버그에서 이미 몇 가지를 논의했습니다. 몇 가지 방법은 매우 간단하고 몇 분 안에 작성할 수 있습니다. 따라서 솔루션을 소유하고 유지하는 데 가치를 제공할 정도로 해결하기 어려운 문제가 아닙니다. 각 제안에는 강점과 약점이 있습니다. 약점은 각각의 경우 누군가가 약점을 사용하는 것을 방해하는 요소입니다. 모든 사람이 문제를 해결해야 한다는 데 동의하는지조차 명확하지 않습니다.

후크 _are_ 프리미티브
다음은 Dan의 스레드입니다. https://twitter.com/dan_abramov/status/1093698629708251136 이에 대해 설명합니다. 일부 표현은 다르지만 React 클래스 Components와 Flutter StatefulWidgets 간의 유사성으로 인해 논리는 대부분 Flutter에 적용됩니다.

더 구체적으로 말하면 flutter_hooks 를 동적 상태 믹스인으로 생각할 수 있습니다.

그들이 원시적이라면 "문제가 무엇입니까?"라는 질문에 대답하기가 훨씬 쉬울 것입니다. 당신은 "여기 내가 하고 싶은 일이 있는데 할 수 없다"고 말할 것입니다.

OP에 있습니다.

상태 논리를 재사용하기가 어렵습니다. 복잡하고 깊이 중첩된 빌드 방법을 사용하거나 여러 위젯에 논리를 복사하여 붙여넣어야 합니다.
믹스인이나 함수를 통해 이러한 논리를 재사용하는 것은 불가능합니다.

코드가 더 간단하거나 그렇지 않은 경우와 다르게 인수분해될 수 있지만 기본 요소는 아닙니다. Hooks를 사용하는 코드와 동일한 작업을 수행하는 코드를 작성하기 위해 Hooks와 유사한 프레임워크가 필요하지 않습니다.

프로그램을 작성하는 데 클래스가 필요하지 않습니다. 그러나 클래스를 사용하면 코드를 구조화하고 의미 있는 방식으로 인수분해할 수 있습니다.
그리고 클래스는 기본 요소입니다.

프리미티브인 믹스인도 마찬가지입니다.

후크는 같은 것입니다.

이러한 함수에 대한 호출을 래핑하기 위해 Hook이 필요한 이유는 무엇입니까?

우리가 이 논리를 _one_ 장소가 아니라 _two_ 장소에서 호출해야 할 때를 위해.

믹스인이나 함수를 통해 이러한 논리를 재사용하는 것은 불가능합니다.

어떤 경우인지 구체적인 예를 들어주세요. 지금까지 우리가 연구한 모든 예제는 후크 없이 간단했습니다.

지금까지 이 스레드에서 @rrousselGit 후크를 해결하고 쉽게 재사용하고 상태 논리를 구성할 수 있는 다른 솔루션을 본 적이 없습니다.

최근에 다트와 플러터를 많이 하지 않았기 때문에 위의 속성 솔루션 코드 샘플에서 누락된 항목이 있을 수 있지만 솔루션이 있습니까? 오늘날 재사용 대신 복사 붙여넣기가 필요하지 않은 옵션은 무엇입니까?
@rrousselGit 질문에 대한 대답은 무엇입니까?

현재 _ExampleState 내부에 있는 코드를 다른 위젯에서 재사용하는 보조 위젯을 만들어 주시겠습니까?
트위스트: 새 위젯은 State 내부에서 내부적으로 사용자 ID를 관리해야 합니다.

위의 속성 솔루션으로 쉬운 상태 논리를 재사용할 수 없다면 다른 옵션은 무엇입니까?
답은 단순히 플러터에서 쉽게 재사용할 수 없어야 한다는 것입니까? 완전히 괜찮지 만 약간 슬픈 IMHO.

BTW, SwiftUI가 새롭고/다른 영감을 주는 방식으로 수행합니까? 아니면 동일한 상태 논리 재사용 가능성도 부족합니까? 나는 swiftui를 전혀 사용하지 않았습니다. 어쩌면 너무 다른가요?

기본적으로 모든 빌더. 빌더는 현재 상태를 재사용할 수 있는 유일한 방법입니다.
Hooks는 빌더를 더 읽기 쉽고 생성하기 쉽게 만듭니다.

다음은 다른 프로젝트를 위해 지난달에 만든 사용자 정의 후크 모음입니다.

• 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 사이의 중복을 방지합니다.

그들은 또한 StreamBuilder / ValueListenableBuilder 이어야 하는 useProvider 많이 사용합니다.

중요한 부분은 위젯이 "단 하나의 후크"를 거의 사용하지 않는다는 것입니다.
예를 들어 위젯은 다음을 수행할 수 있습니다.

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 방법의 절반은 독자에게 유용하지 않습니다. Builders는 중요한 것에서 우리를 산만하게 합니다.
• 괄호가 없어서 코드가 컴파일되지 않는 이유를 이해하는 데 5분을 낭비했습니다.

flutter_hooks 사용자로서 제 의견을 드리겠습니다. 후크를 사용하기 전에는 Flutter에 만족했습니다. 나는 그런 것이 필요하다고 보지 않았다. 그것에 대해 읽고 그것에 대한 YouTube 비디오를 본 후에도 여전히 확신이 서지 않았고 멋있어 보였지만 실제로 동기를 부여하려면 몇 가지 연습이나 예제가 필요했습니다. 그런데 나는 뭔가를 알아차렸다. 나는 어떤 희생을 치르더라도 상태 저장 위젯을 피하고 있었고 많은 상용구와 관련된 내용이 있었고 클래스를 건너뛰면서 무언가를 찾으려고 노력했습니다. 그 때문에 나는 임시 상태의 대부분을 나머지 앱 상태와 함께 상태 관리 솔루션으로 옮겼고 상태 비저장 위젯만 사용했습니다. 그러나,이 비즈니스 로직은 점점 이유로 인해 신뢰의 신속 떨림에 따라 원인이 Navigator , 또는 BuildContext 에 액세스하기위한 InheritedWidget 의 / Providers 높은 나무. 그것이 좋은 상태 관리 접근 방식이라고 말하지는 않았지만 그렇지 않다는 것을 알고 있습니다. 하지만 UI에서 상태 관리에 대한 걱정을 하지 않기 위해 할 수 있는 모든 것을 했습니다.

잠시 후크를 사용한 후 Flutter를 사용하여 앱 상태보다 임시 상태를 적절한 위치에(UI와 함께) 훨씬 더 생산적이고 훨씬 더 만족스럽게 사용했습니다.

나에게 그것은 임시 상태/컨트롤러를 위한 가비지 수집기와 같습니다. UI에서 모든 구독을 삭제하는 것을 기억할 필요는 없지만 이것이 flutter_hooks 가 저에게 하는 일이라는 사실을 여전히 잘 알고 있습니다. 또한 내 코드를 유지 관리하고 리팩토링하기가 훨씬 쉽습니다. 지난 1년 동안 대학원 연구와 재미를 위해 ~10개의 앱을 작성하면서 이야기했습니다.

다른 사람들과 마찬가지로 Flutter SDK 자체에 포함해야 하는 주된 동기가 무엇인지 정확히 모르겠습니다. 그러나 여기에 그 주제에 대해 두 가지 생각이 있습니다.

1. 가끔 초기화/폐기해야 하는 컨트롤러가 있는 패키지를 더 쉽게 사용할 수 있도록 후크를 만들 것입니다. (예: golden_layout 또는 zefyr ). 나는 flutter_hooks 사용하는 다른 사용자들이 그러한 패키지로부터 혜택을 받을 것이라고 믿습니다. 그러나 말 그대로 1-3개의 기능을 포함하는 패키지를 게시하는 것을 정당화할 수 없는 것 같습니다. 대안은 내가 사용하는 다양한 패키지에 대한 많은 후크를 포함하는 주방 싱크 패키지를 만드는 것입니다. 그런 다음 git 종속성을 사용할 수 있지만 다른 패키지 + flutter_hooks를 사용하는 사람은 내 git에 의존해야 합니다. 혜택을 받기 위해(검색 가능성이 낮고 관심 없는 패키지에 대한 종속성을 포함할 수 있음) 3가지 기능이 포함된 패키지 또는 pub.dev에 garden-sink 패키지를 게시합니다. 모든 아이디어는 우스꽝스럽고 발견하기 쉽지 않습니다. 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 팀의 답변에 다소 당황했습니다. 두 가지 방법으로 앱을 사용해 보고 차이점을 직접 확인하는 데 시간을 들이지 않은 것 같습니다.

공정하게 말하자면 이것은 엄청나게 긴 스레드이며 프레임워크의 설립자는 여러 솔루션으로 매일 여러 번 적극적으로 기여하고 이에 대한 피드백을 요청하고 참여하고 요청된 내용을 이해하기 위해 노력했습니다. 나는 솔직히 도움이 되는 유지 보수의 명확한 예를 생각하기 위해 고군분투합니다.

이 문제에 대해 조금 더 인내심이 있었으면 합니다. 이 스레드를 읽은 후 후크를 더 깊이 이해하지 못합니다. 단, 일회용 제품의 수명을 State에 묶는 또 다른 방법이라는 점입니다. 나는 그 접근 방식을 스타일적으로 선호하지 않으며, 입장이 '시간을 들여 패러다임에서 완전히 새로운 앱을 작성하면 근본적으로 결함이 있는 무언가가 있다고 생각합니다. 그러면 왜 프레임워크에 끼워넣어야 하는지 이해할 수 있을 것입니다! ' - React 엔지니어가 이 스레드에서 언급했듯이 Flutter에는 실제로 권장되지 않으며 이 스레드에서 설명하는 이점은 재배선의 비용에 비해 작습니다. 즉, 이점을 보려면 완전히 새로운 코드베이스가 필요합니다.

나는 솔직히 도움이 되는 유지 보수의 명확한 예를 생각하기 위해 고군분투합니다.

동의. 시간을 내어 이 토론에 참여해 주신 Hixie에게 감사드립니다.

이 스레드를 읽은 후 후크를 더 이상 깊이 이해하지 못합니다.

공정하게 말하면 이 문제는 명시적으로 후크에 대해 이야기하는 것을 피하려고 합니다.
이것은 해결책보다 문제를 설명하려고 노력하는 것에 관한 것입니다.

그렇게 하지 못한다고 느끼십니까?

저는 여기서 양쪽( @rrousselGit 및 @Hixie)을 느낄 수 있으며 Flutter 프레임워크의 (내) 사용 측면/관점에서 피드백을 남기고 싶었습니다.

flutter_hooks 접근 방식은 상용구를 상당히 줄이고(이러한 상태 구성을 재사용할 수 있으므로 여기에 표시된 예에서만) 리소스 초기화/폐기에 대해 적극적으로 생각할 필요가 없어 복잡성을 줄입니다. 일반적으로 말하자면 Flutter 자체의 "핵심"에 (주관적으로) 잘 맞지는 않지만 개발 흐름/속도를 개선하고 지원하는 데 좋은 역할을 합니다.

내가 작성한 코드의 95% 이상은 빌드 메서드가 선언적일 뿐이고 로컬 변수나 반환된 위젯 하위 트리 외부의 호출이 없는 것처럼 모든 논리 부분은 리소스를 초기화, 할당 및 삭제하고 리소스를 추가하는 상태 함수 내부에 있습니다. 청취자(제 경우에는 MobX 반응) 및 그러한 논리적인 것입니다. 이것은 Flutter 자체의 대부분의 접근 방식이기도 하므로 매우 기본적으로 느껴집니다. 그렇게 하면 개발자에게 당신이 하는 일에 대해 항상 명시적이고 개방적일 수 있는 기회를 주기도 합니다. 따라서 이러한 위젯을 항상 StatefulWidget 변환하고 initState / dispose에 유사한 코드를 작성해야 합니다. 항상 정확히 무엇을 하려는지 정확히 기록하는 결과를 위젯이 사용 중인 위젯에 직접 작성합니다. 개인적으로 @Hixie가 이미 자신을 언급했듯이 이런 종류의 상용구 코드를 작성하는 것이 어떤 식으로든 귀찮게 하지 않으며 개발자로서 flutter_hooks 에 의존하는 대신 올바르게 처리하는 방법을 결정할 수 있습니다 flutter_hooks 사용하면 어떤 상태를 후크로 작성하여 재사용할 가치가 있는지에 대해 여전히 생각해야 합니다. 다른 풍미는 다양한 "단일" 사용 후크를 생성하거나 후크를 전혀 사용하지 않을 수 있습니다. 구성을 너무 자주 재사용하지 않지만 더 많은 사용자 정의 구성을 작성하는 경향이 있습니다.

오해하지 마세요. 이러한 후크의 접근 방식은 매우 훌륭하고 유용해 보이지만 저에게는 이를 처리하는 방법의 핵심 개념을 변경하는 매우 기본적인 개념처럼 느껴집니다. 개발자가 "기본적으로" 수행하는 방법에 만족하지 않는 경우 이러한 접근 방식을 사용할 수 있는 기회를 개발자에게 제공하는 패키지 자체로서 매우 기분이 좋습니다. 통합되면 이 개념을 사용하기 위해 Flutter의 큰 부분을 다시 작성하거나(많은 작업) 미래/선택된 항목에 사용합니다(이러한 혼합 접근 방식을 사용하는 것이 혼란스러울 수 있음).

Flutter 프레임워크 자체에 통합되고 지원/활용된다면 분명히 여기에 뛰어들 것입니다. 현재 접근 방식을 이해하고 심지어 좋아하며 이를 기본적으로 구현하는 데 필요한 (가능한) 조치를 보았기 때문에 주저 및/또는 수행해서는 안 되는 이유를 이해하고 패키지로 보관할 수 있습니다.

내가 틀렸다면 정정해 주세요. 하지만 이 스레드는 읽기 가능하고 구성 가능한 방식으로 여러 위젯에서 상태 논리를 재사용하는 문제에 관한 것입니다. 특히 후크가 아닙니다. 나는 이 스레드가 해결책이 무엇인지에 대한 공개적인 접근 방식으로 문제에 대한 토론을 하고 싶었기 때문에 열린 것이라고 생각합니다.

후크는 하나의 솔루션이기 때문에 언급되었지만 @rrousselGit 이 여기에서 사용하여 그들이 해결하는 문제/문제를 설명하고(솔루션이기 때문에) 플러터에 더 고유한 다른 솔루션이 나올 수 있다고 믿습니다. 와 함께 제시했습니다. 지금까지 재사용성 문제를 해결했지만 이 스레드에 다른 솔루션이 제시되지 않았습니까?

즉, 스레드가 현재 어디로 가고 있는지 모르겠습니다.
문제가 실제로 존재한다고 생각합니다. 아니면 우리가 이것을 토론하고 있습니까?
오늘날 Flutter의 핵심이 있는 여러 위젯에서 구성 가능한 방식으로 상태 논리를 재사용하는 것이 어렵다는 데 모두 동의한다면 핵심 솔루션이 될 수 있는 솔루션은 무엇입니까? 빌더는 실제로 (인용하기 위해)

가독성이 현저히 떨어짐

속성 솔루션은 쉽게 재사용할 수 없는 것 같거나 다음과 같은 용도로 사용하는 방법에 대한 답변이 없었기 때문에 잘못된 결론을 내렸습니다.

현재 다른 위젯의 _ExampleState 내부에 있는 코드를 재사용하는 보조 위젯을 만드시겠습니까?
트위스트: 새 위젯은 State 내부에서 내부적으로 사용자 ID를 관리해야 합니다.

@timsneath가 제안한 대로 설계 문서를 기꺼이 도와드리겠습니다. 몇 가지 사례 연구 사례로 문제를 설명하고 다양한 솔루션을 언급하고 Flutter에 맞는 솔루션을 찾을 수 있는지 탐색하는 것이 더 나은 형식이라고 생각합니다. 나는 이 문제에 대한 논의가 다소 길을 잃는 데 동의합니다.

나는 현재 디자인 문서를 만드는 아이디어에 대해 상당히 회의적입니다.
현재 @Hixie 는 Flutter 내에서 이 문제를 직접 해결하는 것에 반대합니다.

제가 보기에는 문제의 중요성과 그 문제를 해결하는 Google의 역할에 대해 의견이 일치하지 않는 것 같습니다.
양측이 이에 동의하지 않는다면, 해결책이 무엇이든 간에 이 문제를 해결하는 방법에 대해 어떻게 생산적인 토론을 할 수 있을지 모르겠습니다.

이 문제 스레드는 매우 흥미롭게 읽었으며 관점의 교환이 여전히 시민적이라는 것을 알게 되어 기쁩니다. 그러나 나는 현재의 난국에 약간 놀랐습니다.

후크와 관련하여 내 견해는 Flutter가 @rrousselGit 에서 제공하는 특정 후크 솔루션이 반드시 필요한 것은 아니지만 그렇다고 말하지도 않는다는 것입니다. Remi와 다른 지지자들이 언급한 모든 이유 때문에 Flutter는 후크와 유사한 이점을 제공하는 솔루션이 필요합니다. @emanuel-lundman은 위의 주장을 잘 요약했으며 나는 그의 견해에 동의합니다.

동일한 기능을 제공하는 다른 실행 가능한 제안이 없고 후크가 React에서 잘 입증된 실적을 갖고 있고 Flutter를 기반으로 할 수 있는 기존 솔루션이 있다는 사실을 감안할 때 제 생각에는 그렇지 않을 것입니다. 그렇게 하는 것은 나쁜 선택입니다. 후크 개념은 Flutter SDK(또는 그 이하)에도 포함된 프리미티브로서 Flutter에서 어떤 것도 빼앗아 갈 것이라고 생각하지 않습니다. 제 생각에는 Flutter를 사용하여 이를 풍부하게 만들고 유지 관리 가능하고 즐거운 앱을 훨씬 더 쉽게 개발할 수 있을 것입니다.

후크가 혜택을 받고자 하는 사람들을 위한 패키지로 제공된다는 주장은 일리가 있는 말이지만, 후크와 같은 원시적인 경우에는 적합하지 않다고 생각합니다. 여기 이유가 있습니다.

내부적으로 재사용 가능한 패키지를 만들 때 우리는 종종 Dart+Flutter SDK에만 의존할 수 있다는 점에서 패키지가 "순수"해야 하는지 또는 그 안에 다른 패키지를 허용하는지 여부에 대해 토론합니다. 것. 심지어 Provider는 "순수한" 패키지를 위해 나오지만 종종 더 높은 수준의 패키지를 위해 허용됩니다. 앱의 경우 어떤 패키지가 괜찮은지 아닌지에 대한 동일한 논쟁이 항상 있습니다. 공급자는 녹색이지만 Hooks와 같은 것은 여전히 ​​패키지로 물음표입니다.

솔루션과 같은 후크가 SDK의 일부인 경우 제공하는 기능을 사용하는 것이 분명한 선택이 될 것입니다. Hooks를 사용하고 이미 패키지로 허용하고 싶지만, 이것이 Flutter 코드 스타일을 생성하고 이를 사용하지 않는 Flutter 개발자에게 익숙하지 않을 수 있는 개념을 도입하는 것도 걱정됩니다. SDK에서 지원하지 않고 이 길을 간다면 갈림길 같은 느낌이 듭니다. 소규모 개인 프로젝트의 경우 Hooks를 사용하는 것이 쉬운 선택입니다. Riverpod와 함께 사용하는 것이 좋습니다.

(저희 패키지 보수주의는 과거에 다른 패키지 관리자에 대한 패키지 및 종속성 엉망으로 인해 화상을 입었기 때문에 아마도 고유하지 않을 것입니다.)

지금까지 유일하게 작동하는 시연된 솔루션이라 할지라도 후크가 현재 문제를 해결하는 유일한 방법이 될 것이라고 말하는 것은 아닙니다. 솔루션에 커밋하기 전에 보다 일반적인 수준에서 옵션을 조사하는 것은 확실히 흥미롭고 유효한 접근 방식일 수 있습니다. 그러기 위해서는 Flutter SDK가 _현재 쉽게 재사용할 수 있는 상태 논리와 관련하여 결함이 있음을 인식해야 합니다. 이는 정교한 설명에도 불구하고 현재 없는 것 같습니다.

저에게는 Hooks를 핵심 프레임워크에 넣지 않는 두 가지 주요 이유가 있습니다. 첫 번째는 API에 위험한 함정이 있다는 것입니다. 기본적으로 잘못된 순서로 후크를 어떻게든 호출하면 문제가 발생합니다. 이것은 나에게 치명적인 문제처럼 보인다. 규율을 따르고 문서를 따르면 피할 수 있지만 이 코드 재사용 문제에 대한 IMHO의 좋은 솔루션에는 그런 결함이 없다는 것을 이해합니다.

두 번째는 사람들이 이 문제를 해결하기 위해 Hooks(또는 다른 라이브러리)를 사용할 수 없는 이유가 없어야 한다는 것입니다. 이제 사람들이 논의한 것처럼 Hooks는 특히 작동하지 않습니다. 왜냐하면 Hooks를 작성하는 것은 사람들이 관련 없는 라이브러리가 hooks를 지원하기를 바랄 만큼 충분히 부담스럽기 때문입니다. 하지만 이 문제에 대한 좋은 해결책은 그럴 필요가 없다고 생각합니다. 좋은 솔루션은 단독으로 존재하며 다른 모든 라이브러리가 이에 대해 알 필요가 없습니다.

최근에 프레임워크에 RestorableProperties를 추가했습니다. 그들이 여기에서 어떻게든 활용될 수 있는지 보는 것은 흥미로울 것입니다...

나는 분석기 또는 린터가 해결해야 하는 숨겨진 문제가 있는 API에 대해 @Hixie 가 동의합니다. 참여를 원하는 사람이라면 누구나 설계 문서 제안을 통해, 아니면 재사용 가능한 수명 주기 관리 문제에 대해 다양한 솔루션을 모색해야 한다고 생각합니다. 이상적으로는 더 Flutter에 고유하고 Flutter API를 활용하는 동시에 hook API가 수행하는 문제를 해결하는 것입니다. Vue 버전은 앞서 언급했듯이 후크 호출 순서에 의존하지 않기 때문에 시작하기에 좋은 모델이라고 생각합니다. 나와 함께 조사하는 데 관심이 있는 사람이 있습니까?

@Hixie 하지만 위젯 간에 구성 가능한 방식으로 상태 논리를 재사용하는 좋은 방법이 없다는 문제에 동의합니까? 그래서 ResuableProperties를 어떻게든 활용하는 것에 대해 생각하기 시작했습니까?

저에게는 Hooks를 핵심 프레임워크에 넣지 않는 두 가지 주요 이유가 있습니다. 첫 번째는 API에 위험한 함정이 있다는 것입니다. 기본적으로 잘못된 순서로 후크를 어떻게든 호출하면 문제가 발생합니다. 이것은 나에게 치명적인 문제처럼 보인다. 규율을 따르고 문서를 따르면 피할 수 있지만 이 코드 재사용 문제에 대한 IMHO의 좋은 솔루션에는 그런 결함이 없다는 것을 이해합니다.

후크와 함께 작업하고 후크를 사용하는 다른 사람들과 함께 작업했기 때문에 이것은 실제로 그렇게 큰 문제가 아닙니다. 그리고 그들이 테이블에 가져오는 모든 큰 이점(개발 속도, 재사용성, 구성 가능성 및 쉽게 읽을 수 있는 코드의 큰 이점)과 전혀 비교되지 않습니다.
후크는 후크입니다. 마치 클래스가 함수가 아닌 클래스인 것처럼 조건부로 사용할 수 없습니다. 당신은 그것을 빨리 배웁니다. 그리고 당신의 편집자도 이 문제에 대해 도움을 줄 수 있습니다.

두 번째는 사람들이 이 문제를 해결하기 위해 Hooks(또는 다른 라이브러리)를 사용할 수 없는 이유가 없어야 한다는 것입니다. 이제 사람들이 논의한 것처럼 Hooks는 특히 작동하지 않습니다. 왜냐하면 Hooks를 작성하는 것은 사람들이 관련 없는 라이브러리가 hooks를 지원하기를 바랄 만큼 충분히 부담스럽기 때문입니다. 하지만 이 문제에 대한 좋은 해결책은 그럴 필요가 없다고 생각합니다. 좋은 솔루션은 단독으로 존재하며 다른 모든 라이브러리가 이에 대해 알 필요가 없습니다.

후크를 작성하는 것은 부담스럽지 않습니다.
현재 IMHO에서 사용할 수 있는 솔루션보다 여전히 쉽습니다(해당 문구를 다시 사용하기 위해 😉).
제가 글을 잘못 이해하고 있는 것일 수도 있습니다. 하지만 아무도 그런 말을 하지 않은 것 같은데?
사람들이 후크 솔루션이 테이블에 가져다주는 모든 이점을 정말로 감사하게 여기고 모든 곳에서 사용할 수 있기를 바라는 것처럼 읽었습니다. 모든 혜택을 누리기 위해. 후크는 재사용할 수 있으므로 타사 개발자가 자신의 래퍼를 작성하지 않고도 자신의 후크를 코딩하고 배송할 수 있다면 좋을 것입니다. 상태 논리를 재사용할 수 있다는 이점을 얻으십시오.
@rrousselGit 과 @gaearon 이 이미 원시적인 것을 설명했다고 생각합니다. 그래서 나는 그것에 들어가지 않을 것이다.
아마도 이 글이 사람들이 이 스레드에 작성한 내용을 잘 요약한 것인지 알 수 없기 때문에 이해하지 못할 수도 있습니다. 죄송합니다.

앞으로 방법이 있기를 바랍니다. 그러나 적어도 이것이 문제라는 데 동의하고 후크가 테이블 위에 있지 않은 것 같기 때문에 더 나은 대체 솔루션을 생각해 내야 할 때라고 생각합니다.
아니면 그냥 플러터 코어에서 문제 수정을 건너뛰기로 결정하십시오.

누가 앞으로의 길을 결정합니까?
다음 단계는 무엇입니까?

이것은 나에게 치명적인 문제처럼 보인다. 규율을 따르고 문서를 따르면 피할 수 있지만 이 코드 재사용 문제에 대한 IMHO의 좋은 솔루션에는 그런 결함이 없다는 것을 이해합니다.

React에서는 정적 분석인 linter를 사용하여 이 문제를 해결합니다. 경험상 이 결함은 대규모 코드베이스에서도 중요하지 않았습니다. 우리가 결함으로 간주할 수 있는 다른 문제가 있지만 지속 호출 순서에 의존하는 것이 사람들이 직관적 으로 문제가 될 것이라고 생각하는 반면 균형은 실제로는 상당히 다르다는 점을 지적하고 싶었습니다.

내가 이 댓글을 쓰는 진짜 이유는 Flutter가 컴파일된 언어를 사용하기 때문입니다. "린팅"은 선택 사항이 아닙니다. 따라서 호스트 언어와 UI 프레임워크 사이에 정렬이 있으면 "조건부" 문제가 정적으로 발생하지 않도록 강제할 수 있습니다. 그러나 이는 UI 프레임워크가 언어 변경(예: Compose + Kotlin)에 동기를 부여할 수 있는 경우에만 작동합니다.

@Hixie 하지만 위젯 간에 구성 가능한 방식으로 상태 논리를 재사용하는 좋은 방법이 없다는 문제에 동의합니까? 그래서 ResuableProperties를 어떻게든 활용하는 것에 대해 생각하기 시작했습니까?

그것은 확실히 사람들이 제기한 것입니다. 그것은 내가 본능적으로 경험한 것이 아닙니다. Flutter로 내 자신의 앱을 작성할 때 문제라고 느낀 것은 아닙니다. 그렇다고 해서 일부 사람들에게 실제 문제가 되지 않는다는 의미는 아닙니다.

후크는 재사용할 수 있으므로 타사 개발자가 자신의 래퍼를 작성하지 않고도 자신의 후크를 코딩하고 배포할 수 있다면 좋을 것입니다.

제 요점은 여기에서 좋은 솔루션은 래퍼를 작성할 필요가 없다는 것입니다.

다음 단계는 무엇입니까?

예를 들어 다음 단계가 많이 있습니다.

• 여기서 이야기하지 않은 Flutter의 특정 문제가 있는 경우 문제를 신고하고 문제를 설명하세요.
• Hooks보다 더 나은 방법으로 이 문제의 문제를 해결하는 방법에 대한 좋은 아이디어가 있다면 그렇게 하는 패키지를 만드십시오.
• Hooks를 개선하기 위해 할 수 있는 일이 있다면 그렇게 하십시오.
• Hooks의 잠재력을 최대한 활용하지 못하게 하는 Flutter 문제가 있는 경우 새 문제로 제출하세요.
  등.

이 문제 스레드는 매우 흥미롭게 읽었으며 관점의 교환이 여전히 시민적이라는 것을 알게 되어 기쁩니다.

나는 그 때 무례한 스레드가 어떻게 생겼는지보고 싶지 않습니다. 이 스레드에는 공감이 너무 적어서 옆에서 읽고 따라가기가 어렵습니다.

제 요점은 여기에서 좋은 솔루션은 래퍼를 작성할 필요가 없다는 것입니다.

하지만 래퍼를 작성할 필요는 없습니다. 그러나 익숙해진 자신의 코드에서 이점과 재사용성을 얻고 싶을 수도 있습니다. 라이브러리를 그대로 사용할 수 있습니다. 후크 래핑 재료를 작성하는 경우(가능한 경우) 이는 부담이라고 생각하기 때문이 아니라 대안보다 낫다고 생각하기 때문일 수 있습니다.

이것은 실제로 좋은 이유이며 이 스레드의 문제에 대한 솔루션이 핵심적인 이유를 언급한 이유입니다. 코어의 재사용 가능한 구성 가능한 상태 논리 솔루션은 이러한 재사용 가능한 논리가 종속성을 추가하지 않고 모든 패키지에 안전하게 배송될 수 있기 때문에 사람들이 래퍼를 작성할 필요가 없다는 것을 의미합니다.

코어의 재사용 가능한 구성 가능한 상태 논리 솔루션은 이러한 재사용 가능한 논리가 종속성을 추가하지 않고 모든 패키지에 안전하게 배송될 수 있기 때문에 사람들이 래퍼를 작성할 필요가 없다는 것을 의미합니다.

내가 말하려는 요점은 IMHO가 좋은 솔루션을 사용하려면 _아무도_가 해당 논리를 작성할 필요가 없다는 것입니다. 재사용할 중복 논리가 없을 것입니다. 예를 들어, 이전의 "fetchUser" 예제를 보면 아무도 "fetchUser" 함수를 호출하기 위해 후크 또는 이와 동등한 것을 작성할 필요가 없으며 "fetchUser" 함수를 직접 호출하기만 하면 됩니다. 유사하게 "fetchUser"는 후크(또는 우리가 사용하는 모든 것)에 대해 아무것도 알 필요가 없고 후크(또는 우리가 사용하는 모든 것)는 "fetchUser"에 대해 아무것도 알 필요가 없습니다. 후크를 사용하는 것처럼 사소한 논리를 작성하는 동안 유지합니다.

현재 제한 사항은 후크가 언어 제한 사항 위에 있는 패치라는 사실로 인해 발생합니다.

일부 언어에서 후크는 다음과 같은 언어 구조입니다.

state count = 0;

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

이는 호출 간에 일부 상태를 유지할 수 있는 비동기 /동기화 함수의 변형입니다.

언어의 일부로 유형이 아닌 줄 번호로 각 변수를 구별할 수 있기 때문에 더 이상 조건 없는 사용이 필요하지 않습니다.

후크 제한 사항은 --track-widget-creation 제한 사항과 유사하다고 덧붙입니다.

이 플래그는 위젯에 대한 const 생성자 정규화를 중단합니다. 그러나 위젯은 선언적이므로 문제가 되지 않습니다.

그런 의미에서 후크는 동일합니다. 제한 사항은 선언적으로 조작되므로 실제로 중요하지 않습니다.
우리는 다른 것을 읽지 않고는 하나의 매우 특정한 후크를 얻지 못할 것입니다.

fetchuser 예제가 이상적인 예제가 아닐 수도 있습니다.
그러나 useStream, useAnimstion 또는 useStreamCinroller는 위젯 트리를 훨씬 더 깔끔하게 만들고 dudChangeDependencues를 처리하거나 처리하는 것을 잊어버리는 것을 방지합니다.
따라서 현재 방식은 함정에 빠질 수 있습니다. 따라서 호출 시퀀스의 잠재적인 문제는 그보다 더 큰 문제는 아닌 것 같습니다.
내 자신의 후크를 작성하기 시작할지 확실하지 않지만 프레임워크 내에서 사용할 준비가 된 자주 필요한 컬렉션이 있으면 좋을 것입니다.
그것은 그들을 처리하는 대안적인 방법일 뿐입니다.

@Hixie , 설명하려는 내용을 파악하지 못해 정말 죄송합니다. 늦은 저녁이라고 생각하지만 아마 저만 그런 것 같습니다 😳.. 하지만 설명하는 좋은 솔루션에서 상태 값은 어디에 문제에 대한 솔루션이 위젯 간에 쉽게 구성 및 공유할 수 있도록 래핑/캡슐화하는 상태 비즈니스 논리 및 수명 이벤트 논리가 있습니까? 좋은 솔루션의 기능과 이상적으로 작동하는 방법에 대해 자세히 설명해 주시겠습니까?

여기에 약간 끼어들어 이 토론의 예의에 대한 언급이 있음을 확인합니다. 저는 개인적으로 여기 있는 누군가가 무례하다고 생각하지 않습니다.

즉, 이것이 사람들이 모든면에서 깊이 관심을 갖는 주제라는 점은 주목할 가치가 있다고 생각합니다.

• @rrousselGit 은 StackOverflow 및 package:provider 문제 추적기의 상태 관리에 대한 초보자 질문에 수년 동안 답변해 왔습니다. 나는 이 파이어호스 중 후자만 따르고 있고, 레미의 근면성과 인내심에 경의를 표할 수밖에 없다.
• @Hixie 와 Flutter 팀의 다른 사람들은 Flutter의 API, 안정성, 표면, 유지 관리 가능성 및 가독성에 깊은 관심을 가지고 있습니다. Flutter의 개발자 경험이 오늘날과 같은 위치에 있게 된 것은 이 덕분입니다.
• Flutter 개발자는 개발 시간의 상당 부분을 수행하기 때문에 상태 관리에 깊은 관심을 가지고 있습니다.

이 토론의 모든 당사자가 자신이 하는 일에 대해 논쟁할 충분한 이유가 있음이 분명합니다. 메시지를 전달하는 데 시간이 걸리는 것도 이해할 수 있습니다.

따라서 토론이 여기에서든 다른 형식으로든 계속된다면 기쁠 것입니다. 공식 문서와 같이 어떤 식으로든 도움이 된다면 알려주세요.

반면에 사람들이 여기 토론이 손에 잡히지 않는다고 생각한다면 잠시 멈추고 더 나은 의사 소통 방법이 있는지 봅시다.

(따로 이 토론에 참여 해주신 @gaearon 에게 전하고 싶습니다 . 이 점에서 React의 경험은 매우 소중합니다.)

@emanuel-lundman

그러나 당신이 설명하는 좋은 솔루션에서 문제에 대한 솔루션이 위젯 간에 쉽게 구성하고 공유할 수 있도록 래핑/캡슐화하는 상태 값, 상태 비즈니스 논리 및 수명 이벤트 논리가 어디에 있습니까? 좋은 솔루션의 기능과 이상적으로 작동하는 방법에 대해 자세히 설명해 주시겠습니까?

제가 잘 몰라서 자세히 말씀을 드리지 못해서 죄송합니다. :-)

@escamoteur

fetchuser 예제가 이상적인 예제가 아닐 수도 있습니다.
그러나 useStream, useAnimstion 또는 useStreamCinroller는 위젯 트리를 훨씬 더 깔끔하게 만들고 dudChangeDependencues를 처리하거나 처리하는 것을 잊어버리는 것을 방지합니다.

이 문제의 어려움 중 하나는 문제를 설명하고 분석할 때 문제를 실제 문제가 아닌 것으로 치부하고 새로운 문제를 설명하는 등의 "골대 이동"이었습니다. 실제로 유용할 수 있는 것은 문제의 실제 예가 있는 데모 Flutter 응용 프로그램과 같이 설명을 위해 지나치게 단순화되지 않은 몇 가지 정식 예를 제시하는 것입니다. 그런 다음 Hooks 및 기타 제안을 사용하여 이를 다시 구현하고 구체적인 용어로 서로에 대해 실제로 평가할 수 있습니다. (문제가 무엇인지 정확히 이해하지 못하는 경우를 제외하고는 직접 이 작업을 수행할 것이므로 Hooks를 옹호하는 사람이 수행하는 것이 가장 좋습니다.)

실제로 유용할 수 있는 것은 몇 가지 정식 예를 제시하는 것입니다. 예를 들어 설명을 위해 지나치게 단순화되지 않은 문제의 실제 예가 있는 데모 Flutter 애플리케이션

내가 여기에 제시한 예에 대해 어떻게 생각합니까? https://github.com/flutter/flutter/issues/51752#issuecomment -669626522

이것은 실제 코드 스니펫입니다.

좋은 시작이 될 것 같아요. 후크를 사용하지 않는 버전과 후크를 사용하는 버전으로 독립 실행형 앱으로 실행되는 상태로 만들 수 있습니까?

죄송합니다. 앱이 아닌 코드 스니펫을 의미했습니다.

"데모 Flutter 응용 프로그램" 아이디어의 문제 중 하나는 이 스레드에서 만든 예제가 매우 실제적이라는 것입니다.
그것들은 지나치게 단순화되지 않았습니다.
후크의 주요 사용 사례는 디바운스, 이벤트 핸들러, 구독 또는 암시적 부작용과 같은 마이크로 상태를 인수분해하여 더 유용한 로직을 달성하기 위해 함께 결합됩니다.

https://marvel.riverpod.dev/#/ 와 같은 Riverpod에 대한 몇 가지 예가 있습니다. 여기서 소스 코드는 다음과 같습니다. https://github.com/rrousselGit/river_pod/tree/master/examples/marvel/lib
그러나 그것은 지금까지 언급된 것과 크게 다르지 않을 것입니다.

@Hixie

이것이 왜 문제인지 이해하기가 정말 어렵습니다. 저는 Flutter 애플리케이션을 많이 작성했지만 실제로 그렇게 큰 문제가 되지 않는 것 같습니까? 최악의 경우에도 속성을 선언하고, 초기화하고, 폐기하고, 디버그 데이터에 보고하는 데 4줄이 소요됩니다(실제로는 일반적으로 초기화할 때와 동일한 줄에서 선언할 수 있기 때문에 일반적으로 더 적습니다. 앱은 일반적으로 디버그 속성에 상태를 추가하는 것에 대해 걱정할 필요가 없으며 이러한 객체 중 다수는 폐기해야 하는 상태가 없습니다.

나는 같은 배에 있다.
저도 여기에 설명된 문제를 잘 이해하지 못한다는 점을 인정합니다. 나는 사람들이 재사용할 필요가 있는 "상태 논리"가 무엇인지 이해하지 못합니다.

나는 많은 상태 저장 양식 위젯을 가지고 있으며 일부는 수십 개의 양식 필드를 가지고 있으며 텍스트 컨트롤러와 포커스 노드를 직접 관리해야 합니다. statelesswidget의 수명 주기 메서드에서 생성하고 삭제합니다. 꽤 지루하지만 동일한 양의 컨트롤러/focusNode 또는 동일한 사용 사례를 사용하는 위젯이 없습니다. 그들 사이의 유일한 공통점은 상태가 있고 형식이 된다는 일반적인 개념입니다. 패턴이라고 해서 코드가 반복되는 것은 아닙니다.
내 코드의 많은 부분에서 배열을 반복해야 하므로 앱 반복 코드 전체에서 "for(var thing in things)"를 호출하지 않을 것입니다.

저는 라이프사이클 API의 단순함에서 비롯된 StatefulWidget의 힘을 좋아합니다. 한 가지 작업을 수행하고 앱의 나머지 부분과 분리하여 수행하는 StatefulWidget을 작성할 수 있습니다. 내 위젯의 "상태"는 항상 자체적으로 비공개이므로 내 위젯을 재사용하는 것은 문제가 되지 않으며 코드 재사용도 문제가 되지 않습니다.

여기에서 가져온 예제와 관련하여 몇 가지 문제가 있습니다. 이는 귀하의 요점과 어느 정도 일치합니다.

• 정확히 동일한 "상태 논리"를 사용하여 여러 상태 저장 위젯을 만드는 것은 잘못된 것으로 보이며 위젯이 자체적으로 포함된다는 아이디어에 반대합니다. 그러나 다시, 나는 사람들이 일반적인 "상태 논리"를 의미하는 것에 대해 혼란스러워합니다.
• 후크는 일반 다트 및 기본 프로그래밍 개념(예: 함수)을 사용하여 이미 수행할 수 없는 작업을 수행하지 않는 것 같습니다.
• 문제는 "재사용 가능한 전역 상태"를 선호하는 것으로 보이는 특정 스타일의 프로그래밍과 관련이 있거나 발생하는 것으로 보입니다.
• 몇 줄의 코드를 추상화하면 "조기 코드 최적화" 냄새가 나며 프레임워크 및 사람들이 사용하는 방식과 거의 관련이 없는 문제를 해결하기 위해 복잡성이 추가됩니다.

이것은 가독성이 현저히 떨어집니다.

• 10단계의 들여쓰기가 있습니다. 필터 논리를 재사용하기 위해 FilterBuilder 를 만드는 경우 12단계입니다.

• 필터 로직은 그대로 재사용할 수 없습니다.

  • 실수로 timer 취소하는 것을 잊어버릴 수 있습니다.
• build 방법의 절반은 독자에게 유용하지 않습니다. Builders는 중요한 것에서 우리를 산만하게 합니다.
• 괄호가 없어서 코드가 컴파일되지 않는 이유를 이해하는 데 5분을 낭비했습니다.

귀하의 예는 Flutter의 StatelessWidget 및 State 수명 주기 API의 실제 문제라기보다는 공급자가 얼마나 장황한지, 그리고 모든 것에 대해 InheritedWidgets를 남용하는 것이 왜 나쁜지를 보여주는 것입니다.

@rrousselGit 명확하지 않은 경우 죄송합니다. 위에서 제가 제안한 것은 구체적으로 현실적이고 설명하는 문제를 보여주는 바닐라 Flutter 응용 프로그램(StatefulWidget 등을 사용하여)을 생성하여 실제 전체 응용 프로그램을 기반으로 제안할 수 있도록 하는 것입니다. "fetchUser" 예제와 같이 여기에서 논의한 구체적인 예제는 항상 "이런 경우를 처리할 수 있고 간단하고 Hooks가 필요하지 않을 것입니다"라는 라인에 따른 토론으로 끝났습니다. "글쎄요, 그건 지나치게 단순화되어 있습니다. 실제 세계에서는 Hooks가 필요합니다." 그래서 제 요점은 실제로 Hooks가 필요하고 지나치게 단순화되지 않은 실제 예제를 만들어 코드 재사용의 어려움을 보여줌으로써 새로운 코드를 사용하지 않고도 이러한 문제를 피할 수 있는지 여부를 확인할 수 있다는 것입니다. , 또는 새 코드가 필요한 경우, 후자의 경우 Hooks와 같은 모양이어야 하는지 또는 더 나은 솔루션을 찾을 수 있는지 여부.

나는 사람들이 재사용할 필요가 있는 "상태 논리"가 무엇인지 이해하지 못합니다.

그럴 수 있지
상태 논리와 평행을 이루는 것은 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의 실제 문제라기보다는 공급자가 얼마나 장황한지, 그리고 모든 것에 대해 InheritedWidgets를 남용하는 것이 왜 나쁜지를 보여주는 것입니다.

이것은 공급자와 관련이 없습니다(이 코드는 결국 공급자를 사용하지 않습니다).
어떤 경우가 있기 때문에, 제공자는 더 나은이 context.watch 대신 Consumer .

표준 솔루션은 Consumer 를 ValueListenableBuilder 로 바꾸는 것이므로 똑같은 문제가 발생합니다.

@Hixie 에 동의합니다. 후크를 사용하는 것과 Flutter만 사용하는 것의 효율성을 비교하기 위해 두 가지를 나란히 비교할 필요가 있다고 생각합니다. 이것은 또한 후크가 더 나은지 아닌지 또는 바닐라 앱이 이 세 번째 솔루션으로 빌드된 경우 다른 솔루션이 더 나은지 여부를 다른 사람들에게 확신시키는 데 도움이 됩니다. 이 바닐라 앱 개념은 TodoMVC 와 같은 것들이 다양한 프론트 엔드 프레임워크 간의 차이점을 보여주는 것과 함께 한동안 사용되어 왔기 때문에 반드시 새로운 것은 아닙니다. 이 예제 앱을 만드는 데 도움을 드릴 수 있습니다.

@satvikpendem
기꺼이 도와드리겠습니다.
flutter_hooks 리포지토리의 예제 앱은 아마도 여러 가지 다른 후크와 이들이 더 쉽게 만드는/문제를 해결하는 것을 보여주고 좋은 출발점이 될 것이라고 생각합니다.

나는 또한 우리가 이 호에 제시된 몇 가지 예와 접근 방식을 사용할 수 있다고 생각합니다.

업데이트: 코드는 https://github.com/TimWhiting/local_widget_state_approaches에 있습니다.
저장소의 적절한 이름이 확실하지 않으므로 그것이 우리가 해결하려는 문제라고 가정하지 마십시오. 상태 저장 및 후크에서 기본 카운터 앱을 수행했습니다. 오늘 밤 시간이 많지는 않지만 문제가 될 수 있는 부분을 더 잘 설명하는 사용 사례를 더 추가하려고 노력할 것입니다. 기여하고 싶은 사람은 액세스 권한을 요청하십시오.

"fetchUser" 예제와 같이 여기에서 논의한 구체적인 예제는 항상 "이런 경우를 처리할 수 있고 간단하고 Hooks가 필요하지 않을 것입니다"라는 라인에 따른 토론으로 끝났습니다. "글쎄요, 그건 지나치게 단순화되어 있습니다. 실제 세계에서는 Hooks가 필요합니다."

나는 동의하지 않는다. 나는 "이런 경우를 처리할 수 있다"는 것을 본 적이 없다고 생각하고 결과 코드가 후크 변형보다 낫다는 데 동의했습니다.

내 요점은 우리가 일을 다르게 할 수 있지만 결과 코드는 오류가 발생하기 쉽고 가독성이 낮다는 것입니다.
이것은 fetchUser 에도 적용됩니다.

후크는 똑같은 일을 합니다.
그러나 Text 대신 상태 논리에 대한 사용자 정의 후크를 얻습니다. 여기에는 리스너, 디바운싱, HTTP 요청 만들기 등이 포함됩니다.

아니요, 저는 여전히 이 일반적인 상태 논리가 무엇인지 이해하지 못합니다. 내 말은 "initState/didUpdateDependency" 메소드에서 데이터베이스에서 읽는 많은 위젯이 있지만 정확히 동일한 쿼리를 만드는 두 위젯을 찾을 수 없으므로 "논리"가 동일하지 않습니다.

HTTP 요청을 만드는 예를 사용합니다. 내 위젯 중 일부가 사용해야 하는 서비스 클래스 어딘가에 "makeHTTPRequest(url, paramters)"가 있다고 가정하면 필요할 때마다 메서드를 직접 호출하는 대신 후크를 사용하는 이유는 무엇입니까? 이 경우 후크를 사용하는 것이 일반 메서드 호출과 어떻게 다릅니까?

청취자. 같은 것을 듣는 위젯이 없습니다. 각 위젯은 필요한 모든 것을 구독하고 구독을 취소할 책임이 있습니다. 후크는 대부분의 경우 구문상의 설탕일 수 있지만 내 위젯은 동일한 객체 조합을 수신하지 않기 때문에 후크는 어떻게든 "매개변수화"되어야 합니다. 다시 말하지만, 후크는 평범한 이전 함수와 어떻게 다른가요?

이것은 공급자와 관련이 없습니다(이 코드는 결국 공급자를 사용하지 않습니다).
어떤 경우가 있기 때문에, 제공자는 더 나은이 context.watch 대신 Consumer .

뭐? "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) {

이것은 공급자와 어떻게 관련이 없습니까? 혼란스러워요. 나는 Provider의 전문가는 아니지만 이것은 확실히 Provider를 사용하는 코드처럼 보인다.

저는 이 문제가 복잡한 상태에 관한 것이 아니라는 사실을 강조하고 싶습니다.
전체 코드베이스에 적용할 수 있는 작은 증분에 관한 것입니다.

여기에 제공된 예제의 가치에 동의하지 않으면 애플리케이션은 대화에 아무 것도 가져오지 않습니다. StatefulWidget으로 할 수 없는 후크로 할 수 있는 것이 없기 때문입니다.

대신 ImplicitFetcher 와 같은 마이크로 스니펫을 나란히 비교하고 측정 가능한 메트릭을 사용하여 어떤 코드가 더 나은지 _객관적으로_ 결정하고 다양한 작은 스니펫에 대해 수행하는 것이 좋습니다.

이것은 공급자와 어떻게 관련이 없습니까? 혼란스러워요. 나는 Provider의 전문가는 아니지만 이것은 확실히 Provider를 사용하는 코드처럼 보인다.

이 코드는 Provider에서 온 것이 아니라 InheritedWidgets를 사용하지 않는 다른 프로젝트에서 온 것입니다.
공급자의 Consumer 에 provider 매개변수가 없습니다.

그리고 제가 언급했듯이 Consumer -> ValueListenableBuilder/StreamBuilder/BlocBuilder/Observer/...

"initState/didUpdateDependency" 메서드에 있지만 정확히 동일한 쿼리를 만드는 두 개의 위젯을 찾을 수 없으므로 "논리"가 동일하지 않습니다.

우리가 재사용하려는 상태 논리는 "쿼리 작성"이 아니라 "x가 변경될 때 무엇인가 수행"입니다. "무언가를 하라"는 변할 수 있지만 "x가 변할 때"는 일반적입니다

구체적인 예:
ID가 변경될 때마다 위젯이 HTTP 요청을 하도록 할 수 있습니다.
또한 package:async 의 CancelableOperation을 사용하여 보류 중인 요청을 취소하려고 합니다.

이제 정확히 동일한 작업을 수행하려는 두 개의 위젯이 있지만 다른 HTTP 요청이 있습니다.
결국, 우리는 다음을 가지고 있습니다:

CancelableOperation<User> pendingUserRequest;

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

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

dispose() {
  pendingUserRequest.cancel();
}

대:

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 후크로 분해할 수 있습니다.

즉, 동일한 두 위젯을 사용하면 대신 다음을 수행할 수 있습니다.

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

VS

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

이 시나리오에서는 요청 및 취소와 관련된 모든 논리가 공유됩니다. fetchUser vs fetchMessage 라는 의미 있는 차이만 남습니다.
이 useUnaryCancelableOperation 에서 패키지를 만들 수도 있으며 이제 모든 사람이 앱에서 이를 재사용할 수 있습니다.

여기에 제공된 예제의 가치에 동의하지 않으면 애플리케이션은 대화에 아무 것도 가져오지 않습니다. StatefulWidget으로 할 수 없는 후크로 할 수 있는 것이 없기 때문입니다.

만약 그것이 정말로 사실이라면 우리는 이 버그를 닫아야 한다고 생각합니다. 왜냐하면 우리는 이미 여기에 주어진 예를 논의했고 그것들은 설득력이 없었기 때문입니다. 하지만 상황을 더 잘 이해하고 싶습니다. 이 버그의 이전 의견에서 이점이 응용 프로그램 수준에 있는 것처럼 들리므로 응용 프로그램의 예를 연구하는 것이 좋습니다.

유일한 차이점은 fetchUser 를 fetchMessage 변경했다는 것입니다. 논리는 그렇지 않으면 100% 동일합니다. 그러나 오류가 발생하기 쉬운 재사용할 수 없습니다.

오류가 발생하기 쉬운 것은 무엇이며 재사용할 수 있는 것은 무엇입니까? 완전히 새로운 추상화 및 클래스 계층 구조를 구현하는 것은 클래스에 세 가지 메서드를 구현할 필요가 없고 너무 과도합니다.

다시 말하지만, 어떤 것이 일반적인 패턴이라고 해서 새 기능을 만들어야 한다는 의미는 아닙니다. 게다가 이 경우 반복적인 코드를 줄이려면 StatefulWidget* 클래스를 확장하고 initstate/didUpdateWidget 메서드를 공통 비트로 재정의하면 됩니다.

후크를 사용하면 이것을 useUnaryCancelableOperation 후크로 인수분해할 수 있습니다.

즉, 동일한 두 위젯을 사용하면 대신 다음을 수행할 수 있습니다.

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

VS

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

이 시나리오에서는 요청 및 취소와 관련된 모든 논리가 공유됩니다. fetchUser vs fetchMessage 라는 의미 있는 차이만 남게 됩니다.
이 useUnaryCancelableOperation 에서 패키지를 만들 수도 있고 이제 모든 사람이 앱에서 이를 재사용할 수 있습니다.

미안하지만 그건 나에게 큰 결정적 아니오. 적은 양의 코드 중복성만 절약한다는 사실 외에도 개념적으로 "initState" 및 "update" 수명 주기 메서드에 속하는 코드를 빌드 메서드로 "인수분해"하는 것은 큰 문제가 아닙니다.

내 빌드 방법이 레이아웃만 빌드하고 다른 것은 빌드하지 않을 것으로 기대합니다. 종속성을 설정하고 해제하는 것은 확실히 빌드 방법에 속하지 않으며, 동일한 유형의 코드를 명시적으로 다시 작성하여 내 위젯이 하는 일을 미래의 나와 다른 사람들에게 명시적으로 표시해야 하는 것이 매우 기쁩니다. 그리고 빌드 메소드에 모든 것을 집어넣지 맙시다.

정말 그렇다면 이 버그를 닫아야 한다고 생각합니다.

@Hixie 제발 하지마. 사람들은 이 문제에 관심이 있습니다. 나는 약 레딧에 당신과 함께 이야기 한 같은 일을 하지만, SwiftUI의 맥락에서 : https://github.com/szotp/SwiftUI_vs_Flutter

후크가 아니라 상태 저장 위젯을 어떻게든 개선하는 것입니다. 사람들은 단순히 상용구 작성을 싫어합니다. RAII 및 View의 의미를 복사하는 데 익숙한 SwiftUI 코드를 작성하는 개발자에게는 일회용품을 수동으로 관리하는 것이 옳지 않은 것처럼 보입니다.

그래서 저는 flutter 팀이 적어도 이것을 문제로 보고 대안적인 솔루션/개선 사항에 대해 생각하기를 권장합니다.

내 빌드 방법이 레이아웃만 빌드하고 다른 것은 빌드하지 않을 것으로 기대합니다. 종속성을 설정하고 해제하는 것은 확실히 빌드 방법에 속하지 않습니다.
중요한 포인트입니다. 빌드 메소드는 순수해야 합니다. 그래도 난 우리가 어려움 없이 장점을 가질 수 있기를 바랐어

여기에 더 많은 예를 요구하는 것이 정말 이해가 되지 않습니다. 얼굴에 선명합니다.

후크에 의해 해결된 문제는 간단하고 명백하며 코드를 DRY로 유지합니다. 이것의 이점은 명백한 것, 더 적은 코드 == 더 적은 버그, 더 쉬운 유지 관리, 더 적은 버그가 숨길 장소, 더 적은 줄의 전체 가독성 증가, 주니어 프로그래머가 더 잘 절연된다는 것입니다.

실제 사용 사례를 말하는 경우 매번 12개의 다른 보기에서 12개의 애니메이터 컨트롤러를 설정 및 분해하여 dispose() 호출을 놓치거나 일부를 재정의할 수 있는 문을 열어두는 앱입니다. 다른 수명 주기 방법. 그런 다음 이를 수십 개의 다른 상태 저장 인스턴스에 적용하면 수백 또는 수천 개의 무의미한 코드 라인을 쉽게 볼 수 있습니다.

Flutter는 우리가 지속적으로 반복해야 하는 작은 개체의 상태를 설정하고 해체해야 하는 이러한 경우로 가득 차 있습니다. 이러한 경우는 존재할 필요가 없지만 존재하는 버그에 대한 모든 종류의 기회를 만듭니다. 왜냐하면 현재로서는 우아한 접근 방식이 없기 때문입니다. 이 자동 설정/해체/동기화 논리를 공유합니다.

설정 및 분해 단계가 있거나 항상 연결해야 하는 수명 주기 후크가 있는 말 그대로 _모든_ 상태에서 이 문제를 볼 수 있습니다.

나 자신은 위젯을 사용하는 것이 가장 좋은 접근 방식이라는 것을 알았습니다. 예를 들어 설정/해제가 너무 성가시고 장황하며 버그가 발생하기 쉽기 때문에 AnimatorController는 거의 사용하지 않습니다. 대신 가능한 모든 곳에서 TweenAnimationBuilder를 사용합니다. 그러나 이 접근 방식은 주어진 보기에서 더 많은 수의 상태 저장 개체에 도달하므로 실제로 아무 것도 필요하지 않은 곳에 중첩 및 자세한 정보를 강요한다는 한계가 있습니다.

@szotp 저는 하지 않았습니다... 차라리 우리가 솔루션을 평가할 수 있도록 문제를 보여주는 하나 이상의 기본 앱을 설정하고 싶습니다. 나는 그것을 스스로 할 것이지만 우리가 해결하려는 것이 정확히 무엇인지 이해하지 못하기 때문에 내가 그것을 하는 것이 잘못된 사람입니다.

@escamoteur Baseline 앱은 어려움이 없는 솔루션을 설계하는 데 도움이 됩니다.

@esDotDev 우리는 지금까지 이 버그에서 이와 같은 경우에 대해 논의했지만 Hooks 이외의 솔루션은 솔루션이 해결한 예제에 포함되지 않은 일부 문제를 해결하지 못하기 때문에 그럴 때마다 기각됩니다. 따라서 문제에 대한 간단한 설명은 전체 범위를 파악하기에 충분하지 않은 것 같습니다. 예를 들어, "12개의 애니메이터 컨트롤러" 사례는 애니메이션 컨트롤러 배열과 Dart의 기능적 기능으로 해결할 수 있습니다. TweenAnimationBuilder가 또 다른 솔루션이 될 수 있습니다. 둘 중 어느 것도 Hooks를 포함하지 않습니다. 그러나 내가 제안하면 누군가 내가 놓친 것을 지적하고 "그것은 ... 때문에 작동하지 않습니다."라고 말하고 (예제 컨텍스트에서 새로운) 문제를 제기할 것이라고 확신합니다. 따라서 우리 모두가 동의하는 기본 앱의 필요성은 문제의 전체 확산을 포괄합니다.

누군가가 이것을 앞으로 추진하고 싶다면 내가 가장 좋은 방법은 위에서 설명한 것입니다(https://github.com/flutter/flutter/issues/51752#issuecomment-670249755 및 https://github.com /flutter/flutter/issues/51752#issuecomment-670232842). 그것은 우리 모두가 우리가 해결하려는 문제의 범위를 나타낸다는 데 동의할 수 있는 출발점을 제공할 것입니다. 그런 다음 모든 요구 사항(예: @rrousselGit 의 재사용 필요성, @Rudiksz 의 깨끗한 빌드 방법에 대한 필요성 등)을 해결하는 방식으로 이러한 문제를 해결하는 솔루션을 설계할 수 있으며 가장 중요한 것은 이러한 솔루션을 평가할 수 있다는 것입니다. 기본 앱의 컨텍스트입니다.

나는 우리 모두가 이 문제에 대해 상당히 쉽게 동의할 수 있다고 생각합니다.
_Streams, AnimatorController 등과 관련된 설정/해제 작업을 공유하는 우아한 방법은 없습니다. 이는 불필요한 장황함, 버그 발생 및 가독성 감소로 이어집니다._

그것에 동의하지 않는 사람이 있습니까? 거기에서 시작하여 해결책을 찾아 앞으로 나아가면 안 될까요? 우리는 먼저 이것이 핵심 문제라는 데 동의해야 합니다. 아직까지는 그렇지 않은 것 같습니다.

하지만 글을 쓰면서 문제의 이름이 정확히 일치한다는 것을 깨달았습니다.
" 상태 논리를 재사용하는 것은 너무 장황하거나 너무 어렵습니다 "

나에게 그것은 매우 명백한 문제이며, 우리는 신속하게 토론 단계를 지나서 무엇이 효과가 있을지 브레인스토밍에 들어가야 합니다. 재사용할 수 있는 미세 상태가 필요합니다... 뭔가 알아낼 수 있을 거라 확신합니다. 하루가 끝날 때 많은 Flutter 보기를 정리하고 더 강력하게 만들 것입니다.

@Hixie 제발 하지마. 사람들은 이 문제에 관심이 있습니다. 나는 약 레딧에 당신과 함께 이야기 한 같은 일을 하지만, SwiftUI의 맥락에서 : https://github.com/szotp/SwiftUI_vs_Flutter

당신의 SwiftUI 예제는 단순히 StatefulWidget 클래스를 확장함으로써 몇 줄의 코드로 다트에서 복제될 수 있습니다.

알리미를 구독하지 않거나 외부 호출을 수행하지 않는 StatefulWidgets가 있으며 실제로 대부분이 그렇습니다. 나는 약 100개의 사용자 정의 위젯을 가지고 있으며(모두 Stateful은 아니지만) 그 중 15개는 여기 예제에서 설명하는 모든 종류의 "공통 상태 논리"가 있습니다.

장기적으로 몇 줄의 코드(일명 상용구)를 작성하는 것은 불필요한 오버헤드를 피하기 위한 작은 절충안입니다. 그리고 다시, initState/didUpdate 메소드를 구현해야 하는 이 문제는 너무 과장된 것 같습니다. 여기에 설명된 패턴 중 하나를 사용하는 위젯을 만들 때 처음에는 수명 주기 메서드를 "구현"하는 데 5-10분을 보낸 다음 해당 수명 주기 메서드를 건드리지 않으면서 실제로 위젯 자체를 작성하고 연마하는 데 며칠을 할애합니다. 소위 상용구 설정/해체 코드를 작성하는 데 소비하는 시간은 내 앱 코드에 비해 적습니다.

내가 말했듯이 StatefulWidget은 용도에 대해 거의 가정하지 않기 때문에 강력하고 효율적입니다.

이 특정 사용 사례에 대해 StatefulWidget을 서브클래싱하는(또는 그렇지 않은) Flutter에 새로운 유형의 위젯을 추가하는 것은 괜찮지만 StatefulWidget 자체에 적용하지는 맙시다. 나는 "후크" 시스템이나 마이크로스테이트와 함께 오는 오버헤드가 필요하지 않은 위젯을 많이 가지고 있습니다.

@esDotDev 일부 사람들이 직면한 문제라는 데 동의합니다. 나는 이 문제의 앞부분에서 몇 가지 솔루션을 제안하기도 했습니다(GitHub이 모든 주석을 표시하는 것을 좋아하지 않기 때문에 다양한 버전의 Property 클래스 검색, 지금은 묻힐 수 있음). 어려움은 이러한 제안이 특정 문제를 해결하지 않았기 때문에 기각되었다는 것입니다(예: 한 경우에는 핫 리로드를 처리하지 않았고 다른 경우에는 didUpdateWidget을 처리하지 않았습니다). 그래서 더 많은 제안을 했지만 다른 것을 처리하지 않았기 때문에 다시 기각되었습니다(무엇을 잊어버렸는지). 이것이 우리가 그 문제에 대한 솔루션을 찾을 수 있도록 _전체_ 문제를 나타내는 데 동의하는 일종의 기준선을 갖는 것이 중요한 이유입니다.

목표는 결코 변하지 않았습니다. 제안된 솔루션이 유연성이 부족하다는 비판이 제기되었습니다. 이들 중 어느 것도 구현된 스니펫 외부에서 계속 작동하지 않습니다.

이것이 이 호의 제목에 "어려움"이 언급된 이유입니다. 현재 문제를 해결하는 방식에 유연성이 없기 때문입니다.

그것을 보는 또 다른 방법은 다음과 같습니다.

이 문제는 기본적으로 상태 로직을 위해 위젯 레이어를 구현해야 한다고 주장합니다.
제안된 솔루션은 "하지만 RenderObject로 할 수 있습니다"입니다.

_장기적으로, 몇 줄의 코드(일명 상용구)를 작성하는 것은 불필요한 오버헤드를 피하기 위한 작은 절충안입니다._

이 진술과 함께 몇 가지 니트 :

1. 실제로 몇 줄은 아닙니다. 대괄호, 줄 간격 @overides 등을 acct에 사용하면 간단한 애니메이터 컨트롤러에 대해 10-15개 이상의 줄을 볼 수 있습니다. 그것은 내 마음에 사소하지 않습니다 ... 사소하지 않은 방법처럼. 이 작업을 수행하는 3줄은 저에게 버그가 있습니다(Unity에서는 Thing.DOTween() ). 15는 웃기네요.

1. 그것은 고통이지만 타이핑에 관한 것이 아닙니다. 30줄이 기계식 상용구인 50줄 클래스가 있다는 것은 어리석은 일입니다. 난독화. 상용구를 작성 _하지 않는_ 경우 경고 또는 기타 사항이 없고 방금 버그를 추가했다는 사실에 관한 것입니다.
2. Hooks와 같은 것으로 논의할 가치가 있는 오버헤드는 없습니다. 우리는 각각에 소수의 fxns가 있는 객체 배열에 대해 이야기하고 있습니다. Dart에서는 매우 빠릅니다. 홍어 이모입니다.

@esDotDev

나에게 그것은 매우 명백한 문제이며, 우리는 신속하게 토론 단계를 지나서 무엇이 효과가 있을지 브레인스토밍에 들어가야 합니다.

위젯 확장. ValueNotifier가 공통 사용 패턴을 단순화하기 위해 ChangeNotifier를 확장하는 방식과 마찬가지로 모든 사람은 특정 사용 사례에 대해 자신만의 StatelessWidget을 작성할 수 있습니다.

예, 그것이 효과적인 접근 방식이라는 데 동의하지만 바라는 점이 있습니다. 애니메이터가 1개라면 TweenAnimationBuilder를 사용할 수 있습니다. 쿨, 여전히 5줄의 코드와 비슷하지만 무엇이든 상관없습니다. 그것은 작동합니다 ... 너무 나쁘지 않습니다. 하지만 2~3개 있으면? 이제 저는 중첩 지옥에 있습니다. 어떤 이유로 cpl 다른 상태 저장 개체가 있는 경우 모든 들여쓰기가 엉망이 되거나 임의의 설정, 업데이트 및 분해 컬렉션을 캡슐화하는 매우 구체적인 위젯을 만들고 있습니다. 논리.

위젯 확장. ValueNotifier가 공통 사용 패턴을 단순화하기 위해 ChangeNotifier를 확장하는 방식과 마찬가지로 모든 사람은 특정 사용 사례에 대해 자신만의 StatelessWidget을 작성할 수 있습니다.

한 번에 하나의 기본 클래스만 확장할 수 있습니다. 그건 스케일이 아니다

믹스인은 다음 논리적 시도입니다. 그러나 OP가 언급했듯이 확장되지도 않습니다.

@esDotDev

또는 설정, 업데이트 및 해제 논리의 임의 컬렉션을 캡슐화하는 매우 구체적인 위젯을 만들고 있습니다.

3-4가지 종류의 AnimationController를 설정해야 하는 일종의 위젯은 매우 구체적인 사용 사례처럼 들리며 설정/해제 로직의 임의 수집을 지원하는 것은 확실히 프레임워크의 일부가 되어서는 안 됩니다. 사실 이것이 initState/didUpdateWidget 메소드가 처음에 노출되는 이유이므로 원하는 대로 설정을 무작위로 수집할 수 있습니다.

가장 긴 initState 메서드는 5줄의 코드이며, 위젯은 과도한 중첩을 겪지 않으므로 요구 사항과 사용 사례가 확실히 다릅니다. 또는 다른 개발 스타일.

@esDotDev

3. Hooks와 같은 것으로 논의할 가치가 있는 오버헤드가 없습니다. 우리는 각각에 소수의 fxns가 있는 객체 배열에 대해 이야기하고 있습니다. Dart에서는 매우 빠릅니다. 홍어 이모입니다.

제안된 솔루션이 완전히 사실이 아닌 flutter_hooks 패키지와 같은 것이라면. 예, 개념적으로는 함수가 포함된 배열이지만 구현은 사소하거나 효율적이지 않습니다.

내 말은, 내가 틀릴 수도 있지만 HookElement가 자체 빌드 메서드에서 자체적으로 다시 빌드해야 하는지 여부를 확인하는 것처럼 보입니다!
또한 모든 단일 위젯 빌드에서 후크를 초기화, 재초기화 또는 폐기해야 하는지 여부를 확인하는 것은 상당한 오버헤드처럼 보입니다. 옳지 않다고 느끼므로 내가 틀렸기를 바랍니다.

@brianegan 의 아키텍처 예제 중 하나를 비교를 위한 기본 앱으로 사용하는 것이 의미가 있습니까?

내가 여기에 끼어들 수 있다면 이것이 이미 말했는지 확실하지 않습니다. 그러나 React에서 우리는 후크가 있는 수명 주기를 생각하지 않습니다. 이것이 컴포넌트/위젯을 구축하는 데 익숙하다면 무섭게 들릴 수도 있지만, 여기에서 수명 주기가 실제로 중요하지 않은 이유가 있습니다.

대부분의 경우 props를 기반으로 수행할 상태 또는 작업으로 구성 요소/위젯을 빌드할 때 해당 상태/props가 변경될 때 무언가가 발생하기를 원합니다(예: 이 스레드에서 언급한 것처럼 -userId 소품이 변경되면 사용자의 세부 정보를 가져옵니다. 일반적으로 위젯의 모든 props가 변경될 때 발생하는 것보다 userId 변경의 "효과"로 생각하는 것이 훨씬 더 자연스럽습니다.

정리에 대해서도 마찬가지지만, "모든 props/state가 변경되거나 변경될 때 X를 정리하는 것을 기억해야 함을 기억해야 합니다. 전체 구성 요소가 파괴될 때".

저는 Flutter를 한동안 작성하지 않았기 때문에 현재의 분위기나 이 접근 방식이 현재 Flutter 사고 방식에 미칠 제한 사항을 알고 있는 것처럼 들리려고 하지 않습니다. 저는 다양한 의견에 열려 있습니다. 나는 React hooks에 익숙하지 않은 많은 사람들이 내가 라이프사이클 패러다임에 너무 깊이 뿌리박혀 있기 때문에 내가 소개되었을 때와 같은 혼란을 겪고 있다고 생각합니다.

@escamoteur @Rudiksz @Hixie 나는 우리가이 예제를 만들기 위해 시작하는 곳으로 초대받은 것을 @TimWhiting에 의해 생성 된 GitHub의 프로젝트가 있었다. 각 개인/그룹은 미리 정의된 문제를 해결하는 방법을 만들 수 있습니다. 페이지와 같은 완전한 기능을 갖춘 앱은 아니지만 더 복잡한 예를 보여주는 역할을 하는 경우 앱을 추가할 수도 있습니다. 그런 다음 문제를 논의하고 더 나은 API를 만들 수 있습니다. @TimWhiting 은 관심 있는 사람을 초대할 수 있습니다.

https://github.com/TimWhiting/local_widget_state_approaches

Jetpack compose 는 여기 에서 react 와 비교한 hook과도 비슷합니다.

@satvikpendem @TimWhiting 멋지네요 ! 감사합니다.

@esDotDev
매우 구체적인 사용 사례와 설정/해제 로직의 임의 수집 지원은 확실히 프레임워크의 일부가 되어서는 안 됩니다.

이것은 갈고리가 머리를 때리는 못입니다. 각 유형의 개체는 자체 설정 및 분해를 담당합니다. 애니메이터는 스트림과 마찬가지로 스스로를 생성, 업데이트 및 파괴하는 방법을 알고 있습니다. Hooks는 특히 뷰 전체에 흩어져 있는 상태 스캐폴딩의 '임의 컬렉션' 문제를 해결합니다. 보기 코드의 대부분이 비즈니스 로직 및 레이아웃 형식화에 집중할 수 있도록 하여 승리합니다. 모든 프로젝트에서 동일한 일반적인 상용구를 숨기기 위해 사용자 지정 위젯을 만들도록 강요하지 않습니다.

가장 긴 initState 메서드는 5줄의 코드이며, 위젯은 과도한 중첩을 겪지 않으므로 요구 사항과 사용 사례가 확실히 다릅니다. 또는 다른 개발 스타일.

내 것도. 그러나 그것은 initState() + dispose() + didUpdateDependancies()이며 마지막 2개 중 하나가 누락되면 버그가 발생할 수 있습니다.

표준 예는 다음과 같을 것이라고 생각합니다. 1개의 스트림 컨트롤러와 2개의 애니메이터 컨트롤러를 사용하는 보기를 작성합니다.

내가 볼 수있는 한 3 가지 옵션이 있습니다.

1. 30줄 정도의 상용구를 클래스에 추가하고 일부 믹스인을 추가합니다. 장황할 뿐만 아니라 처음에는 따라가기가 상당히 어렵습니다.
2. 보기 코드에 도달하기 전에 약 15개의 들여쓰기 수준에 대해 2개의 TweenAnimationBuilder와 StreamBuilder를 사용하면 여전히 스트림에 대한 많은 상용구가 있습니다.
3. 3개의 상태 저장 하위 개체를 가져오고 사용자 정의 초기화/파기 코드를 정의하려면 6줄의 들여쓰기되지 않은 코드를 build() 맨 위에 추가하세요.

SingleStreamBuilderDoubleAnimationWidget인 네 번째 옵션이 있을 수 있지만 이것은 개발자를 위한 임시 작업이며 일반적으로 꽤 성가십니다.

또한 새로운 개발자의 인지 부하 3은 다른 2보다 훨씬 낮습니다. 대부분의 새로운 개발자는 TweenAnimationBuilder의 존재조차 모르고, 단순히 SingleTickerProvider의 개념을 배우는 것 자체가 작업입니다. "애니메이터를 주세요"라고 말하는 것이 더 쉽고 강력한 접근 방식입니다.

나는 오늘 무언가를 코딩하려고 노력할 것이다.

2. 2개의 TweenAnimationBuilder와 StreamBuilder를 약 15개의 들여쓰기 수준에 대해 사용하여 보기 코드에 도달하기 전에도 스트림에 대한 상용구를 많이 사용할 수 있습니다.

오른쪽. 15단계 들여쓰기를 사용하는 실제 코드 예제를 보여주세요.

라이브러리에서 30줄의 코드를 6줄 + 수백 줄로 대체하면 인지 부하가 ​​어떻게 감소합니까? 네, 라이브러리가 하는 "마법"은 무시할 수 있지만 규칙은 무시할 수 있습니다. 예를 들어 후크 패키지는 후크가 빌드 메소드에서만 사용해야 한다는 불확실한 용어로 알려줍니다. 이제 걱정해야 할 추가 제약 조건이 있습니다.

15,000줄의 코드가 있는 프로젝트에서 focusnodes, textcontrollers, singletickerproviders 또는 내 statefulwidgets의 다양한 수명 주기 메서드를 포함하는 코드가 200줄 미만일 것입니다. 어떤 인지 과부하에 대해 이야기하고 있습니까?

@Rudiksz 수동 공격을 중지하십시오.
우리는 싸우지 않고 동의할 수 있습니다.

후크 제약 조건은 가장 적은 걱정거리입니다.

우리는 후크에 대해 구체적으로 말하는 것이 아니라 문제에 대해 이야기하고 있습니다.
필요하다면 다른 해결책을 제시할 수 있습니다.

중요한 것은 우리가 해결하고자 하는 문제입니다.

또한 위젯은 빌드 내에서만 무조건적으로 사용할 수 있습니다.

그것은 후크 제약 조건과 동일하지만 사람들이 그것에 대해 불평하지 않는다고 생각합니다.

또한 위젯은 빌드 내에서만 무조건적으로 사용할 수 있습니다.

그것은 후크 제약 조건과 동일하지만 사람들이 그것에 대해 불평하지 않는다고 생각합니다.

아니오, 동일하지 않습니다. 여기에 제시된 문제는 _prepares_ 위젯이 _before_ (재)빌드되는 코드와 관련된 것 같습니다. 상태, 종속성, 스트림, 컨트롤러 등을 준비하고 트리 구조의 변경 사항을 처리합니다. 단일 함수 호출 뒤에 숨겨져 있더라도 이들 중 어느 것도 빌드 메서드에 있어서는 안 됩니다.
해당 논리의 진입점은 빌드 메서드에 있어서는 안 됩니다.

어떤 종류의 초기화 논리를 빌드 메소드에 넣도록 강요하는 것은 빌드 메소드에서 위젯 트리를 구성하도록 "강제"하는 것과 같지 않습니다. 빌드 방법의 전체 이유는 기존 상태(변수 집합)를 가져와서 그려지는 위젯 트리를 생성하는 것입니다.

반대로, 나는 initState/didUpdateWidget 메소드 내부에 위젯을 빌드하는 코드를 추가하도록 강요하는 것도 반대합니다.

현재와 ​​같이 statefulwidget 수명 주기 메서드는 매우 명확한 역할을 하며 완전히 다른 관심사로 코드를 분리하는 것을 매우 쉽고 간단하게 만듭니다.

개념적으로 여기에서 설명하는 문제를 이해하기 시작했지만 여전히 실제 문제로 보지 못합니다. 카운터 앱이 아닌 실제 예가 마음을 바꾸는 데 도움이 될 수 있습니다.

참고로 제가 최근에 실험한 Riverpod 에는 제약이 없는 매우 갈고리 같은 아이디어가 있습니다.

예를 들어 다음을 해결합니다.

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

주요 문제는 이것이 한 종류의 개체에만 해당되며 개체 인스턴스가 재구축 간에 일관된 hashCode를 가지고 있다는 사실에 의존하여 작동한다는 것입니다.

그래서 우리는 여전히 hooks의 유연성과는 거리가 멀다.

@rrousselGit 내가 확장하지 않고 생각 StatelessWidget / StatefulWidget 수업을하고 ConsumerStatelessWidget 같은 것을 만들어, 같은 것을 가질 수 있습니다 context.watch 에 확장 방법을 사용하여 BuildContext 클래스를 만들고 공급자가 InheritedWidgets와 함께 watch 기능을 제공하도록 합니다.

그건 다른 주제입니다. 하지만 이 문제에 대한 해결책으로 InheritedWidgets에 의존할 수는 없습니다. https://github.com/flutter/flutter/issues/30062

이 문제를 해결하기 위해 InheritedWidgets를 사용하면 https://github.com/flutter/flutter/issues/12992 및 https://github.com/flutter/flutter/pull/33213 때문에 차단됩니다.

개념적으로 여기에서 설명하는 문제를 이해하기 시작했지만 여전히 실제 문제로 보지 못합니다.

Flutter를 SwiftUI와 비교하면 실제 문제가 있는 것이 분명합니다.

Flutter와 다른 사람들이 이 문제를 해결하기 위해 열심히 일했기 때문에 보기가 어려울 수 있습니다. AnimatedBuilder, StreamBuilder, Consumer, AnimatedOpacity 등 각 특정 사례에 대한 래퍼가 있습니다. StatefulWidget은 이러한 작은 재사용 가능한 유틸리티를 구현하는 데 훌륭하게 작동하지만 너무 낮은 수준입니다. 재사용할 수 없는 도메인 특정 구성 요소의 경우 다수의 텍스트 컨트롤러, 애니메이션 또는 비즈니스 로직이 요구하는 모든 것이 있을 수 있습니다. 일반적인 해결책은 총알을 깨물고 모든 상용구를 작성하거나 신중하게 구성된 공급자 및 청취자 트리를 만드는 것입니다. 어떤 접근 방식도 만족스럽지 않습니다.

@rrousselGit이 말하는 것과
상태 유지의 경우 문제는 매우 유사합니다. 자동화될 수 있는 지루하고 오류가 발생하기 쉬운 작업입니다.

그리고 그건 그렇고, 후크가 이것을 전혀 해결하지 못한다고 생각합니다. 후크는 flutter의 내부를 변경하지 않고 가능한 유일한 접근 방식일 뿐입니다.

StatefulWidget은 이러한 작은 재사용 가능한 유틸리티를 구현하는 데 훌륭하게 작동하지만, 다수의 텍스트 컨트롤러, 애니메이션 또는 비즈니스 로직이 요구하는 모든 것이 있을 수 있는 재사용 불가능한 도메인 특정 구성 요소에는 너무 낮은 수준입니다.

재사용할 수 없는 도메인 특정 구성 요소를 빌드하려면 높은 수준의 위젯이 필요하다고 말할 때 혼란스럽습니다. 보통은 정반대입니다.

AnimatedBuilder, StreamBuilder, Consumer, AnimatedOpacity는 모두 특정 사용 사례를 구현하는 위젯입니다. 특정 논리가 있어서 이러한 상위 수준 위젯을 사용할 수 없는 위젯이 필요한 경우에는 하위 수준 API로 드롭다운하여 나만의 특정 사용 사례를 작성할 수 있습니다. 소위 상용구라고 하는 것은 내 고유한 위젯이 스트림, 네트워크 호출, 컨트롤러 등의 고유한 조합을 관리하는 방법을 구현하는 것입니다.

후크, 후크와 같은 동작 또는 심지어 "자동화"를 옹호하는 것은 소위 상용구 코드를 작성하지 않고도 누구나 갖고 싶어하는 재사용할 수 없는 높은 수준의 논리를 처리할 수 있는 낮은 수준의 위젯이 필요하다고 말하는 것과 같습니다.

상태 유지의 경우 문제는 매우 유사합니다. 자동화될 수 있는 지루하고 오류가 발생하기 쉬운 작업입니다.

다시. 다수의 텍스트 컨트롤러, 애니메이션 또는 비즈니스 로직에서 요구하는 모든 "__!

@rrousselGit이 말하는 것과

저는 6-7년 전에 ios와 android 개발을 했습니다(Android가 머티리얼 디자인으로 전환했을 때). 그리고 이 관리 및 재활용 보기 중 어떤 것도 문제가 되었던 기억이 없으며 Flutter가 더 좋거나 나쁘게 보이지 않습니다. 나는 현재의 일에 대해 말할 수 없다. 나는 Swift와 Kotlin이 출시되었을 때 그만뒀다.

StatefulWidgets에 강제로 작성해야 하는 상용구는 코드 기반의 약 1%입니다. 오류가 발생하기 쉬운가요? 코드의 모든 라인은 잠재적인 버그 소스이므로 확실합니다. 번거롭나요? 15000에서 200줄의 코드가 나오나요? 나는 정말로 그렇게 생각하지 않습니다. 그러나 그것은 단지 제 생각일 뿐입니다. Flutter의 텍스트/애니메이션 컨트롤러인 focusnodes에는 모두 개선할 수 있는 문제가 있지만 장황한 것은 아닙니다.

나는 사람들이 무엇을 개발하여 너무 많은 상용구를 필요로 하는지 정말 궁금합니다.

여기 주석 중 일부를 들으면 1줄 대신 5줄의 코드를 관리하는 것이 5배 더 어려운 것처럼 들립니다. 그렇지 않다.

예를 들어 각 AnimationController에 대해 initState 및 dispose를 설정하는 대신에 한 번만 수행하고 해당 논리를 재사용하는 것보다 오류가 발생하기 쉽습니다. 기능을 사용하는 것과 같은 원리, 재사용성. 나는 빌드 기능에 후크를 넣는 것이 문제가 있다는 데 동의하지만 분명히 더 나은 방법이 있습니다.

여기서 문제를 보는 사람과 보지 못하는 사람의 차이점은 전자는 React, Swift, Kotlin과 같이 이전에 후크와 같은 구조를 사용하고 후자는 순수 Java에서 작업하는 것과 같이 사용하지 않았다는 것입니다. 또는 안드로이드. 내 경험에 따르면 확신할 수 있는 유일한 방법은 후크를 시도하고 표준 방식으로 돌아갈 수 있는지 확인하는 것입니다. 종종 많은 사람들이 제 경험상 그렇게 할 수 없습니다. 사용해보면 압니다.

이를 위해 저는 작은 프로젝트에 대해 flutter_hooks를 사용하고 어떻게 작동하는지 확인한 다음 기본 방식으로 다시 실행하는 데 회의적인 사람들을 권장합니다. @Hixie 의 제안처럼 읽을 수 있는 앱 버전을 만드는 것만으로는 충분하지 않습니다(물론 그렇게 할 것이지만). 저는 각 사람이 차이점을 확인하기 위해 직접 후크를 사용해야 한다고 믿습니다.

@Hixie 의 제안처럼 읽을 수 있는 앱 버전을 만드는 것만으로는 충분하지 않습니다(물론 그렇게 할 것이지만). 저는 각 사람이 차이점을 확인하기 위해 직접 후크를 사용해야 한다고 믿습니다.

나는 공급자를 시도하는 데 며칠을 낭비하고 블록을 시도하는 데 더 많은 날을 보냈습니다. 나는 그 중 어느 것도 좋은 솔루션이라는 것을 찾지 못했습니다. 그것이 당신을 위해 작동한다면, 좋습니다.

나 심지어 당신이 겪고있는 문제에 제안 된 솔루션을 시도하기 위해서는, 당신은 그것의 이점을 증명해야합니다. 플러터 후크가 있는 예제를 살펴보고 구현을 살펴보았습니다. 그냥 싫다.

어떤 상용구 감소 코드가 프레임워크에 추가되더라도 Stateful/StatelessWidget이 변경되지 않은 상태로 유지되기를 바랍니다. 이 대화에 더 이상 추가할 수 없습니다.

후크에 대한 이야기 ​​없이 Dart를 변경할 수 있는 가상의 세계에서 다시 시작하겠습니다.

논의된 문제는 다음과 같습니다.

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');
}

이 코드는 훨씬 더 읽기 쉽고 후크와 관련이 없으며 제한 사항이 없습니다.
가독성 향상은 줄 수가 아니라 서식 및 들여쓰기에 관한 것입니다.

그러나 Builder가 루트 위젯이 아닌 경우는 어떻습니까?

예시:

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 주석과 같이 _많은_ 빌더를 사용할 계획이라면 코드를 읽기 어렵게 만든다는 것입니다.

이 새로운 구문으로 가독성 문제를 수정했습니다. 따라서 더 많은 것을 빌더로 추출할 수 있습니다.

예를 들어 이 주석에 언급된 useFilter 는 다음과 같을 수 있습니다.

FilterBuilder(
  debounceDuration: const Duration(seconds: 2),
  builder: (context, filter) {
    return TextField(onChange: (value) => filter.value = value);
  }
)

그런 다음 new 키워드와 함께 사용할 수 있습니다.

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

사용자 정의 후크/빌더를 생성하기 위해 후크에 대해 이야기한 "함수로 추출"은 어떻습니까?

함수에서 Builders 조합을 추출하여 이러한 키워드로 동일한 작업을 수행할 수 있습니다.

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 가 되는 use 이며 궁극적으로 useStream 로 구현됩니다.

이 코드는 훨씬 더 읽기 쉽습니다.

이것은 의견의 문제라고 생각합니다. 어떤 사람들은 당신이 설명하는 버전이 더 읽기 쉽다고 생각한다는 데 동의합니다. 개인적으로 나는 훨씬 더 명시적인 마법이 없는 버전을 선호합니다. 그러나 나는 두 번째 스타일을 가능하게 만드는 데 반대하지 않습니다.

즉, 다음 단계는 @TimWhiting 의 앱(https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/stateful/counter.dart)에서 작업하여 모든 문제가 있는 앱으로 만드는 것입니다. 해결하고자 합니다.

그 가치를 위해 https://github.com/flutter/flutter/issues/51752#issuecomment -670959424 React의 Hooks에 대한 영감과 거의 유사합니다. Builder 패턴은 React에서 널리 사용되었던 Render Props 패턴과 동일해 보이지만 유사하게 깊은 트리로 이어졌습니다. 나중에 @trueadm 은 Render Props에 대한 구문 설탕 을 제안했으며 나중에 Hooks로 이어졌습니다(불필요한 런타임 오버헤드 제거).

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

귀하의 예에는 새로운 키워드 또는 기능을 보증하는 항목이 없습니다.

무슨 말을 하려는지 알고 있습니다. '값' 변수는 모든 위젯/함수 호출을 통해 전달되어야 하지만 이는 애플리케이션을 설계한 방법의 결과일 뿐입니다. 사용 사례에 따라 "빌드" 메서드와 사용자 지정 위젯을 모두 사용하여 코드를 분리하고 동일한 변수를 세 번의 호출 체인에 전달할 필요가 없습니다.

재사용 가능한 코드는 외부 부작용(예: InheritedWidgets 또는 (반)전역 상태)에 가능한 한 적게 의존할 때 재사용할 수 있습니다.

@Rudiksz 여기 토론에 아무 것도 추가하지 않는다고 생각합니다. 우리는 이러한 문제를 하루 종일 수행하기 때문에 이러한 문제를 완화하기 위한 전략을 알고 있습니다. 문제가 되지 않는다고 생각되면 그대로 계속 사용하면 되며 이는 전혀 영향을 미치지 않습니다.

이것을 근본적인 고통으로 보는 많은 사람들이 분명히 있으며 앞뒤로 순환하는 것은 무의미합니다. 당신은 다양한 주장을 통해 사람들이 원하는 것을 원하지 않거나 다른 사람의 마음을 바꾸지 않는다는 것을 설득하지 않을 것입니다. 이 토론에 참여하는 모든 사람들은 분명히 Flutter에서 수백 또는 수천 시간을 자신의 벨트 아래에 두고 있으며, 우리 모두가 이에 대해 동의해야 한다고 기대하지 않습니다.

이것은 의견의 문제라고 생각합니다. 어떤 사람들은 당신이 설명하는 버전이 더 읽기 쉽다고 생각한다는 데 동의합니다. 개인적으로 나는 훨씬 더 명시적인 마법이 없는 버전을 선호합니다. 그러나 나는 두 번째 스타일을 가능하게 만드는 데 반대하지 않습니다.

의견의 문제라면 상당히 한쪽으로 치우쳐 있다고 생각합니다.

1. 둘 다 마법이 있다. 나는 이 빌더들이 내부적으로 무엇을 하고 있는지 반드시 알지는 못합니다. 비 마법 버전은 이러한 빌더 내부에 실제 상용구를 작성하고 있습니다. SingleAnimationTIckerProvider 믹스인을 사용하는 것은 Flutter 개발자의 95%에게도 마법입니다.
2. 하나는 value1 및 value2 인 트리에서 나중에 사용될 매우 중요한 변수 이름을 난독화하고 다른 하나는 빌드 맨 앞과 중앙에 있습니다. 이것은 명확한 구문 분석 / 유지 관리의 승리입니다.
3. 하나는 위젯 트리가 시작되기 전에 6단계의 들여쓰기가 있고 다른 하나는 0입니다.
4. 하나는 5개의 수직선이고 다른 하나는 15개입니다.
5. 하나는 실제 콘텐츠 조각을 눈에 띄게 표시(Text())하고 다른 하나는 트리 아래로 중첩되어 숨깁니다. 또 다른 명확한 구문 분석 승리.

일반적인 의미에서 나는 이것이 아마도 취향의 문제라고 볼 수 있습니다. 그러나 Flutter는 특히 일반적으로 라인 수, 들여쓰기 및 신호: 잡음 비율에 문제가 있습니다. 나는 Dart 코드에서 선언적으로 트리를 형성하는 기능을 절대적으로 _사랑_하지만, 특히 여러 계층의 래핑된 빌더에 의존할 때 매우 읽기 어렵고 장황한 코드로 이어질 수 있습니다. 따라서 우리가 이 싸움을 계속하고 있는 Flutter 자체의 맥락에서 이러한 종류의 최적화는 다소 만연한 일반적인 장황한 문제를 해결하는 데 정말 훌륭한 도구를 제공하기 때문에 킬러 기능입니다.

TL;DR - Flutter에서 들여쓰기와 줄 수를 크게 줄인 모든 것은 일반적으로 Flutter 고유의 줄 수와 들여쓰기가 많기 때문에 두 배로 가치가 있습니다.

@Rudiksz 여기 토론에 아무 것도 추가하지 않는다고 생각합니다. 우리는 이러한 문제를 하루 종일 수행하기 때문에 이러한 문제를 완화하기 위한 전략을 알고 있습니다. 문제가 되지 않는다고 생각되면 그대로 계속 사용하면 되며 이는 전혀 영향을 미치지 않습니다.

핵심 프레임워크의 변경 사항인 경우를 제외하고 저에게 영향을 미치지 않습니까?

이것을 근본적인 고통으로 보는 많은 사람들이 분명히 있으며 앞뒤로 순환하는 것은 무의미합니다. 당신은 다양한 주장을 통해 사람들이 원하는 것을 원하지 않거나 다른 사람의 마음을 바꾸지 않는다는 것을 설득하지 않을 것입니다. 이 토론에 참여하는 모든 사람들은 분명히 Flutter에서 수백 또는 수천 시간을 자신의 벨트 아래에 두고 있으며, 우리 모두가 이에 대해 동의해야 한다고 기대하지 않습니다.

맞아요 이 말은 이미 수없이 맞고 죽었으니 더이상 댓글에 답글 달지 않겠습니다.

빌더는 기술적으로 상태 논리를 재사용하는 방법입니다. 그러나 문제는 코드를 잘 읽지 못하게 만든다는 것입니다.

이것은 그것을 완벽하게 진술합니다. Flutter 용어로 생각하려면 단일 라인 빌더가 필요합니다.

수십 개의 탭과 줄이 필요하지 않지만 일부 사용자 정의 상용구가 위젯 수명 주기에 연결되도록 허용하는 빌더.

"모든 것이 위젯이다"라는 주문은 특히 여기서 좋은 것이 아닙니다. 빌더의 관련 코드는 일반적으로 설정 소품과 빌드 fxn에 필요한 상태를 반환하는 것입니다. 모든 단일 줄 바꿈과 탭은 기본적으로 무의미합니다.

핵심 프레임워크의 변경 사항인 경우를 제외하고 저에게 영향을 미치지 않습니까?

@Rudiksz 아무도 우리가 Stateful 위젯을 변경하자고 제안하지 않는다고 생각합니다. 원하는 경우 항상 현재 형태로 사용할 수 있습니다. 우리가 생각해 낼 수 있는 솔루션이 무엇이든 변경 없이 Stateful 위젯을 사용하거나 완전히 다른 유형의 위젯을 사용합니다. Stateful 위젯이 나쁘다고 말하는 것이 아니라 더 구성 가능한 위젯 상태를 허용하는 다른 유형의 위젯을 원한다는 것입니다. 연결된 하나의 상태 개체 대신 여러 상태 개체와 별개이지만 해당 상태 개체에 액세스할 수 있는 하나의 빌드 기능을 포함하는 상태 저장 위젯으로 생각하십시오. 이런 식으로 initState 및 dispose 이미 구현되어 있는 일반 상태 비트(해당 상태와 연결된 상태 논리와 함께)를 재사용할 수 있습니다. 본질적으로 보다 모듈화된 상태로, 다양한 상황에서 다양한 방식으로 구성될 수 있습니다. 다시 말하지만, 이것은 구체적인 제안이 아니라 다른 방식으로 생각할 수도 있습니다. 아마도 flutter 와 같은 솔루션으로 바뀔 수 있지만 모르겠습니다.

즉, 다음 단계는 @TimWhiting 의 앱(https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/stateful/counter.dart)에서 작업하여 모든 문제가 있는 앱으로 만드는 것입니다. 해결하고자 합니다.

이 문제는 본질적으로 수천 컷의 죽음 중 하나이기 때문에 이것은 까다롭습니다. 그것은 단지 부풀림을 추가하고 코드베이스 전체에서 가독성을 감소시킵니다. 전체 클래스가 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에서 그다지 매력적이지 않습니다. 이러한 방식으로 컨트롤러를 부트스트랩, 관리 및 파괴해야 한다는 것을 알고 있기 때문에 성가시고 버그가 발생하기 쉽습니다. 직접 만드는 것을 피하고 대신 맞춤형 StatefulWidget/Builder를 생성하도록 합니다. 빌더에 가독성 문제가 있거나 최소한 훨씬 더 장황하고 공백이 많기 때문에 컨트롤러 유형 개체가 사용하기 쉽고 더 강력하면 좋을 것입니다.

까다롭다

네, API 디자인은 까다롭습니다. 내 인생에 오신 것을 환영합니다.

따라서 이 예제 중 30개를 보는 것이 무엇을 보여줄지 모르지만 1개는 그렇지 않습니다.

도움이 될 것은 30개의 예제가 아니라 "음, 물론, 이 예제에서는 작동하지만 _real_ 예제에서는 그렇지 않습니다"라고 말할 수 있는 방식으로 단순화할 수 없을 만큼 충분히 정교한 예제입니다.

도움이 되는 것은 30개의 예제가 아니라 "글쎄, 물론, 이 예제에서는 작동하지만 실제 예제에서는 그렇지 않습니다"라고 말할 수 있는 방식으로 단순화할 수 없을 만큼 충분히 정교한 예제입니다.

이미 몇 번 말했지만 훅을 판단하는 방식은 불공평하다.
Hooks는 이전에 불가능했던 것을 가능하게 만드는 것이 아닙니다. 이런 종류의 문제를 해결하기 위해 일관된 API를 제공하는 것입니다.

다르게 단순화할 수 없는 것을 보여주는 애플리케이션을 요청하는 것은 나무를 오르는 능력으로 물고기를 판단하는 것입니다.

우리는 단지 후크를 판단하려고 하는 것이 아니라 모든 사람의 요구를 해결하는 솔루션이 있는지 확인하기 위해 다양한 솔루션을 평가하려고 합니다.

(각 제안서에 실제로 신청서를 작성하고 비교하지 않는다면 여기에서 다른 제안서를 어떻게 평가할 것인지 궁금합니다. 대신 어떤 평가 지표를 제안하시겠습니까?)

이 문제에 대한 해결책을 판단하는 적절한 방법은 응용 프로그램이 아닙니다(API의 각 개별 사용은 여기에 있는 예와 같이 무시됩니다).

제안된 솔루션을 판단해야 하는 사항은 다음과 같습니다.

• 결과 코드가 기본 구문보다 객관적으로 더 나은가요?
  
  
  
  • 실수를 피합니까?
  
  
  • 더 읽기 쉬운가요?
  
  
  • 쓰기가 더 쉽나요?
  
  
• 코드는 얼마나 재사용할 수 있습니까?
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  
  
  
  • 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  
  

이 그리드에서 평가할 때 Property / addDispose 제안서는 "결과 코드가 더 좋습니까?" 그러나 재사용성과 유연성 모두에 대해 낮은 평가를 받았습니다.

실제 사용되는 각 제안을 실제로 보지 않고 이러한 질문에 답하는 방법을 모르겠습니다.

왜요?

이 제안이 진정으로 재사용 가능한 코드를 생성하고 많은 문제를 해결하는 데 어려움을 겪을 것임을 알기 위해 Property 를 사용하여 응용 프로그램을 만들 필요가 없었습니다.

기존 *Builder를 사용하여 제안된 솔루션을 사용하여 다시 구현할 수 있습니다.
이 스레드에 나열된 후크 또는 React 커뮤니티에서 만든 일부 후크를 시도하고 다시 구현할 수도 있습니다(온라인에서 사용할 수 있는 후크 편집이 많이 있음).

이 제안이 진정으로 재사용 가능한 코드를 생성하고 많은 문제를 해결하는 데 어려움을 겪을 것임을 알기 위해 Property 를 사용하여 응용 프로그램을 만들 필요가 없었습니다.

불행히도, 나는 여기서 당신의 본능을 공유하지 않습니다(당신이 가치를 처리해야 한다고 말할 때까지 Property (https://github.com/flutter/flutter/issues/51752#issuecomment-667737471)가 훌륭하게 작동했다고 생각했다는 사실에서 알 수 있듯이) 동일한 API를 사용하는 위젯과 로컬 상태에서 모두 가져오기 전까지는 제약 조건이라는 사실을 몰랐습니다). 해당 문제를 해결하는 Property 버전도 제공하면 확실히 문제가 해결될 것입니까, 아니면 다루지 않는 새로운 문제가 있습니까? 목표가 없으면 우리 모두가 목표라는 데 동의합니다. 우리가 솔루션을 설계하는 대상이 무엇인지 모르겠습니다.

기존 *Builder를 사용하여 제안된 솔루션을 사용하여 다시 구현할 수 있습니다.

분명히 _아무도_ 아닙니다. 예를 들어, 당신은 OP에서 하나를 주었고, 내가 첫 번째 Property 제안을 할 때 (https://github.com/flutter/flutter/issues/51752#issuecomment-664787791) 다음에서 설명하지 않은 문제를 지적했습니다. 오리지널 빌더.

이 스레드에 나열된 후크 또는 React 커뮤니티에서 만든 일부 후크를 시도하고 다시 구현할 수도 있습니다(온라인에서 사용할 수 있는 후크 편집이 많이 있음).

나는 우리가 어디에서 시작하는지 상관하지 않습니다. 문제를 설명하고 후크를 사용한다고 생각하는 특히 좋은 예가 있다면 훌륭합니다. @TimWhiting 의 저장소에 추가해 보겠습니다. 요점은 동일한 것을 여러 가지 다른 방법으로 구현하는 것입니다. 아이디어가 어디에서 왔는지 상관하지 않습니다.

도움이 될 것은 30개의 예제가 아니라 "음, 물론, 이 예제에서는 작동하지만 _real_ 예제에서는 그렇지 않습니다"라고 말할 수 있는 방식으로 단순화할 수 없을 만큼 충분히 정교한 예제입니다.

읽을 수 없는 빌더나 버그가 발생하기 쉬운 수명 주기 상용구 없이 AnimatorController(또는 생각할 수 있는 다른 재사용 가능한 상태 저장 구성 요소)를 사용하려는 단순한 욕구보다 더 정교한 것은 없을 것입니다.

범용 방식으로 요청된 가독성 및 견고성 이점을 해결하는 솔루션이 제안되지 않았습니다.

나는 _any_ builder가 할 것이라는 사실을 주장합니다. 이 문제는 "We need syntax sugar for Builders"로 이름이 바뀌고 동일한 토론으로 이어질 수 있기 때문입니다.

AnimationController 생성 및 삭제와 같은 다른 모든 인수는 빌더로 추출될 수 있다는 것을 기반으로 합니다.

Widget build(context) {
  return AnimationControllerBuilder(
    duration: Duration(seconds: 2),
    builder: (context, animationController) {

    }
  );
}

결국 완벽한 예는 StreamBuilder를 완전히 다시 구현하고 다양한 시나리오에서 테스트하는 것이라고 생각합니다.

• 스트림은 Widget 에서 옵니다.
• // InheritedWidget에서
• 지역 주에서

"시간이 지남에 따라 스트림이 변경될 수 있음"에 대해 각 개별 사례를 테스트하여 다음과 같이 하십시오.

• 새 스트림이 있는 didUpdateWidget
• InheritedWidget이 업데이트되었습니다.
• 우리는 setState를 호출했습니다

이것은 현재 Property 또는 onDispose 해결할 수 없습니다.

@esDotDev "요청된 가독성 및 견고성 이점"을 열거할 수 있습니까? 누군가가 이러한 가독성과 견고성 이점으로 AnimationController를 처리하는 제안을 하면 여기서 끝인가요?

@rrousselGit 나는 당신이 당신의 문제를 해결하지 못한다고 전에 말했듯이 Property를 옹호하는 것이 아닙니다. 그러나 누군가가 StreamBuilder가 하는 모든 작업을 수행하지만 들여쓰기가 없는 솔루션을 만들면 그게 될까요? 당신은 행복할까요?

그러나 누군가가 StreamBuilder가 하는 모든 작업을 수행하지만 들여쓰기가 없는 솔루션을 만들면 그게 될까요? 당신은 행복할까요?

대부분 그렇습니다.

물론 이 솔루션을 다른 솔루션과 비교해야 합니다. 그러나 그것은 수용 가능한 수준에 도달할 것입니다.

@esDotDev "요청된 가독성 및 견고성 이점"을 열거할 수 있습니까?

종속성 및 수명 주기에 대한 상용구를 완전히 캡슐화할 수 있다는 점에서 견고합니다. 즉. 나는 fetchUser에게 매번 id가 변경될 때 다시 빌드해야 한다고 말할 필요가 없으며 내부적으로 그렇게 하는 것을 알고 있습니다. Animation이 부모 위젯이 폐기될 때마다 스스로 폐기하도록 지시할 필요는 없습니다. (Property가 이 작업을 수행할 수 있는지 여부를 완전히 이해하지 못합니다) 이것은 개발자가 코드 기반 전체에서 반복적인 작업에 대한 실수를 저지르는 것을 방지합니다(현재 빌더를 사용하는 주요 이점 중 하나).

가독성은 들여쓰기되지 않은 한 줄의 코드로 상태 저장 항목을 얻을 수 있고 해당 항목에 대한 변수가 호이스트되고 명확하게 표시된다는 것입니다.

@esDotDev 누군가가 AnimationController를 이러한 가독성과 견고성 이점으로 처리하는 제안을 한다면 여기서 끝인가요?

구체적으로 AnimationController 번호를 의미한다면. AnimationController/FocusController/TextEditingController와 같은 객체를 의미한다면 그렇습니다.

명확하지 않은 정의된 수명이 있는 값을 반환하는 함수와 같은 API를 갖는 것은

이것은 중요한 오해라고 생각합니다. 후크의 수명은 정의에 따라 하위 상태이기 때문에 명확합니다. 그것들은 그것들을 "사용"하는 국가의 일생 동안 _항상_ 존재합니다. 실제로 더 명확할 수 없습니다. 구문이 이상하고 생소할 수 있지만 명확성이 부족한 것은 아닙니다.

TweenAnimationBuilder()의 수명도 명확합니다. 부모가 떠나면 사라집니다. 하위 위젯과 마찬가지로 하위 상태입니다. 그것들은 완전히 독립적인 상태 "구성 요소"이며, 쉽게 조합하고 재사용할 수 있으며, 버그가 아닌 기능이 선언된 상태에 자연스럽게 바인딩되기를 원하기 때문에 수명을 명시적으로 관리하지 않습니다.

@esDotDev

등

더 자세하게 얘기해 주 시겠어요? (이것이 내가 모든 기반을 다루는 데모 응용 프로그램을 제안한 이유입니다. 계속해서 이것이 가장 좋은 방법이라고 생각합니다.) 구성이 변경되어 자동으로 삭제되지 않는 한 초기화 프로그램을 호출하는 것 외에 중요한 기능이 있습니까? 호스트 요소가 삭제될 때 할당된 리소스?

TextEditingController와 유사한 객체

더 자세하게 얘기해 주 시겠어요? 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를 갖는 것과 동일한 제약 조건은

더 자세하게 얘기해 주 시겠어요? TextEditingController는 어떤 면에서 AnimationController보다 더 정교합니까?

아니요, 하지만 init/dispose에서 다른 작업을 수행하거나 다른 속성에 바인딩되며 특정 상용구를 캡슐화하고 싶습니다.

@esDotDev 그래서 빌더와 같은 것을 원하지만 들여쓰기 없이 한 줄로(아마도 빌더 콜백 자체 제외)? 내가 방금 게시한 예제(https://github.com/flutter/flutter/issues/51752#issuecomment-671004483)는 오늘날 빌더에서 그렇게 하므로 아마도 그 이상의 추가 제약이 있을 것입니다.

(FWIW, 빌더 또는 빌더와 같은 것이 아니라 한 줄에 있는 것이 좋은 솔루션이라고 생각하지 않습니다. 각 데이터 유형에 자체 빌더가 생성되어야 하기 때문입니다. 즉석에서 빌드하는 좋은 방법은 없습니다. .)

(FWIW, 빌더 또는 빌더와 같은 것이 아니라 한 줄에 있는 것이 좋은 솔루션이라고 생각하지 않습니다. 각 데이터 유형에 자체 빌더가 생성되어야 하기 때문입니다. 즉석에서 빌드하는 좋은 방법은 없습니다. .)

이게 무슨 뜻인지 이해가 되지 않습니다. 당신은 그것을 다시 말할 수 있습니까? 🙏

Animations용 ​​AnimationBuilder와 Streams용 StreamBuilder 등을 만들어야 합니다. 단일 빌더를 가지고 StatefulWidget을 생성할 때 "여기에 새 빌더를 얻는 방법, 폐기하는 방법, 데이터를 가져오는 방법이 있습니다"라고 말하는 대신.

그러나 이것이 다른 제약 조건을 위반한다고 생각합니다. 그렇기 때문에 문제를 해결하기 전에 문제에 대한 전체 설명이 우리 모두가 동의할 수 있는 것을 선호합니다.

나는 그것이 궁극적으로 여기의 목표인 읽을 수 있는 코드에 대한 요청을 분명히 위반한다고 생각합니다. 그렇지 않으면 우리 모두는 백만 개의 특정 유형의 빌더를 사용하고 영원히 중첩하고 하루라고 부릅니다.

나는 요청되는 것이 다음과 같다고 생각합니다.

Widget build(context) {
   var snapshot1 = get AsyncSnapshot<int>(stream1);
   var snapshot2 = get AsyncSnapshot<int>(stream2);
   return Column(children: [Text(snapshot1.data), Text(snapshot2.data)]);
}

이것이 모든 코드입니다. 스트림이 우리를 위해 생성되고, 스트림이 우리를 위해 폐기되고, 우리는 발을 들여놓을 수 없으며 코드가 훨씬 더 읽기 쉽습니다.

Animations용 ​​AnimationBuilder와 Streams용 StreamBuilder 등을 만들어야 합니다.

나는 그것을 문제로 보지 않는다. 우리는 이미 RestorableInt 대 RestorableString 대 RestorableDouble을 가지고 있습니다.

그리고 제네릭은 다음을 해결할 수 있습니다.

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)을 위반하는 것입니다. 즉, 빌드 메서드를 호출하는 동안 초기화 코드가 발생하지 않도록 보장합니다.

@rrousselGit

나는 그것을 문제로 보지 않는다. 우리는 이미 RestorableInt 대 RestorableString 대 RestorableDouble을 가지고 있습니다.

그리고 AnimationBuilder와 StreamBuilder 등이 있습니다. 그렇습니다. 두 경우 모두 불행합니다.

제네릭 빌더

그것은 내가 Property에 대해 제안한 것과 유사하지만, 거기에서 귀하의 우려 사항을 이해했다면 너무 장황하다고 생각한 것입니다.

이전에 누군가 StreamBuilder가 하는 모든 작업을 수행하지만 들여쓰기가 없는 솔루션을 만들면 만족할 것이라고 말했습니다. 내 시도에 대해 언급하지 않으셨습니다(https://github.com/flutter/flutter/issues/51752#issuecomment-671004483). 그 솔루션에 만족하십니까?

@esDotDev

요청되는 내용은 다음과 같습니다.

이는 다른 사람들이 나열한 꽤 합리적인 제약 조건(예: @Rudiksz)을 위반하는 것입니다. 즉, 빌드 메서드를 호출하는 동안 초기화 코드가 발생하지 않도록 보장합니다.

이 코드가 빌드에 있는 것은 중요하지 않습니다. 중요한 부분은

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는 Widget/State/life-cycles에 연결되어 있지 않으므로 이 패스_ ✅
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  _커스텀 빌더를 만들고 이 패턴을 사용할 수 있습니다. 그래서 이번 패스_. ✅
• 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  _아니요, 구문은 비교적 일관성이 있습니다_. ✅

1. 이 기능 IMO는 예를 들어 LayoutBuilder를 포함한 모든 빌더 위젯으로 확장될 수 있습니다.
2. 리스닝을 비활성화하는 방법이 필요합니다. 그래야 10x 컨트롤러를 생성하고 이를 리프에 전달하여 다시 빌드하거나 flutter가 빌더에서 얻은 값을 트리의 어느 부분에서 사용했는지 알 수 있어야 합니다.
3. 이것을 사용하는 것은 후크보다 훨씬 더 장황하지 않아야 합니다.
4. 이를 제대로 처리하려면 컴파일러를 확장해야 합니다.
5. 디버깅 도우미가 필요합니다. 이것을 사용하는 위젯 중 하나에 중단점을 넣었다고 가정해 보겠습니다. 빌드 메소드 내에서 중단점에 도달하면 빌더 중 하나가 트리거되었기 때문에 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)을 위반하는 것입니다. 즉, 빌드 메서드를 호출하는 동안 초기화 코드가 발생하지 않도록 보장합니다.

우리는 이미 *Builders를 사용하여 암시적으로 그렇게 하고 있습니다. 우리는 그것들을 들여 쓰기 위해 문법 설탕이 필요합니다. async/wait 및 future와 매우 유사하다고 생각합니다.

@esDotDev 설명하는 내용은 이전에 내가 Property로 제안한 내용과 매우 유사합니다(예: https://github.com/flutter/flutter/issues/51752#issuecomment-664787791 또는 https://github.com/flutter/flutter/ 참조). 문제/51752#issuecomment-667737471). 이러한 종류의 솔루션이 패키지로 생성되는 것을 방지하는 것이 있습니까? 즉, 이러한 종류의 기능을 사용할 수 있도록 하려면 핵심 프레임워크에서 어떤 변경을 해야 합니까?

@rrousselGit Shawn과 마찬가지로

그리드에 대한 문제는 지금까지 솔루션에 적용하면 얻을 수 있는 것과는 매우 다른 것으로 가정한다는 것입니다.

스테이트풀 위젯

• 결과 코드가 기본 구문보다 객관적으로 더 나은가요?
  
  
  
  • 실수를 피합니까?
    
    _기본 구문과 동일하며 특별히 오류가 발생하지 않습니다._ 🔷
  
  
  • 더 읽기 쉬운가요?
    
    _똑같아서 똑같이 가독성이 좋고 가독성이 좋습니다._ 🔷
  
  
  • 쓰기가 더 쉽나요?
    
    _똑같아서 똑같이 쓰기 쉽고, 적당히 쉽네요._ 🔷
  
  
• 코드는 얼마나 재사용할 수 있습니까?
  _재사용할 코드가 거의 없습니다._ ✅
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  _기본입니다._ 🔷
• 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  _그렇지 않은 것 같습니다._ ✅

속성에 대한 변형

• 결과 코드가 기본 구문보다 객관적으로 더 나은가요?
  
  
  
  • 실수를 피합니까?
    
    _코드를 다른 곳으로 옮기지만 특별히 실수를 줄이지는 않습니다._ 🔷
  
  
  • 더 읽기 쉬운가요?
    
    _초기화 코드와 정리 코드 및 기타 수명 주기 코드를 같은 위치에 두므로 명확하지 않습니다._ ❌
  
  
  • 쓰기가 더 쉽나요?
    
    _초기화 코드와 클린업 코드, 기타 라이프사이클 코드가 혼재되어 있어서 쓰기가 더 어렵습니다._ ❌
  
  
• 코드는 얼마나 재사용할 수 있습니까?
  _StatefulWidget만큼 정확히 재사용할 수 있으며 다른 장소에서도 사용할 수 있습니다._ ✅
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  _StatefulWidget에 대한 구문 설탕이므로 차이가 없습니다._ 🔷
• 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  _성능 및 메모리 사용량이 약간 저하됩니다._ ❌

빌더의 변형

• 결과 코드가 기본 구문보다 객관적으로 더 나은가요?
  
  
  
  • 실수를 피합니까?
    
    _기본적으로 StatefulWidget 솔루션이지만 제외되었습니다. 실수는 거의 동일해야합니다._ 🔷
  
  
  • 더 읽기 쉬운가요?
    
    _빌드 방법은 더 복잡하고 나머지 논리는 다른 위젯으로 이동하므로 거의 동일합니다._ 🔷
  
  
  • 쓰기가 더 쉽나요?
    
    _처음 작성하기(빌더 위젯 만들기)가 더 어렵고 그 이후에는 약간 더 쉬워지므로 거의 동일합니다._ 🔷
  
  
• 코드는 얼마나 재사용할 수 있습니까?
  _StatefulWidget만큼 정확히 재사용할 수 있으며 다른 장소에서도 사용할 수 있습니다._ ✅
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  _ 이것은 StatefulWidget의 구문 설탕이므로 대부분 차이가 없습니다. 어떤 측면에서는 실제로 더 좋습니다. 예를 들어 종속성 변경을 처리할 때 실행해야 하는 코드의 양이 줄어듭니다._ ✅
• 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  _그렇지 않은 것 같습니다._ ✅

후크와 같은 솔루션

• 결과 코드가 기본 구문보다 객관적으로 더 나은가요?
  
  
  
  • 실수를 피합니까?
    
    _잘못된 패턴(예: 빌드 메서드의 구성)을 조장하고 조건문과 함께 실수로 사용하면 버그가 발생할 위험이 있습니다._ ❌
  
  
  • 더 읽기 쉬운가요?
    
    _빌드 방법을 이해하기 위해 알아야 할 개념의 수를 늘립니다._ ❌
  
  
  • 쓰기가 더 쉽나요?
    
    _개발자는 새로운 개념의 hook을 작성하는 법을 배워야 하므로 더 어렵습니다._ ❌
  
  
• 코드는 얼마나 재사용할 수 있습니까?
  _StatefulWidget만큼 정확히 재사용할 수 있으며 다른 장소에서도 사용할 수 있습니다._ ✅
• 이 API로 얼마나 많은 문제를 해결할 수 있습니까?
  _StatefulWidget에 대한 구문 설탕이므로 차이가 없습니다._ 🔷
• 일부 특정 문제로 인해 일부 혜택을 잃게 됩니까?
  _성능 및 메모리 사용량이 저하됩니다._ ❌

왜 우리가 계속 장황하게 돌아가는지 이해가 되지 않습니다.
나는 그것이 문제가 아니며 문제는 재사용성 대 가독성 대 유연성이라고 여러 번 명시적으로 말했습니다.

죄송합니다. 속성이 너무 장황하다고 말한 사람이 누구인지 잘못 기억했습니다. 네 말이 맞아, 당신의 우려는 이전에 나열되지 않은 새로운 사용 사례가 있어서 처리하지 못했다는 것입니다. 하지만 Property를 확장하여 해당 사용 사례도 처리하는 것은 사소한 일이라고 생각합니다(나는 시도하지 않았지만 요구 사항이 조정될 때 반복적으로 반복해야 하는 것보다 문제를 한 번에 해결할 수 있도록 명확한 데모 앱이 나올 때까지 기다리는 것이 더 나은 것 같습니다.

@szotp

1. 이 기능 IMO는 예를 들어 LayoutBuilder를 포함한 모든 빌더 위젯으로 확장될 수 있습니다.

LayoutBuilder는 대부분의 빌더인 FWIW와는 매우 다른 위젯입니다. 지금까지 논의된 제안 중 어느 것도 LayoutBuilder와 유사한 문제에 대해 작동하지 않으며 귀하의 의견 전에 설명된 요구 사항에는 LayoutBuilder가 포함되어 있지 않습니다. 이 새로운 기능을 사용하여 LayoutBuilder를 처리해야 하는지도 알아야 합니다. @TimWhiting 과

1. 리스닝을 비활성화하는 방법이 필요합니다. 그래야 10x 컨트롤러를 생성하고 이를 리프에 전달하여 다시 빌드하거나 flutter가 빌더에서 얻은 값을 트리의 어느 부분에서 사용했는지 알 수 있어야 합니다.

이것이 정확히 무엇을 의미하는지 잘 모르겠습니다. 내가 말할 수 있는 한 오늘은 리스너와 빌더를 사용하여 이 작업을 수행할 수 있습니다(예: 정확히 이 작업을 수행하기 위해 앞서 인용한 앱에서 ValueListenableBuilder를 사용합니다).

이는 다른 사람들이 나열한 꽤 합리적인 제약 조건(예: @Rudiksz)을 위반하는 것입니다. 즉, 빌드 메서드를 호출하는 동안 초기화 코드가 발생하지 않도록 보장합니다.

우리는 이미 *Builders를 사용하여 암시적으로 그렇게 하고 있습니다.

정확하지 않다고 생각합니다. 빌더에 따라 다르지만 일부는 initState, didChangeDependencies, didUpdateWidget 및 빌드 로직을 분리하기 위해 매우 열심히 일하므로 최소한의 코드만 변경된 사항을 기반으로 각 빌드를 실행하면 됩니다. 예를 들어, ValueListenableBuilder는 처음 생성될 때만 리스너를 등록하며, 해당 빌더는 상위 또는 빌더 재실행의 initState 없이 재실행될 수 있습니다. 이것은 Hooks가 할 수 있는 일이 아닙니다.

@esDotDev 당신이 설명하는 것은 내가 이전에 Property로 제안한 것과 매우 유사하게 들립니다( 예: #51752(comment) 참조 ).

내가 올바르게 이해한다면, UserId에 대한 DidDependancyChange 또는 AnimationProperty 또는 해당 유형에 대한 init/update/dispose를 처리하는 데 필요한 다른 속성을 자동으로 처리하는 UserProperty 를 만들 수 있습니까? 그러면 이것은 나에게 좋은 것 같습니다. 가장 일반적인 사용 사례를 빠르게 만들 수 있습니다.

나를 실망시키는 유일한 것은 여기 미래의 건축가입니다. 하지만 이것은 단지 당신이 선택한 예 때문이라고 생각합니까?

예를 들어 이것을 만들 수 있습니까?

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()해야 하는 것은 버그와 인지 부하로 이어집니다.

개발자가 두 번 생각할 필요 없이 적절한 didUpdate 및 dispose 및 debugFillProperties 및 전체 작동과 함께 애니메이터를 사용할 수 있다면 좋을 것입니다. 모든 개발자는 Animator를 수동으로 관리하는 것보다 기본적으로 사용합니다.

그렇다면 이것은 완전히 LGTM입니다! 프레임워크에 추가한다는 점에서 1급 구문 접근 방식으로 승격되어야 하는지(1년 정도면 일반 관행이 됨을 의미함), 아니면 개발자의 한 자리 수 비율이 플러그인으로 존재하는지 여부입니다. 사용하다.

Property 가 얼마나 사소한지 감안할 때, 그 스타일을 좋아하는 사람에게 추천하는 것은 자신만의 코드를 만들고(도움이된다면 내 코드로 시작하는 것일 수도 있음) 적절하다고 생각하는 대로 앱에서 직접 사용하고 조정하는 것입니다. 그들의 필요를 해결하기 위해. 많은 사람들이 좋아한다면 패키지로 만들 수도 있지만 사소한 일에 대해서는 코드에 복사하고 필요에 따라 조정하는 것이 얼마나 유익한지 명확하지 않습니다.

나를 실망시키는 유일한 것은 여기 미래의 건축가입니다. 하지만 이것은 단지 당신이 선택한 예 때문이라고 생각합니까?

@rrousselGit이 제공한 예제를

예를 들어 이것을 만들 수 있습니까?

AnimationController 생성자를 매번 호출하는 대신 호출되는 클로저로 옮기고 싶을 것입니다. 왜냐하면 initProperties 는 새로운 클로저를 얻기 위해 핫 리로드 중에 호출되지만 일반적으로 생성하고 싶지 않기 때문입니다. 핫 리로드 중 새 컨트롤러(예: 애니메이션을 재설정함). 하지만 네, 그 외에는 괜찮은 것 같습니다. 당신은 할 수있는 AnimationControllerProperty 소요 AnimationController 생성자 인자를 그들과 함께 올바른 일을 (가 변경되었을 경우는 예를 들어 뜨거운 다시로드에 시간을 업데이트).

개발자가 두 번 생각할 필요 없이 적절한 didUpdate 및 dispose 및 debugFillProperties 및 전체 작동과 함께 애니메이터를 사용할 수 있다면 좋을 것입니다. 모든 개발자는 Animator를 수동으로 관리하는 것보다 기본적으로 사용합니다.

개발자가 그것에 대해 생각하지 않는 것에 대한 나의 걱정은 할당 및 폐기 시점에 대해 생각하지 않으면 항상 필요하지 않은 많은 것을 할당하거나 그렇지 않은 논리를 실행하게 될 가능성이 더 높다는 것입니다. 실행해야 하거나 덜 효율적인 코드로 이어지는 다른 작업을 수행해야 합니다. 이것이 내가 이것을 기본 권장 스타일로 만들기를 꺼리는 이유 중 하나입니다.

AnimationController 생성자 인수를 사용하여 올바른 작업을 수행하는 AnimationControllerProperty를 만들 수도 있습니다(예: 변경되는 경우 핫 리로드 시 지속 시간 업데이트).

@Hixie 감사합니다. 정말 멋지고 문제를 잘 해결한 것 같습니다.

개발자가 이러한 것에 대해 생각해서는 안 된다고 제안하는 것은 아니지만 99% 사용 사례는 거의 항상 사용되는 StatefulWidget에 바인딩되어 있고 그 이외의 다른 작업을 수행하면 이미 중간 개발자 영역으로 이동하고 있다고 생각합니다.

다시 말하지만 이것이 원시 AnimatorController보다 TweenAnimationBuilder를 권장하는 것과 근본적으로 어떻게 다른지 모르겠습니다. 그것은 기본적으로이 다른 상태에서 관리 상태 지분을 포함을 / 원하는 (그리고 당신이 원하는 보통) 경우, 다음이 방법은 간단하고 강력한을 할 수 있다는 생각이다.

이 시점에서 우리는 통화를 조직하고 다양한 이해 관계자와 함께 논의해야 합니다.
같은 질문에 계속해서 답하고 있기 때문에 이 토론이 진행되지 않고 있습니다.

나는 그렇게 긴 토론과 많은 논쟁 끝에 어떻게 StatefulWidget에 비해 빌더가 실수를 피하지 않거나 후크가 원시 StatefulWidget보다 더 재사용 가능하지 않다고 주장할 수 있는지 이해하지 못합니다.

모든 주요 선언적 프레임워크(React, Vue, Swift UI, Jetpack Compose)에 이 문제를 기본적으로 해결할 수 있는 방법이 있다는 점을 고려하면 특히 실망스럽습니다.
Flutter만이 이 문제를 고려하지 않는 것 같습니다.

@esDotDev IMHO가 AnimationBuilder, TweenAnimationBuilder 또는 ValueListenableBuilder를 사용하는 주된 이유는 호스트 위젯의 나머지 부분을 다시 빌드하지 않고 값이 변경될 때만 다시 빌드하기 때문입니다. 성능 문제입니다. 자세한 정보나 코드 재사용에 관한 것이 아닙니다. 내 말은, 그러한 이유로 그것들을 사용하는 것도 괜찮습니다. 그러한 이유로 유용하다고 생각한다면 적어도 저에게는 그것이 주요 사용 사례가 아닙니다. 또한 Property(또는 Hooks)가 제공하지 않는 것입니다. 그것들을 사용하면 무언가가 변경될 때 _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.

흥미로운. 우리는 실제로 이와 같은 소규모 재구축을 저장함으로써 성능 향상을 측정하거나 관찰한 적이 없습니다. 2주마다 수백 개의 클래스 파일을 제거할 때 발생할 수 있는 일상적인 오류 없이 코드를 간결하고 가독성 있게 유지하는 것이 대규모 앱 코드 기반보다 훨씬 더 중요합니다.

RepaintBoundaries를 의도적으로 정의하지 않는 한 전체 트리에 발생하는 것으로 보이는 픽셀 다시 그리기 비용은 부분 위젯 레이아웃 비용보다 실제 성능에서 훨씬 더 중요한 요소입니다. 특히 4k 모니터 범위에 들어갈 때.

그러나 이것은 건축업자가 실제로 이런 종류의 일을 이해하는 좋은 예입니다. 하위 컨텍스트를 만들고 싶다면 빌더가 의미가 있으며 거기에 도달하는 좋은 방법입니다.

우리는 그렇게 하지 않는 경우가 많습니다. 이 경우 Builder는 클러터를 추가할 뿐이지만 대안은 다른 유형의 클러터일 뿐이므로 허용합니다. 적어도 Builder에서는 버그가 거의 없음이 보장됩니다. 전체 보기가 다시 빌드되거나 반드시 보기를 다시 빌드할 필요가 전혀 없는 경우(TextEditingController, FocusController) 빌더를 사용하는 것은 거의 의미가 없으며 모든 경우에 상용구를 손으로 굴리는 것은 기본적으로 DRY가 아닙니다.

성능 문제가 자주 발생하므로 확실히 상황에 따라 다릅니다. 나는 사람들이 그런 스타일을 좋아한다면 Hooks나 Property 같은 것을 사용하는 것이 합리적이라고 생각합니다. 그것은 오늘날 가능하며 프레임워크에서 추가로 필요한 것이 없는 것 같습니다(그리고 Property에서 알 수 있듯이 실제로 많은 코드가 필요하지 않습니다).

아니요, 하지만 커뮤니티에 TweenAnimationBuilder 및 ValueListenableBuilder를 빌드하도록 요청하고 빌드할 StatefulWidget을 제공하지 않는 것과 같습니다.

당신이 묻는 것은 아니지만 이러한 유형의 아키텍처의 주요 이점 중 하나는 쉽게 공유할 수 있는 아주 작은 구성 요소에 자연스럽게 적합하다는 것입니다. 작은 기초 조각을 제자리에 배치하면 ...

StatefulWidget은 Property에 비해 _lot_ 많은 코드이며 중요하지 않습니다(대부분 글루 코드인 Property와 달리). 즉, Property가 광범위하게 재사용할 수 있는 것이라면(정확한 필요에 따라 각 응용 프로그램이나 팀에 대한 맞춤형 버전을 만드는 것과는 대조적으로), 나는 그 사용을 옹호하는 누군가에게 패키지를 만들어 업로드하도록 권장합니다. pub . 실제로 Hooks에도 동일하게 적용됩니다. 커뮤니티가 좋아하는 것이라면 Provider와 마찬가지로 많이 사용됩니다. 프레임워크 자체에 그런 것을 넣어야 하는 이유는 명확하지 않습니다.

이것은 본질적으로 확장 가능하기 때문이라고 생각합니다. 공급자는 아닙니다. 단순한 도구일 뿐입니다. 이것은 StatefulWidget과 마찬가지로 StatefulComponent를 위해 확장되도록 만들어진 것입니다. 상대적으로 사소하다는 사실이 반드시 반대되어야 하는 것 아닌가?

"이 스타일을 선호하는 사람들"에 대한 메모. 3개의 재정의와 15-30줄을 저장할 수 있다면 대부분의 경우 가독성이 향상될 것입니다. 객관적으로 말하자면. 또한 객관적으로 2가지 전체 오류 클래스를 제거합니다(사물 처리를 잊거나 deps 업데이트를 잊음).

멋진 토론에 대해 정말 감사합니다. 이것이 어디로 가는지 보고 흥분됩니다. 저는 확실히 여기에 남길 것입니다. :)

이 스레드가 내가 작업 중인 다른 프로젝트를 마칠 때 계획했던 플러터에 다시 빠져드는 것을 환멸스럽게 만든다고 말하는 것을 유감스럽게 생각합니다. 때문에 좌절도 느낀다.

모든 주요 선언적 프레임워크(React, Vue, Swift UI, Jetpack Compose)에 이 문제를 기본적으로 해결할 수 있는 방법이 있다는 점을 고려하면 특히 실망스럽습니다.

이 스레드에서 문제가 반복해서 명확하게 설명되었기 때문에 Flutter 예제 앱을 구축하는 데 시간을 할애해서는 안 된다고 생각한다는 점에서
또한 앱을 작성하려면 솔루션이 필요하기 때문에 솔루션을 찾고 있다면 플러터로 앱을 작성할 수 없습니다. 이 대화의 플러터 사람들은 최소한 후크를 좋아하지 않는다는 것이 꽤 분명했습니다. 그리고 Flutter에는 OP에 설명된 대로 문제에 대한 다른 솔루션이 없습니다. 어떻게 작성해야합니다.

(적어도 나에게는) 이것이 심각하게 받아들여지지 않는다고 생각합니다. @Hixie 죄송합니다. We understand the problem and want to solve it 의미에서 심각하게 받아들이지 않는다는 뜻입니다. 다른 선언적 프레임워크와 마찬가지로 분명히 완료된 것 같습니다.
또 다른 종류의 동일한 메모에 다음과 같은 내용이 있습니다.

쓰기가 더 쉽나요?
개발자는 새로운 개념인 후크를 작성하는 법을 배워야 하므로 더 어렵습니다.

나를 슬프게 만들어. 왜 개선하거나 변경합니까? 당신은 무슨 일이 있어도 항상 그 주장을 할 수 있습니다. 새로운 솔루션이 한 번 배우면 훨씬 쉽고 즐겁더라도. 해당 명령문의 후크를 많은 것으로 대체할 수 있습니다. 우리 엄마는 30년 전에 전자레인지에 대해 그런 말을 사용했을 수 있습니다. 예를 들어 문장에서 "hooks"를 "flutter" 또는 "dart"로 바꾸면 동일하게 작동합니다.

쓰기가 더 쉽나요?
똑같으니 쓰기도 쉽네요.

is it easier to write? (부울 답변 질문)에서 @rrousselGit이 의미하는 바는 동일하다면 대답이 false / undefined 가 아니라는 것입니다.

나는 우리가 문제가 있다는 것에 동의하지도 않고 단지 많은 사람들이 이것을 문제로 여긴다는 사실에 동의하지 않기 때문에 어떻게 우리가 어딘가에 도달할 수 있을지 알 수 없습니다. 예:

그것은 확실히 사람들이 제기한 것입니다. 그것은 내가 본능적으로 경험한 것이 아닙니다. Flutter로 내 자신의 앱을 작성할 때 문제라고 느낀 것은 아닙니다. 그렇다고 해서 일부 사람들에게 실제 문제가 되지 않는다는 의미는 아닙니다.

그리고 많은 사람들이 OP에 대한 솔루션이 핵심에 있어야 하는 이유에 대해 여러 번 많은 주장을 했음에도 불구하고.
예를 들어, 제3자가 오늘날 위젯을 사용하고 생성하는 것처럼 쉽고 자연스럽게 사용할 수 있도록 하려면 핵심이 되어야 합니다. 그리고 다른 여러 이유. 만트라는 패키지에 넣는 것뿐인 것 같습니다. 그러나 이미 후크와 같은 패키지가 있습니다. 그것이 해결 된 것이라면 스레드를 닫으십시오.

@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를 자세히 살펴보지 않았다는 인상을 받고 있습니다. 그렇지 않으면 우리의 우려가 이해하기 쉬울 것이라고 생각합니다.

저는 스위프트 UI를 공부했습니다. Flutter 코드보다 Swift UI 코드를 작성하는 것이 확실히 덜 장황하지만 가독성 비용은 IMHO가 매우 높습니다. "마법"(소비자 코드에서 명확하지 않은 방식으로 작동하는 논리라는 의미에서)이 많이 있습니다. 일부 사람들이 선호하는 스타일이라고 전적으로 믿을 수 있지만 Flutter의 장점 중 하나는 마술이 거의 없다는 것입니다. 이는 때때로 더 많은 코드를 작성한다는 것을 의미하지만, 또한 해당 코드를 디버깅하는 것이 _훨씬_ 더 쉽다는 것을 의미합니다.

많은 스타일의 프레임워크를 위한 여지가 있다고 생각합니다. MVC 스타일, React 스타일, 매우 간결한 마술, 마술이 필요 없지만 장황한... Flutter 아키텍처의 장점 중 하나는 이식성 측면이 프레임워크 자체와 완전히 분리되어 있으므로 모든 도구를 활용할 수 있다는 것입니다. -- 크로스 플랫폼 지원, 핫 리로드 등 -- 완전히 새로운 프레임워크를 만듭니다. (예: flutter_sprites와 같은 다른 Flutter 프레임워크가 이미 있습니다.) 마찬가지로 프레임워크 자체도 레이어 방식으로 설계되어 있어 예를 들어 모든 RenderObject 로직을 재사용할 수 있지만 위젯 레이어를 대체할 수 있습니다. 위젯이 너무 많습니다. 누군가 이를 대체할 대체 프레임워크를 만들 수 있습니다. 물론 패키징 시스템이 있으므로 기존 프레임워크 코드를 잃지 않고 기능을 추가할 수 있습니다.

여하튼, 여기에서 내 소심의 요점은 이것이 전부 아니면 전무가 아니라는 것입니다. 장기적으로 우리가 당신을 행복하게 하는 솔루션을 채택하지 않더라도, 그것이 당신이 좋아하는 제품의 일부로부터 계속 혜택을 받을 수 없다는 것을 의미하지는 않습니다.

이 문제에 관심이 있는 사람들은 @TimWhiting 과 불가능할 때 오늘날의 모습을 보여주는 앱을 만들 것을 촉구합니다(https://github.com/TimWhiting/local_widget_state_approaches). 이것은 여기에 댓글을 달고 있는 _모든__ 사람들(Hooks를 좋아하는 사람들과 Hooks를 좋아하지 않는 사람들 포함)의 요구를 해결하는 방식으로 이 문제를 해결하는 방법에 대한 제안을 만드는 데 직접적인 도움이 될 것입니다.

"_빌더를 평면화하고 빌더가 구현되는 방법에 신경 쓰지 않는 구문 설탕._"이 개발자가 일급 기능으로 원하는 이유를 이해하는 것은 정말 어렵지 않습니다. 우리는 대체 접근 방식의 문제를 계속해서 설명했습니다.

간단히 말해서 빌더는 재사용성 문제를 해결하지만 읽고 작성하기가 어렵습니다. "문제"는 단순히 우리가 훨씬 더 읽기 쉬운 빌더와 유사한 기능을 원한다는 것입니다.

3개의 중첩된 빌더가 읽기 어렵거나 일반적으로 빌더가 실제로 코드 재사용 목적을 수행하지 않는다는 데 근본적으로 동의하지 않는다면 앱이 이를 더 명확하게 보여줄 수 없습니다. 우리 중 많은 사람들이 실제로 중첩을 줄이는 것을 좋아하고 애플리케이션 전체에 코드를 복제하는 것을 좋아하지 않는다는 사실을 듣는 것이 더 중요합니다. 그래서 우리는 2가지 비이상적인 옵션 사이에 갇혀 있습니다.

이 문제를 고려하고 가능한 솔루션을 설명하고 우리가 해결하려고 하는 것을 정확하게 도출하려고 노력하면서 이번 주말에 말 그대로 몇 시간을 보냈습니다.

나는 그것에 대해 감사합니다

이해의 부족과 고려를 거부하는 문제를 혼동하지 마십시오.

이해가 부족해도 괜찮지만 현재 상황은 희망이 없어 보입니다.
우리는 토론의 맨 처음에 만들어진 요점에 대해 여전히 토론하고 있습니다.

내 관점에서, 나는 다른 문제를 보여주고 질문에 답하는 상세한 설명을 작성하는 데 몇 시간을 보낸 것처럼 느껴지지만 내 의견은 무시되고 같은 질문이 다시 질문되었습니다.

예를 들어, 현재 구문의 가독성 부족이 논의의 중심에 있습니다.
이를 뒷받침하기 위해 가독성 문제에 대해 몇 가지 분석을 했습니다.

• https://github.com/flutter/flutter/issues/51752#issuecomment -669626522
• https://github.com/flutter/flutter/issues/51752#issuecomment -670959424

이러한 분석에는 상당한 수의 👍가 있고 다른 사람들도 동의하는 것 같습니다.

그러나 최근 답변에 따르면 가독성 문제가 없습니다. https://github.com/flutter/flutter/issues/51752#issuecomment -671009593

또한 다음을 제안했습니다.

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 감사합니다. 이것은 귀하의 관점을 이해하는 데 많은 도움이 됩니다. 나는 그들이 코드 마술로 너무 지나쳤을 수 있다는 데 동의하지만 적어도 그들이 옳았던 것은 몇 가지 있다고 확신합니다.

그리고 저는 Flutter의 계층화된 아키텍처를 매우 좋아합니다. 위젯을 계속 사용하고 싶습니다. 따라서 아마도 대답은 Dart & Flutter의 확장성을 개선하는 것입니다. 저에게 다음은 다음과 같습니다.

코드 생성을 보다 원활하게 하세요. Dart에서 SwiftUI 마법을 구현하는 것이 가능할 수도 있지만 필요한 일반적인 설정은 너무 크고 너무 느립니다.

코드 생성을 사용하는 것이 패키지를 가져오고 일부 주석을 두드리는 것처럼 간단하다면 논의된 문제가 있는 사람들은 그렇게 하고 불평을 멈출 것입니다. 나머지는 계속해서 좋은 오래된 StatefulWidget을 직접 사용합니다.

편집: flutter generate 는 좋은 방향으로 나아가는 단계라고 생각합니다. 제거된 것은 부끄러운 일입니다.

다음 Flutter 개발자 설문조사에서 이것이 매우 흥미로운 질문이 될 것이라고 생각합니다.

좋은 시작이 될 것입니다. 이 문제를 다른 부분/질문으로 나누고 이것이 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');
            },
          );
        },
      );
    },
  );
}

이 코드는 읽을 수 없습니다.

나는 그것에 대해 읽을 수없는 것을 정말로 보지 못합니다. 무슨 일이 일어나고 있는지 정확하게 설명합니다. 네 개의 위젯이 있습니다. 세 개의 위젯에는 빌더 메소드가 있고, 하나는 문자열만 있습니다. 저는 개인적으로 유형을 생략하지 않을 것입니다. 변수가 모두 무엇인지 알 수 없기 때문에 읽기가 더 어려울 것이라고 생각하지만 큰 문제는 아닙니다.

읽을 수 없는 이유는 무엇입니까?

분명히 말씀드리자면, 당신은 그것을 읽을 수 없다고 생각합니다. 나는 당신이 틀렸다고 말하려는 것이 아닙니다. 왜 그런지 이해가 안됩니다.

구문을 다음과 같이 변경하는 새 키워드를 도입하여 가독성 문제를 해결할 수 있습니다.

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를 다시 빌드합니다. ; 또한 초기화 논리는 이제 모든 빌드를 입력하고 건너뛰어야 합니다.)

당신은 장황한 것이 문제가 아니라고 말했으므로 더 간결하다고 해서 더 읽기 쉬운 것은 아닙니다. 제 생각에는 (당신이 문제 제목에 "너무 장황하다"를 입력했기 때문에 저도 이것에 대해 혼란스럽긴 하지만 문제의 원래 설명). 들여쓰기를 덜 하고 싶다고 말씀하셨지만, 들여쓰기 없이 빌더를 사용하는 버전도 읽을 수 없다고 설명하셨으니, 아마도 원본의 들여쓰기가 문제가 아닐 것입니다.

빌더가 재사용성의 정점이고 대체 구문을 원하지만 제안한 제안은 빌더와 같지 않으므로(위젯이나 요소를 생성하지 않음) 빌더 측면이 특별히 중요하지 않습니다. 를 찾고 있습니다.

내가 말할 수 있는 한 훌륭하게 작동하는 (Hooks) 솔루션이 있지만 사람들이 Hooks를 사용할 수 있도록 프레임워크에서 무언가를 변경하고 싶습니까? 사람들이 Hooks를 패키지로 사용할 만큼 충분히 좋아하지 않는다면 프레임워크에도 좋은 솔루션이 아닐 수도 있습니다. Flutter 팀은 가치 있는 것을 만듭니다.

더 쉬운 코드 재사용에 대한 욕구가 있다는 것을 이해합니다. 그게 무슨 뜻인지 모르겠어요.

다음은 위의 두 버전과 가독성 면에서 어떻게 비교됩니까?

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 여기에 사람들이 해결하기를 원하는 실제 문제가 있다는 데는 의심의 여지가 없다고 생각합니다. 저에게 질문은 바로 그 문제가 무엇인지 입니다. 그래서 우리는 솔루션을 설계할 수 있습니다.

후크 결함에 대한 우려나 코드에 포함되기를 원하는 것에 대한 우려에 답할 수는 있지만 지금은 그것이 우리가 집중해야 하는 부분이라고 생각하지 않습니다.

우리는 먼저 문제가 무엇인지에 동의해야 합니다. 그렇지 않다면 다른 주제에 대해 어떻게 동의할 수 있을지 모르겠습니다.

나는 그것에 대해 읽을 수없는 것을 정말로 보지 못합니다. 무슨 일이 일어나고 있는지 정확하게 설명합니다. 네 개의 위젯이 있습니다. 세 개의 위젯에는 빌더 메소드가 있고, 하나는 문자열만 있습니다. 저는 개인적으로 유형을 생략하지 않을 것입니다. 변수가 모두 무엇인지 알 수 없기 때문에 읽기가 더 어려울 것이라고 생각하지만 큰 문제는 아닙니다.

여기서 문제의 큰 부분은 코딩 방식이 대부분의 사람들이 코딩하는 방식과 크게 다르다는 것입니다.

예를 들어 Flutter와 귀하가 제공한 앱 예제는 다음과 같습니다.

• dartfmt를 사용하지 마십시오
• always_specify_types 사용

이 두 가지 포인트만으로 커뮤니티의 1% 이상을 대표한다면 놀랄 것입니다.

따라서 당신이 읽을 수 있다고 평가하는 것은 대부분의 사람들이 읽을 수 있다고 생각하는 것과는 매우 다를 수 있습니다.

나는 그것에 대해 읽을 수없는 것을 정말로 보지 못합니다. 무슨 일이 일어나고 있는지 정확하게 설명합니다. 네 개의 위젯이 있습니다. 세 개의 위젯에는 빌더 메소드가 있고, 하나는 문자열만 있습니다. 저는 개인적으로 유형을 생략하지 않을 것입니다. 변수가 모두 무엇인지 알 수 없기 때문에 읽기가 더 어려울 것이라고 생각하지만 큰 문제는 아닙니다.

읽을 수 없는 이유는 무엇입니까?

내 추천은 특정 항목을 검색할 때 눈이 보고 있는 위치와 거기에 도달하는 데 얼마나 많은 단계가 필요한지 분석하는 것입니다.

실험을 해보자:
두 개의 위젯 트리를 제공하겠습니다. 하나는 선형 구문을 사용하고 다른 하나는 중첩 구문을 사용합니다.
또한 해당 스 니펫에서 찾아야 할 특정 사항을 알려 드리겠습니다.

선형 구문 또는 중첩 구문 사용에 대한 답을 찾는 것이 더 쉽습니까?

질문:

• 이 빌드 메소드에서 반환된 비빌더 위젯은 무엇입니까?
• bar 변수는 누가 생성합니까?
• 우리는 몇 명의 건축업자를 가지고 있습니까?

빌더 사용:

 위젯 빌드(컨텍스트) {
 ValueListenableBuilder 반환(
 valueListenable: someValueListenable,
 빌더: (context, foo, _) {
 스트림 빌더를 반환(
 스트림: someStream,
 빌더: (컨텍스트, baz) {
 TweenAnimationBuilder 반환(
 트윈: 트윈(...),
 빌더: (컨텍스트, 바) {
 반환 Container();
 },
 );
 },
 );
 },
 );
 }

 위젯 빌드(컨텍스트) {
 최종 foo = 키워드 ValueListenableBuilder(valueListenable: someValueListenable);
 최종 막대 = 키워드 StreamBuilder(스트림: someStream);
 최종 baz = 키워드 TweenAnimationBuilder(tween: Tween(...));

 반환 이미지();
 }

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

읽을 수 없는 이유는 무엇입니까?

중첩으로 인해 중첩을 사용하면 빠르게 스캔하고 무시할 수 있는 부분과 진행 중인 작업을 이해하는 데 필수적인 부분을 파악하기가 더 어려워집니다. 코드는 본질적으로 "순차적"이지만 중첩은 이를 숨깁니다. 또한 중첩은 작업을 어렵게 만듭니다. 두 항목을 재정렬하거나 두 항목 사이에 새 항목을 삽입하고 싶다고 상상해보세요. 순차 코드에서는 사소하지만 중첩 작업이 필요할 때는 어렵습니다.

이것은 async/await 설탕과 원시 Future API로 작업하는 것과 매우 유사하며, 아래에 있는 dame 연속 기반 개념(그리고 찬성 및 반대 인수도 매우 유사함) - 예 Future API는 직접 사용할 수 있으며 아무 것도 숨기지 않지만 가독성 및 유지 관리 용이성 확실히 좋지 않습니다. async/wait가 승자입니다.

내 추천은 특정 항목을 검색할 때 눈이 보고 있는 위치와 거기에 도달하는 데 얼마나 많은 단계가 필요한지 분석하는 것입니다.

저는 25년 동안 10개 이상의 다른 언어로 프로그래밍을 해왔으며, 이는 코드를 가독성 있게 만드는 요소를 평가하는 가장 나쁜 방법입니다. 소스 코드의 가독성은 까다롭지만 "내 눈이 보는 곳"이나 사용하는 코드 줄 수보다 프로그래밍 개념과 논리를 얼마나 잘 표현하느냐가 더 중요합니다.

또는 오히려 가독성에 너무 집중하고 유지 관리에 덜 집중하는 것 같습니다.

코드의 __intent__가 덜 명확하고 동일한 위치에 숨겨진 다른 관심사로 인해 유지 관리가 더 어려워지기 때문에 예제는 덜 읽기 쉽습니다.

final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);

그 가치는 얼마나 될까요? 위젯? 문자열 변수? 내부에서 사용한다고 합니다
return Text('$value $value2 $value3');

기본적으로 원하는 것은 위젯 B의 빌드 메서드에서 변수 A를 참조하여 A 값이 변경될 때마다 B가 다시 빌드되도록 하는 것입니다. 그것이 말 그대로 mobx가 하는 일이며, 적절한 양의 마법/보일러 플레이트로 정확하게 수행합니다.

final value2 = keyword StreamBuilder(stream: someStream);

이것은 무엇을 반환해야합니까? 위젯? 스트림? 문자열 값?

다시 말하지만, 그것은 문자열 값처럼 보입니다. 당신은 단순히 위젯 스트림이 값을 방출 할 때마다 다시 것을, 빌드 방법에 원인을 스트림을 참조하고 방출 값에 액세스 할 수 있으며 위젯이 생성 될 때마다 스트림의 / 갱신 / 폐기를 만들 수 있기를 원하는 그래서 / 업데이트 /파괴됨? 한 줄의 코드로? 빌드 메소드 내부?

예, 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;

둘 다 똑같은 일을 합니다. 즉, 객체를 듣고 값을 언래핑합니다.

나는 그것에 대해 읽을 수없는 것을 정말로 보지 못합니다. 무슨 일이 일어나고 있는지 정확하게 설명합니다. 네 개의 위젯이 있습니다. 세 개의 위젯에는 빌더 메소드가 있고, 하나는 문자열만 있습니다. 저는 개인적으로 유형을 생략하지 않을 것입니다. 변수가 모두 무엇인지 알 수 없기 때문에 읽기가 더 어려울 것이라고 생각하지만 큰 문제는 아닙니다.

동일한 주장이 Promise/Future 체인에 적용될 수 있습니다.

foo().then(x =>
  bar(x).then(y =>
    baz(y).then(z =>
      qux(z)
    )
  )
)

대

let x = await foo();
let y = await bar(x);
let z = await baz(y);
await qux(z);

첫 번째 작성 방법은 Promise가 후드 아래에서 생성되고 있으며 체인이 정확히 어떻게 형성되는지를 명확히 해준다고 말할 수 있습니다. 나는 당신이 그것을 구독하는지, 또는 당신이 구문을받을 자격이 있다는 점에서 약속이 빌더와 근본적으로 다르다고 생각하는지 궁금합니다.

문자열을 반환하는 "TweenAnimationBuilder"라는 클래스?! 나는 이것이 왜 끔찍한 생각인지 가까이 가지도 않습니다.

Promises/Futures에 대해 동일한 주장을 하고 await 가 Promise를 반환한다는 사실을 모호하게 한다고 말할 수 있습니다.

구문을 통해 사물을 "풀기"한다는 아이디어는 거의 새로운 것이 아닙니다. 예, 주류 언어에서는 async/await를 통해 제공되었지만, 예를 들어 F#에는 일부 하드코어 FP 언어의 do 표기법과 유사한 계산 표현식이 있습니다. 거기에서 훨씬 더 많은 권한을 가지며 특정 법률을 충족하는 모든 래퍼와 함께 작동하도록 일반화됩니다. Dart에 Monad를 추가하는 것을 제안하는 것은 아니지만 비동기 호출에 반드시 해당하지 않는 "래핑 해제"에 대한 유형 안전 구문에 대한 전례가 있다는 점을 언급할 가치가 있다고 생각합니다.

한 걸음 물러서서, 여기 많은 사람들이 (저를 포함하여) 어려움을 겪고 있는 한 가지는 가독성에 대한 이 질문이라고 생각합니다. @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 는 두 번째가 첫 번째 것보다 더 읽기 쉽다는 아이디어에 확신을

그래서 여기에 두 번째 코드 블록이 첫 번째 코드 블록보다 더 읽기 쉬운 이유에 대한 내 분석(가치가 있는 작은 금액에 대해)이 있습니다.

1. 첫 번째 코드 블록이 두 번째 코드보다 훨씬 더 들여쓰기되어 있습니다.

내 경험에 따르면 들여쓰기는 일반적으로 비동기식, 분기 또는 콜백과 동일하며, 모두 들여쓰기되지 않은 선형 코드보다 더 많은 인지 부하가 ​​필요합니다. 첫 번째 코드 블록에는 여러 겹의 들여쓰기가 있으므로 여기에서 일어나는 일과 궁극적으로 렌더링되는 내용(단일 Text )을 살펴보는 데 적지 않은 시간이 걸립니다. 아마도 다른 사람들은 마음속으로 들여쓰기를 통해 작업하는 것이 더 나을 것입니다.

두 번째 코드 블록에는 문제를 완화하는 들여쓰기가 없습니다.

2. 첫 번째 코드 블록은 의도를 표현하기 위해 더 많은 구문이 필요합니다.

첫 번째 코드 블록에는 return 문 3개, 빌더 문 3개, 람다 헤더 3개, 컨텍스트 3개, 마지막으로 값 3개가 있습니다. 궁극적으로 우리가 관심을 갖는 것은 이 세 가지 가치입니다. 나머지는 우리를 거기에 이르게 하는 상용구입니다. 저는 실제로 이것이 이 코드 블록에서 가장 어려운 부분이라고 생각합니다. 너무 많은 일이 진행되고 있고 내가 실제로 관심을 갖고 있는 부분(빌더가 반환하는 값)은 너무 작은 부분이기 때문에 실제로 필요한 부분에 집중하는 대신 상용구를 만드는 데 정신 에너지의 대부분을 소비합니다( 다시, 값).

두 번째 코드 블록에는 상용구가 크게 줄어들어 내가 관심 있는 부분, 즉 값에 집중할 수 있습니다.

3. 첫 번째 코드 블록은 중첩의 가장 깊은 부분에서 build 메서드의 가장 중요한 부분을 숨깁니다.

이 build 메서드의 모든 부분이 중요하다는 것을 알고 있지만 이 스타일의 선언적 UI 코드를 읽을 때 일반적으로 찾고 있는 것은 이 경우 가장 깊은 중첩 빌더에 포함된 Text 위젯입니다. 그 Text 위젯은 전면 중앙에 위치하지 않고 들여쓰기, 구문 및 의도의 여러 레이어에 묻혀 있습니다. 이 레이어 중 하나에 Column 또는 Row 를 던지면 훨씬 더 깊이 중첩되고 그 시점에서 가장 들여쓰기된 섹션으로 추적하는 이점조차 없습니다. .

두 번째 코드 블록에서 반환되는 실제 렌더링 가능 Widget 은 함수의 맨 아래에 있으며 즉시 명백합니다. 또한 제안된 구문 OP와 같은 것이 있을 때 시각적인 Widget 항상 함수의 맨 아래에 있다는 것을 알 수 있으므로 코드를 훨씬 더 예측 가능하고 읽기 쉽게 만듭니다.

중첩과 관련 하여 _tree_ 를 표현하는 중첩과 _sequence_ 를 표현하는 중첩 에는 차이가 있습니다.

일반적인 View -> Text 중첩 등의 경우 중첩은 화면에 부모-자식 관계 를 나타내기 때문에 중요합니다. Context와 같은 기능의 경우(Flutter에 있는지 확실하지 않음) 컨텍스트의 범위를 나타냅니다. 따라서 중첩 자체는 이러한 경우에 중요한 의미론적 의미를 가지며 무시할 수 없습니다. 부모와 자식의 자리만 바꿔서 결과가 같을 것이라고 기대할 수는 없습니다.

그러나 빌더의 중첩(React의 "Render Props"라고도 함) 또는 Promises의 중첩을 사용하면 중첩이 일련의 변환/증가 를 전달해야 합니다. 트리 자체는 그다지 중요하지 않습니다. 예를 들어 독립적인 ABuilder -> BBuilder -> CBuilder 중첩할 때 부모-자식 관계는 추가 의미를 전달하지 않습니다.

아래 범위에서 세 가지 값을 모두 사용할 수 있는 한 해당 트리 구조는 실제로 관련이 없습니다. 개념적으로는 "평평"하고 중첩은 구문의 아티팩트일 뿐입니다. 물론 서로의 값을 사용할 수도 있지만(이 경우 순서가 중요함) 이것은 순차 함수 호출에서도 마찬가지이며 중첩 없이 수행할 수 있습니다.

이것이 async/await 가 매력적인 이유입니다. 낮은 수준의 메커니즘을 설명하는 추가 정보(Promise의 부모-자식 관계)를 제거하고 대신 높은 수준의 의도(시퀀스 설명)에 집중할 수 있습니다.

트리는 목록보다 유연한 구조입니다. 그러나 각 부모에게 자식이 하나만 있으면 병적 나무 가 됩니다. 본질적으로 목록입니다. Async/Await 및 Hooks는 정보를 전달하지 않는 것에 구문을 낭비하고 있음을 인식하고 제거합니다.

이것은 내가 이전에 "이것은 상용구에 관한 것이 아니다"라고 말했고 이제는 내 자신과 모순되는 것처럼 보이기 때문에 이것은 실제로 흥미롭습니다. 여기 두 가지가 있다고 생각합니다.

그 자체로 빌더(또는 최소한 React의 Render Props) 는 "재사용 가능한 논리" 문제에 대한 솔루션(AFAIK)입니다. 많이 사용하면 인체 공학적이지 않다는 것입니다. 동일한 구성 요소에서 4개 또는 5개 이상을 사용하는 들여쓰기에 의해 자연스럽게 낙담하게 됩니다. 각 다음 레벨은 가독성 히트입니다.

그래서 나에게 해결되지 않은 것처럼 보이는 부분은 독자의 중첩 비용을 줄이는 것입니다. 그리고 그 인수는 async / await 와 정확히 같은 인수입니다.

다음과 같은 이유로 읽을 수 없습니다.

• 공백을 과도하게 사용하면 잘 확장되지 않습니다. 우리는 모니터에 너무 많은 라인만을 가지고 있으며 강제 스크롤은 가독성을 감소시키고 congitive 부하를 증가시킵니다. 우리가 이미 60줄 위젯 트리를 가지고 있고 빌더를 위해 나에게 15줄을 추가로 강요했다고 상상해보십시오. 이상적이지는 않습니다.
• Hz 공간을 낭비하며, 이는 추가 래핑으로 이어지며 라인 공간을 더욱 낭비합니다.
• 콘텐츠로 알려진 리프 노드를 왼쪽에서 더 멀리, 한 눈에 보기 힘든 트리 안으로 밀어 넣습니다.
• '핵심 플레이어' 또는 '비상용성'을 한 눈에 식별하는 것은 훨씬 더 어렵습니다. 내 추론이 시작되기 전에 "중요한 것을 찾아야" 합니다.

이것을 보는 또 다른 방법은 비 상용구 코드를 강조 표시하고 눈이 쉽게 즐길 수 있도록 함께 그룹화되어 있는지 또는 눈이 주위를 스캔해야 하는 모든 곳에 흩어져 있는지 여부를 강조 표시하는 것입니다.

강조 표시를 사용하면 매우 쉽게 추론할 수 있습니다. 그것 없이는 누가 무엇을 어디에서 사용하고 있는지 파악하기 전에 전체 상세 정보를 읽어야 합니다.

이제 이것과 비교하면 강조 표시는 기본적으로 중복됩니다. 내 눈이 갈 곳이 없기 때문입니다.

가독성 대 grokability에서 아마도 불일치가 있다는 점에 주목할 가치가 있습니다. @Hixie 는 대규모 트리를 지속적으로 읽고 이해해야 하는 모놀리식 클래스 파일에서 시간을

참고로 React의 Context는 InheritedWidgets/Provider입니다.

그들 사이의 유일한 차이점은 후크 전에 React에서 Builder 패턴을 사용하여 Context/Inheritedwidget을 소비한다는 것입니다.

Flutter에는 간단한 함수 호출로 다시 빌드를 바인딩하는 방법이 있습니다.
따라서 InheritedWidgets를 사용하여 트리를 평면화하기 위해 후크가 필요하지 않습니다. 이는 빌더 문제를 해결하는 방법입니다.

Builder가 덜 자주 필요하기 때문에 논의가 더 어려운 이유 중 하나일 것입니다.

그러나 후크와 같은 솔루션을 도입하면 https://github.com/flutter/flutter/issues/30062를 모두 해결할 수 있다는 점을 언급할 가치가
및 https://github.com/flutter/flutter/issues/12992

또한 @Hixie 는 내 의견으로는 다른 언어보다 Flutter가 기본적으로 모든 트리이기 때문에 깊은 중첩 트리를 읽는 데 더 익숙합니다. 물론 Flutter 자체의 주요 개발자 중 한 명으로서 그는 훨씬 더 많은 경험을 했을 것입니다. Flutter는 본질적으로 @Hixie 가 HTML5 사양을 만든 경험이 있는 HTML과 마찬가지로 깊은 중첩이 있는 왼쪽에서 오른쪽 프레임워크로 생각할 수 있습니다. 즉, 코드 블록의 가장 오른쪽 지점은 주요 논리와 반환 값이 있는 곳입니다.

그러나, 대부분의 개발자는 그렇지 않다, 또는 하단 언어에 더

그것을 보는 또 다른 방법은 내 두뇌가 시각적으로 수정해야 하는 코드의 양입니다. 나에게 이것은 트리에서 반환되는 내용을 구문 분석하기 전에 내 두뇌가 수행해야 하는 "간단한 작업"을 정확하게 나타냅니다.

간단히 말해서 빌더 버전은 말 그대로 추가 정보나 컨텍스트를 추가하지 않으면서 4배 더 큰 수직 공간을 가지며 훨씬 더 희소/산란한 방식으로 코드를 압축합니다. 내 생각에 그것은 열려 있고 닫힌 경우이며, 그 이유만으로 객관적으로 읽기가 쉽지 않으며, 우리 모두가 플러터로 처리한 들여쓰기 및 중괄호 정렬에 대한 추가인지 부하를 고려하지도 않습니다.

내 눈을 처리에 더 최적화된 배고픈 CPU라고 생각하십니까? :)

일반적인 View -> Text 중첩 등의 경우 중첩은 화면에 _부모-자식 관계_를 나타내기 때문에 중요합니다. Context와 같은 기능의 경우(Flutter에 있는지 확실하지 않음) 컨텍스트의 범위를 나타냅니다. 따라서 중첩 자체는 이러한 경우에 중요한 의미론적 의미를 가지며 무시할 수 없습니다. 부모와 자식의 자리만 바꿔서 결과가 같을 것이라고 기대할 수는 없습니다.

전적으로 동의하며 앞서 언급했습니다. 상태가 있는 추가 비시각적 컨트롤러를 사용하고 있기 때문에 시각적 디스플레이 트리에 추가 컨텍스트 레이어를 생성하는 것은 의미상 의미가 없습니다. 5개의 애니메이터를 사용하여 이제 위젯의 깊이가 5개입니까? 그 높은 수준에서만 현재 접근 방식은 냄새가납니다.

여기에 두 가지 문제가 있습니다.

1. 값비싼 리소스를 사용할 때 얼마나 어렵고 명시적이어야 하는지에 대해 의견이 분분하다고 생각합니다. Flutter의 철학은 개발자가 언제 어떻게 사용할지에 대해 진지하게 생각할 수 있도록 더 어렵고 명시적이어야 한다는 것입니다. 스트림, 애니메이션, 레이아웃 빌더 등은 너무 쉬울 경우 비효율적으로 사용될 수 있는 사소하지 않은 비용을 나타냅니다.

2. 빌드는 동기화이지만 앱 개발자로서 다루는 가장 흥미로운 것은 비동기입니다. 물론 빌드를 비동기식으로 만들 수는 없습니다. 우리는 Stream/Animation/FutureBuilder와 같은 이러한 편의를 만들었지만 개발자가 필요로 하는 것에 항상 충분히 잘 작동하지는 않습니다. 프레임워크에서 Stream이나 FutureBuilder를 많이 사용하지 않는다는 뜻일 것입니다.

물론 개발자에게 비동기 작업으로 작업할 때 항상 사용자 지정 렌더 개체를 작성하도록 지시하는 것이 솔루션이라고 생각하지 않습니다. 그러나 이 버그에서 내가 보고 있는 예에는 우리가 그냥 기다릴 수 없는 비동기 및 동기화 작업이 혼합되어 있습니다. 빌드는 모든 호출에서 무언가를 생성해야 합니다.

fwiw에서 React 팀은 1 동기로 가독성 문제 재사용을 해결했습니다.
Hooks Motivation: 컴포넌트 간에 Stateful 로직을 재사용하기 어렵습니다.
React 는 재사용 가능한 동작을 구성 요소에 "첨부"하는 방법을 제공하지 않습니다 . 이 문제를 해결하려고 시도하는 패턴에 익숙할 수 있습니다. 그러나 이러한 패턴을 사용하려면 구성 요소를 사용할 때 구성 요소를 재구성해야 하므로 번거롭고 코드를 따르기가 더 어려워질 수 있습니다 .

이것은 Flutter가 현재 기본적으로 '상태를 구성'하는 방법을 제공하지 않는 것과 매우 유사합니다. 또한 레이아웃 트리를 수정하여 작업하기가 더 복잡하고 "따라하기가 더 어려워지는" 빌더를 만들 때 발생하는 일을 반영합니다.

build 가 매번 호출되어야 하는 경우 @dnfield 아마도 빌드가 항상 동기화되도록 build 메서드에 없는 후크를 만들 수 있습니다 initState 및 dispose 입니다. 후크를 작성하는 사람들로부터 그렇게 하는 데 문제가 있습니까?

Promises/Futures에 대해 동일한 주장을 하고 await 가 Promise를 반환한다는 사실을 모호하게 한다고 말할 수 있습니다.

아니요. Await는 말 그대로 하나의 단일 기능에 대한 구문 설탕입니다. 장황한 Futures 또는 선언적 구문을 사용하는 날씨에 코드의 __intent__는 동일합니다.

여기에서 요구하는 것은 완전히 다른 문제를 처리하는 소스 코드를 동일한 우산 아래로 옮기고, 단일 키워드 뒤에 모든 종류의 다른 동작을 숨기고, 어떻게든 인지 부하를 줄인다고 주장하는 것입니다.

그것은 완전히 잘못된 것입니다. 이제 그 키워드를 사용할 때마다 결과가 비동기 작업을 수행하고, 불필요한 재구축을 트리거하고, 수명이 긴 개체를 초기화하고, 네트워크 호출을 수행하고, 디스크에서 파일을 읽거나, 단순히 정적 값을 반환하는지에 대해 궁금해해야 하기 때문입니다. . 이 모든 상황은 매우 다르며 내가 사용하는 후크의 맛에 익숙해져야 합니다.

여기 있는 대부분의 개발자는 구현 세부 사항에 대해 걱정할 필요 없이 이러한 "후크"를 사용할 수 있기 때문에 이러한 종류의 세부 사항에 신경쓰는 것을 좋아하지 않고 손쉬운 개발을 원한다는 것을 토론에서 이해합니다.
완전한 의미를 이해하지 못한 채 소위 "후크"를 사용하면 비효율적이고 잘못된 코드가 생성되고 사람들이 발에 총을 쏘게 됩니다. 따라서 "초보자 개발자 보호" 문제도 해결되지 않습니다.

사용 사례가 간단하다면 후크를 기꺼이 사용할 수 있습니다. 빌더를 원하는 대로 사용하고 중첩할 수 있지만 앱이 복잡해져서 코드를 재사용하는 데 어려움을 겪을수록 자신의 코드와 아키텍처에 더 많은 관심을 기울여야 한다고 생각합니다. 잠재적으로 수백만 명의 사용자를 위한 앱을 구축하고 있다면 중요한 세부 사항을 추상화하는 "마법"을 사용하는 것을 매우 주저할 것입니다. 지금 저는 Flutter의 API가 매우 간단한 사용 사례에 대해 단순하고, 누구나 매우 효율적인 방식으로 모든 종류의 복잡한 로직을 구현할 수 있도록 여전히 유연하다는 것을 알았습니다.

@Rudiksz 다시 말하지만 아무도 후크로 이동하도록 강요하지 않습니다. 현재 스타일은 그대로 유지됩니다. 이 지식에 직면하여 당신의 주장은 무엇입니까?

어쨌든 사람들은 여러 후크가 어떻게든 앱을 차단하고 있다는 것을 알게 되면 여전히 효율적인 코드를 작성할 수 있습니다. 현재 스타일에서와 마찬가지로 프로필을 작성하거나 앱을 실행할 때도 볼 수 있습니다.

@Rudiksz 다시 말하지만 아무도 후크로 이동하도록 강요하지 않습니다. 현재 스타일은 그대로 유지됩니다. 이 지식에 직면하여 당신의 주장은 무엇입니까?

이런, 이 같은 주장은 프레임워크의 문제에 대해 불평하는 사람들에게도 적용됩니다. 아무도 후크 패키지를 사용하지 않도록 강요하지 않습니다.

나는 여기서 매우 무뚝뚝할 것이다.
이 문제는 실제로 후크, statefulwidget 및 누가 무엇을 사용하는지에 관한 것이 아니라 일부 사람들이 5줄의 코드를 덜 작성할 수 있도록 수십 년의 모범 사례를 되돌리는 것에 관한 것입니다.

당신의 주장은 정말 통하지 않습니다. 이 문제가 생성된 이유는 flutter_hooks 패키지가 프레임워크에 있는 것으로 가능한 모든 작업을 수행하지 않는 반면 현재 모델은 기본적으로 프레임워크에 이미 있기 때문에 가능하기 때문입니다. 인수는 기본적으로 flutter_hooks의 기능을 프레임워크로 이동하는 것입니다. 당신의 주장은 내가 현재 모델로 할 수 있는 것은 무엇이든지 후크 패키지로도 할 수 있다고 가정합니다. 이는 사실이 아닙니다. 이 토론의 다른 사람들과 같습니다. 그것이 사실이라면 작동할 것이고, 이는 또한 후크가 기본적으로 프레임워크에 있다는 것을 의미하며, 따라서 다시 후크와 비후크가 동일하므로 현재 모델과 후크 기반을 사용할 수 있습니다. 제가 주장했던 모델입니다.

코드를 쉽게 읽을 수 있도록 유지하는 것이 모범 사례이고 과도한 중첩이 안티 패턴이라는 것을 알고 있으므로 모범 사례가 어디에서 왔는지 모르겠습니다. 정확히 어떤 모범 사례를 언급하고 있습니까?

fwiw에서 React 팀은 1 동기로 가독성 문제 재사용을 해결했습니다.
Hooks Motivation: 컴포넌트 간에 Stateful 로직을 재사용하기 어렵습니다.
React 는 재사용 가능한 동작을 구성 요소에 "첨부"하는 방법을 제공하지 않습니다 . 이 문제를 해결하려고 시도하는 패턴에 익숙할 수 있습니다. 그러나 이러한 패턴을 사용하려면 구성 요소를 사용할 때 구성 요소를 재구성해야 하므로 번거롭고 코드를 따르기가 더 어려워질 수 있습니다 .

Flutter가 React보다 훨씬 더 훌륭하다고 모든 사람들이 열광하는 것을 들었습니다. React가 하는 모든 일을 하지 않기 때문일까요? Flutter가 React보다 몇 마일 앞서 있다고 말할 수도 없고 모든 작업을 React와 똑같이 수행하도록 요청할 수도 없습니다.

Flutter가 주어진 문제에 대해 사용하기로 결정한 솔루션은 무엇이든 자체 장점이 있어야 합니다. 나는 React에 익숙하지 않지만 분명히 나는 ​​정말 놀라운 기술을 놓치고 있습니다. :/

Flutter가 React와 같은 모든 작업을 수행해야 한다고 주장하는 사람은 아무도 없다고 생각합니다.

그러나 사실 Flutter의 위젯 레이어는 React에서 크게 영감을 받았습니다. 공식 문서에 나와 있습니다.
결과적으로 위젯은 React 구성 요소와 동일한 이점과 동일한 문제가 있습니다.

이것은 또한 React가 이러한 문제를 다루는 데 Flutter보다 더 많은 경험을 가지고 있음을 의미합니다.
그것은 그들을 더 오래 마주했고 더 잘 이해했습니다.

따라서 Flutter 문제에 대한 솔루션이 React 문제에 대한 솔루션과 유사하다는 것은 놀라운 일이 아닙니다.

@Rudiksz Flutter의 사용자 API는 내부 API가 다를 수 있음에도 불구하고 React의 클래스 기반 모델과 매우 유사합니다. 나는 다른 프레임워크에서 후크와 유사한 구조를 사용하거나 사용하지 않은 사람들에게 거의 독점적으로 기반을 둔 의견의 이분법이 있는 것 같다고 앞서 언급했듯이 후크가 있는 React를 시도하는 것이 좋습니다.

유사성을 감안할 때, 위에서 언급한 것처럼 문제에 대한 솔루션이 유사해 보이는 것은 놀라운 일이 아닙니다.

제발 서로 싸우지 않도록 최선을 다합시다.

싸움이 우리를 이끌 유일한 것은 이 토론을 끝내고 해결책을 찾지 못하는 것뿐입니다.

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 UserNickname 를 사용하려고 합니다. 보시다시피 fetchNicknames는 하나의 닉네임뿐만 아니라 닉네임의 맵을 반환합니다. 그래서 매번 호출하는 것은 불필요합니다. 여기에 적용할 수 있는 몇 가지 솔루션:

• fetchNicknames() 호출 로직을 상위 위젯으로 이동하고 결과를 저장합니다.
• 캐시 관리자를 사용합니다.

첫 번째 솔루션은 허용되지만 2가지 문제가 있습니다.
1 - 이제 UserNickname 쓸모없게 렌더링됩니다. 왜냐하면 이것은 이제 단지 텍스트 위젯이고 다른 곳에서 사용하려면 상위 위젯( ListView )에서 수행한 작업을 반복해야 하기 때문입니다. . 닉네임을 보여주는 로직은 UserNickname 하지만 따로 ​​옮겨야 합니다.
2 - 다른 많은 하위 트리에서 fetchNicknames() 를 사용할 수 있으며 응용 프로그램의 한 부분만이 아니라 모든 응용 프로그램에 대해 캐시하는 것이 좋습니다.

따라서 캐시 관리자를 선택하고 InheritedWidgets 또는 Provider 있는 CacheManager 클래스를 제공한다고 상상해 보십시오.

캐싱에 대한 지원을 추가한 후:

__후크 위젯__

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 statful의 상용구는 전혀 문제가 되지 않습니다. 사용자의 닉네임과 아바타가 모두 있는 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)],
    );
  }
}

하지만 __stateful 위젯__의 경우 우리가 작성한 로직을 그대로 사용할 수 없습니다. 로직을 클래스로 이동해야 하며(예: Property ) 여전히 새 위젯에서 속성 클래스를 사용하여 위젯 글루를 다시 작성해야 합니다.

첫 번째 3개의 예에서 변경 사항을 보면 위젯 자체를 전혀 변경하지 않았습니다. 필요한 변경 사항은 상태 논리에만 있고 변경된 유일한 위치는 모두 상태 논리였기 때문입니다.
이것은 우리에게 어디에서나 사용할 수 있는 깨끗하고(의견이 있는) 구성 가능하고 완전히 재사용 가능한 상태 논리를 제공했습니다.

IMHO의 유일한 문제는 useUserNickname 호출하는 것이 단일 함수가 이만큼 할 수 있기 때문에 무섭다는 것입니다.
그러나 반응에 대한 경험과 프로덕션 rn(후크를 많이 사용하는)에 있는 2개의 앱에서 flutter_hooks 를 사용한 경험은 좋은 상태 관리가 없음을 증명합니다(저도 MobX 및 기타 상태 관리 솔루션을 시도했지만 위젯의 접착제는 항상 존재합니다)가 훨씬 더 무섭습니다. 프론트엔드 앱의 모든 화면에 대해 5페이지의 문서를 작성할 필요가 없습니다. 첫 번째 릴리스 이후 몇 달 안에 내 앱의 페이지가 어떻게 작동하는지 이해하기 위해 몇 가지 작은 기능을 추가해야 할 수도 있습니다. 앱이 서버를 너무 많이 호출합니까? 쉬운 작업 관련 훅으로 이동하여 변경하면 전체 앱이 해당 훅을 사용하기 때문에 전체 앱이 수정됩니다. 우리는 좋은 추상화를 가진 후크를 사용하지 않고 앱에서 비슷한 것을 가질 수 있지만 내가 말하는 것은 후크가 좋은 추상화라는 것입니다.

@gaearon 이 나보다 더 잘

위의 예를 보면 위의 어떤 방법(상태 저장 및 후크 위젯)도 다른 방법보다 성능이 좋지 않습니다. 그러나 요점은 그 중 하나가 사람들이 성능이 좋은 코드를 작성하도록 권장한다는 것입니다.

또한 다음을 사용하여 업데이트(예: 애니메이션)가 너무 많은 경우 StreamBuilder 처럼 업데이트해야 하는 하위 트리만 업데이트할 수 있습니다.

1 - HookWidget 및 StatefulWidget/StatelessWidget 모두에 대해 완전히 실행 가능한 옵션인 새 위젯 만들기
2 - flutter_hooks 패키지에서 HookWidgetBuilder 와 유사한 것을 사용합니다. 상위 및 하위 위젯 데이터가 매우 밀접하게 결합되어 있기 때문입니다.

참고 사항: 이 주제에 대해 논의하고 이 문제에 많은 에너지를 쏟은 @Hixie 와 @rrousselGit 에게 정말 감사드립니다. 이 회담의 결과가 정말 기대됩니다.

@Hixie 의 시작점을 기반으로 꽤 멋지고 우아한 생각을 하고 있습니다. 아직 공유할 준비가 되지 않았지만 꽤 괜찮은 코드 샘플을 만들 수 있게 되었고, 너무 이질적으로 보이는 후크보다 apple:apple 을 비교하는 것이 더 쉬울 것이라고 생각합니다.

따라서 다음과 같은 서명이 있는 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. 맨 위에서 하나는 20줄, 다른 하나는 45개입니다. 하나는 1315자이고 다른 하나는 825자입니다. 이 클래스에서는 3줄과 200자만 중요하므로(빌드에서 발생하는 일) 이것은 이미 신호 의 엄청난 개선입니다.
2. 바닐라 옵션에는 버그가 생성될 수 있는 여러 지점이 있습니다. 처리하는 것을 잊거나 didChange 처리를 잊거나 didChange에서 실수를 하면 코드 기반에 버그가 있습니다. 여러 유형의 컨트롤러를 사용하면 상황이 더욱 악화됩니다. 그런 다음 모든 다른 유형의 객체를 분해하는 단일 함수가 있습니다. 이 객체는 이와 같이 멋지고 순차적으로 명명되지 않습니다. 그것은 지저분해지며 실수를 하거나 항목을 놓치기 쉽습니다.
3. 바닐라 옵션은 playOnInit와 같은 일반적인 패턴이나 로직을 재사용하는 방법을 제공하지 않으므로 이 로직을 복제하거나 Animator를 사용하려는 매우 단일 클래스에서 일부 사용자 정의 함수를 만들어야 합니다.
4. 여기에서 SingleTickerProviderMixin을 이해할 필요가 없습니다. 이것은 '마법'이고 몇 달 동안 Ticker가 무엇인지 이해하기 어렵습니다. 여기에서 StatefulAnimationProperty의 소스 코드를 직접 볼 수 있고 애니메이션 컨트롤러가 컨텍스트에서 직접 티커 공급자를 사용하는 방법을 확인할 수 있습니다.

대신 StatefulPropertyManager가 하는 일을 이해해야 합니다. 그러나 결정적으로 이것은 한 번 배우고 모든 유형의 객체에 적용된다는 점입니다. SingleTickerProviderMixin은 주로 애니메이터 컨트롤러 사용과 관련이 있으며 모든 컨트롤러에는 사용을 더 쉽게 하기 위해 자체 믹싱이 있을 수 있으므로 지저분해집니다. 이 모든 것을 알고 있는 별개의 "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를 사용하면 훨씬 더 매력적이고 덜 복잡해집니다. 코드 기반 전체에서 Builders의 사용은 일반적으로 줄어들어 더 쉽게 grokable 트리를 만들 수 있습니다.

또한 이전에 나열된 FetchUser 예제와 같이 현재 기본적으로 빌더가 필요한 사용자 정의 상태 개체를 _매우_ 쉽게 만들 수 있습니다.

다음 Flutter 개발자 설문조사에서 이것이 매우 흥미로운 질문이 될 것이라고 생각합니다.

좋은 시작이 될 것입니다. 이 문제를 다른 부분/질문으로 나누고 이것이 Flutter 개발자가 해결하고자 하는 실제 문제인지 확인하십시오.

명확해지면 이 대화가 더 유창하고 풍부해질 것입니다.

각 댓글 아래의 이모티콘 반응은 커뮤니티가 이를 문제로 보는지 여부에 대한 명확한 아이디어를 제공합니다. 이 문제에 대해 250개 이상의 긴 댓글을 읽은 개발자의 의견은 많은 의미가 있습니다.

@esDotDev 그것은 내가 가지고 들지만 나는 그것을 고려하지 않았습니다. 구현에서 누락된 한 가지는 추가해야 한다고 생각하는 TickerMode(TickerProviderStateMixin의 요점) 처리입니다.

내가 고군분투하는 주요 문제는 효율적인 방법으로 이 작업을 수행하는 방법입니다. 예를 들어, ValueListenableBuilder는 성능을 측정 가능하게 개선하는 데 사용할 수 있는 자식 인수를 사용합니다. Property 접근 방식으로 그렇게 할 수 있는 방법이 없습니다.

@Hixie
이와 같은 접근 방식의 효율성 손실은 불가피한 것으로 보입니다. 하지만 저는 코드를 프로파일링한 후 최적화하려는 Flutter의 사고 방식을 좋아합니다. Property 접근 방식의 명확성과 간결함의 이점을 얻을 수 있는 응용 프로그램이 많이 있습니다. 코드를 프로파일링하고 빌더로 리팩터링하거나 위젯의 일부를 자체 위젯으로 분리하는 옵션이 항상 있습니다.

문서는 모범 사례를 반영하고 장단점을 명확히 하기만 하면 됩니다.

내가 고군분투하는 주요 문제는 효율적인 방법으로 이 작업을 수행하는 방법입니다. 예를 들어, ValueListenableBuilder는 성능을 측정 가능하게 개선하는 데 사용할 수 있는 자식 인수를 사용합니다. Property 접근 방식으로 그렇게 할 수 있는 방법이 없습니다.

흠, 속성의 전체 요점은 비시각적 개체에 대한 것입니다. 뭔가가 트리에 컨텍스트 슬롯을 갖고 싶다면 그 것은 빌더여야 합니다(사실 이것들이 지금 빌더여야 한다고 생각하는 유일한 것입니까?)

따라서 전체 뷰를 바인딩하려는 경우 대부분 사용하는 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()),
   ]
)

꽤 🔥 이모,

예, 작동하는지 모르겠지만 빌더의 다른 속성이 속성에 의해 설정된다는 점을 제외하고 빌드 메서드는 일반 빌더와 마찬가지로 자식을 사용합니다.
빌더의 컨텍스트가 필요한 경우 빌드 메소드는 컨텍스트를 제공하는 빌더 인수를 허용합니다.

내부적으로 메서드는 지정된 속성을 사용하여 일반 빌더를 만들고 자식 인수를 일반 빌더에 전달하고 이를 반환할 수 있습니다.

다음 코드가 있다고 가정합니다.

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 속성 자체가 시세 공급자가 되는 당신의 아이디어가 마음에

이 후크 스타일 접근 방식의 가장 강력한 측면 중 하나는 상태 저장 논리를 _완전히_ 캡슐화할 수 있다는 것입니다. 따라서 이 경우 AC의 전체 목록은 다음과 같습니다.

1. AC 생성
2. 시세를 줘
3. 위젯 변경 처리
4. ac 및 시세의 정리 처리
5. 틱에 뷰 다시 작성

현재 1,3,4를 수동으로 반복적으로 처리하는(또는 처리하지 않는) 개발자와 2와 ​​5를 처리하는 반 마법의 SingleTickerProviderMixin('이것'을 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
예를 들어 주셔서 감사합니다. 최선을 다했습니다. 내가 뭔가를 놓쳤을 수도 있습니다.

Property가 정의된 상태에 바인딩되기 때문에 이것이 작동하지 않는다고 생각합니다. 따라서 ExpensiveParent는 항상 여기에서 다시 작성됩니다. 그런 다음 Builder 예제에서와 같이 자식의 캐싱도 문제가 있다고 생각합니다. 부모 상태가 빌드될 때만 자식을 다시 빌드하는 것으로 알고 있지만 이 방법에서는 속성이 캐시를 무효화할 때를 알지 못합니다(하지만 아마도 이 해결 가능한가요?)

그러나 이것은 새로운 컨텍스트를 도입하려는 빌더에게 완벽한 사용 사례입니다. StatefulProperties(순수 상태) 및 StatefulWidget(상태 및 레이아웃 혼합)의 컨텍스트를 갖는 것이 매우 우아하다고 생각합니다.

의도적으로 하위 컨텍스트를 생성할 때마다 정의에 따라 트리 아래에서 더 멀리 수행하게 되므로 빌더의 주요 단점 중 하나(전체 트리에 강제 중첩)를 방지하는 데 도움이 됩니다.

@escamoteur (그리고 그 의견을 작성한 @sahandevs ) 예, 저는 더 일찍 공부하고 있었습니다. 사람들이 없애고 싶어하는 그런 논리를 보여주는 데 확실히 도움이 된다고 생각합니다. 하지만 대부분의 논리(예: 캐싱과 관련된 모든 것)가 앱 상태 비즈니스 논리에 있고 위젯 근처에는 없을 것으로 예상한다는 점에서 예제 자체가 약간 모호하다고 생각합니다. 또한 핫 리로드를 중단하지 않고 해당 주석에서 제안된 대로 구문을 간략하게 만드는 좋은 방법을 볼 수 없습니다(예: 사용 중인 후크 수를 변경하는 경우 다시 로드 동안 상태를 유지할 수 있는 방법이 명확하지 않습니다. ).

즉, 위의 @esDotDev 및 @TimWhiting 작업이 매우 흥미롭고 이러한 문제를 해결할 수 있다고 생각합니다. Hooks만큼 짧지는 않지만 더 안정적입니다. 그런 것을 포장하는 것이 완벽할 것이라고 생각합니다. 잘 작동한다면 Flutter Favorite도 될 수 있습니다. 건물 속성과 성능 영향에 대한 복잡성과 다양한 사람들이 다양한 스타일을 선호하는 방식을 고려하면 개선이 그다지 중요하지 않기 때문에 이것이 핵심 프레임워크 기능으로 의미가 있는지 확신할 수 없습니다. 결국 다른 사람들이 다른 스타일을 사용하는 것은 괜찮지만 핵심 프레임워크에 여러 스타일이 있는 것을 원하지 않습니다. 이는 새로운 개발자를 오도할 뿐입니다.

Flutter를 배우는 올바른 방법은 먼저 위젯을 이해한 다음 추상 구문으로 바로 건너뛰기 보다는 위젯을 추상화하는 도구(Hook 또는 기타)를 배우는 것이라는 주장도 있습니다. 그렇지 않으면 시스템 작동 방식의 핵심 구성 요소를 놓치게 되어 성능이 좋은 코드를 작성하는 데 문제가 생길 수 있습니다.

또한 핫 리로드를 중단하지 않고 해당 주석에서 제안된 대로 구문을 간략하게 만드는 좋은 방법을 볼 수 없습니다(예: 사용 중인 후크 수를 변경하는 경우 다시 로드 동안 상태를 유지할 수 있는 방법이 명확하지 않습니다. ).

후크는 문제 없이 핫 리로드와 함께 작동합니다.
일치하지 않는 runtimeType이 있는 첫 번째 후크는 모든 후속 후크를 파괴합니다.

이것은 추가, 제거 및 재정렬을 지원합니다.

현재 존재하는 부분보다 완전한 추상화가 바람직하다는 주장이 있다고 생각합니다.

속성의 컨텍스트에서 Animator가 어떻게 작동하는지 이해하고 싶다면 완전히 무시하거나 뛰어들면 됩니다.

AnimatorController가 StatefulWidget의 컨텍스트에서 작동하는 방식을 이해하려면 기본 수명 주기 후크를 이해해야 하지만 기본 틱 메커니즘이 어떻게 작동하는지 이해해야 합니다. 이것은 어떤 의미에서 두 세계 모두에서 최악입니다. '그냥 작동'하게 만드는 마법은 충분하지 않지만 새로운 사용자를 혼란스럽게 만들고 일부 mixin(그 자체가 대부분의 경우 새로운 개념임)과 마법의 vsync 속성을 맹목적으로 신뢰하도록 하기에는 충분합니다.

코드 기반의 다른 예제는 잘 모르겠지만 StatefulWidget에 대해 일부 도우미 믹스인이 제공되었지만 항상 수행해야 하는 다른 부트스트랩이 있는 모든 상황에 적용됩니다. 개발자는 부트스트래핑(지루한 부분)을 배우고 Mixin(흥미로운/복잡한 부분)을 무시합니다.

즉, 위의 @esDotDev 및 @TimWhiting 작업이 매우 흥미롭고 이러한 문제를 해결할 수 있다고 생각합니다. Hooks만큼 짧지는 않지만 더 안정적입니다.

이것이 어떻게 더 신뢰할 수 있습니까?

조건부로 또는 수명 주기 외부에서 속성을 생성/업데이트할 수 없습니다. 나쁜 상태가 될 수 있기 때문입니다. 예를 들어 속성을 조건부로 호출하면 조건이 false인 경우 속성이 삭제되지 않습니다.
그리고 모든 속성은 모든 재구축에서 여전히 재평가됩니다.

그러나 사용자가 NNBD 이후 모든 곳에서 ! 를 사용하도록 하거나 업데이트 전에 사용자가 속성에 액세스할 수 있도록 하는 등 여러 문제가 발생합니다.

예를 들어 누군가 didUpdateWidget 내부의 속성을 읽는다면 어떻게 될까요?

• initProperties 가 수명 주기 전에 실행되었습니까? 그러나 이는 빌드당 속성을 여러 번 업데이트해야 할 수도 있음을 의미합니다.
• didUpdateWidget 후에 initProperties 가 실행되었습니까? 그런 다음 didUpdateWidget 내부의 속성을 사용하면 오래된 상태가 될 수 있습니다.

결국, 우리는 모든 후크 문제를 가지고 있지만:

• 우리는 `StatelessWidget.xml' 내에서 속성을 사용할 수 없습니다. 따라서 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));

    ...
  }
}

폐기 것이다 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),
                      );
                    });
              });
        });
  }
}

중요한 코드를 찾는 것이 훨씬 더 어렵습니다(적어도 내 눈에는). 또한, fwiw, 나는 이것을 작성할 때 3번 정도 다시 시작해야 했습니다. 어떤 브래킷이 어디에 속하는지, 내 세미 콜론이 어디로 가야 하는지 등을 계속해서 혼란스러워했기 때문입니다. 중첩 빌더는 내부에서 작성하거나 작업하는 것이 재미가 없습니다. 하나의 잘못된 세미콜론과 dartfmt는 전체를 완전히 부숴버립니다.

이것이 어떻게 더 신뢰할 수 있습니까?

이것이 왜 이것이 핵심 플러그인 imo가 _해야_ 하는지에 대한 완벽한 예입니다. 여기에 필요한 도메인 지식은 _deep_입니다. 저는 이와 같은 간단한 캐싱 시스템을 구현하기 위한 스크립팅 지식이 있지만 발생할 수 있는 모든 엣지 케이스 또는 우리가 들어갈 수 있는 나쁜 상태를 알 수 있는 도메인 지식이 거의 없습니다. Remi 말고도 Flutter 팀 말고도 이런 걸 아는 개발자는 전 세계에 4명 정도 있는 것 같아요! (분명히 과장).

Stateless 위젯을 지원하는 문제는 좋은 문제입니다. 한편으로는 StatefulWidgets가 이상하게 장황합니다. 다른 한편, 여기에서 우리는 진정으로 순수한 장황함에 대해 이야기하고 있습니다. 2개의 클래스를 정의해야 하는 경우 발생할 수 있는 버그가 없습니다. 엉망으로 만들 수 있는 방법이 없으며 컴파일러가 허용하지 않습니다. StatelessWidget에서 하고 싶은 흥미로운 작업이 전혀 없습니다. 그래서 나는 이것이 중요한 문제라는 것에 대해 매도되지 않았습니다... 확실히 있으면 좋겠지만, 이것은 마지막 5% imo이며, 꼼짝할 필요가 없습니다.

반면에 ... 키워드 지원이 있는 remi의 구문은 절대적으로 아름답고 유연하고 강력합니다. 그리고 StatelessWidget 지원을 무료로 제공한다면 그건 추가 사항일 뿐입니다 🔥

StatelessWidget을 지원하는 것은 중요한 IMO입니다. 선택 사항이지만 여전히 매우 좋습니다.

그것이 중요하지 않다는 데 동의하지만 사람들은 이미 StatelessWidget 대신 함수를 사용하는 것에 대해 싸우고 있습니다.
사람들이 빌더를 사용하기 위해 StatefulWidget을 사용하도록 요구하는 것은(대부분의 빌더가 동일한 속성을 가질 가능성이 높기 때문에) 갈등을 심화시킬 뿐입니다.

뿐만 아니라 다트에서 고차 함수를 생성할 수 있는 세상(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 가 더 안정적이라는 의미가 무엇을 의미하는지 추측하고 있습니다. 후크가 갖는 작업 순서/조건부 문제로 고통받지 않습니다. 이는 아키텍처 POV에서 매우 '신뢰할 수 없는' 것이기 때문입니다. 배우고 한 번 학습하면 위반하지 않음).

그러나 키워드를 사용한 제안도 마찬가지입니다. 나는 new 키워드의 경우가 매우 강력하다고 생각합니다.

• State에 접목하는 것보다 더 유연하고 구성 가능
• 더욱 간결해진 구문
• Stateless에서 작동하는 매우 좋은 옵션입니다.

내가 마음에 들지 않는 점은 우리가 몇 가지 간단한 개체의 속성을 여러 번/빌드로 설정하는 비용에 대해 걱정하고 있지만 기본적으로 백만 수준의 컨텍스트와 많은 레이아웃 비용을 생성하는 솔루션을 옹호한다는 것입니다. 내가 오해하고 있는 걸까?

다른 단점은 이러한 마법의 아이디어입니다. 하지만 마법 같은 일을 하려는 경우 새 키워드를 사용하면 커뮤니티에 쉽게 강조 표시하고 요청하고 그것이 무엇인지, 어떻게 작동하는지 설명할 수 있기 때문에 새로운 키워드가 효과적인 방법이라고 생각합니다. 기본적으로 이것은 Flutter에서 내년에 대해 누구나 이야기할 수 있는 모든 것이 될 것이며, 거기서 생성되는 멋진 플러그인의 폭발을 보게 될 것이라고 확신합니다.

@Hixie 가 더 안정적이라는 의미가 무엇을 의미하는지 추측하고 있습니다. 후크가 갖는 작업 순서/조건부 문제로 고통받지 않습니다. 이는 아키텍처 POV에서 매우 '신뢰할 수 없는' 것이기 때문입니다. 배우고 한 번 학습하면 위반하지 않음).

그러나 후크는 정적으로 분석할 수 있으므로 이러한 문제가 발생하지 않으므로 오용될 때 컴파일 오류가 발생할 수 있습니다.

이것은 문제가 되지 않는다

마찬가지로 사용자 지정 오류가 발생하지 않는 경우 이전에 언급했듯이 Property는 똑같은 문제를 겪습니다.
우리는 합리적으로 쓸 수 없습니다:

Property property;

<strong i="12">@override</strong>
void initProperties() {
  if (condition) {
    property = init(property, MyProperty());
  }
}

condition 를 true에서 false로 전환하면 속성이 삭제되지 않습니다.

루프에서 실제로 호출할 수도 없습니다. 일회성 과제이기 때문에 실제로 의미가 없습니다. 루프에서 속성을 실행하는 사용 사례는 무엇입니까?

그리고 속성을 어떤 순서로든 읽을 수 있다는 사실은 위험하게 들립니다.
예를 들어 다음과 같이 작성할 수 있습니다.

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줄 정도이고 애니메이션 속성은 그렇게 단순하지 않으며 여러 핸들러 및 기타 기능이 정의되어 있습니다. 암시적 위젯 중 하나에서 처리되지 않는 작업을 수행하고 있다고 가정합니다(AnimatedContainer 이외의 다른 목적은 매우 단일 목적이므로 어렵지 않음).

요점은 이와 같은 것을 구축할 때 빌더가 잘 작동하지 않는다는 것입니다. 처음부터 가독성(및 쓰기 가능성) 구멍에 집어넣고 간단한 사용 사례에 적합하므로 "작성"하지 않습니다. 잘. Compose는 2개 이상의 항목으로 구성된 것입니다.

내가 어떻게 사용하는지에 집중하지 마십시오. 실제 예에서 ...

...그리고 다시 원점으로 돌아갑니다. 실제 사례를 가져오지 않겠습니까?

복잡한 애니메이션을 사용하는 실제 예가 필요하십니까?
https://github.com/gskinnerTeam/flutter_vignettes

임의의 복잡한 애니메이션을 표시하는 것은 예제를 난독화하는 것 외에는 아무 것도 하지 않습니다. 일부 위젯 내에서 여러 애니메이터(또는 상상할 수 있는 다른 상태 저장 객체)를 사용하는 많은 사용 사례가 있습니다.

당연하지. 여기의 예는 "X"를 수행하기 위해 일부 위젯에서 3개의 애니메이션을 활용하는 것입니다. X는 상용구의 양을 강조하기 위해 예제에서 의도적으로 단순화되었습니다.

위젯 "코어"는 100줄 또는 그 이상일 것입니다.

다른 게시물에서 "핵심"을 가리는 상용구 예제를 ​​게시했지만 이제 핵심이 수백 줄이 될 것이라고 말합니까? 그래서 실제로, 상용구는 코어에 비해 미미할까요? 당신은 그것을 두 가지 방법으로 가질 수 없습니다.
당신은 끊임없이 당신의 주장을 바꾸고 있습니다.

내가 어떻게 사용하는지에 집중하지 마십시오. 실제 예에서 ...

...그리고 다시 원점으로 돌아갑니다. 실제 사례를 가져오지 않겠습니까?

다양한 아이디어를 가지고 노는 것만으로도 실제 사례를 만드는 데 시간이 많이 걸리기 때문일 것입니다. 의도는 독자가 실제 상황에서 어떻게 사용될 수 있는지 상상하도록 하는 것이지 주변에 방법이 있다는 것은 언급하지 않습니다. 물론 애니메이션 컨테이너를 사용할 수는 있지만 사용할 수 없다면 어떻게 될까요? 애니메이션 컨테이너만으로 만들기에는 너무 복잡하다면 어떨까요?

이제 작가들은 좋은 예나 나쁜 것으로 보여질 수 있는 진정한 실제 예를 사용하지 않기 때문에 그것에 대한 의견이 없습니다. 당면한 문제를 완전히 해결하십시오. 이것은 후크 지지자와 반대자 사이에 혼돈의 주요 원인인 것 같습니다. 각각이 어느 정도 서로를 지나쳐 말하는 것처럼 보이기 때문에 상대방이 "실제" 예가 다음과 같다고 말할 수 없도록 실제 앱을 만들자는 Hixie의 제안을 지지합니다. 제시되지 않았으며 지지자는 실제 시나리오를 단순히 상상해야 한다고 말할 수 없습니다.

반은 상용구로 되어 있는 100줄짜리 클래스를 갖는 것은 어리석은 일이라고 생각합니다. 이것이 바로 내가 여기서 설명하는 것입니다. 코어가 아무리 크더라도 여러 빌더를 사용할 때 발생하는 많은 소음으로 인해 난독화되어서는 안 됩니다.

그리고 그 이유는 대규모 코드베이스에서 스캔 가능성, 가독성 및 유지 관리 때문입니다. 빌더에서 쓰는 것은 중괄호 지옥에 빠지는 경향이 있기 때문에 생산성을 잃게 되지만 줄을 쓰는 것은 아닙니다.

다른 게시물에서 "핵심"을 가리는 상용구 예제를 ​​게시했지만 이제 핵심이 수백 줄이 될 것이라고 말합니까? 그래서 실제로, 상용구는 코어에 비해 미미할까요? 당신은 그것을 두 가지 방법으로 가질 수 없습니다.
당신은 끊임없이 당신의 주장을 바꾸고 있습니다.

다시 말하지만, 이 문제는 상용구에 관한 것이 아니라 가독성과 재사용성에 관한 것입니다.
100줄이면 상관없습니다.
중요한 것은 이 라인이 얼마나 읽기/유지/재사용 가능한가입니다.

논쟁이 상용구에 대한 것인데도 충분히 동등한 표현 방식을 제공하는 사용자인 내가 왜 그런 상용구를 용인해야 합니까? 프로그래밍은 추상화를 만들고 작업을 자동화하는 것입니다. 다양한 클래스와 파일에서 동일한 작업을 반복해서 수행하는 요점을 실제로 보지 못합니다.

복잡한 애니메이션을 사용하는 실제 예가 필요하십니까?
https://github.com/gskinnerTeam/flutter_vignettes

확실히, 당신은 내가 당신의 전체 프로젝트를 파헤칠 것이라고 기대할 수 없습니다. 정확히 어떤 파일을 봐야 하나요?

임의의 복잡한 애니메이션을 표시하는 것은 예제를 난독화하는 것 외에는 아무 것도 하지 않습니다.

정반대입니다. 기존 솔루션으로는 해결할 수 없는 임의의 복잡한 애니메이션을 보여주는 것이 그 예일 것입니다. Hixie가 계속해서 묻고 있는 것입니다.

gif를 스캔하고 그 중 일부를 구축하는 방법을 상상하기 시작하십시오. 그 저장소는 실제로 17개의 독립 실행형 앱입니다. 또한 복잡한 애니메이션이 존재할 수 있다는 것을 증명하기 위해 내가 임의의 애니메이션을 작성할 것이라고 기대할 수도 없습니다. 저는 Flash를 시작으로 20년 동안 그것들을 구축해 왔습니다. 어쨌든 애니메이션에만 국한된 것은 아니며 더 큰 요점을 설명하는 가장 간단한 가장 친숙한 API일 뿐입니다.

아시다시피 애니메이터를 사용하면 매번 해야 하는 6가지가 있지만 수명 주기 후크도 필요합니다?? 좋아, 이제 매번 수행해야 하는 6단계가 있는 모든 것으로 확장합니다. 그리고 2곳에서 사용해야 합니다. 또는 3개를 동시에 사용해야 합니다. 그것은 표면상의 문제가 너무 분명해서, 설명하기 위해 무엇을 더 추가할 수 있을지 모르겠습니다.

프로그래밍은 추상화를 만들고 작업을 자동화하는 것입니다. 다양한 클래스와 파일에서 동일한 작업을 반복해서 수행하는 요점을 실제로 보지 못합니다.

__모두__? 따라서 성능, 유지 보수성은 관련이 없습니까?

노동을 "자동화"하는 것과 노동을 "하는 것"이 ​​동일한 시점이 옵니다.

여러분, 실제 사례를 만들 시간이나 의향이 없어도 괜찮습니다. 하지만 문제를 설명하기 위해 예제를 만드는 데 관심이 없다면 사람들이 문제를 해결해야 한다고 생각하지도 마세요( 문제를 보여주기 위해 예제를 만드는 것보다 훨씬 더 많은 작업입니다. 여기에 있는 누구도 누군가를 위해 무엇을 해줄 필요가 없습니다. 우리 모두가 서로를 도우려고 노력하는 오픈 소스 프로젝트입니다.

@TimWhiting https://github.com/TimWhiting/local_widget_state_approaches 리포지토리 에 라이선스 파일을 넣어 주시겠습니까? 어떤 사람들은 해당 라이선스(BSD, MIT 또는 이상적으로는 유사) 없이는 기여할 수 없습니다.

동일한 것을 표현하는 충분히 동등한 방법이 주어지면 사용자인 내가 어떤 경우에도 그러한 상용구를 용인해야 하는 이유는 무엇입니까?

예, 유지보수성과 성능은 물론 중요합니다. 동등한 솔루션이 있는 경우 상용구가 적고 읽기 쉽고 재사용이 가능한 등의 솔루션을 선택해야 합니다. 예를 들어 후크의 성능을 측정하지 않았기 때문에 후크가 답이라는 말은 아니지만 경험상 후크를 유지 관리하기가 더 쉽습니다. 후크와 같은 구조가 Flutter 코어에 삽입된 경우 작업에 어떤 영향을 미치는지에 대한 귀하의 주장에 대해 여전히 확신할 수 없습니다.

gif를 스캔하고 그 중 일부를 구축하는 방법을 상상하기 시작하십시오.

gif를 스캔했습니다. 빌더 위젯을 사용하지 않습니다.
많은 애니메이션이 너무 복잡해서 더 높은 수준의 빌더를 사용하여 구현했다는 것을 알았다면 아마도 패키지를 사용하지 않았을 것입니다.

어쨌든 이 토론은 개인적인 의견 차이가 더 많이 발생하는 것 같습니다. 우리는 당면한 주요 작업에 집중해야 합니다. 내가 앞에서 말했듯이 상대가 제기된 문제를 진정으로 해결하지 못하는 개선책을 찾을 경우 후크 지지자들이 어떻게 더 작은 예를 보여줄 수 있는지 잘 모르겠습니다. 지금은 @TimWhiting 의 저장소에 기여해야 한다고 생각합니다.

기존 솔루션으로는 해결할 수 없는 임의의 복잡한 애니메이션을 보여주는 것이 그 예일 것입니다. Hixie가 계속해서 묻고 있는 것입니다.

오늘날 가능하지 않은 것의 예를 보여주는 것은 이 문제의 범위를 벗어납니다.
이 문제는 오늘날 가능하지 않은 일부를 차단 해제하는 것이 아니라 이미 가능한 것의 구문을 개선하는 것에 관한 것입니다.

오늘날 가능하지 않은 것을 제공하라는 요청은 주제에서 벗어났습니다.

@TimWhiting https://github.com/TimWhiting/local_widget_state_approaches 리포지토리 에 라이선스 파일을 넣어 주시겠습니까? 어떤 사람들은 해당 라이선스(BSD, MIT 또는 이상적으로는 유사) 없이는 기여할 수 없습니다.

완료. 죄송합니다. 예제에 대해 작업할 시간이 많지 않았지만 이번 주에 작업에 들어갈 것입니다.

기존 솔루션으로는 해결할 수 없는 임의의 복잡한 애니메이션을 보여주는 것이 그 예일 것입니다. Hixie가 계속해서 묻고 있는 것입니다.

오늘날 가능하지 않은 것의 예를 보여주는 것은 이 문제의 범위를 벗어납니다.
이 문제는 오늘날 가능하지 않은 일부를 차단 해제하는 것이 아니라 이미 가능한 것의 구문을 개선하는 것에 관한 것입니다.

오늘날 가능하지 않은 것을 제공하라는 요청은 주제에서 벗어났습니다.

내가 말한 것을 다시 말해보자.

작성하기 어렵고 성능에 영향을 미치지 않으면서 크게 개선될 수 있는 애니메이션, 상태 등 을 사용 사례를 보여주는 것이 그 예가 될 것이며, 이것이 Hixie가 계속 묻는 것입니다.

더 적은 상용구, 더 많은 재사용성, 더 많은 마법에 대한 요구를 이해합니다. 나도 적은 양의 코드를 작성해야 하는 것을 좋아하고, 더 많은 작업을 수행하는 언어/프레임워크가 상당히 먹음직스럽습니다.
지금까지 여기에 제시된 예제/솔루션 콤보는 코드를 크게 향상시키지 못했습니다. 즉, 얼마나 많은 코드 줄을 작성해야 하는지 그 이상에 관심이 있는 경우입니다.

여러분, 실제 사례를 만들 시간이나 의향이 없어도 괜찮습니다. 하지만 문제를 설명하기 위해 예제를 만드는 데 관심이 없다면 사람들이 문제를 해결해야 한다고 생각하지도 마세요( 문제를 보여주기 위해 예제를 만드는 것보다 훨씬 더 많은 작업입니다. 여기에 있는 누구도 누군가를 위해 무엇을 해줄 필요가 없습니다. 우리 모두가 서로를 도우려고 노력하는 오픈 소스 프로젝트입니다.

@TimWhiting https://github.com/TimWhiting/local_widget_state_approaches 리포지토리 에 라이선스 파일을 넣어 주시겠습니까? 어떤 사람들은 해당 라이선스(BSD, MIT 또는 이상적으로는 유사) 없이는 기여할 수 없습니다.

저는 이러한 다양한 예제와 코드 조각을 만드는 데 약 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가 제공한 예제 이미지는 않습니까 ? 그들에게 부족한 것은 무엇입니까? 성능 메트릭이 없다고 가정하지만 @rrousselGit 은 빌더보다 성능이

@esDotDev 내 생각에 핵심은 모든 수명 주기 관리 솔루션을 비교할 수 있는 단일 표준 예를 갖는 것입니다(후크뿐만 아니라 미래의 다른 솔루션도 가능). TodoMVC와 동일한 원칙입니다. React, Vue, Svelte 등의 다양한 구현을 가리킬 필요는 없습니다. 차이점을 보여주기 위해 모두 동일한 애플리케이션을 구현하기를 원할 것입니다. 그러면 비교할 수 있습니다.

그것은 나에게 의미가 있지만 한 페이지보다 더 커야 하는 이유를 이해하지 못합니다.

여러 애니메이션을 관리하는 것은 일반적이고 많은 상용구를 필요로 하고 오류가 발생하기 쉽고 현재 좋은 솔루션이 없는 완벽한 예입니다. 그것이 의미가 없다면 사람들이 애니메이션이 어떻게 복잡할 수 있는지조차 이해하지 못한다고 말할 것이라면 분명히 모든 유스 케이스는 아키텍처 문제가 아니라 유스 케이스의 컨텍스트에 대해 무너질 것입니다. 설명하려고 합니다.

물론 @TimWhiting 의 리포지토리에는 완전한 앱이 없습니다. 다른 사람들이 솔루션을 구현할 수 있는 해당 리포지토리에 대한 애니메이션의 표준 예를 만들 수 있다면 그것이 작동할 것입니다.

나는 또한 우리가 거대한 앱이나 다른 것이 필요하다고 생각하지 않지만 TodoMVC와 유사한 복잡성이 충분해야합니다. 기본적으로 상대방이 "이런 식으로 더 잘할 수 있다"고 말할 수 없을 정도로 충분해야 합니다.

@Hixie 실제 앱이 접근 방식을 비교하도록 요청하는 데 결함이 있습니다.

두 가지 결함이 있습니다.

• 우리는 아직 문제에 대해 동의하지 않습니다.
• 누락된 부품이 있으므로 실제 생산 조건에서 예제를 구현할 수 없습니다.

예를 들어 다음을 사용하여 애플리케이션을 작성할 수 없습니다.

final snapshot = keyword StreamBuilder();

구현되지 않았기 때문입니다.

POC와 프로덕션 코드를 비교하는 것이기 때문에 성능도 판단할 수 없습니다.

오용이 있을 때 오류를 지적하는 컴파일러 통합이 없기 때문에 "후크를 조건부로 호출할 수 없습니다"와 같은 항목이 오류가 발생하기 쉬운지 여부를 평가할 수 없습니다.

디자인의 성능을 판단하고, API 사용성을 평가하고, 구현하기 전에 구현하는 것... 모두 API 디자인의 일부입니다. 내 직장에 오신 것을 환영합니다. :-) (Flutter 상식: 우리가 dart:ui를 만들기 전에 RenderObject와 RenderBox et al의 처음 몇 천 라인이 구현되었다는 것을 알고 계셨습니까?)

그것은 당신이 불가능한 것을 요구한다는 사실을 바꾸지 않습니다.

여기에서 제안된 일부는 언어 또는 분석기의 일부입니다. 커뮤니티에서 구현하는 것은 불가능합니다.

확실하지 않습니다. 다른 프레임워크와 언어가 항상 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줄 절약). 결정적으로 이것은 교묘한 버그 및 중복 비즈니스 로직 문제를 완전히 해결할 수 있지만, 특히 10행 히트인 StatefulWidget이 필요하기 때문에 여전히 약간 장황합니다.

'키워드'와 같은 것을 사용하면 상용구 라인을 본질적으로 0%로 줄입니다. 수업의 전체 초점은 (고유한) 비즈니스 로직과 시각적 트리 요소에 있을 수 있습니다. 일반적으로 StatefulWIdget을 훨씬 더 드물게 사용하고 대다수의 보기가 10~20% 덜 장황하고 더 집중됩니다.

또한 위의 패널 시나리오는 실제 세계이며 실제 세계에서 분명히 이 접근 방식은 실제로 좋지 않으므로 사용하지 않았으며 코드 기반에서 볼 수 없습니다. 또한 중첩된 빌더를 사용하지도 않습니다. 그 빌더가 보기 흉하게 보이므로 사용자도 볼 수 없습니다.

IsOpen 속성을 사용하고 자체적으로 열리고 닫히는 전용 SlidingPanel 위젯을 만들었습니다. 이것은 일반적으로 특정 동작이 필요하고 상태 저장 논리를 일부 초특정 위젯으로 이동한 다음 사용하는 이러한 사용 사례의 모든 단일 솔루션입니다. 기본적으로 자신의 ImplicitlyAnimatedWidget을 작성합니다.

이것은 일반적으로 잘 작동하지만 여전히 시간과 노력이며, 말 그대로 애니메이션이 존재하는 유일한 이유는 애니메이션을 사용하는 것이 너무 어렵기 때문입니다(일반적으로 상태 저장 구성 요소를 재사용하는 것이 너무 어렵기 때문입니다). 예를 들어 Unity 또는 AIR에서는 단일 축에서 패널을 이동하기 위해 전용 클래스를 만들지 않았습니다. 열거나 닫는 코드 한 줄이면 됩니다. 전용 위젯이 수행할 작업은 없습니다. Flutter에서는 AnimatorController의 부트스트래핑 및 분해를 캡슐화하는 유일한 합리적인 방법이기 때문에 Flutter에서 전용 위젯을 만들어야 합니다(TAB으로 중첩, 중첩, 중첩하지 않으려는 경우)

여기서 내 요점은 이런 유형의 것이 실제 사례를 찾기 어려운 이유라는 것입니다. 개발자로서 우리는 이러한 것들이 우리 코드베이스에 너무 많이 존재하도록 할 수 없으므로 이상적이지는 않지만 효과적인 해결 방법으로 문제를 해결합니다. 그런 다음 코드베이스를 볼 때 이러한 해결 방법이 적용되고 모든 것이 괜찮아 보이지만 팀이 만들고자 하는 것이 아닐 수도 있고 거기에 도달하는 데 20% 더 오래 걸렸을 수도 있습니다. 디버그하는 데 어려움이 있지만, 이 중 어느 것도 코드를 보면 분명하지 않습니다.

완전성을 위해 빌더로 만든 동일한 사용 사례가 있습니다. 줄 수가 크게 줄어들고 버그가 발생할 가능성이 없으며 외국 개념을 배울 필요가 없습니다. RE TickerProviderMixin... 하지만 중첩은 슬픈 일이고 다양한 변수가 트리 전체에 뿌려지는 방식(동적 종료 값, 값1, 값2 등) ) 비즈니스 로직을 필요 이상으로 읽기 어렵게 만듭니다.

```다트
클래스 _SlidingPanelViewState 확장 상태{
부울 isLeftMenuOpen = true;
부울 isRightMenuOpen = true;
부울 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, __) {
이중 leftPanelSize = 320;
이중 leftPanelPos = -leftPanelSize * (1 - leftAnimValue);
이중 rightPanelSize = 230;
더블 rightPanelPos = -rightPanelSize * (1 - rightAnimValue);
이중 bottomPanelSize = 80;
이중 bottomPanelPos = -bottomPanelSize * (1 - btmAnimValue);
반환 스택(
어린이들: [
//비지
용기(색상: 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(),
),
// 버튼
열(
어린이들: [
버튼("왼쪽", () => setState(() => isLeftMenuOpen = !isLeftMenuOpen)),
버튼("btm", () => setState(() => isBtmMenuOpen = !isBtmMenuOpen)),
버튼("오른쪽", () => setState(() => isRightMenuOpen = !isRightMenuOpen)),
],
)
],
);
},
);
},
);
},
);
}
}

마지막 것은 흥미롭습니다... 저는 원래 빌더가 스택이 아닌 위치 지정 위젯 주위에 있어야 한다고 제안하려고 했지만(그리고 여전히 왼쪽 및 오른쪽 패널에 대해 제안할 것입니다) 맨 아래에 있는 것이 영향을 미친다는 것을 깨달았습니다. 세 가지 모두, 나는 깨달았다 당신에게 일을주는 빌더 child 인수 실제로 당신이 정말로 모두 유지하기 원하기 때문에, 충분하지 Container 와 Row 를 통해 일정을 빌드. 첫 번째 빌더 위에 만들 수 있다고 가정합니다.

여기서 내 요점은 이런 유형의 것이 실제 사례를 찾기 어려운 이유라는 것입니다. 개발자로서 우리는 이러한 것들이 우리 코드베이스에 너무 많이 존재하도록 할 수 없으므로 이상적이지는 않지만 효과적인 해결 방법으로 문제를 해결합니다. 그런 다음 코드베이스를 볼 때 이러한 해결 방법이 적용되고 모든 것이 괜찮아 보이지만 팀이 만들고자 하는 것이 아닐 수도 있고 거기에 도달하는 데 20% 더 오래 걸렸을 수도 있습니다. 디버그하는 데 어려움이 있지만, 이 중 어느 것도 코드를 보면 분명하지 않습니다.

참고로 이것은 사고가 아닙니다. 이것은 매우 의도적으로 설계된 것입니다. 이러한 위젯을 자체 위젯으로 사용하면 성능이 향상됩니다. 우리는 이것이 사람들이 Flutter를 사용하는 방식을 매우 의도했습니다. 이것은 위에서 "Flutter의 디자인 철학의 큰 부분은 사람들을 올바른 선택으로 안내하는 것"이라고 언급했을 때 언급한 것입니다.

나는 원래 빌더가 스택보다는 배치된 위젯 주위에 있어야 한다고 제안하려고 했습니다(그리고 나는 여전히 왼쪽 및 오른쪽 패널에 대해 제안할 것입니다)

간결함을 위해 실제로 생략했지만 일반적으로 여기에 Content 컨테이너가 필요하고 3가지 메뉴 모두의 크기를 사용하여 자체 위치를 정의합니다. 즉, 3개 모두가 트리의 맨 위에 있어야 하며, 다시 빌드하는 경우 전체 보기가 필요하며 주위를 돌아다니지 않고 다시 빌드해야 합니다. 이것은 기본적으로 고전적인 데스크탑 스타일의 스캐폴드입니다.

물론 우리는 트리를 분해할 수 있습니다(항상 선택 사항). 우리는 더 큰 위젯에 많이 사용하지만 실제로 한 눈에 grokability를 향상시키는 것을 본 적이 없습니다. 독자가 그것에 대해 수행해야 하는 추가적인 인지 단계가 있습니다. 가리키다. 당신이 나무를 쪼개는 순간, 갑자기 변수 할당의 빵 부스러기 흔적을 따라가서 여기에 전달되는 것이 무엇인지 파악하고 전체가 어떻게 함께 들어맞는지 파악합니다. 소화 가능한 나무로 나무를 제시하는 것은 항상 내 경험에서 추론하기가 더 쉽습니다.

아마도 전용 RenderObject에 대한 좋은 사용 사례일 것입니다.

또는 위젯 수명 주기에 연결할 수 있는 3개의 쉽게 관리되는 AnimatorObjects :D

이러한 위젯을 자체 위젯으로 사용하면 성능이 향상됩니다.

여기에서 구체화하기 때문에: 이 경우 이것은 스캐폴드이기 때문에 모든 하위 보기는 이미 자체 위젯입니다. 이 사람은 자식 배치 및 번역만 담당합니다. 자식은 BottomMenu(), ChannelMenu(), SettingsView(), MainContent() 등입니다.

이 경우 우리는 단순히 이동에 대한 상용구를 관리하기 위해 자체 포함된 위젯의 무리를 자체 포함된 위젯의 또 다른 레이어로 래핑합니다. 나는 이것이 성능 승리라고 생각하지 않습니까? 이 경우 우리는 우리가 실제로 하고 싶은 것이 아니라 프레임워크가 _생각하는_ 우리가 하고 싶은 것, 즉 더 간결하고 일관된 방식으로 동일한 성능의 뷰를 작성하는 것으로 밀어붙이고 있습니다.

[편집] 이 컨텍스트를 추가하기 위해 예제를 업데이트하겠습니다.

전용 RenderObject를 제안하는 이유는 레이아웃을 더 좋게 만들기 때문입니다. 나는 애니메이션 측면이 상태 저장 위젯에 있을 것이라는 데 동의합니다. 스택 수학을 사용하는 대신 3개의 0..1 더블(value1, value2, value3)을 렌더 객체로 전달합니다. 그러나 그것은 대부분 이 토론의 부수적인 것입니다. 이 작업을 수행하는 시점에서 상태 저장 위젯에서 Hooks 또는 이와 유사한 것으로 제공되는 단순화를 수행하고 싶을 것입니다.

더 관련성이 높은 메모에서 @TimWhiting 의 프로젝트에 대한 데모를 만드는 데 균열이 있었습니다: https://github.com/TimWhiting/local_widget_state_approaches/pull/1
Hooks 버전은 어떻게 생겼는지 궁금합니다. 특히 성능 특성을 유지하는 것(또는 개선하는 것; 현재 최적이 아닌 곳을 보여주는 주석이 있음)을 더 간단하게 만드는 좋은 방법을 볼 수 있을지 확신이 서지 않습니다.

(단순화할 수 있는 방법을 찾은 경우 여기에서 수행할 것인지 또는 완료하기 전에 해결해야 할 중요한 사항이 누락된 것인지도 매우 궁금합니다.)

이 예에서 복원 항목이 중요합니까? 나는 그것 때문에 어려움을 겪고 있으며 RestorationMixin이 무엇을 하는지조차 모릅니다. 나는 그것이 ... 나를 위해 이것을 이해하는 데 약간의 시간이 걸릴 것이라고 가정합니다. 나는 Remi가 4초 만에 후크 버전을 완성할 것이라고 확신합니다. :)

StatefulHookWidget 가 아닌 HookWidget 를 사용하여 복원 API를 사용하는 것은 현재 지원되지 않습니다.

이상적으로는 변경할 수 있어야 합니다.

final value = useState(42);

안으로:

final value = useRestorableInt(42);

그러나 현재 복원 API는 실제로 후크를 염두에 두고 설계되지 않았기 때문에 약간의 생각이 필요합니다.

참고로 React hooks에는 일반적으로 다음과 같이 사용되는 "핵심" 기능이 있습니다.

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 애니메이션 예제를 후크로 이식했습니다.

흥미로운 예였습니다. 생각해주셔서 감사합니다!
기본적으로 "active" 및 "duration"의 구현이 어디에나 있다는 점에서 좋은 예입니다(그리고 그 점에서 서로 의존함).
요점까지 수많은 "if (active)" / "controller.repeat" 호출이 있었습니다.

반면 후크를 사용하면 모든 논리가 선언적으로 처리되고 중복 없이 한 곳에 집중됩니다.

이 예제는 또한 객체를 쉽게 캐시하기 위해 후크를 사용하는 방법을 보여줍니다. 이는 ExpensiveWidget을 너무 자주 재구축하는 문제를 해결했습니다.
const 생성자의 이점을 얻지만 동적 매개변수와 함께 작동합니다.

우리는 또한 더 나은 핫 리로드를 얻습니다. 배경색의 Timer.periodic 기간을 변경하고 즉시 변경 사항을 확인할 수 있습니다.

@rrousselGit 링크가 있습니까? @TimWhiting 의 저장소에서 새로운 것을 보지 못했습니다.

StatefulHookWidget 가 아닌 HookWidget 를 사용하여 복원 API를 사용하는 것은 현재 지원되지 않습니다.

우리가 어떤 솔루션을 제시하든, 모든 마지막 믹스인에 대해 알 필요가 없도록 해야 합니다. 누군가 TickerProviderStateMixin 또는 RestorationMixin과 같은 mixin을 도입하는 다른 패키지와 함께 우리 솔루션을 사용하려는 경우 그렇게 할 수 있어야 합니다.

https://github.com/TimWhiting/local_widget_state_approaches/pull/3

동의하지만 나는 그것에 대해 걱정하지 않습니다. useAnimationController는 예를 들어 사용자가 SingleTickerProvider에 대해 신경 쓸 것을 요구하지 않습니다.

AutomaritKeepAlive는 동일한 치료로부터 혜택을 받을 수 있습니다.
내가 생각한 것 중 하나는 "useKeepAlive(bool)" 후크를 갖는 것입니다.

이것은 mixin과 "super.build(context)"를 모두 피합니다(후자는 상당히 혼란스럽습니다)

또 다른 흥미로운 점은 리팩토링 중에 필요한 변경 사항입니다.

예를 들어 원시 접근 방식과 후크에 대해 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이 필요합니다.
• 후크 변경은 순전히 추가적입니다. 기존 라인은 편집/이동되지 않았습니다.

이것은 매우 중요하며 이 스타일의 자체 포함된 상태 개체에서 중요한 승리입니다. 트리의 중첩 컨텍스트를 기반으로 하는 모든 것을 리팩토링하고 변경하는 것은 근본적으로 더 어렵고 복잡합니다. 이는 프로젝트가 진행되는 동안 코드베이스의 최종 품질에 보이지 않지만 확실한 영향을 미칩니다.

동의!
또한 코드 검토를 훨씬 쉽게 읽을 수 있습니다.

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

두 번째 diff에서는 Container 가 변경되지 않고 Text 변경되었다는 것이 명확하지 않습니다.

@rrousselGit 키워드 지원으로 어떻게 보일 수 있는지 나타내는 버전을 시도하고 수행하는 것이 합리적이라고 생각하십니까? 전용 'use' 키워드만 있는 후크와 실질적으로 유사합니까, 아니면 더 쉽게 따라갈 수 있습니까? useEffect, useMemo 등과 같은 외국 개념이 너무 많기 때문에 후크 접근 방식을 균일하게 비교하기가 어렵습니다.

주목해야 할 또 다른 사항은 이 모든 것이 실제로 문제가 되는 곳은 여러 위젯이 있는 경우 이 '색상 스테핑' 논리를 공유하는 데 모두 필요하지만 결과 색상을 완전히 다른 방식으로 사용한다는 것입니다. 후크 스타일 접근 방식을 사용하면 재사용할 수 있는 논리를 묶어서 사용하기만 하면 됩니다. 우리가 강요하는 아키텍처 코너가 없습니다. 정말 불가지론적이며 유연합니다.

Stateful 접근 방식에서 우리는

• 논리 복사 및 붙여넣기(유지 관리가 매우 불가능)
• 빌더 사용(특히 중첩을 사용할 때 가독성이 좋지 않음)
• 믹싱(잘 구성되지 않음, 공유 상태에서 서로 다른 믹스인이 충돌하기 매우 쉽습니다)

내가 생각하는 핵심은 후자의 경우 즉시 아키텍처 문제가 있다는 것입니다. 이것을 내 트리의 어디에 넣어야 하는지, 이것을 가장 잘 캡슐화할 수 있는 방법은 빌더여야 합니까, 아니면 사용자 정의 위젯이어야 할까요? 전자의 경우 이 재사용된 논리 덩어리를 저장할 파일이 유일한 결정이므로 트리에 전혀 영향이 없습니다. 이것은 이러한 로직 캡슐화 중 몇 가지를 함께 사용하거나 계층 구조에서 위아래로 이동하거나 형제 위젯으로 이동하려는 경우 등 구조적으로 매우 좋습니다.

나는 결코 전문 개발자가 아닙니다. 그러나 논리 를

Vue.js를 오랫동안 사용하지 않았지만 다음 버전을 위한 자체 API(Hooks에서 영감을 받음)도 있으므로 한 번 살펴보는 것이 좋습니다.

• Vue 3 구성 API
• Vue 3 컴포지션 API와 React Hooks 비교

그리고 CMIIW는 반응 후크의 규칙(조건부 사용하지 않음)이 Composition API에 적용되지 않는다고 생각합니다. 따라서 규칙을 시행하기 위해 린터를 사용할 필요가 없습니다.

다시 동기부여 섹션은 여기에서 OP를 강력하게 강화합니다.

동기 부여
복잡한 구성 요소의 코드는 시간이 지남에 따라 기능이 증가함에 따라 추론하기가 더 어려워집니다. 이것은 특히 개발자가 자신이 작성하지 않은 코드를 읽을 때 발생합니다.
[문제가 있었다] 여러 구성 요소 간에 논리를 추출하고 재사용하기 위한 깨끗하고 비용이 들지 않는 메커니즘이 부족했습니다.

핵심 단어는 "깨끗한"과 "비용 무료"입니다. Mixin은 비용이 들지 않지만 깨끗하지는 않습니다. 빌더는 깨끗하지만 가독성 측면에서 비용이 들지 않으며, 계층 구조 측면에서 트리를 이동하고 추론하기가 더 어렵기 때문에 위젯 아키텍처 측면에서 비용이 들지 않습니다.

나는 또한 이것이 가독성 논의에서 언급하는 것이 중요하다고 생각합니다. "_개발자가 작성하지 않은 코드를 읽을 때 특히 발생_". 물론 _당신의_ 중첩 빌더는 읽기 쉬울 수 있고, 거기에 무엇이 있는지 알고 편안하게 건너뛸 수 있습니다. 다른 사람의 코드를 읽고 있는 것입니다. 당신이 더 큰 프로젝트에서 하는 것처럼 또는 몇 주/mth 전의 코드를 읽고 있는 것입니다. 이러한 것들을 파싱하고 리팩토링하기 어렵습니다.

다른 특히 관련 섹션.

단순히 구성 요소를 갖는 것만으로는 충분하지 않은 이유:

... 구성 요소를 생성하면 인터페이스의 반복 가능한 부분과 해당 기능을 재사용 가능한 코드 조각으로 추출할 수 있습니다. 이것만으로도 우리의 애플리케이션은 유지보수성과 유연성 측면에서 꽤 멀리 갈 수 있습니다. 그러나 우리의 집합적인 경험은 이것만으로는 충분하지 않을 수 있음을 입증했습니다. 특히 애플리케이션이 정말 커질 때 수백 개의 구성 요소를 생각해 보십시오. 이러한 대규모 응용 프로그램을 처리할 때 코드 공유 및 재사용이 특히 중요합니다.

논리적 단편화를 줄이고 더 강력하게 캡슐화하는 것이 승리인 이유:

단편화는 복잡한 구성 요소를 이해하고 유지 관리하기 어렵게 만듭니다. 옵션의 분리는 근본적인 논리적 문제를 흐리게 합니다. 또한 하나의 논리적 문제에 대해 작업할 때 관련 코드에 대한 옵션 블록 주위를 지속적으로 "점프"해야 합니다. 동일한 논리적 문제와 관련된 코드를 함께 배치할 수 있다면 훨씬 좋을 것입니다.

제가 제출한 것 외에 개선하려고 하는 표준 예제에 대한 다른 제안이 있는지 궁금합니다.
사람들이 사용하고 싶어하는 출발점이라면 훌륭합니다. 그러나 현재 가장 큰 문제는 장황한 표현이라고 말하고 싶습니다. 이 예제에서는 재사용할 코드가 많지 않습니다. 따라서 OP에 설명된 대로 문제를 잘 나타내는지 확실하지 않습니다.

개인적으로 솔루션에서 찾고자 하는 특성을 표현하는 방법에 대해 좀 더 생각하고 있었고, 현재 Hooks 제안에서 볼 수 있는 큰 문제 중 하나를 깨닫게 되었습니다. Flutter 프레임워크에 병합하고 싶습니다: Locality and Encapsulation, 또는 오히려 부족합니다. Hooks의 디자인은 전역 상태를 사용합니다(예: 현재 빌드 중인 위젯을 추적하는 정적). IMHO 이것은 우리가 피해야 하는 디자인 특성입니다. 일반적으로 우리는 API를 독립적으로 만들려고 하므로 하나의 매개변수로 함수를 호출하면 해당 매개변수 외부의 값으로 아무 것도 할 수 없다는 확신이 있어야 합니다(이것이 우리가 BuildContext를 전달하는 이유입니다. , useContext 해당하는 대신). 이것이 모든 사람이 필연적으로 원하는 특성이라고 말하는 것이 아닙니다. 물론 사람들은 Hooks가 문제가 되지 않는다면 Hooks를 사용할 수 있습니다. Flutter에서 더 많은 작업을 수행하지 않으려는 것입니다. 우리가 전역 상태(예: 바인딩에서)를 가질 때마다 우리는 결국 그것을 후회하게 되었습니다.

Hooks는 아마도 컨텍스트에 대한 메소드일 수 있지만(나는 그들이 초기 버전에 있었다고 생각합니다), 솔직히, 저는 그것들을 현재처럼 병합하는 데 많은 가치를 보지 못합니다. 병합은 성능 향상이나 특정 디버깅 도구를 연결하는 것과 같이 패키지를 분리하는 데 약간의 어드벤쳐가 필요합니다. 그렇지 않으면 혼란만 가중시킬 것입니다. 예를 들어 리스너블을 수신하는 공식적인 3가지 방법(AnimatedBuilder, StatefulWidget 및 useListenable)이 있습니다.

그래서 나에게 가야 할 길은 코드 생성을 개선하는 것입니다. 몇 가지 변경 사항을 제안했습니다. https://github.com/flutter/flutter/issues/63323

이러한 제안이 실제로 구현된다면 앱에서 마법 같은 SwiftUI와 같은 솔루션을 원하는 사람들은 다른 사람을 귀찮게 하지 않고 패키지만 만들 수 있습니다.

내가 아는 한 이 문제에 대해 아직 동의하지 않기 때문에 후크의 유효성에 대해 논의하는 것은 현 단계에서 주제에서 벗어난 것입니다.

이 문제에서 몇 번 언급했듯이 다른 많은 솔루션이 있으며 그 중 다수는 언어 기능입니다.
후크는 가장 기본적인 형태로 구현하기에 비교적 저렴한 다른 기술의 기존 솔루션의 포트일 뿐입니다.

이 기능은 SwiftUI 또는 Jetpack Compose가 수행하는 것과 같이 후크와 완전히 다른 경로를 취할 수 있습니다. "named mixin" 제안 또는 Builders 제안에 대한 구문 설탕.

나는 이 문제의 핵심이 StreamBuilder와 같은 패턴의 단순화를 요구한다는 사실을 주장합니다.

• StreamBuilder는 중첩으로 인해 가독성/쓰기성이 좋지 않습니다.
• 믹스인 및 함수는 StreamBuilder에 대한 가능한 대안이 아닙니다.
• 모든 StatefulWidget에서 StreamBuilder 구현을 복사하여 붙여넣는 것은 합리적이지 않습니다.

지금까지의 모든 주석은 다른 동작(일회용 개체 생성, HTTP 요청 만들기 등) 또는 다른 구문 제안에 대한 StreamBuilder의 대안을 언급했습니다.

더 이상 무슨 말을 해야 할지 잘 모르겠어서 어떻게 더 발전할 수 있을지 모르겠습니다.
@Hixie 이 진술에서 이해하지 못하거나 동의하지 않는 것은 무엇입니까?

@rrousselGit 이것을 보여주는 데모 앱을 만들 수 있습니까? 나는 내가 문제라고 이해한 것을 보여주는 데모 앱을 만들려고 시도했지만 분명히 나는 ​​그것을 제대로 이해하지 못했습니다. ("StreamBuilder와 같은 패턴"과 데모 앱에서 수행한 작업의 차이점이 무엇인지 잘 모르겠습니다.)

• StreamBuilder는 중첩으로 인해 가독성/쓰기성이 좋지 않습니다.

당신은 이미 장황한 것이 문제가 아니라고 말했습니다. 중첩은 장황함의 또 다른 측면일 뿐입니다. 중첩이 실제로 문제라면 Padding, Expanded, Flexible, Center, SizedBox 및 실제 이유 없이 중첩을 추가하는 기타 모든 위젯을 따라야 합니다. 그러나 중첩은 모놀리식 위젯을 분할하여 쉽게 해결할 수 있습니다.

모든 StatefulWidget에서 StreamBuilder 구현을 복사하여 붙여넣는 것은 합리적이지 않습니다.

StatefulWidget이 생성 및 폐기해야 하는 스트림을 생성 및 폐기하는 코드 행을 복사하여 붙여넣는다는 의미입니까? 네, 정말 합리적입니다.

자체 스트림을 생성/폐기해야 하는 수백 개의 _different_ 사용자 정의 StatefulWidget이 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

이 모든 작업은 모든 단일 애니메이션 틱에서 수행됩니다. "final color = useAnimation"과 같은 다른 후크를 추가하면(animationColor);", 색상에 애니메이션 효과를 주기 위해 이제 위젯이 업데이트되었는지 _2_번 확인합니다.

나는 여기 앉아서 앱 상태나 위젯 또는 위젯 트리를 변경하지 않고 앞뒤로 움직이는 텍스트를 보고 있지만 여전히 후크는 트리/위젯이 업데이트되었는지 지속적으로 확인하고 있습니다. 이러한 특정 후크를 "사용"하는 모든 위젯이 이 폴링 동작을 수행하도록 하는 것은 좋지 않습니다.

빌드 메서드 내에서 상태 개체의 초기화/업데이트/폐기 논리를 처리하는 것은 잘못된 디자인일 뿐입니다. 재사용성, 핫리로드 또는 인지 부하에서 얻은 개선 사항이 성능에 미치는 영향을 정당화하지 못합니다.
다시 말하지만, 내 생각에는. 후크는 패키지이므로 이득이 오버헤드를 정당화한다고 생각하면 누구나 사용할 수 있습니다.

또한 빌드 프로세스 내부의 모든 것을 추상화하려는 경우 언어 기능, 컴파일러 마술 또는 추상화가 그러한 불필요한 검사를 방지할 수 있다고 생각하지 않습니다. 따라서 StatefulWidget을 확장하는 것과 같은 대안이 남아 있습니다. 이미 할 수 있는 일, 수없이 해고된 일.

@Hixie 당신은 질문에 대답하지 않았습니다. 위에 나열된 글머리 기호 목록에서 이해하지 못하거나 동의하지 않는 것은 무엇입니까?

나는 당신이 내가 무엇을 보여주기를 원하는지 모른 채 예를 만들 수 없습니다.

@Rudiksz 확실히 우리가 실제로 고려하는 모든 솔루션은 상황을 악화시키지 않도록 프로파일링하고 벤치마킹해야 합니다. @TimWhiting에 제출한 데모 앱을 구성하는 방법 중 일부는 엉망이 되기 쉬운 유형의 패턴을 정확히 다루기 위한 것입니다. (그리고 앞서 언급했듯이 개선의 여지가 있습니다. 코드의 TODO를 참조하십시오.)

@rrousselGit 너무 주관적이기 때문에 이것에 대해 잡초에

• 첫째, 나는 일반적으로 Streams를 사용하지 않을 것입니다. ValueListenable은 거의 동일한 사용 사례에 대해 훨씬 더 나은 IMHO 패턴입니다.
• StreamBuilder가 특히 읽거나 쓰기가 어렵다고 생각하지 않습니다. 하지만 @satvikpendem이 이전 에
• 믹스인과 함수가 StreamBuilder에 대한 가능한 대안이 될 수 있는지 여부에 관해서는 Hooks가 함수를 사용하여 스트림을 수신할 수 있다는 것을 꽤 잘 보여주고 있다고 생각합니다. 해결책이 될 수도 없습니다.
• 마지막으로 복사 붙여넣기 구현과 관련하여 주관적인 문제입니다. initState/didUpdateWidget/dispose/build에 로직을 개인적으로 복사하여 붙여넣지 않고 매번 새로 작성하는데 대부분 괜찮아 보입니다. "제어 불능" 상태가 되면 StreamBuilder와 같은 위젯에 포함시킵니다. 그래서 다시 내 의견은 아마도 여기에서 관련이 없을 것입니다.

일반적으로 귀하가 보고 있는 문제를 내가 경험했는지 여부는 관련이 없습니다. 당신의 경험은 내 의견과 상관없이 유효합니다. 나는 당신이 경험하는 문제에 대한 해결책을 찾기 위해 일하게 되어 기쁩니다. 비록 내가 그 문제를 느끼지 않더라도 말입니다. 내가 직접 문제를 경험하지 않는 것의 유일한 효과는 이 토론에서 보았듯이 내가 문제를 잘 이해하는 것이 더 어렵다는 것입니다.

내가 당신이 증명하고 싶은 것은 당신이 누군가가 솔루션을 만들 때, 당신이 다른 상황에서 때 사용하기 어려운받을 수 있음을 말하여 해고하지 않을 것이라고 상당한 정도로는 그 데모에, 받아 들일 생각하는 코딩 패턴 (즉, 모든 관련 상황을 포함합니다. 예를 들어 "업데이트" 부분 또는 처리해야 할 중요하다고 생각하는 다른 부분을 포함해야 함) 또는 솔루션이 한 가지 경우에는 작동하지만 일반적인 경우에는 작동하지 않는다고 말합니다(예: 이전 피드백을 통해 매개변수가 여러 위치에서 제공되고 여러 상황에서 업데이트되어 위의 속성과 같은 솔루션이 일반적인 코드를 제외하지 않을 것이라는 점을 분명히 합니다.

문제는 당신이 나에게 "명백한" 영역에 있는 무언가에 대한 예를 요구하고 있다는 것입니다.

나는 몇 가지 예를 만드는 데 신경 쓰지 않지만, 당신이 이해하지 못하는 것을 이해하지 못하기 때문에 당신이 무엇을 기대하고 있는지 전혀 모릅니다.

할 말은 이미 다 했습니다.
당신이 이해하지 못하는 것을 이해하지 않고 내가 할 수 있는 유일한 것은 나 자신을 반복하는 것입니다.

여기에서 일부 스니펫을 실행할 수 있지만 이는 나 자신을 반복하는 것과 같습니다.
스 니펫이 유용하지 않은 경우 실행할 수 있다고 해서 아무 것도 변경되지 않는 이유를 알 수 없습니다.

믹스인과 함수가 StreamBuilder에 대한 가능한 대안이 될 수 있는지 여부에 관해서는 Hooks가 함수를 사용하여 스트림을 수신할 수 있다는 것을 꽤 잘 보여주고 있다고 생각합니다. 해결책이 될 수도 없습니다.

후크를 함수로 간주해서는 안 됩니다.
Iterable/Stream과 유사한 새로운 언어 구조입니다.

함수는 후크가 하는 일을 할 수 없습니다. 상태 또는 위젯을 다시 빌드할 수 있는 기능이 없습니다.

mixins의 문제는 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

이 예에 추가할 것이 생각나지 않습니다.

하지만 FWIW 저는 Riverpod를 사용하여 오픈 소스 날씨 앱을 만들고 있습니다. 완료되면 여기에 링크하겠습니다.

여기에서 논의된 문제와 관련된 빌더에 대해 몇 가지 질문을 하는 트위터 설문조사를 했습니다.

https://twitter.com/remi_rousselet/status/1295453683640078336

투표는 아직 보류 중이지만 현재 숫자는 다음과 같습니다.

200명의 사람들 중 86%가 중첩을 포함하지 않는 빌더를 작성하는 방법을 원한다는 사실 자체가 말해줍니다.

분명히 말씀드리자면 저는 이 문제를 해결하지 말라고 제안한 적이 없습니다. 우리가 그것을 해결해서는 안 된다고 생각한다면, 그 문제는 종결될 것입니다.

나는 당신이 링크 한 스 니펫을 사용하는 예를 만들려고 노력할 것입니다.

링크된 스니펫을 기반으로 예제를 만드는 데 도움을 드릴 수 있지만 이 스니펫이 충분하지 않은 이유를 알아야 합니다.
그렇지 않으면 내가 할 수 있는 유일한 방법은 이러한 스니펫을 컴파일하는 것입니다. 하지만 그것이 당신이 원하는 것인지 의심스럽습니다.

예를 들어 다음은 수많은 ValueListenableBuilder+TweenAnimationBuilder https://gist.github.com/rrousselGit/a48f541ffaaafe257994c6f98992fa73에 대한 요지입니다.

예를 들어 다음은 수많은 ValueListenableBuilder+TweenAnimationBuilder https://gist.github.com/rrousselGit/a48f541ffaaafe257994c6f98992fa73에 대한 요지입니다.

FWIW, 이 특정 예는 mobx에서 더 쉽게 구현할 수 있습니다.
실제로 후크 구현보다 짧습니다.

Mobx의 옵저버블은 스테로이드의 ValueNotifier이고 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;
}

애니메이션 빌더가 필요하지 않은 또 다른 구현이 있습니다. 위젯의 빌드 방법은 템플릿과 같은 의미론적 html 파일과 같이 최대한 순수합니다.

https://gist.github.com/Rudiksz/cede1a5fe88e992b158ee3bf15858bd9

@Rudiksz "총계" 필드의 동작이 스니펫에서 깨졌습니다. 두 카운터가 함께 애니메이션을 적용할 수 있지만 다른 시간과 다른 곡선으로 애니메이션을 완료하는 예제와 일치하지 않습니다.
마찬가지로 이 예제가 ValueListenableBuilder 변형에 무엇을 추가하는지 잘 모르겠습니다.

마지막 요점에 관해서는 TickerMode 지원하지 않으며 리스너가 제거되거나 컨트롤러가 폐기되지 않으므로 TickerProvider 가 깨졌습니다.

그리고 Mobx는 주제에서 벗어날 가능성이 높습니다. 우리는 앰비언트 상태/ValueListenable vs Stores vs Streams를 구현하는 방법에 대해 논의하는 것이 아니라, Mobx가 어떤 식으로든 해결하지 못하는 로컬 상태/중첩 빌더를 처리하는 방법에 대해 논의하고 있습니다.

––––

또한 후크 예에서 useAnimatedInt 는 패키지로 추출될 수/있어야 하며 개별 텍스트 애니메이션과 총계 사이의 지속 시간/곡선이 중복되지 않는다는 점을 명심하십시오.

공연의 경우 Hooks를 사용하면 단일 요소만 다시 빌드하는 반면 Builders는 2-4개 빌더를 다시 빌드합니다.
따라서 Hooks는 훨씬 더 빠를 수 있습니다.

스니펫에서 "총계" 필드의 동작이 깨졌습니다. 두 카운터가 함께 애니메이션을 적용할 수 있지만 다른 시간과 다른 곡선으로 애니메이션을 완료하는 예제와 일치하지 않습니다.

당신은 분명히 예제를 실행하려고 하지도 않았습니다. 그것은 당신의 코드와 똑같이 동작합니다.

마지막 요점은 TickerMode를 지원하지 않기 때문에 TickerProvider가 깨졌습니다.

이게 무슨 말인지 모르겠네요. TickerMode를 사용하지 않는 _your_ 예제를 리팩토링했습니다. 다시 요구 사항을 변경하고 있습니다.

공연의 경우 Hooks를 사용하면 단일 요소만 다시 빌드하는 반면 Builders는 2-4개 빌더를 다시 빌드합니다. 따라서 Hooks는 훨씬 더 빠를 수 있습니다.

아니 그냥 아니. 후크 위젯은 모든 단일 빌드에서 변경 사항을 지속적으로 폴링합니다. valuelistenables를 기반으로 하는 빌더는 "반응형"입니다.

마찬가지로 이 예제가 ValueListenableBuilder 변형에 무엇을 추가하는지 잘 모르겠습니다 .

그리고 Mobx는 주제에서 벗어날 가능성이 높습니다. 우리는 앰비언트 상태/ValueListenable vs Stores vs Streams를 구현하는 방법을 논의하는 것이 아니라, Mobx가 어떤 식으로든 해결하지 못하는 로컬 상태/ 중첩 빌더 를 처리하는 방법에 대해 논의하고 있습니다.

농담이시군요. 나는 당신의 예를 들어 중첩된 ValueListenableBuilders *와 트윈 빌더를 "다뤘습니다"?! 구체적으로 문제로 제기한 점.
그러나 여기 이 문장은 이 토론에 대한 당신의 전체적인 태도를 설명합니다. 후크가 아닌 경우 "주제에서 벗어남"이지만 솔루션으로 사용할 후크인지 여부는 신경 쓰지 않는다고 말합니다.
쉬게 해줘

당신은 분명히 예제를 실행하려고 하지도 않았습니다. 코드와 똑같이 작동합니다.

그렇지 않습니다. 첫 번째 카운터는 5초 동안, 두 번째 카운터는 2초 동안 움직이며 둘 다 다른 곡선도 사용합니다.

내가 준 두 스니펫을 사용하여 두 카운터를 동시에 증가시킬 수 있으며 애니메이션의 모든 단일 프레임 동안 "총계"가 정확할 것입니다. 첫 번째 카운터가 계속 움직이는 동안 두 번째 카운터가 애니메이션을 중지하더라도

반면에 구현에서는 2개의 TweenAnimationBuilder를 하나로 병합했기 때문에 이 경우를 고려하지 않습니다.
이를 수정하려면 다음과 같이 작성해야 합니다.

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

두 개의 TweenAnimationBuilders 는 두 카운터 모두 개별적으로 애니메이션할 수 있다는 사실을 존중하는 데 필요합니다. 그리고 첫 번째 Observer 는 counters.secondCounter 관찰할 수 없기 때문에 두 개의 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://dash-overflow.net/articles/why_vsync/

그리고 이 접근 방식을 사용하면 원래 TweenAnimationBuilder가 필요한 모든 위치에서 Tween 논리를 다시 구현해야 합니다. 특히 논리가 그렇게 사소하지 않다는 점을 고려하면 상당한 중복이 발생합니다.

내가 준 두 스니펫을 사용하여 두 카운터를 동시에 증가시킬 수 있으며 애니메이션의 모든 단일 프레임 동안 "총계"가 정확할 것입니다. 첫 번째 카운터가 계속 움직이는 동안 두 번째 카운터가 애니메이션을 중지하더라도

반면에 구현에서는 2개의 TweenAnimationBuilder를 하나로 병합했기 때문에 이 경우를 고려하지 않습니다.

네, 그건 제가 기꺼이 하려고 했던 절충안입니다. 애니메이션이 변경 사항에 대한 시각적 피드백일 뿐이고 정확성이 중요하지 않은 경우를 쉽게 상상할 수 있습니다. 그것은 모두 요구 사항에 달려 있습니다.

나는 당신이 이의를 제기할 것이라고 생각했기 때문에 이 정확한 문제를 해결하는 동시에 코드를 더욱 깔끔하게 만드는 두 번째 버전이 있습니다.

요점을 언급하는 경우 이전에 언급했듯이 이 접근 방식은 TickerProvider/TickerMode를 중단합니다. vsync는 SingleTickerProviderClientStateMixin을 사용하여 가져와야 하며 그렇지 않으면 성능 문제를 일으킬 수 있는 음소거 논리를 지원하지 않습니다.

따라서 위젯에서 tickerprovider를 생성하고 이를 카운터에 전달합니다. 또한 애니메이션 컨트롤러도 폐기하지 않았습니다. 이러한 세부 사항은 구현하기가 너무 쉬워서 예제에 아무것도 추가할 것 같지 않았습니다. 그러나 여기에서 우리는 그것들을 엿보고 있습니다.

나는 Counter() 클래스를 구현하여 귀하의 예제와 그 이상을 수행하지 않습니다.

그리고 이 접근 방식을 사용하면 원래 TweenAnimationBuilder가 필요한 모든 위치에서 Tween 논리를 다시 구현해야 합니다. 특히 논리가 그렇게 사소하지 않다는 점을 고려하면 상당한 중복이 발생합니다.

뭐라고 요? 왜요? 설명해주세요. Counter 클래스의 인스턴스를 두 개 이상 만들고 다양한 위젯에서 사용할 수 없는 이유는 무엇입니까?

@Rudiksz 귀하의 솔루션이 실제로 제시된 문제를 해결하고 있는지 잘 모르겠습니다. 당신은 말한다

나는 Counter() 클래스를 구현하여 귀하의 예제와 그 이상을 수행하지 않습니다.

그리고 아직

네, 그건 제가 기꺼이 하려고 했던 절충안입니다. 애니메이션이 변경 사항에 대한 시각적 피드백일 뿐이고 정확성이 중요하지 않은 경우를 쉽게 상상할 수 있습니다. 그것은 모두 요구 사항에 달려 있습니다.

따라서 위젯에서 tickerprovider를 생성하고 이를 카운터에 전달합니다. 또한 애니메이션 컨트롤러도 폐기하지 않았습니다. 이러한 세부 사항은 구현하기가 너무 쉬워서 예제에 아무것도 추가할 것 같지 않았습니다. 그러나 여기에서 우리는 그것들을 엿보고 있습니다.

@rrousselGit 의 후크 버전과 표면적으로만 동일한 코드를 제공했지만, 후크 버전에 포함된 부분을 생략했기 때문에 실제로는 동일하지 않습니다. 그런 경우에는 비교가 되지 않죠? 제안된 솔루션과 솔루션을 비교하려면 솔루션을 포함하지 않은 이유에 대해 이야기하는 대신 요구 사항과 정확히 일치하도록 하는 것이 가장 좋습니다. 이것이 @TimWhiting 의 저장소를 만드는 이유입니다. 모든 요구 사항을 충족했다고 생각되는 경우 솔루션을 제출할 수 있습니다.

당신은 분명히 예제를 실행하려고 하지도 않았습니다. 코드와 똑같이 작동합니다.

아니 그냥 아니.

농담이시군요. 나는 당신의 예를 취하고 중첩된 ValueListenableBuilders * 및 트윈 빌더를 "다루었습니다"

이러한 비난은 삼가해 주십시오. 이러한 비난은 근본적인 문제를 해결하지 않고 이 스레드를 악랄하게 만들 뿐입니다. 상대방을 비방하거나 비방하거나 화내지 않고 요점을 말할 수 있습니다. 이것이 제가 이 스레드에서 본 댓글의 효과입니다. 또한 자신의 게시물에 이모티콘으로 반응하는 효과가 무엇인지 잘 모르겠습니다.

@rrousselGit

링크된 스니펫을 기반으로 예제를 만드는 데 도움을 드릴 수 있지만 이 스니펫이 충분하지 않은 이유를 알아야 합니다.
그렇지 않으면 내가 할 수 있는 유일한 방법은 이러한 스니펫을 컴파일하는 것입니다. 하지만 그것이 당신이 원하는 것인지 의심스럽습니다.

내가 단순한 스니펫보다 더 정교한 앱을 요청하는 이유는 내가 귀하의 스니펫 중 하나를 처리한 예제를 게시했을 때, 당신이 그것이 적절하지 않은 다른 경우도 처리하지 않았기 때문에 충분하지 않다고 말했기 때문입니다. '(예: didUpdateWidget을 처리하지 않았거나 이러한 스니펫 중 두 개를 나란히 두는 것을 처리하지 않았거나 처리하고자 하는 기타 완벽하게 합리적인 것). 좀 더 정교한 앱을 사용하면 솔루션이 확보되면 처리해야 하는 새로운 문제가 발생하는 "고민" 순간이 없도록 충분히 정교하게 만들 수 있기를 바랍니다. 분명히 우리 모두가 처리해야 하는 무언가를 놓칠 가능성이 있지만 아이디어는 기회를 최소화하는 것입니다.

그다지 환영받지 못하는 최근 게시물과 관련하여 여러분, 작은 예제로 왔다 갔다 하는 것보다 @TimWhiting 의 repo에서 예제를 만드는 데 집중합시다. 우리가 이미 논의한 바와 같이, 작은 예는 대안이 실제로 잘 작동함을 입증하기에 충분히 대표할 만큼 충분히 정교하지 않을 것입니다.

모든 요구 사항을 충족했다고 생각되는 경우 솔루션을 제출할 수 있습니다.

사실 이후에 요구 사항이 변경되었습니다. 나는 두 가지 해결책을 제시했다. 타협을 하는 것(매우 합리적인 것)과 제공된 예제를 정확히 구현하는 것.

@rrousselGit 의 후크 버전과 표면적으로만 동일한 코드를 제공했지만 실제로는 동일하지 않습니다.

"후크 솔루션"을 구현하지 않고 ValueListenableBuilder 예제를 구현했으며 특히 "중첩 문제"에 중점을 둡니다. 후크가 하는 모든 일을 하는 것은 아닙니다. 저는 단순히 불만 목록의 한 항목을 대체 솔루션을 사용하여 단순화할 수 있는 방법을 보여주었습니다.

토론에 외부 패키지를 가져올 수 있다면 저도 마찬가지입니다.

재사용성: 아래 리포지토리의 예를 살펴보세요.
https://github.com/Rudiksz/cbl_example

메모:

• 위젯 외부에서 "논리"를 캡슐화하고 거의 HTML처럼 보이는 린(lean) 위젯을 갖는 방법을 보여주기 위한 것입니다.
• 후크가 덮는 모든 것을 덮지는 않습니다. 그것은 요점이 아니다. 나는 우리가 후크 패키지가 아니라 스톡 Flutter 프레임워크에 대한 대안에 대해 논의하고 있다고 생각했습니다.
• 모든 마케팅 팀이 제시할 수 있는 _모든_ 사용 사례는 다루지 않습니다.
• 그러나 Counter 개체 자체는 매우 유연하며 서로 다른 카운터의 합계를 계산하거나 반응형으로 만들거나 사용자 입력에 응답해야 하는 복잡한 위젯의 일부로 독립 실행형으로 사용할 수 있습니다(AppBar 제목 참조).
• 사용하려는 카운터의 양, 초기 값, 지속 시간, 애니메이션 유형을 사용자 지정하는 것은 소비 위젯에 달려 있습니다.
• 애니메이션 처리 방식의 세부 사항에는 단점이 있을 수 있습니다. Flutter 팀이 위젯 외부에서 애니메이션 컨트롤러와 트윈을 사용하여 어떻게든 프레임워크를 깨뜨릴 수 있다고 말하면 저는 재고하겠습니다. 개선할 점은 분명히 있습니다. 내가 사용하는 사용자 지정 tickerprovider를 소비 위젯의 mixin으로 만든 것으로 바꾸는 것은 간단합니다. 나는 그것을 하지 않았다.
• 이것은 "Builder" 패턴에 대한 또 하나의 대안일 뿐입니다. Builders가 필요하거나 사용하고 싶다고 말하면 해당 사항이 없습니다.
• 그래도 사실은 추가 기능 없이 코드를 단순화할 수 있는 방법이 있다는 것입니다. 마음에 들지 않으면 사지 마십시오. 나는 이것을 프레임워크로 만들기 위해 이것을 옹호하는 것이 아니다.

편집: 이 예제에는 버그가 있습니다. 변경 사항이 애니메이션되는 동안 "증가"를 시작하면 카운터가 재설정되고 현재 값에서 증가합니다. 이 "카운터"에 대한 정확한 요구 사항을 모르기 때문에 일부러 수정하지 않았습니다. 이 문제를 해결하기 위해 증가/감소 방법을 변경하는 것은 간단합니다.

그게 다야.

@Hixie 내 예(https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/hooks/animated_counter.dart)가 충분하지 않다고 말하는 방식으로 귀하의 의견을 해석해야 합니까?

또한 Zoom/Google 모임 통화를 할 수 있습니까?

또한 자신의 게시물에 이모티콘으로 반응하는 효과가 무엇인지 잘 모르겠습니다.

아무것도. 그것은 전혀 관련이 없습니다. 왜 꺼냈어?

@rrousselGit 충분히 좋은지 본인 만이 알 수 있습니다. 해당 예제를 리팩토링하여 깔끔하고 짧고 중복 코드가 없도록 하는 방법을 찾으면 만족하실까요? 아니면 이 버그를 충족시키기 위해 처리해야 하는 해당 예제에서 처리되지 않는 지원해야 한다고 생각하는 항목이 있습니까?

충분히 좋은지 당신만이 알 수 있습니다

나는 그것에 대해 판단할 수 없다. 우선, 유한한 응용 프로그램 집합을 사용하여 문제를 포착할 수 있다고 생각하지 않습니다.

나는 당신이 원하는 대로 일하는 것에 신경 쓰지 않지만 그것이 우리를 어떻게 발전시킬지 이해하지 못하기 때문에 지도가 필요합니다.

우리의 관점에서 문제를 보여주는 수많은 코드 조각을 제공했다고 생각합니다. 표시된 예제가 수행하지 않는 경우 더 많은 코드 예제를 통해 더 명확해질 것이라고 생각하지 않습니다.

예를 들어 읽기에 끔찍한 여러 중첩 빌더나 버그가 발생할 가능성이 많은 50줄의 순수 상용구를 보고도 문제를 충분히 강력하게 입증하지 못한다면 갈 곳이 없습니다.

전체 요청이 캡슐화된 상태 일 때 믹스인을 제안하고 함수가 솔루션인 것은 매우 이상합니다. 다시 사용할 수 있습니다. 함수는 상태를 유지할 수 없습니다. 믹스인은 캡슐화되지 않습니다. 이 제안은 제공된 모든 예와 근거의 요점을 놓치고 여전히 질문에 대한 깊은 오해를 보여줍니다.

제 생각에는 우리가 2점을 이기고 있다고 생각합니다. 어느 쪽도 심각하게 논쟁할 수 없다고 생각합니다.

1. 중첩 빌더는 본질적으로 읽기 어렵습니다.
2. 중첩된 빌더 외에 위젯 수명 주기 후크가 있는 상태를 캡슐화하고 공유하는 _방법이 없습니다_.

여러 번 언급했듯이 Remi의 설문조사에서도 간단히 말해서: 우리는 builder의 장황함과 중첩된 클로저 없이 builder의 기능을 원합니다. 그것이 완전히 요약되지 않습니까? 여기서 계속 진행하려면 추가 코드 예제가 필요한 이유가 완전히 혼란스럽습니다.

Remi의 설문조사에 따르면 Flutter 개발자의 80%는 가능한 경우 코드에서 중첩된 빌더를 피하는 일종의 기능을 선호합니다. 이것은 정말로 그 자체로 말해줍니다. 커뮤니티 감정이 매우 명확할 때 이 스레드에서 우리에게서 그것을 가져갈 필요가 없습니다.

내 관점에서 문제는 명확하며 여기에서 근거를 설명하는 데 단락을 지정하는 경쟁 프레임워크를 보면 훨씬 더 명확해집니다. Vue, React, Flutter는 모두 사촌이며 모두 React에서 파생되었으며 위젯 수명 주기에 연결해야 하는 재사용 상태와 관련된 이 문제에 모두 직면합니다. 그들은 모두 왜 이와 같은 것을 구현했는지 자세히 설명합니다. 괜찮습니다. 모두 관련이 있습니다.

@rrousselGit 여러 개의 후크가 있는 예를 만들 수 있습니까? 예를 들어, 수십 개의 AnimationController를 사용하여 애니메이션을 만들고 있습니다. 일반 Flutter로 다음을 수행할 수 있습니다.

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의 설문조사에서도 간단히 말해서: 우리는 builder의 장황함과 중첩된 클로저 없이 builder의 기능을 원합니다. 그것이 완전히 요약되지 않습니까? 여기서 계속 진행하려면 추가 코드 예제가 필요한 이유가 완전히 혼란스럽습니다.

나는 말 그대로 Remi가 제공한 예제를 사용하여 장황함을 줄이고 빌더의 중첩을 피할 수 있는 방법에 대한 예제를 제공했습니다.
나는 그의 코드를 내 앱에 집어넣고 실행하고 다시 작성했습니다. 기능에 관한 한 최종 결과는 거의 동일했습니다. 코드에 요구 사항이 없었기 때문에 코드를 실행하는 것만으로도 알 수 있었습니다. 물론 우리는 극단적인 경우와 잠재적인 문제에 대해 논의할 수 있지만 그 대신 주제를 벗어난 것으로 불렸습니다.

간단한 사용 사례에는 Builders를 사용하고 복잡한 사용 사례에는 Builders를 사용하지 않습니다. 여기서 주장은 빌더를 사용하지 않고 간결하고 재사용 가능한 코드를 작성하는 쉬운 방법이 없다는 것입니다. 암시적으로 이는 Builders가 반드시 있어야 하며 Flutter 앱을 개발하는 유일한 방법이라는 의미이기도 합니다. 그것은 명백히 거짓입니다.

방금 작동하는 개념 증명 코드를 보여주었습니다. 빌더나 후크를 사용하지 않았으며 이 특정 github 문제가 해결하고자 하는 "무한한 문제 세트"를 100% 다루지 않습니다. 주제를 벗어난 것이라고 했습니다.
참고로, 벤치마크가 없어도 빌더 위젯을 능가할 정도로 매우 효율적입니다. 잘못된 것으로 판명되면 마음을 바꾸게 되어 기쁩니다. Mobx가 성능 병목 현상이 되는 것을 발견하면 즉시 Mobx를 버리고 바닐라 빌더로 전환할 것입니다.

Hixie는 Google에서 일하기 때문에 인내심을 갖고 예의 바르게 대해야 하며 참여가 부족하다고 부를 수 없습니다. 그가 할 수 있는 최선은 더 많은 예를 제시하는 것입니다.

나는 누구의 이름도 부르지 않았고 인신공격도 하지 않았다. 나는 여기에 제시된 주장에만 반응했으며 내 의견을 공유했습니다.
(내가 아는 것은 인기가 없고 소수에 불과함) 심지어 실제 카운터 예제를 코드로 제시하려고 시도했습니다. 더 많은 것을 할 수 있습니다. 제 사례가 부족한 부분에 대해 논의하고 이를 개선할 수 있는 방법을 모색하고 싶지만, 주제에서 벗어나는 것은 일종의 불쾌한 일입니다.

나는 금지당하는 것 외에는 잃을 것이 없기 때문에 당신을 불러도 상관없습니다.
당신이 경험하는 문제가 무엇이든 간에 후크가 유일한 해결책("React가 그것을 수행하기 때문에")이고 대안이 당신이 상상하는 "무한한 문제 세트"를 100% 채우지 않는 한, 당신 둘은 죽은 세트라는 것이 분명합니다. 당신은 참여를 고려하지 않을 것입니다.

이는 합리적이지 않으며 진정으로 참여하려는 욕구가 부족함을 보여줍니다.

물론 위의 내용은 모두 "내 생각일 뿐"입니다.

그 예에서 후크의 유용성을 보았지만 내 경우에는 많은 개체를 한 번에 초기화하려는 것처럼 보이는 경우(이 경우 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를 사용하여 요청 시 후크 개체(예: AnimationController)의 배열을 만들고 이미 인스턴스화된 폐기를 원합니다. 후크에서 어떻게 작동하는지 잘 모르겠습니다.

@satvikpendem 은 클래스의 속성과 같은 후크에 대해 생각합니다. 루프에서 정의하거나 수동으로 하나씩 이름을 지정합니까?

다음과 같이 정의하는 귀하의 예에서

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는 앱이 로드 상태일 때 연결됨)

두 번째 스니펫에서는 루프에서 useState 를 호출합니다. useState 를 상태 논리의 일부가 아닌 가치 보유자로 생각하고 있습니다. 이 목록은 ListView 에 항목의 무리를 표시하는 데 필요합니까? 그렇다면 목록의 모든 항목을 개별적으로가 아닌 상태로 생각해야 합니다.

final listData = useState([]);

이것은 useState 에 대한 것이며 조건이나 루프에서 일부 후크를 호출하는 몇 가지 사용 사례(매우 드물다고 생각합니다)를 볼 수 있습니다. 이러한 종류의 후크에는 데이터 목록을 처리하기 위한 후크가 있어야 합니다. 예를 들어:

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());
  }
}

이것은 단일 버전의 후크가 있는 경우 단순히 여러 항목이 있는 버전에 사용할 수 없고 대신 논리를 다시 작성해야 함을 의미합니까? 아니면 이 작업을 수행하는 더 좋은 방법이 있습니까?

누군가가 non-hooks 예제를 제공하고 싶어도 저도 알고 싶습니다. 재사용 가능성 퍼즐의 이 부분에 대해 궁금합니다. 고유한 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 여러 개의 후크가 있는 예를 만들 수 있습니까? 예를 들어, 수십 개의 AnimationController를 사용하여 애니메이션을 만들고 있습니다. 일반 Flutter로 다음을 수행할 수 있습니다.

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개의 애니메이션 컨트롤러를 만들었지만 다른 위젯이 소유하고 있습니다.

왜 그것이 필요한지에 대한 예를 공유하고 후크로 변환하여 Tim의 저장소에 추가할 수 있습니까?

Hixie는 Google에서 일하기 때문에 인내심을 갖고 예의 바르게 대해야 하며 참여가 부족하다고 부를 수 없습니다. 그가 할 수 있는 최선은 더 많은 예를 제시하는 것입니다.

@Hixie , 그렇게 느끼시면 그렇게 말씀해 주세요(여기에서 또는 개인적으로 저에게 연락하십시오).

나는 말 그대로 Remi가 제공한 예제를 사용하여 장황함을 줄이고 빌더의 중첩을 피할 수 있는 방법에 대한 예제를 제공했습니다.

감사합니다. 하지만 이 논리를 다른 사용 사례에 적용할 때 이 코드에서 공통 패턴을 추출하는 방법이 명확하지 않습니다.

OP에서 나는 현재 3가지 선택이 있다고 언급했습니다.

• 빌더를 사용하고 중첩 코드가 있습니다.
• 더 복잡한 상태 논리로 확장되지 않는 코드를 인수분해하지 마십시오( StreamBuilder 및 AsyncSnapshot 는 복잡한 상태 논리라고 주장합니다).
• mixins/oop/...를 사용하여 일부 아키텍처를 구성하려고 시도하지만 _작은_ 비트가 다른 모든 사용 사례에서 다시 작성해야 하는 문제에 너무 특정한 솔루션으로 끝납니다.

세 번째 선택( 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 에 대해 하나의 AnimationController ). 다음은 여러 위젯 간에 공유되는 단 하나의 AnimationController로 만든 버전입니다. 그러나 미래에는 각 위젯을 독립적으로 애니메이션할 수 있습니다. 예를 들어 맞춤 스크롤 휠 효과를 사용하여 CupertinoPicker 구현과 같은 복잡한 변환을 수행할 수 있습니다. .

Stack에는 FloatingActionButton을 클릭할 때 위아래로 움직이는 세 개의 상자가 있습니다.

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 위치에 대한 데이터를 알고 있습니다.

문제는 AnimationControllers와 움직임을 구동하는 데 사용하는 Box 가 같은 클래스에 있지 않기 때문에 사용할 배열을 유지하여 AnimationController를 통과해야 한다는 것입니다. Builder 또는 각 Box 가 자체 AnimationController를 유지하도록 합니다.

후크를 사용하면 Box es와 상위 위젯이 같은 클래스에 있지 않은 경우 각 Box 가 AnimationController에서 전달되는 첫 번째 경우에 대해 AnimationController 목록을 어떻게 만들까요? 이것은 HookBuilder를 사용한 위의 답변을 기반으로 할 때 필요하지 않은 것 같지만, 말씀하신 대로 상태를 하위 위젯으로 이동하고 각 Box useAnimationController 를 통해 자체 AnimationController를 갖도록 선택하면 , 또 다른 문제가 발생합니다. 생성된 AnimationController를 부모 클래스에 노출하여 각 자식에 대한 독립 애니메이션을 조정하고 실행할 수 있도록 하려면 어떻게 해야 합니까?

Vue에서는 emit 패턴을 통해 이벤트를 부모에게 다시 내보낼 수 있으므로 Flutter에서는 부모가 전역 상태를 업데이트하고 자식이 전역 상태를 수신하는 Riverpod 또는 Rx와 같은 고급 상태 관리 솔루션이 필요합니까? 상태? 적어도 이와 같은 간단한 예에서는 그렇지 않은 것 같습니다. 내 혼란을 해결해 주셔서 감사합니다.

@satvikpendem 죄송합니다. 명확하지 않았습니다. 후크로 차단하는 문제가 아니라 후크 없이 수행하는 방법을 보여줄 수 있습니까?

어디에서 막히기 보다는 무엇을 하려는지 명확히 이해하고 싶습니다.

그러나 빠른 추측으로, 대신 Interval 곡선을 찾고 있고 단일 애니메이션 컨트롤러가 있다고 생각합니다.

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

나는 실제로 각 위젯에 대해 하나씩 여러 애니메이션 컨트롤러를 원합니다. 서로 독립적으로 이동할 수 있고 자체 지속 시간, 곡선 등을 사용할 수 있기 때문입니다. 위의 코드에는 내가 파악할 수 없는 버그가 있는 것 같습니다. 깔끔하게 애니메이션되어야 하지만 기본적으로 버튼 클릭 시 3개의 상자를 위아래로 애니메이션해야 합니다. 우리는 각각이 동일한 곡선을 갖는 대신에 각각 다른 곡선을 제공하거나 이전 것보다 지속 시간이 더 길거나 짧은 100개의 상자를 만들거나 짝수를 위로 올리는 시나리오를 상상할 수 있습니다. 이상한 것들은 내려갑니다.

일반 Flutter를 사용하면 initState 및 dispose 둘 다 루프를 가질 수 있지만 후크가 있는 것처럼 보이지 않으므로 어떻게 대처할 수 있는지 궁금합니다. 또한 Box 클래스를 부모 위젯 안에 넣고 싶지 않습니다. 둘 다 단단히 캡슐화하고 싶지 않기 때문입니다. 상위 논리를 동일하게 유지할 수 있어야 하지만 예를 들어 Box 를 Box2 로 바꿀 수 있어야 합니다.

감사 해요!
후크에 해당하는 @TimWhiting 의 repo에 귀하의 예를 푸시했습니다.

TL;DR, 후크(또는 빌더)를 사용하면 명령형이 아니라 선언형으로 생각합니다. 따라서 하나의 위젯에 컨트롤러 목록이 있는 대신 컨트롤러를 항목으로 이동하고 암시적 애니메이션을 구현하는 명령적으로 구동합니다.

@rrousselGit 감사합니다! 후크를 사용하기 시작한 후 잠시 동안 이러한 유형의 구현에 어려움을 겪었지만 이제 어떻게 작동하는지 이해합니다. 위에서 말했듯이 후크가 유용한 이유를 이해하는 데 더 매력적일 수 있으므로 각 애니메이션 컨트롤러에 대해 다른 대상이 있는 버전에 대한 PR을 열었습니다.

우리는 각각이 동일한 곡선을 갖는 대신에 각각 다른 곡선을 제공하거나 이전 것보다 지속 시간이 더 길거나 짧은 100개의 상자를 만들거나 짝수를 위로 올리는 시나리오를 상상할 수 있습니다. 이상한 것들은 내려갑니다.

선언적 버전을 만들려고 했으나 didUpdateWidget/Hook 수명 주기 방식이 이해가 안 된 것 같아서 자식 prop이 부모에서 변경되었을 때 애니메이션을 구동하는 방법을 몰랐습니다. 그러나 귀하의 코드로 해결되었습니다.

오늘 내 코드 기반에서 실제 예제를 발견했으므로 공유하는 것이 좋겠다고 생각했습니다.

따라서 이 시나리오에서 저는 Firestore로 작업하고 있으며 각 StreamBuilder로 수행할 몇 가지 상용구를 가지고 있으므로 나만의 사용자 정의 빌더를 만들었습니다. 또한 ValueListenable로 작업해야 합니다.사용자가 목록을 재정렬할 수 있습니다. Firestore와 관련된 금전적 비용상의 이유로 이것은 매우 구체적인 구현이 필요합니다(각 항목은 자체 주문을 저장할 수 없으며 대신 목록은 연결된 ID의 필드로 저장해야 함). 이런 식으로 잠재적으로 많은 돈을 절약할 수 있습니다. 다음과 같이 읽습니다.

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을 만들지 않습니다.

많은 실제 시나리오와 마찬가지로 "X를 사용하지 마십시오"라는 조언은 현실적이지 않습니다. Firebase에는 Streams라는 연결 방법이 하나만 있고 이 소켓과 같은 동작을 원할 때마다 선택의 여지가 없기 때문입니다. 스트림을 사용합니다. 세라비.

이렇게 하면 세분화된 재구성과 관련된 최적화가 손실되지만 모든 시각적 요소가 맨 아래 리프 노드에 있고 모든 래퍼가 순수 상태이므로 다른 IRL을 만들지 않습니다.

여전히 차이가 있습니다. 노드가 시각적인지 여부는 재구축 비용에 영향을 미치지 않습니다.

나는 아마도 그 예를 다른 위젯에 포함시킬 것입니다. _buildItemList 는 FamilyStreamBuilder 뿌리를 둔 부분과 마찬가지로 위젯이어야 합니다.

우리는 세분화된 재구축을 잃지 않습니다.
실제로 후크는 useMemoized 사용하여 위젯 인스턴스를 쉽게 캐시할 수 있도록 하여 이러한 측면을 개선합니다.

Tim의 repo에는 그렇게 하는 몇 가지 예가 있습니다.

나는 아마도 그 예를 다른 위젯에 포함시킬 것입니다. _buildItemList 는 FamilyStreamBuilder 뿌리를 둔 부분과 마찬가지로 위젯이어야 합니다.

문제는 이 보기에서 성능에 대한 우려가 전혀 없기 때문에 실제로 이 작업을 수행하고 싶지 않다는 것입니다. 따라서 100% 저는 이와 같은 미세 최적화보다 코드 지역성과 일관성을 선호합니다. 이 보기는 사용자가 작업을 시작하거나(~avg 10초당 한 번) 백엔드 데이터가 변경되고 열린 목록을 응시할 때(거의 발생하지 않음)에만 다시 작성됩니다. 또한 주로 목록인 단순한 보기일 뿐이며 목록에는 내부적으로 자체 최적화가 많이 있습니다. 나는 build()가 기술적으로 언제든지 실행할 수 있다는 것을 알고 있지만 실제로 임의의 재구축은 매우 드뭅니다.

이 모든 논리가 하나의 위젯에 그룹화되어 있으면 이 보기에서 작업하고 디버그하는 것이 훨씬 더 쉽습니다. 주로 나중에 다시 돌아올 때 내 삶을 더 쉽게 만들기 위한 노력입니다. :)

주의해야 할 또 다른 사항은 구멍에 있는 3개의 클로저와 16개의 공간 내부에 트리를 구성할 수 있는 방법이 없었기 때문에 중첩이 기본적으로 빌드 방법에서 "강제"되었다는 것입니다.

예, 그런 다음 별도의 위젯으로 이동하는 것이 합리적이라고 말할 수 있습니다. 하지만 빌드 방법에 머무르지 않는 이유는 무엇입니까? 상용구를 실제로 _필요로 하는 수준으로 줄일 수 있다면 2개의 파일로 항목을 분할하는 가독성 및 유지 관리 번거로움이 필요하지 않습니다. (성능이 문제가 아니라고 가정하고 종종 그렇지 않습니다)

이 시나리오에서 이미 Stream Builder를 처리하기 위해 사용자 지정 위젯을 만들었습니다. 이제 이 빌더의 구성을 처리하기 위해 다른 하나를 만들어야 합니까?? 약간 오버인 것 같습니다.

이 보기에서 성능 문제가 전혀 없기 때문에

오 성능을 위해 위젯으로 리팩토링하지 않겠습니다. 빌더가 이미 처리해야 합니다. 가독성과 재사용성을 위해 리팩토링하겠습니다. 나는 그것이 "올바른" 방법이라고 말하는 것이 아니라 코드를 구조화하는 방법을 말하는 것입니다. 어쨌든 그것은 여기도 저기도 아니다.

구멍에 3개의 클로저와 16개의 공간이 있는 내부에 트리를 구성할 방법이 없습니다.

나는 당신보다 더 넓은 모니터를 가질 수 있습니다 ... :-/

그런 다음 2개의 파일로 항목을 분할하는 가독성 및 유지 관리 번거로움이 필요하지 않습니다.

위젯을 같은 파일인 FWIW에 넣겠습니다.

어쨌든, 이것은 좋은 예이며 더 많은 위젯을 사용하는 것보다 구문이 다른 하나의 위젯을 사용하는 것이 더 낫다고 생각합니다.

나는 당신보다 더 넓은 모니터를 가질 수 있습니다 ... :-/

나는 ultrawide :D를 가지고 있지만 dartfmt는 분명히 우리 모두를 80으로 제한합니다. 따라서 16을 잃는 것은 중요합니다. 주요 문제는 내 진술의 끝이 },);});},),),); 뭔가 엉망이 되었을 때 정말 재미가 없다는 것입니다. 이 계층 구조를 편집할 때마다 매우 조심해야 하며 swap with parent 와 같은 일반적인 IDE 도우미가 작동을 멈춥니다.

위젯을 같은 파일인 FWIW에 넣겠습니다.

100%지만 여전히 단일 파일에서 수직으로 점프하는 것이 유지 관리하기가 더 어렵다는 것을 알았습니다. 물론 불가피하지만 가능하면 줄이고 '함께 하는 것'을 하려고 합니다.

결정적으로, 기본 목록을 자체 위젯으로 리팩토링하더라도(내 생각에는 중첩된 빌드 메서드보다 읽기 쉽습니다) 상위 위젯에 중첩되지 않은 상태에서 훨씬 더 읽기 쉽습니다. 내가 들어와서 모든 논리를 한 눈에 이해하고 _MyListView() 위젯을 명확하게 보고 바로 시작할 수 있으며 주변 컨텍스트를 이해한다고 확신합니다. 또한 상대적으로 쉽게 추가 종속성을 추가/제거할 수 있으므로 확장이 매우 잘 됩니다.

dartfmt는 분명히 우리 모두를 80으로 제한합니다.

내 말은, 그것이 내가 일반적으로 dartfmt를 사용하지 않는 이유 중 하나이며 사용할 때 120 또는 180자로 설정합니다...

여기에서의 경험은 완전히 유효합니다.

사실 저도 하루 종일 120입니다. :) 하지만 pub.dev는 80으로 포맷되지 않은 플러그인을 적극적으로 다운레이트합니다. 그리고 저는 이 값을 변경할 때 저(우리)가 소수라는 인상을 받습니다.

그건 말도 안 됩니다. 우리는 그것을 고쳐야 합니다.

pub.dev는 dartfmt를 존중하지 않는 플러그인을 평가하지 않습니다. 점수 페이지에는 댓글만 표시되지만 점수에는 영향을 미치지 않습니다.
그러나 틀림없이 dartfmt에는 라인 길이보다 더 많은 문제가 있습니다.

줄 길이가 너무 크면 다음과 같이 여러 줄에서 더 읽기 쉬운 것이 한 줄로 표시됩니다.

object
  ..method()
  ..method2();

다음이 될 수 있습니다.

object..method()..method2();

나는 이것을보고있다?

문제의 패키지: https://pub.dev/packages/sized_context/score

흥미롭습니다. 공급자가 한동안 dartfmt를 사용하지 않았기 때문에 이전에는 확실히 그렇지 않았습니다.
정정합니다.

네, 확실히 새로운 동작입니다. 제가 작년 봄에 처음 게시했을 때 모든 상자에 체크 표시를 했는지 확인했고 dartfmt가 필요하지 않았습니다.

이러한 모든 논의가 끝나면 Flutter에서 후크와 같은 솔루션에 대한 기본 지원을 볼 수 있기를 바랍니다. useHook 또는 use Hook 또는 flutter 팀이 자신의 기능이 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 의 예가 이제 사람들이 해결하고자 하는 문제를 대표한다고 가정하는 것이 맞습니까?

나는 다른 사람들이 어떻게 느끼는지 잘 모르겠지만 문제가 거기에 어느 정도 표현되어 있다고 생각합니다.

해당 저장소에서 중간 솔루션을 시도했습니다. 후크처럼 구성 가능하지만 함수 호출의 순서에 의존하지 않거나 루프를 허용하지 않습니다. StatefulWidget을 직접 사용합니다. 여기에는 믹스인과 키로 고유하게 식별되는 상태 저장 속성이 포함됩니다. 나는 이것을 궁극적인 해결책으로 홍보하려는 것이 아니라 두 접근 방식 사이의 중간 지점으로 홍보하려고 합니다.

저는 이것을 lifecycleMixin 접근 방식이라고 불렀습니다. 여기에서 논의한 LateProperty 접근 방식과 매우 유사하지만 주요 차이점은 구현된 수명 주기가 더 많고 쉽게 구성할 수 있다는 것입니다. (수명 주기 부분에서 나는 initState 이외의 위젯 수명 주기를 사용하지 않았고 많이 폐기했기 때문에 거기서 완전히 엉망이 되었을 수 있습니다).

나는 다음과 같은 이유로 이 접근 방식을 좋아합니다.

1. 런타임 페널티가 거의 없습니다.
2. 빌드 경로에 상태를 생성하거나 관리하는 로직/함수가 없습니다(빌드는 순수하게 상태를 가져오기만 할 수 있음).
3. 빌더를 통해 재구축을 최적화할 때 수명 주기 관리가 더 명확해집니다. (그러나 작은 상태 비트의 재사용성과 구성성을 희생하지는 않습니다.)
4. 상태 비트 생성을 재사용할 수 있으므로 특정 방식으로 생성 및 폐기해야 하는 공통 상태 비트로 라이브러리를 만들 수 있으므로 고유한 코드에 상용구가 적습니다.

다음과 같은 이유로 후크와 비교하여 이 접근 방식이 마음에 들지 않습니다.

1. 후크가 할 수 있는 모든 작업을 포함하는지 모르겠습니다.
2. 당신은 고유의 특성을 식별하기위한 키를 사용합니다. (따라서 일부 상태를 구성하는 로직을 구성할 때 상태의 각 부분을 고유하게 식별하기 위해 키에 추가해야 합니다. 키를 필수 위치 매개변수로 만드는 것이 도움이 되지만, 변수에 대한 고유 ID).
3. 공통 상태 비트를 생성하기 위해 재사용 가능한 함수를 생성하기 위해 확장을 많이 사용합니다. 그리고 확장은 IDE에서 자동으로 가져올 수 없습니다.
4. 다른 위젯의 수명 주기를 혼합하거나 명시적으로 올바르게 관리하지 않고 위젯 간에 액세스하면 자신을 엉망으로 만들 수 있습니다.
5. 빌더 구문이 약간 이상해서 생성된 상태가 빌드 함수의 범위에 있지만 빌드 함수는 순수하게 남겨둡니다.
6. 아직 모든 예제를 구현하지 않았으므로 다루지 못하는 사용 사례가 있을 수 있습니다.

간단한 카운터 예.
애니메이션 카운터 예

뼈대
재사용 가능한 상태 구성 논리의 공통 비트

시간이 얼마나 남았는지 잘 모르겠습니다. 대학원 공부는 항상 저를 바쁘게 만들고 있지만 피드백을 받고 싶습니다. @rrousselGit 이것이 후크에 얼마나 가깝습니까? 재사용성 또는 구성 가능성에 명백한 구멍이 있습니까?

내 솔루션을 홍보하려는 것이 아니라 중간 지점에서 긍정적인 토론을 장려하는 것입니다. 우리가 누락된 사항이나 이 솔루션이 제공하는 사항에 대해 동의할 수 있다면 앞으로 좋은 진전을 이룰 것이라고 생각합니다.

@TimWhiting 이 접근 방식의 주요 문제는 견고성 부족입니다. 여기서 큰 동인은 간결한 형태로 건축업자의 신뢰성에 대한 필요성입니다. 매직 id와 수명 주기에서 충돌하는 기능은 모두 버그가 발생하기 위한 새로운 벡터를 생성하며, 읽기에는 꽤 불쾌하지만 적어도 우리는 그들이 100개라는 것을 알고 있기 때문에 빌더를 사용하는 것을 팀에 계속 권장할 것입니다. % 버그가 없습니다.

예제와 관련하여 여전히 완벽한 예제는 위젯에 연결된 기간 값과 함께 AnimationController를 사용하는 것이라고 생각합니다. 간단하고 친숙하게 유지합니다. 이보다 더 난해할 필요는 없습니다. 재사용 가능한 상용구에 대한 완벽한 작은 사용 사례이며, 수명 주기 후크가 필요하며, 모든 솔루션은 여러 애니메이션을 간결하게 사용할 수 있는 능력으로 쉽게 판단할 수 있습니다.

다른 모든 것은 이와 동일한 사용 '상태 저장 컨트롤러' 사용 사례의 변형일 뿐입니다. initState에서 X를 수행하고 dispose 상태에서 Y를 수행하고 종속성이 변경되면 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 다른 암시적으로 애니메이션된 위젯이 필요의 큰 부분을 차지합니다.
  flutter_hooks에 useImplicitlyAnimatedInt 후크를 추가하면 변경될 수 있습니다.

@esDotDev lifecycleMixin 접근 방식에서 키/ID의 필요성을 제거했습니다. 빌더 구문에서는 여전히 약간 어색합니다. 그러나 결국에는 그것이 도움이 될 수도 있습니다. 내가 겪고 있는 한 가지 문제는 유형 시스템입니다. 작동하지 않는 특정 방식으로 일을 던지려고 합니다. 그러나 아마도 주의 깊은 캐스팅이나 유형 시스템 숙달이 필요할 것입니다. 라이프사이클을 혼합하는 한, 액세스하려는 특정 상태가 해당 위젯의 라이프사이클에서 액세스할 수 없는 경우 몇 가지 합리적인 예외를 발생시켜 개선할 수 있다고 생각합니다. 또는 lifecyclebuilder 내에서 빌더의 수명 주기에만 액세스해야 하는 린트입니다.

Remi 덕분에 놀랐습니다. 사람들이 Animation을 매우 자주 사용하여 코어에 있는 대규모 전환 위젯 모음을 구동할 것이라고 생각합니다. .

여전히 AnimatorController가 암시적 및 명시적 위젯 제품군과 함께 매우 잘 제공되고 있음에도 불구하고 여전히 '상태를 유지하고 위젯 매개변수 및 수명 주기에 연결해야 하는 것'의 훌륭한 예라고 생각합니다. 그리고 해결해야 할 문제의 완벽한 작은 예로서 역할을 합니다(사실은 Flutter에서 12개의 위젯이 있음에도 불구하고 완전히 해결되었습니다). 우리 모두는 콘텐츠가 아닌 아키텍처에 대해 논의하고 집중할 수 있습니다.

예를 들어 var anim = AnimationController.use(context, duration: widget.duration ?? _duration); 가 일등 시민이라면 이러한 암시적 또는 명시적 애니메이션이 실제로 존재할 필요가 없는 방법을 생각해 보십시오. 위젯의 컨텍스트 내에서 상태 저장 사물(AnimationController)을 쉽게 합성하는 핵심 문제를 관리하기 위해 모두 생성되었기 때문에 중복으로 렌더링됩니다. AnimatedBuilder + AnimatorController.use() 동일한 작업을 수행할 수 있으므로 TAB 은 거의 무의미해집니다.

애니메이션 주위에 생겨난 엄청난 양의 위젯을 보면 일반적인 사용 사례의 필요성을 잘 보여줍니다. 핵심 설정/해제 로직을 재사용하는 것은 매우 번거롭고 버그가 발생하기 쉬우므로 15개 이상의 위젯이 모두 매우 구체적인 작업을 처리하지만 대부분은 몇 가지만 사용하여 동일한 애니메이션 상용구를 반복하고 있습니다. 많은 경우에 고유한 코드 라인.

예, 우리 자신의 상태 저장 논리를 재사용하기 위해 이 작업을 수행할 수도 있음을 보여줍니다. 사용의 모든 단일 순열에 대한 위젯을 만듭니다. 그러나 얼마나 번거롭고 유지 관리가 골치 아픈지! 수명 주기 후크를 사용하여 작은 상태 저장 개체를 쉽게 구성할 수 있는 방법이 훨씬 더 좋으며, 렌더링을 위한 전용 위젯이나 재사용 가능한 빌더를 만들려는 경우 맨 위에 레이어를 쉽게 만들 수 있습니다.