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

जो कोड की कुछ दोहराई गई पंक्तियों से छुटकारा दिलाता है। आप डीबग गुणों के लिए एक समान सार वर्ग लिख सकते हैं, और यहां तक ​​​​कि एक जो दोनों को जोड़ता है। आपकी init स्थिति कुछ इस तरह दिख सकती है:

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

क्या हम डिस्पोजेबल कक्षाओं के लिए ऐसी टाइपिंग जानकारी प्रदान करने से चूक रहे हैं?

मुझे चिंता है कि ढांचे के भीतर इसे आसान बनाने का कोई भी प्रयास वास्तव में उस जटिलता को छुपाएगा जिसके बारे में उपयोगकर्ताओं को सोचना चाहिए।

विजेट उस जटिलता को छुपाते हैं जिसके बारे में उपयोगकर्ताओं को सोचना होता है।
मुझे यकीन नहीं है कि यह वास्तव में एक समस्या है।

अंत में यह उपयोगकर्ताओं पर निर्भर करता है कि वे इसे कैसे भी चाहते हैं।

समस्या सिर्फ डिस्पोजल की नहीं है।

यह समस्या के अद्यतन भाग को भूल जाता है। स्टेज लॉजिक जीवनचक्र पर भी भरोसा कर सकता है जैसे कि didChangeनिर्भरताएं और didUpdateWidget।

कुछ ठोस उदाहरण:

• SingleTickerProviderStateMixin जिसके अंदर तर्क है didChangeDependencies ।
• AutomaticKeepAliveClientMixin, जो super.build(context) पर निर्भर करता है

ढांचे में कई उदाहरण हैं जहां हम राज्य तर्क का पुन: उपयोग करना चाहते हैं:

• स्ट्रीमबिल्डर
• ट्विनएनीमेशनबिल्डर
  ...

ये कुछ और नहीं बल्कि एक अद्यतन तंत्र के साथ राज्य का पुन: उपयोग करने का एक तरीका है।

लेकिन वे उसी मुद्दे से पीड़ित हैं जैसा कि "बिल्डर" भाग पर उल्लेख किया गया है।

जिससे कई समस्याएं होती हैं।
उदाहरण के लिए स्टैक ओवरफ्लो पर सबसे आम मुद्दों में से एक यह है कि लोग साइड इफेक्ट के लिए StreamBuilder का उपयोग करने की कोशिश कर रहे हैं, जैसे "परिवर्तन पर एक मार्ग धक्का"।

और आखिरकार उनका एकमात्र समाधान स्ट्रीमबिल्डर को "बेदखल" करना है।
इसमें शामिल है:

• विजेट को स्टेटफुल में बदलना
• मैन्युअल रूप से स्ट्रीम को initState+didUpdateWidget+didChangeनिर्भरता में सुनें
• जब धारा बदलती है तो 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)); }

यह अपने आप में जटिल नहीं है। समस्या तब शुरू होती है जब हम उस दृष्टिकोण को मापना चाहते हैं।
एक विशिष्ट फ़्लटर ऐप में दर्जनों टेक्स्ट-फ़ील्ड हो सकते हैं, जिसका अर्थ है कि यह तर्क कई बार दोहराया गया है।

इस तर्क को हर जगह कॉपी-पेस्ट करना "काम करता है", लेकिन हमारे कोड में कमजोरी पैदा करता है:

• किसी एक चरण को फिर से लिखना भूलना आसान हो सकता है (जैसे dispose पर कॉल करना भूल जाना)
• यह कोड में बहुत अधिक शोर जोड़ता है

मुझे वास्तव में यह समझने में परेशानी होती है कि यह समस्या क्यों है। मैंने बहुत सारे स्पंदन अनुप्रयोग लिखे हैं, लेकिन यह वास्तव में इतना बड़ा मुद्दा नहीं लगता है? यहां तक ​​​​कि सबसे खराब स्थिति में, संपत्ति घोषित करने, इसे प्रारंभ करने, इसे निपटाने और इसे डीबग डेटा पर रिपोर्ट करने के लिए चार लाइनें हैं (और वास्तव में यह आमतौर पर कम है, क्योंकि आप आमतौर पर इसे उसी लाइन पर घोषित कर सकते हैं जिसे आप इसे प्रारंभ करते हैं, आम तौर पर ऐप्स डीबग गुणों में राज्य जोड़ने के बारे में चिंता करने की आवश्यकता नहीं है, और इनमें से कई वस्तुओं में राज्य नहीं है जिसे निपटाने की आवश्यकता है)।

मैं सहमत हूं कि प्रति संपत्ति प्रकार एक मिश्रण काम नहीं करता है। मैं मानता हूं कि बिल्डर पैटर्न अच्छा नहीं है (यह सचमुच ऊपर वर्णित सबसे खराब स्थिति के समान ही लाइनों का उपयोग करता है)।

NNBD के साथ (के साथ विशेष रूप late final तो initiializers संदर्भित कर सकते हैं कि 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),
      ),
    );
  }
}

ऐसा लगता है कि वास्तव में चीजें बेहतर नहीं होती हैं। यह अभी भी चार लाइनें है।

विजेट उस जटिलता को छुपाते हैं जिसके बारे में उपयोगकर्ताओं को सोचना होता है।

वे क्या छिपाते हैं?

समस्या रेखाओं की संख्या नहीं है, बल्कि ये रेखाएँ क्या हैं।

StreamBuilder लगभग stream.listen + setState + subscription.close जितनी लाइनें हो सकती हैं।
लेकिन StreamBuilder लिखना बिना किसी प्रतिबिंब के किया जा सकता है, ऐसा कहने के लिए।
प्रक्रिया में कोई गलती संभव नहीं है। यह सिर्फ "स्ट्रीम पास करें, और इसमें से विजेट बनाएं"।

जबकि कोड को मैन्युअल रूप से लिखने में बहुत अधिक विचार शामिल होते हैं:

• क्या समय के साथ धारा बदल सकती है? अगर हम इसे संभालना भूल गए, तो हमारे पास एक बग है।
• क्या हम सब्सक्रिप्शन बंद करना भूल गए? एक और बग
• सदस्यता के लिए मैं किस चर नाम का उपयोग करूं? वह नाम उपलब्ध नहीं हो सकता है
• परीक्षण के बारे में क्या? क्या मुझे परीक्षण की नकल करनी है? StreamBuilder , स्ट्रीम को सुनने के लिए यूनिट परीक्षण लिखने की कोई आवश्यकता नहीं है, यह बेमानी होगा। लेकिन अगर हम इसे हर समय मैन्युअल रूप से लिखते हैं, तो गलती करना पूरी तरह से संभव है
• यदि हम एक साथ दो धाराओं को सुनते हैं, तो अब हमारे पास बहुत ही समान नामों वाले कई चर हैं जो हमारे कोड को प्रदूषित करते हैं, यह कुछ भ्रम पैदा कर सकता है।

वे क्या छिपाते हैं?

• FutureBuilder/StreamBuilder श्रवण तंत्र को छुपाता है और वर्तमान स्नैपशॉट क्या है इसका ट्रैक रखता है।
  दो Future बीच स्विच करने का तर्क भी काफी जटिल है, क्योंकि इसमें subscription.close() ।
• AnimatedContainer पिछले और नए मानों के बीच एक ट्वीन बनाने के तर्क को छुपाता है।
• सूचीदृश्य "एक विजेट को माउंट करें जैसा दिखता है" के तर्क को छुपाता है

ऐप्स को आमतौर पर डीबग गुणों में राज्य जोड़ने के बारे में चिंता करने की आवश्यकता नहीं होती है

वे नहीं करते, क्योंकि वे डिबगफिलप्रॉपर्टीज पद्धति को बनाए रखने की जटिलता से निपटना नहीं चाहते हैं।
लेकिन अगर हमने डेवलपर्स से कहा "क्या आप चाहते हैं कि यह बॉक्स से बाहर हो तो आपके सभी पैरामीटर और राज्य गुण फ़्लटर के डेवटोल पर उपलब्ध थे?" मुझे यकीन है कि वे हाँ कहेंगे

बहुत से लोगों ने मुझे रिएक्ट के devtool के बराबर एक सच्चे समकक्ष के लिए अपनी इच्छा व्यक्त की है। स्पंदन का devtool अभी तक नहीं है।
रिएक्ट में, हम विजेट की सभी स्थिति + उसके मापदंडों को देख सकते हैं, और इसे बिना कुछ किए संपादित कर सकते हैं।

इसी तरह, लोगों को बहुत आश्चर्य हुआ जब मैंने उन्हें बताया कि provider + मेरे कुछ अन्य पैकेजों का उपयोग करते समय, डिफ़ॉल्ट रूप से उनकी पूरी एप्लिकेशन स्थिति उन्हें दिखाई देती है, बिना कुछ किए ( मॉड्यूलो यह कष्टप्रद devtool बग )

मुझे यह स्वीकार करना होगा कि मैं फ्यूचरबिल्डर का बहुत बड़ा प्रशंसक नहीं हूं, यह बहुत सारे बग का कारण बनता है क्योंकि लोग यह नहीं सोचते कि भविष्य को कब ट्रिगर करना है। मुझे लगता है कि इसके लिए समर्थन छोड़ना हमारे लिए अनुचित नहीं होगा। StreamBuilder ठीक है मुझे लगता है लेकिन फिर मुझे लगता है कि स्ट्रीम स्वयं बहुत जटिल हैं (जैसा कि आप ऊपर अपनी टिप्पणी में उल्लेख करते हैं) तो ...

किसी को ट्वीन्स बनाने की जटिलता के बारे में क्यों सोचना पड़ता है?

ListView वास्तव में एक विजेट को माउंट करने के तर्क को छुपाता नहीं है जैसा दिखता है; यह एपीआई का एक बड़ा हिस्सा है।

समस्या रेखाओं की संख्या नहीं है, बल्कि ये रेखाएँ क्या हैं।

मैं वास्तव में यहाँ की चिंता को नहीं समझता। रेखाएँ साधारण बॉयलरप्लेट की तरह बहुत अधिक लगती हैं। चीज़ की घोषणा करें, चीज़ को इनिशियलाइज़ करें, चीज़ का निपटान करें। यदि यह पंक्तियों की संख्या नहीं है, तो समस्या क्या है?

मैं आपसे सहमत हूँ कि FutureBuilder समस्याग्रस्त है।

यह थोड़ा ऑफ-टॉपिक है, लेकिन मैं सुझाव दूंगा कि विकास में, स्पंदन को हर कुछ सेकंड में एक नकली हॉट-रीलोड को ट्रिगर करना चाहिए। यह फ्यूचरबिल्डर, चाबियों और कई अन्य चीजों के दुरुपयोग को उजागर करेगा।

किसी को ट्वीन्स बनाने की जटिलता के बारे में क्यों सोचना पड़ता है?

ListView वास्तव में एक विजेट को माउंट करने के तर्क को छुपाता नहीं है जैसा दिखता है; यह एपीआई का एक बड़ा हिस्सा है।

हम उस पर सहमत हैं। मेरा कहना था कि हम "यह तर्क छुपाता है" के साथ हुक जैसी किसी चीज़ की आलोचना नहीं कर सकते, क्योंकि हुक जो करते हैं वह TweenAnimationBuilder / AnimatedContainer /... के
तर्क छिपा नहीं है

अंत में, मुझे लगता है कि एनिमेशन एक अच्छी तुलना है। एनिमेशन में निहित बनाम स्पष्ट की यह अवधारणा है।
निहित एनिमेशन को उनकी सादगी, रचनाशीलता और पठनीयता के कारण पसंद किया जाता है।
स्पष्ट एनिमेशन अधिक लचीले होते हैं, लेकिन अधिक जटिल होते हैं।

जब हम इस अवधारणा का अनुवाद स्ट्रीम्स को सुनने में करते हैं, तो StreamBuilder एक _निहित श्रवण_ है, जबकि stream.listen _explicit_ है।

अधिक विशेष रूप से, StreamBuilder आप _cannot_ उस परिदृश्य को संभालना भूल जाते हैं जहां स्ट्रीम बदलती है, या सदस्यता बंद करना भूल जाते हैं।
आप कई StreamBuilder एक साथ भी जोड़ सकते हैं

stream.listen थोड़ा अधिक उन्नत और अधिक त्रुटि-प्रवण है।

एप्लिकेशन को सरल बनाने के लिए बिल्डर्स शक्तिशाली हैं।
लेकिन जैसा कि हम पहले सहमत थे, बिल्डर पैटर्न आदर्श नहीं है। यह लिखना और उपयोग करना दोनों क्रिया है।
यह मुद्दा, और जो हुक हल करता है, वह *बिल्डर्स . के लिए एक वैकल्पिक सिंटैक्स के बारे में है

उदाहरण के लिए, 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 के एपीआई का हिस्सा है कि यह नियंत्रक का मालिक है।
यह useFocusNode , useScrollController , useAnimationController , पर लागू होता है ...

एक तरह से, ये प्रश्न StreamBuilder लागू होते हैं:

• हमें StreamSubscription के जीवन-चक्र के बारे में सोचने की ज़रूरत नहीं है
• सदस्यता राज्य के जीवनकाल के लिए चलती है
• StreamBuilder StreamSubscription का मालिक है

सामान्य तौर पर, आप इसके बारे में सोच सकते हैं:

final value = useX(argument);

के सख्त समकक्ष के रूप में:

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

  },
);

उनके समान नियम और समान व्यवहार हैं।

यह अब डेवलपर की जिम्मेदारी नहीं है

मुझे लगता है कि मौलिक रूप से यहाँ असहमति है। एक फ़ंक्शन-जैसी एपीआई होना जो एक परिभाषित जीवन-समय वाला मान देता है जो स्पष्ट नहीं है, आईएमएचओ, उस मूल्य को बंद करने के आधार पर एपीआई से मौलिक रूप से बहुत अलग है।

मुझे इस शैली का उपयोग करने वाले पैकेज बनाने वाले किसी व्यक्ति के साथ कोई समस्या नहीं है, लेकिन यह उस तरह की शैली के विपरीत है जिसे मैं कोर स्पंदन एपीआई में शामिल करना चाहता हूं।

@ हिक्सी
मुझे नहीं लगता कि @rrousselGit क्या कह रहा था कि वे एक ही चीज हैं लेकिन जीवन चक्र के संबंध में उनके पास "समान नियम और वही व्यवहार" हैं? सही?

हालांकि वे समान समस्याओं का समाधान नहीं करते हैं।

हो सकता है कि मैं यहां गलत हूं लेकिन स्पंदन की कोशिश करते समय आखिरी गिरावट आई है, मेरा मानना ​​​​है कि अगर मुझे एक विजेट में उन तीन बिल्डरों की आवश्यकता होती तो यह बहुत घोंसला होता। तीन हुक (तीन पंक्तियों) की तुलना में।
भी। हुक कंपोज़ेबल हैं इसलिए यदि आपको कई हुक से बना राज्य तर्क साझा करने की आवश्यकता है तो आप एक नया हुक बना सकते हैं जो अन्य हुक और कुछ अतिरिक्त तर्क का उपयोग करता है और केवल एक नए हुक का उपयोग करता है।

विगेट्स के बीच आसानी से स्टेट लॉजिक को साझा करने जैसी चीजें 2019 की स्पंदन गिरावट की कोशिश करते समय मुझे याद आ रही थीं।

निश्चित रूप से कई अन्य संभावित समाधान हो सकते हैं। शायद यह पहले ही हल हो चुका है और मुझे इसे दस्तावेज़ों में नहीं मिला।
लेकिन अगर ऐसा नहीं है तो विकास को गति देने के लिए बहुत कुछ किया जा सकता है अगर हुक जैसी चीज या उन्हीं समस्याओं के लिए कोई अन्य समाधान जहां प्रथम श्रेणी के नागरिक के रूप में उपलब्ध हो।

मैं निश्चित रूप से बिल्डर दृष्टिकोण का उपयोग करने का सुझाव नहीं दे रहा हूं, जैसा कि ओपी का उल्लेख है, जिसमें सभी प्रकार की समस्याएं हैं। मैं जो सुझाव दूंगा वह सिर्फ initState/निपटान का उपयोग कर रहा है। मैं वास्तव में समझ नहीं पा रहा हूं कि यह समस्या क्यों है।

मैं उत्सुक हूं कि लोग https://github.com/flutter/flutter/issues/51752#issuecomment -664787791 में कोड के बारे में कैसा महसूस करते हैं। मुझे नहीं लगता कि यह initState/निपटान से बेहतर है, लेकिन अगर लोग हुक पसंद करते हैं, तो क्या वे भी इसे पसंद करते हैं? क्या हुक बेहतर है? ज़्यादा बुरा?

@ हिक्सी हुक का उपयोग करना अच्छा है क्योंकि वे जीवन चक्र को एक फ़ंक्शन कॉल में विभाजित करते हैं। अगर मैं हुक का उपयोग करता हूं, तो useAnimationController कहें, मुझे initState के बारे में सोचने और अब और निपटाने की आवश्यकता नहीं है। यह डेवलपर से जिम्मेदारी हटा देता है। मुझे चिंता करने की ज़रूरत नहीं है कि मैंने अपने द्वारा बनाए गए हर एक एनीमेशन नियंत्रक का निपटारा किया है या नहीं।

initState और dispose एक ही चीज़ के लिए ठीक हैं लेकिन कल्पना करें कि कई और अलग-अलग प्रकार के राज्य का ट्रैक रखना है। हुक वर्ग के जीवन चक्र में उन्हें फैलाने के बजाय अमूर्तता की तार्किक इकाई के आधार पर रचना करते हैं।

मुझे लगता है कि आप जो पूछ रहे हैं वह पूछने के बराबर है कि फ़ंक्शन क्यों हैं जब हम मैन्युअल रूप से हर बार प्रभावों का ख्याल रख सकते हैं। मैं मानता हूं कि यह बिल्कुल वैसा ही नहीं है, लेकिन यह मोटे तौर पर ऐसा ही लगता है। ऐसा लगता है कि आपने पहले हुक का उपयोग नहीं किया है, इसलिए समस्याएं आपको बहुत स्पष्ट नहीं लगती हैं, इसलिए मैं आपको flutter_hooks पैकेज के साथ हुक का उपयोग करके एक छोटे या मध्यम आकार की परियोजना करने के लिए प्रोत्साहित करूंगा, और देखें यह कैसा महसूस होता है। मैं इसे पूरे सम्मान के साथ कहता हूं, स्पंदन के एक उपयोगकर्ता के रूप में मैंने इन मुद्दों में भाग लिया है जो हुक दूसरों के रूप में समाधान प्रदान करते हैं। मुझे यकीन नहीं है कि आपको कैसे समझाऊं कि ये समस्याएं वास्तव में हमारे लिए मौजूद हैं, हमें बताएं कि क्या कोई बेहतर तरीका है।

मैं प्रतिक्रिया के नजरिए से कुछ विचार जोड़ूंगा।
क्षमा करें यदि वे प्रासंगिक नहीं हैं, लेकिन मैं संक्षेप में बताना चाहता हूं कि हम हुक के बारे में कैसे सोचते हैं।

हुक निश्चित रूप से चीजें "छुपा" रहे हैं। या, आप इसे कैसे देखते हैं, इस पर निर्भर करते हुए, उन्हें इनकैप्सुलेट करें। विशेष रूप से, वे स्थानीय स्थिति और प्रभावों को समाहित करते हैं (मुझे लगता है कि हमारे "प्रभाव" "डिस्पोजेबल" जैसी ही चीजें हैं)। "अंतर्निहितता" यह है कि वे स्वचालित रूप से उस घटक के लिए जीवनकाल संलग्न करते हैं जिसके अंदर उन्हें बुलाया जाता है।

यह निहितता मॉडल में अंतर्निहित नहीं है। आप कल्पना कर सकते हैं कि एक तर्क सभी कॉलों के माध्यम से स्पष्ट रूप से पिरोया जा रहा है - घटक से ही पूरे कस्टम हुक में, प्रत्येक आदिम हुक तक। लेकिन व्यवहार में, हमने पाया कि यह शोर है और वास्तव में उपयोगी नहीं है। इसलिए हमने वर्तमान में कंपोनेंट इम्प्लीमेंटेड ग्लोबल स्टेट को क्रियान्वित किया है। इस तरह के समान है throw ऊपर की ओर सबसे करीब के लिए एक वीएम खोजों में catch बजाय आप के ब्लॉक के आसपास गुजर errorHandlerFrame कोड में।

ठीक है, तो यह उनके अंदर निहित छिपे हुए राज्य के साथ कार्य करता है, जो बुरा लगता है? लेकिन रिएक्ट में, सामान्य रूप से कंपोनेंट्स भी होते हैं। यह कंपोनेंट्स का पूरा बिंदु है। वे ऐसे कार्य हैं जिनके साथ जीवन भर जुड़ा हुआ है (जो यूआई पेड़ में एक स्थिति से मेल खाता है)। राज्य के संबंध में घटक स्वयं एक फ़ुटगन नहीं हैं, इसका कारण यह है कि आप उन्हें केवल यादृच्छिक कोड से नहीं कहते हैं। आप उन्हें अन्य घटकों से बुलाते हैं। तो उनका जीवनकाल समझ में आता है क्योंकि आप UI कोड के संदर्भ में बने रहते हैं।

हालांकि, सभी समस्याएं घटक के आकार की नहीं होती हैं। अवयव दो क्षमताओं को जोड़ते हैं: राज्य + प्रभाव, और जीवन भर पेड़ की स्थिति से बंधा हुआ। लेकिन हमने पाया है कि पहली क्षमता अपने आप में उपयोगी है। जैसे फ़ंक्शन सामान्य रूप से उपयोगी होते हैं क्योंकि वे आपको कोड को एनकैप्सुलेट करने देते हैं, हमारे पास एक आदिम की कमी थी जो हमें पेड़ में एक नया नोड बनाने के बिना राज्य + प्रभाव बंडलों को एनकैप्सुलेट (और पुन: उपयोग) करने देगा। हुक यही हैं। अवयव = हुक + यूआई लौटा।

जैसा कि मैंने उल्लेख किया है, प्रासंगिक स्थिति को छिपाने वाला एक मनमाना कार्य डरावना है। यही कारण है कि हम एक सम्मेलन को एक लिंटर के माध्यम से लागू करते हैं। हुक में "रंग" होता है - यदि आप हुक का उपयोग करते हैं, तो आपका कार्य भी एक हुक है। और लिंटर लागू करता है कि केवल घटक या अन्य हुक हुक का उपयोग कर सकते हैं। यह प्रासंगिक UI स्थिति को छिपाने वाले मनमाने कार्यों की समस्या को दूर करता है क्योंकि अब वे स्वयं घटकों से अधिक निहित नहीं हैं।

संकल्पनात्मक रूप से, हम हुक कॉल को सादे फ़ंक्शन कॉल के रूप में नहीं देखते हैं। जैसे useState() अधिक है use State() अगर हमारे पास सिंटैक्स था। यह एक भाषा विशेषता होगी। आप उन भाषाओं में हुक जैसे बीजगणितीय प्रभावों का मॉडल बना सकते हैं जिनमें प्रभाव ट्रैकिंग होती है। तो उस अर्थ में, वे नियमित कार्यों होगा, लेकिन तथ्य यह है कि वे "उपयोग" राज्य अपने प्रकार हस्ताक्षर का एक हिस्सा होगा। तब आप इस आशय के लिए रिएक्ट को "हैंडलर" के रूप में सोच सकते हैं। वैसे भी, यह बहुत सैद्धांतिक है लेकिन मैं प्रोग्रामिंग मॉडल के संदर्भ में पूर्व कला को इंगित करना चाहता था।

व्यावहारिक रूप से, यहाँ कुछ चीजें हैं। सबसे पहले, यह ध्यान देने योग्य है कि हुक प्रतिक्रिया के लिए "अतिरिक्त" एपीआई नहीं हैं। वे इस बिंदु पर घटक लिखने के लिए एपीआई प्रतिक्रिया कर रहे हैं। मुझे लगता है कि मैं सहमत हूँ कि एक अतिरिक्त विशेषता के रूप में वे बहुत सम्मोहक नहीं होंगे। इसलिए मुझे नहीं पता कि क्या वे वास्तव में स्पंदन के लिए समझ में आते हैं, जिसमें यकीनन एक अलग समग्र प्रतिमान है।

वे क्या अनुमति देते हैं, मुझे लगता है कि मुख्य विशेषता राज्य + प्रभावी तर्क को समाहित करने की क्षमता है, और फिर इसे एक साथ श्रृंखलाबद्ध करें जैसे आप नियमित कार्य संरचना के साथ करेंगे। क्योंकि आदिम रचना करने के लिए डिज़ाइन किए गए हैं, आप useState() जैसे कुछ हुक आउटपुट ले सकते हैं, इसे एक क्यूसम useGesture(state) इनपुट के रूप में पास कर सकते हैं, फिर इसे कई कस्टम useSpring(gesture) इनपुट के रूप में पास कर सकते हैं छोटा सा डेमो है, और एक लेख जहां मैं संक्षेप में बताता हूं कि हुक क्या हैं।

मैं इस बात पर जोर देना चाहता हूं कि

मुझे नहीं पता कि यह बिल्कुल मददगार था, लेकिन उम्मीद है कि यह प्रोग्रामिंग मॉडल पर कुछ परिप्रेक्ष्य बहाएगा।
अन्य सवालों के जवाब देने में खुशी हुई।

मैं निश्चित रूप से बिल्डर दृष्टिकोण का उपयोग करने का सुझाव नहीं दे रहा हूं, जैसा कि ओपी का उल्लेख है, जिसमें सभी प्रकार की समस्याएं हैं। मैं जो सुझाव दूंगा वह सिर्फ initState/निपटान का उपयोग कर रहा है। मैं वास्तव में समझ नहीं पा रहा हूं कि यह समस्या क्यों है।

मैं उत्सुक हूं कि लोग #51752 (टिप्पणी) में कोड के बारे में कैसा महसूस करते हैं। मुझे नहीं लगता कि यह initState/निपटान से बेहतर है, लेकिन अगर लोग हुक पसंद करते हैं, तो क्या वे भी इसे पसंद करते हैं? क्या हुक बेहतर है? ज़्यादा बुरा?

late कीवर्ड चीजों को बेहतर बनाता है, लेकिन यह अभी भी कुछ मुद्दों से ग्रस्त है:

ऐसे Property उन राज्यों के लिए उपयोगी हो सकते हैं जो स्व-निहित हैं या जो उन मापदंडों पर निर्भर नहीं हैं जो समय के साथ बदल सकते हैं। लेकिन अलग स्थिति में होने पर इसका उपयोग करना मुश्किल हो सकता है।
अधिक सटीक रूप से, इसमें "अपडेट" भाग का अभाव है।

उदाहरण के लिए, StreamBuilder के साथ सुनी गई स्ट्रीम समय के साथ बदल सकती है। लेकिन यहां ऐसी चीज को लागू करने का कोई आसान उपाय नहीं है, क्योंकि ऑब्जेक्ट को केवल एक बार इनिशियलाइज़ किया जाता है।

इसी तरह, हुक में विजेट के Key बराबर होता है - जो कि राज्य के एक टुकड़े को नष्ट कर सकता है और उस कुंजी को बदलने पर फिर से बनाया जा सकता है।

इसका एक उदाहरण useMemo , जो एक हुक है जो वस्तु के उदाहरण को कैश करता है।
चाबियों के साथ, हम निहित डेटा लाने के लिए useMemo का उपयोग कर सकते हैं।
उदाहरण के लिए, हमारे विजेट को एक संदेश आईडी प्राप्त हो सकती है - जिसका उपयोग हम संदेश विवरण प्राप्त करने के लिए करते हैं। लेकिन वह संदेश आईडी समय के साथ बदल सकता है, इसलिए हमें विवरण पुनः प्राप्त करने की आवश्यकता हो सकती है।

useMemo , यह ऐसा दिखाई दे सकता है:

String messageId;

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

}

इस स्थिति में, भले ही बिल्ड विधि को फिर से 10 बार कहा जाता है, जब तक कि messageId नहीं बदलता है, डेटा-फ़ेचिंग फिर से नहीं की जाती है।
लेकिन जब messageId बदलता है, तो एक नया Future बनाया जाता है।

यह ध्यान देने योग्य है कि मुझे नहीं लगता कि flutter_hooks अपनी वर्तमान स्थिति में डार्ट के लिए परिष्कृत है। मेरा कार्यान्वयन पूरी तरह से विकसित वास्तुकला की तुलना में एक पीओसी से अधिक है।
लेकिन मुझे विश्वास है कि हमें StatefulWidgets के कोड पुन: प्रयोज्य के साथ कोई समस्या है।

मुझे याद नहीं था कि कहां है, लेकिन मुझे याद है कि आदर्श दुनिया में हुक एक कस्टम फ़ंक्शन जनरेटर होगा, जो async* और sync* बगल में होगा, जो डैन के सुझाव के समान हो सकता है use State बजाय useState

@gaearon

मैं इस बात पर जोर देना चाहता हूं कि यह बॉयलरप्लेट को कम करने के बारे में नहीं है, बल्कि स्टेटफुल इनकैप्सुलेटेड लॉजिक की पाइपलाइनों को गतिशील रूप से लिखने की क्षमता के बारे में है।

यह वह समस्या नहीं है जिस पर यहां चर्चा की जा रही है। आप जो वर्णन करते हैं उसे करने में असमर्थता के बारे में बात करने के लिए मैं एक अलग बग दर्ज करने की अनुशंसा करता हूं। (यह एक बहुत अलग समस्या की तरह लगता है और ईमानदारी से यहां वर्णित एक की तुलना में अधिक सम्मोहक है।) यह बग विशेष रूप से इस बारे में है कि कैसे कुछ तर्क बहुत क्रियात्मक हैं।

नहीं, वह सही है, यह मेरा शब्द है जो भ्रमित करने वाला हो सकता है।
जैसा कि मैंने पहले उल्लेख किया है, यह कोड की पंक्तियों की संख्या के बारे में नहीं है, बल्कि स्वयं कोड की पंक्तियों के बारे में है।

यह फैक्टराइजिंग स्टेट के बारे में है।

यह बग समस्या के बारे में बेहद स्पष्ट है "राज्य तर्क का पुन: उपयोग करना बहुत कठिन/कठिन है" और यह सब होने के बारे में कि राज्य में बहुत अधिक कोड कैसे होता है जब आपके पास ऐसी संपत्ति होती है जिसके लिए कोड की आवश्यकता होती है, initState में, में निपटाने, और डिबगफिलप्रॉपर्टीज में। यदि आप जिस समस्या की परवाह करते हैं वह कुछ अलग है तो मैं उस समस्या का वर्णन करने वाला एक नया बग दर्ज करने की अनुशंसा करता हूं।

मैं वास्तव में, वास्तव में दृढ़ता से हुक (या कोई समाधान) के बारे में भूलने की सलाह देता हूं जब तक कि आप उस समस्या को पूरी तरह से समझ नहीं लेते जिसे आप हल करना चाहते हैं। समस्या की स्पष्ट समझ होने पर ही आप एक नई सुविधा के पक्ष में एक ठोस तर्क व्यक्त करने में सक्षम होंगे, क्योंकि हमें उन समस्याओं के विरुद्ध सुविधाओं का मूल्यांकन करना चाहिए जिन्हें वे हल करते हैं।

मुझे लगता है कि उस समय मैंने जो कुछ कहा था, उसे आप गलत समझ रहे हैं।

समस्या किसी भी तरह से बॉयलरप्लेट नहीं है, बल्कि पुन: प्रयोज्य है।

बॉयलरप्लेट पुन: प्रयोज्य के साथ एक समस्या का परिणाम है, कारण नहीं

यह मुद्दा क्या बताता है:

हम राज्य तर्क का पुन: उपयोग/रचना करना चाह सकते हैं। लेकिन उपलब्ध विकल्प या तो मिश्रित हैं, बिल्डर्स हैं, या इसका पुन: उपयोग नहीं कर रहे हैं - जिनमें से सभी के अपने मुद्दे हैं।

मौजूदा विकल्पों के मुद्दे बॉयलरप्लेट से संबंधित हो सकते हैं, लेकिन हम जिस समस्या को हल करने का प्रयास कर रहे हैं वह नहीं है।
जबकि बिल्डर्स के बॉयलरप्लेट को कम करना एक रास्ता है (जो कि हुक करता है), एक अलग हो सकता है।

उदाहरण के लिए, मैं कुछ समय के लिए सुझाव देना चाहता था जैसे विधियों को जोड़ना:

context.onDidChangeDependencies(() {

});
context.onDispose(() {

});

लेकिन इनके अपने मुद्दे हैं और पूरी तरह से समस्या का समाधान नहीं करते हैं, इसलिए मैंने नहीं किया।

@rrousselGit , समस्या को बेहतर ढंग से दर्शाने के लिए यहां शीर्ष पर मूल समस्या कथन को संपादित करने के लिए स्वतंत्र महसूस करें। एक डिज़ाइन दस्तावेज़ बनाने के लिए भी स्वतंत्र महसूस करें: https://flutter.dev/docs/resources/design-docs जिसे हम एक साथ पुनरावृति कर सकते हैं (फिर से, जैसा कि @Hixie सुझाव देता है, अभी के लिए समस्या विवरण के सबसे

मैंने इस मुद्दे को कुछ बार फिर से देखा है। पूरी ईमानदारी से, मुझे समझ नहीं आ रहा है कि गलतफहमी कहाँ से आ रही है, इसलिए मुझे नहीं पता कि क्या सुधार किया जाए।
मूल टिप्पणी बार-बार पुन: प्रयोज्य/कारक बनाने की इच्छा का उल्लेख करती है। बॉयलरप्लेट के बारे में उल्लेख "स्पंदन क्रिया है" लेकिन "कुछ तर्क पुन: प्रयोज्य नहीं हैं"

मुझे नहीं लगता कि डिजाइन डॉक्टर सुझाव उचित है। इस तरह के दस्तावेज़ को लिखने में काफी समय लगता है, और मैं इसे अपने खाली समय में कर रहा हूँ।
मैं व्यक्तिगत रूप से हुक से संतुष्ट हूं। मैं इन मुद्दों को अपने हित में नहीं लिख रहा हूं, बल्कि एक ऐसी समस्या के बारे में जागरूकता बढ़ाने के लिए हूं जो बड़ी संख्या में लोगों को प्रभावित करती है।

कुछ हफ़्ते पहले, मुझे मौजूदा फ़्लटर ऐप के बारे में आर्किटेक्चर पर चर्चा करने के लिए काम पर रखा गया था। उनका शायद वही था जो यहाँ बताया गया है:

• उनके पास कुछ तर्क हैं जिन्हें कई विजेट्स में पुन: उपयोग करने की आवश्यकता होती है (लोडिंग स्टेट्स को संभालना / "संदेश" को चिह्नित करना जब कुछ विजेट दिखाई देते हैं / ...)
• उन्होंने मिश्रणों का उपयोग करने की कोशिश की, जिससे प्रमुख वास्तुकला दोष उत्पन्न हुए।
• उन्होंने कई स्थानों पर उस तर्क को फिर से लिखकर "बनाने/अद्यतन/निपटान" को मैन्युअल रूप से संभालने का भी प्रयास किया, लेकिन इससे बग उत्पन्न हुई।
  कुछ जगहों पर, वे सब्सक्रिप्शन बंद करना भूल गए। दूसरों में, उन्होंने उस परिदृश्य को नहीं संभाला जहां उनका stream उदाहरण बदलता है

• कुछ विजेट दिखाई देने पर "संदेश" को पढ़ने के रूप में चिह्नित करना

यह एक दिलचस्प मामला है क्योंकि यह मेरे अपने ऐप्स में से एक में होने वाली समस्याओं के समान है, इसलिए मैंने देखा कि मैंने वहां कोड कैसे कार्यान्वित किया है और मुझे वास्तव में इस बग का वर्णन करने वाली अधिकांश समस्याएं नहीं दिख रही हैं, जो हो सकता है मुझे समस्या को समझने में परेशानी क्यों हो रही है। यह प्रश्न में कोड है:

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

क्या आपके पास वास्तविक ऐप्स के उदाहरण हैं जिनका मैं अध्ययन कर सकता हूं ताकि समस्या को कार्रवाई में देखा जा सके?

(बीटीडब्लू, आम तौर पर मैं दृढ़ता से स्ट्रीम का उपयोग न करने की दृढ़ता से अनुशंसा करता हूं। मुझे लगता है कि वे आम तौर पर चीजों को और खराब कर देते हैं।)

(बीटीडब्लू, आम तौर पर मैं दृढ़ता से स्ट्रीम का उपयोग न करने की दृढ़ता से अनुशंसा करता हूं। मुझे लगता है कि वे आम तौर पर चीजों को और खराब कर देते हैं।)

(मैं तहे दिल से सहमत हूं। लेकिन समुदाय की वर्तमान में विपरीत प्रतिक्रिया है। हो सकता है कि चेंजनोटिफ़ायर/सुनने योग्य/वैल्यू नोटिफ़ायर को फ़्लटर से आधिकारिक पैकेज में निकालने से मदद मिलेगी)

क्या आपके पास वास्तविक ऐप्स के उदाहरण हैं जिनका मैं अध्ययन कर सकता हूं ताकि समस्या को कार्रवाई में देखा जा सके?

दुख की बात है नहीं। मैं केवल दूसरों की मदद करते हुए अपने अनुभव को साझा कर सकता हूं। मेरे पास कोई ऐप नहीं है।

यह एक दिलचस्प मामला है क्योंकि यह मेरे अपने ऐप्स में से एक में होने वाली समस्याओं के समान है, इसलिए मैंने देखा कि मैंने वहां कोड कैसे कार्यान्वित किया है और मुझे वास्तव में इस बग का वर्णन करने वाली अधिकांश समस्याएं नहीं दिख रही हैं, जो हो सकता है मुझे समस्या को समझने में परेशानी क्यों हो रही है। यह प्रश्न में कोड है:

आपके कार्यान्वयन में, तर्क किसी भी जीवन-चक्र से बंधा नहीं है और _build_ के अंदर रखा गया है, इसलिए यह समस्या के आसपास काम करता है।
यह उस विशिष्ट मामले में समझ में आ सकता है। मुझे यकीन नहीं है कि वह उदाहरण अच्छा था।

एक बेहतर उदाहरण पुल-टू-रीफ्रेश हो सकता है।

एक विशिष्ट पुल-टू-रीफ्रेश में, हम चाहेंगे:

• पहले निर्माण पर, लोडिंग/त्रुटि की स्थिति को संभालें
• ताज़ा करने पर:
  
  
  
  • यदि स्क्रीन त्रुटि स्थिति में थी, तो लोडिंग स्क्रीन को एक बार फिर दिखाएं
  
  
  • यदि लोडिंग के दौरान रिफ्रेश किया गया था, तो लंबित HTTP अनुरोधों को रद्द करें
  
  
  • अगर स्क्रीन ने कुछ डेटा दिखाया:
  
  
  • नया राज्य लोड होने पर डेटा दिखाते रहें
  
  
  • यदि रिफ्रेश विफल रहता है, तो पहले प्राप्त डेटा दिखाना जारी रखें और त्रुटि के साथ स्नैकबार दिखाएं
  
  
  • यदि उपयोगकर्ता पॉप अप करता है और रीफ्रेश लंबित होने पर स्क्रीन में फिर से प्रवेश करता है, तो लोडिंग स्क्रीन दिखाएं
  
  
  • सुनिश्चित करें कि रीफ्रेश इंडिकेटर रीफ्रेश लंबित होने पर दृश्यमान कहता है
  
  

और हम ऐसी सुविधा को सभी संसाधनों और एकाधिक स्क्रीन के लिए लागू करना चाहेंगे। इसके अलावा, कुछ स्क्रीन एक साथ कई संसाधनों को ताज़ा करना चाह सकते हैं।

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 के साथ काम करेगाऔर सीधे स्पंदन के अंदर भी शामिल किया जा सकता है।

मैं वास्तव में समझ नहीं पा रहा हूं कि आप अपनी आखिरी टिप्पणी में किसकी वकालत कर रहे हैं। मेरा कहना यह है कि ऊपर दिए गए रिफ्रेश इंडिकेटर कोड जितना सरल कुछ करने के लिए आपको ढांचे में बदलाव की आवश्यकता नहीं है, जैसा कि मैंने पहले उद्धृत कोड द्वारा प्रदर्शित किया है।

यदि हमारे पास इस प्रकार के बहुत सारे इंटरैक्शन हैं, न केवल रिफ्रेश इंडिकेटर्स के लिए, बल्कि एनिमेशन और अन्य के लिए, तो उन्हें ऐप स्टेट में डालने के बजाय जहां वे जरूरत के सबसे करीब हैं, उन्हें एनकैप्सुलेट करना बेहतर है, क्योंकि ऐप स्टेट ऐप में हर एक इंटरैक्शन की बारीकियों को जानने की जरूरत नहीं है, अगर ऐप में कई जगहों पर इसकी जरूरत नहीं है।

मुझे नहीं लगता कि हम सुविधा की जटिलता और इसकी पुन: प्रयोज्यता पर सहमत हैं।
क्या आपके पास एक उदाहरण है जो दिखाता है कि ऐसी सुविधा आसान है?

मैंने ऊपर लिखे एक ऐप के स्रोत से लिंक किया है। यह निश्चित रूप से सही कोड नहीं है, और मैं अगली रिलीज के लिए इसके कुछ हिस्सों को फिर से लिखने की योजना बना रहा हूं, लेकिन मुझे इस मुद्दे में आपके द्वारा वर्णित समस्याओं का अनुभव नहीं हुआ।

लेकिन आप स्पंदन के टेक लीड में से एक हैं।
किसी समस्या का सामना करने पर भी, आपके पास तुरंत समाधान निकालने के लिए पर्याप्त कौशल होगा।

फिर भी दूसरी तरफ, बड़ी संख्या में लोग यह नहीं समझते हैं कि निम्नलिखित कोड में क्या गलत है:

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

यह तथ्य इस बात से सिद्ध होता है कि StackOverflow पर बनाया गया Q/AI कितना लोकप्रिय है।

समस्या यह नहीं है कि राज्य तर्क को पुन: प्रयोज्य और मजबूत तरीके से अमूर्त करना असंभव है (अन्यथा इस मुद्दे को बनाने का कोई मतलब नहीं है)।
समस्या यह है कि ऐसा करने के लिए समय और अनुभव दोनों की आवश्यकता होती है।

एक आधिकारिक समाधान प्रदान करके, यह इस संभावना को कम कर देता है कि कोई एप्लिकेशन अप्राप्य समाप्त हो जाता है - जो समग्र उत्पादकता और डेवलपर अनुभव को बढ़ाता है।
हर कोई आपकी संपत्ति के सुझाव के साथ नहीं आ सका। यदि ऐसी कोई चीज़ फ़्लटर के अंदर बनाई गई थी, तो इसे प्रलेखित किया जाएगा, दृश्यता प्राप्त की जाएगी, और अंततः उन लोगों की मदद की जाएगी जिन्होंने इसके बारे में कभी नहीं सोचा होगा।

समस्या यह है कि यह वास्तव में इस बात पर निर्भर करता है कि आपका ऐप क्या है, आपका राज्य कैसा दिखता है, इत्यादि। यदि यहां प्रश्न केवल "आप ऐप स्थिति का प्रबंधन कैसे करते हैं" तो उत्तर हुक की तरह कुछ भी नहीं है, यह बहुत सारे दस्तावेज हैं जो इसे करने के विभिन्न तरीकों के बारे में बात कर रहे हैं और विभिन्न स्थितियों के लिए विभिन्न तकनीकों की सिफारिश कर रहे हैं ... मूल रूप से, यह सेट का दस्तावेज़: https://flutter.dev/docs/Development/data-and-backend/state-mgmt

क्षणिक और ऐप स्थिति है, लेकिन एक और उपयोग का मामला भी प्रतीत होता है: राज्य जो केवल एक ही प्रकार के विजेट से संबंधित है लेकिन फिर भी आप उस प्रकार के विजेट के बीच साझा करना चाहते हैं।

उदाहरण के लिए, ScrollController कुछ प्रकार के एनिमेशन को लागू कर सकता है, लेकिन इसे वैश्विक ऐप स्थिति में रखना आवश्यक नहीं है, क्योंकि यह डेटा नहीं है जिसे सभी ऐप में उपयोग करने की आवश्यकता है। हालाँकि, एकाधिक ScrollController s का तर्क समान हो सकता है, और आप उनमें से प्रत्येक के बीच उस जीवन चक्र तर्क को साझा करना चाहते हैं। राज्य अभी भी केवल ScrollController s के लिए है, इसलिए वैश्विक ऐप स्थिति नहीं है, लेकिन तर्क को कॉपी-पेस्ट करने में त्रुटि की संभावना है।

इसके अलावा, आप इस तर्क को अपनी भविष्य की परियोजनाओं के लिए, लेकिन दूसरों के लिए भी अधिक अनुकूल बनाने के लिए पैकेज करना चाह सकते हैं। यदि आप साइट useHooks को देखते हैं, तो आप तर्क के कई टुकड़े देखेंगे जो कुछ सामान्य क्रियाओं को useAuth उपयोग करते हैं तो आप इसे एक बार लिखते हैं और इस बारे में चिंता करने की ज़रूरत नहीं है कि क्या आपने initState या dispose कॉल मिस कर दिया है, या async फ़ंक्शन में then और catch । फ़ंक्शन केवल एक बार लिखा जाता है, इसलिए त्रुटि के लिए कमरा मूल रूप से गायब हो जाता है। इसलिए, इस तरह का समाधान न केवल एक ही ऐप के कई हिस्सों के लिए और कई ऐप के बीच अधिक संगत है, बल्कि यह अंतिम प्रोग्रामर के लिए भी सुरक्षित है।

मुझे हुक का इस्तेमाल करने वाले लोगों से कोई आपत्ति नहीं है। जहां तक ​​मैं बता सकता हूं, कुछ भी इसे रोक नहीं रहा है। (यदि कोई _is_ उसे रोक रहा है, तो कृपया उसके बारे में एक बग दर्ज करें।)

यह बग हुक के बारे में नहीं है, यह "राज्य तर्क का पुन: उपयोग करना बहुत कठिन/कठिन है" के बारे में है, और मैं अभी भी यह समझने के लिए संघर्ष कर रहा हूं कि इसके लिए स्पंदन में किसी भी बदलाव की आवश्यकता क्यों है। ऐसे कई उदाहरण हैं (हुक सहित) यह दिखाते हैं कि किसी के आवेदन को एक या दूसरे तरीके से संरचित करके वर्बोसिटी से बचना कैसे संभव है, और इसके बारे में पहले से ही बहुत सारे दस्तावेज हैं।

मैं देखता हूं, तो आप पूछ रहे हैं कि क्यों, अगर हुक पैकेज जैसा कुछ मौजूद है जिसे पहले से ही फ़्लटर में कोई बदलाव नहीं किया गया था, तो हुक के लिए पहला पार्टी समाधान होना चाहिए? मुझे लगता है कि @rrousselGit इसका बेहतर उत्तर दे सकता है लेकिन उत्तर में शायद बेहतर समर्थन, अधिक एकीकृत समर्थन और उनका उपयोग करने वाले अधिक लोग शामिल हैं।

मैं आपसे सहमत हो सकता हूं कि इसके अलावा, मैं भी उलझन में हूं कि फ़्लटर को हुक का समर्थन करने के लिए किसी भी मूलभूत परिवर्तन की आवश्यकता क्यों है, क्योंकि स्पष्ट रूप से flutter_hooks पैकेज पहले से मौजूद है।

मैं अभी भी यह समझने के लिए संघर्ष कर रहा हूं कि इसके लिए स्पंदन में किसी भी बदलाव की आवश्यकता क्यों है।

यह कहना कि यह समस्या हल हो गई है क्योंकि समुदाय ने एक पैकेज बनाया है, यह कहने जैसा है कि डार्ट को डेटा-क्लास + यूनियन प्रकारों की आवश्यकता नहीं है क्योंकि मैंने फ्रीज किया है ।
इन दोनों समस्याओं के समाधान के रूप में फ्रीज को समुदाय द्वारा काफी पसंद किया जा सकता है, लेकिन हम अभी भी बेहतर कर सकते हैं।

फ़्लटर टीम के पास समुदाय की तुलना में बहुत अधिक उत्तोलन है। आपके पास संपूर्ण स्टैक को संशोधित करने की क्षमता है; लोग जो प्रत्येक व्यक्तिगत भाग के विशेषज्ञ हैं; और आवश्यक कार्य को प्रायोजित करने के लिए वेतन।

इस समस्या की जरूरत है।
याद रखें: रिएक्ट टीम के लक्ष्यों में से एक हुक के लिए भाषा का हिस्सा होना है, जैसे कि JSX के साथ।

भाषा समर्थन के बिना भी, हमें अभी भी विश्लेषक में काम करने की ज़रूरत है; डार्टपैड; स्पंदन/devtools; और फ़्लटर द्वारा की जाने वाली सभी अलग-अलग चीजों को सरल बनाने के लिए कई हुक (जैसे निहित एनिमेशन, फ़ॉर्म, और बहुत कुछ)।

यह एक अच्छा तर्क है, मैं सहमत हूं, भले ही स्पंदन के सामान्य दर्शन में एक छोटा कोर है। इस कारण से, हम Google, cf वर्णों और एनिमेशन से आने पर भी पैकेज के रूप में नई कार्यक्षमता को तेजी से जोड़ रहे हैं। यह हमें समय के साथ सीखने और बदलने के लिए अधिक लचीलापन देता है। हम इस स्थान के लिए भी ऐसा ही करेंगे, जब तक कि कोई सम्मोहक तकनीकी कारण न हो कि कोई पैकेज अपर्याप्त क्यों था (और विस्तार विधियों के साथ, इसकी संभावना पहले से भी कम है)।

स्पंदन के मूल में चीजों को रखना मुश्किल है। एक चुनौती यह है, जैसा कि आप पहले अनुभव से अच्छी तरह जानते हैं, यह है कि राज्य एक ऐसा क्षेत्र है जो विकसित हो रहा है क्योंकि हम सभी इस बारे में अधिक सीखते हैं कि प्रतिक्रियाशील यूआई आर्किटेक्चर में क्या अच्छा काम करता है। दो साल पहले, अगर हमें एक विजेता चुनने के लिए मजबूर किया गया होता, तो हमने बीएलओसी का चयन किया होता, लेकिन फिर निश्चित रूप से आपके प्रदाता पैकेज ने ले लिया और अब हमारी डिफ़ॉल्ट सिफारिश है।

मैं आराम से Google द्वारा नियोजित योगदानकर्ताओं की कल्पना कर सकता था जो फ़्लटर_हुक या इसी तरह के हुक पैकेज का समर्थन करते थे जिसमें कर्षण था (हालांकि हमारे पास बहुत से अन्य काम हैं जो हमारे ध्यान के लिए प्रतिस्पर्धा कर रहे हैं , जाहिर है)। विशेष रूप से, यदि आप चाहते हैं कि हम इसे आप से ले लें, तो यह स्पष्ट रूप से एक अलग प्रश्न है।

दिलचस्प तर्क, @timsneath। रस्ट समुदाय भी कुछ ऐसा ही करता है, क्योंकि एक बार किसी भाषा या ढांचे के मूल या मानक पुस्तकालय में पेश किए जाने के बाद, इसे बाहर निकालना बहुत मुश्किल होता है। रस्ट के मामले में, यह असंभव है क्योंकि वे हमेशा के लिए पश्च संगतता बनाए रखना चाहते हैं। इसलिए, वे तब तक प्रतीक्षा करते हैं जब तक कि पैकेज नहीं आ जाते हैं और एक-दूसरे के साथ प्रतिस्पर्धा करते हैं जब तक कि केवल कुछ विजेता सामने नहीं आते, फिर वे उसे भाषा में बदल देते हैं।

स्पंदन के साथ भी ऐसा ही मामला हो सकता है। बाद में हुक से बेहतर कुछ हो सकता है, जैसे रिएक्ट को कक्षाओं से हुक में जाना था, लेकिन फिर भी कक्षाओं को बनाए रखना था, और लोगों को पलायन करना पड़ा। तब बेहतर हो सकता है कि कोर में जोड़े जाने से पहले प्रतिस्पर्धी राज्य प्रबंधन समाधान हों। और शायद हम समुदाय को हुक के शीर्ष पर नवाचार करना चाहिए या और भी बेहतर समाधान खोजने का प्रयास करना चाहिए।

मैं उस चिंता को समझता हूं, लेकिन यह राज्य प्रबंधन समाधान के बारे में नहीं है।

ऐसी सुविधा इनहेरिटेडविजेट और स्टेटफुलविजेट के करीब है। यह एक निम्न स्तर का आदिम है, जो एक भाषा विशेषता जितना कम हो सकता है।

हुक ढांचे से स्वतंत्र हो सकते हैं, लेकिन यह केवल भाग्य के माध्यम से है।
जैसा कि मैंने पहले उल्लेख किया है, इस समस्या का दूसरा मार्ग हो सकता है:

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

दिलचस्प हिस्सा है:

• यह अब वर्ग परिभाषा के साथ कसकर युग्मित नहीं है, इसलिए इसे किसी फ़ंक्शन में निकाला जा सकता है।
  हमारे पास सैद्धांतिक रूप से अर्ध-जटिल तर्क हो सकते हैं:
  ``` डार्ट
  एनिमेशन नियंत्रक कुछ पुन: प्रयोज्य लॉजिक (बिल्ड कॉन्टेक्स्ट संदर्भ) {
  अंतिम नियंत्रक = एनिमेशन नियंत्रक (...);
  कंट्रोलर.ऑनडिस्पोज (कंट्रोलर.डिस्पोज);
  नियंत्रक। आगे ();
  शून्य श्रोता () {}
  नियंत्रक। एड लिस्टनर (श्रोता);
  संदर्भ.ऑनडिस्पोज (() => कंट्रोलर.रिमूव लिस्टनर (श्रोता));
  }
  ...

@ ओवरराइड
शून्य initState () {
नियंत्रक = कुछ पुन: प्रयोज्य लॉजिक (संदर्भ);
}
```

• सभी तर्क एक साथ बंडल किए गए हैं। भले ही विजेट ३०० लंबा हो जाए, फिर भी 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 को विजेट के पैरामीटर के रूप में पारित किया जा सकता है। इसलिए हमें उस परिदृश्य को संभालने की जरूरत है जहां अवधि बदलती है।

निपटान कतार की तरह ही एक 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?

जैसा कि मैंने पहले उल्लेख किया है, यह मुद्दा वर्बोसिटी की तुलना में कोड-पुन: प्रयोज्यता के बारे में अधिक है

ठीक। क्या आप कृपया एक नया बग दर्ज कर सकते हैं जो उस बारे में विशेष रूप से बात करता है? इस बग को शाब्दिक रूप से कहा जाता है "राज्य तर्क का पुन: उपयोग करना बहुत कठिन/कठिन है"। अगर वर्बोसिटी मुद्दा नहीं है तो यह मुद्दा नहीं है।

मैं इस चर्चा से काफी असहज होने लगा हूं। इस बिंदु का उत्तर मैं पहले भी दे चुका हूँ:
इस मुद्दे का विषय पुन: प्रयोज्य है, और पुन: प्रयोज्य मुद्दे के परिणामस्वरूप वर्बोसिटी पर चर्चा की जाती है; प्राथमिक विषय के रूप में नहीं।

वर्बोसिटी का उल्लेख करने वाली शीर्ष टिप्पणी में केवल एक बुलेट बिंदु है, और वह है StreamBuilder के साथ, मुख्य रूप से इंडेंटेशन के 2 स्तरों को लक्षित करना।

मुझे यकीन नहीं है कि इसमें संदर्भ क्यों प्रासंगिक है [...]। यदि आप निपटान के दौरान चलाने के लिए चीजों को पंजीकृत करने का एक तरीका चाहते हैं, हालांकि, आप इसे आज आसानी से कर सकते हैं:

जब मैंने context.onDispose लाया, तो मैंने स्पष्ट रूप से उल्लेख किया कि मुझे नहीं लगता कि यह एक अच्छा समाधान है।
मैंने इसे समझाया क्योंकि आपने पूछा कि यह चर्चा से कैसे संबंधित है।

क्यों के लिए context बजाय StateHelper , ऐसा इसलिए है क्योंकि यह अधिक लचीला है (जैसे StatelessWidget के साथ काम करना)

संदर्भ.myLifecycle(() {...}) गर्म-पुनः लोड करने योग्य नहीं है

इस संदर्भ में इससे कोई फर्क नहीं पड़ता क्योंकि यह केवल initState में बुलाए गए चीजों के लिए है? क्या मैं कुछ भूल रहा हूँ?

हम बदल सकते हैं:

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

में:

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

यह myLifecycle कॉलबैक में परिवर्तन लागू नहीं करेगा।

लेकिन अगर हम इस्तेमाल करते हैं:

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

तब हॉट-रीलोड काम करेगा।

सुनिश्चित नहीं है कि इसका क्या अर्थ है, ValueNotifier में क्या गलत है और कहें, ValueListenableBuilder?

यह सिंटैक्स बिल्डर्स का उपयोग करने से बचने के लिए डिज़ाइन किया गया था, इसलिए हम मूल समस्या पर वापस चले गए।

इसके अलावा, अगर हम वास्तव में आपके ValueGetter + queueDidUpdateWidget सुझाव के बजाय हमारे फ़ंक्शन को कंपोज़ेबल बनाना चाहते हैं, तो फ़ंक्शंस को पैरामीटर के रूप में ValueNotifier लेना होगा:

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

जैसा कि हम इस फ़ंक्शन का उपयोग करने वाले विजेट के आधार पर didUpdateWidget अलावा कहीं और से isAnimating प्राप्त करना चाह सकते हैं।
एक ही स्थान पर, यह किया जा सकता हैUpdateWidget; दूसरे में इसे चेंज डिपेंडेंसीज में किया जा सकता है; और किसी अन्य स्थान पर यह stream.listen के कॉलबैक के अंदर हो सकता है।

लेकिन फिर हमें इन परिदृश्यों को आसानी से ValueNotifier में बदलने और हमारे कार्य को ऐसे नोटिफ़ायर को सुनने के लिए एक तरीका चाहिए।
इसलिए हम अपने जीवन को काफी कठिन बना रहे हैं।
मुझे लगता है कि इस पैटर्न की तुलना में ConditionalAnimatorBuilder का उपयोग करना अधिक वास्तविक और आसान है।

क्यों के लिए context बजाय StateHelper , ऐसा इसलिए है क्योंकि यह अधिक लचीला है (जैसे StatelessWidget के साथ काम करना)

स्टेटलेसविजेट, स्टेटलेस विजेट्स के लिए है। पूरी बात यह है कि वे राज्य नहीं बनाएंगे, चीजों का निपटान नहीं करेंगे, didUpdateWidget पर प्रतिक्रिया करेंगे, आदि।

री हॉट रीलोड चीज़, हाँ। इसलिए हम initState में बंद करने के बजाय विधियों का उपयोग करते हैं।

मुझे खेद है कि मैं यह कह रहा हूं, और मैं समझता हूं कि यह निराशाजनक होना चाहिए, लेकिन मुझे अभी भी समझ में नहीं आया कि हम यहां किस समस्या को हल करने का प्रयास कर रहे हैं। मैंने सोचा था कि यह मूल बग सारांश और मूल विवरण का एक बड़ा हिस्सा वर्बोसिटी था, लेकिन मैं समझता हूं कि यह नहीं है। तो समस्या क्या है? ऐसा लगता है कि यहां कई परस्पर अनन्य इच्छाएं हैं, जो इस बग में कई टिप्पणियों में फैली हुई हैं:

• यह घोषित करना कि किसी चीज़ को कैसे निपटाना है उसी स्थान पर किया जाना चाहिए जो इसे आवंटित करता है ...
• ... और वह स्थान जो इसे आवंटित करता है उसे आवंटित करने के बाद से केवल एक बार चलाने की आवश्यकता है ...
• ... और इसे हॉट रीलोड के साथ काम करने की ज़रूरत है (जो परिभाषा के अनुसार कोड को दोबारा नहीं चलाता है जो केवल एक बार चलता है) ...
• ... और इसे राज्य बनाने में सक्षम होना चाहिए जो स्टेटलेस विजेट्स के साथ काम करता है (जो परिभाषा के अनुसार राज्य नहीं है) ...
• ... और इसे didUpdateWidget और didChangeDependencies जैसी चीज़ों में हुकिंग सक्षम करने की आवश्यकता है ...

इस पुनरावृत्त नृत्य में हम यहां शामिल हैं, काम पूरा करने का एक उत्पादक तरीका नहीं है। जैसा कि मैंने पहले कहने की कोशिश की है, यहां कुछ प्राप्त करने का सबसे अच्छा तरीका है कि आप जिस समस्या का सामना कर रहे हैं उसका वर्णन इस तरह से करें कि हम समझ सकें, एक ही स्थान पर वर्णित सभी आवश्यकताओं के साथ और उपयोग के मामलों के साथ समझाया गया। मैं अनुशंसा करता हूं कि समाधान सूचीबद्ध न करें, विशेष रूप से ऐसे समाधान नहीं जिन्हें आप जानते हैं कि आपकी आवश्यकताओं को पूरा नहीं करते हैं। बस यह सुनिश्चित करें कि उन समाधानों को अनुपयुक्त बनाने वाली आवश्यकता विवरण में सूचीबद्ध है।

ईमानदार होने के लिए, मूल रूप से यह मुझे लगता है जैसे आप एक पूरी तरह से अलग ढांचे के डिजाइन के लिए पूछ रहे हैं। यह बिल्कुल ठीक है, लेकिन यह स्पंदन नहीं है। यदि हम एक अलग ढांचा करते हैं, तो यह एक अलग ढांचा होगा, और हमें अभी भी _this_ ढांचे पर बहुत काम करना है। वास्तव में, आप जो कुछ भी वर्णन करते हैं, वह जेटपैक कंपोज़ को कैसे डिज़ाइन किया गया है, इसके समान है। मैं उस डिज़ाइन का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि इसके लिए कंपाइलर जादू की आवश्यकता होती है, इसलिए जो हो रहा है उसे डिबग करना वास्तव में कठिन है, लेकिन हो सकता है कि यह आपकी गली से अधिक हो?

ऐसा लगता है कि यहां कई परस्पर अनन्य इच्छाएं हैं, जो इस बग में कई टिप्पणियों में फैली हुई हैं:

वे पारस्परिक रूप से विशिष्ट नहीं हैं। हुक इनमें से हर एक करते हैं। मैं विवरण में नहीं जाऊंगा क्योंकि हम समाधानों पर ध्यान केंद्रित नहीं करना चाहते हैं, लेकिन वे सभी बॉक्स चेक करते हैं।

जैसा कि मैंने पहले कहने की कोशिश की है, यहां कुछ प्राप्त करने का सबसे अच्छा तरीका है कि आप जिस समस्या का सामना कर रहे हैं उसका वर्णन इस तरह से करें कि हम समझ सकें, एक ही स्थान पर वर्णित सभी आवश्यकताओं के साथ और उपयोग के मामलों के साथ समझाया गया।

मैं अभी भी यह समझने में विफल हूं कि शीर्ष टिप्पणी ऐसा करने में कैसे विफल हो जाती है।
मुझे यह स्पष्ट नहीं है कि दूसरों के लिए क्या स्पष्ट नहीं है।

वास्तव में, आप जो कुछ भी वर्णन करते हैं, वह जेटपैक कंपोज़ को कैसे डिज़ाइन किया गया है, इसके समान है। मैं उस डिज़ाइन का बहुत बड़ा प्रशंसक नहीं हूं क्योंकि इसके लिए कंपाइलर जादू की आवश्यकता होती है, इसलिए जो हो रहा है उसे डिबग करना वास्तव में कठिन है, लेकिन हो सकता है कि यह आपकी गली से अधिक हो?

मैं इससे परिचित नहीं हूं, लेकिन एक त्वरित खोज के साथ, मैं _yes_ कहूंगा।

वे पारस्परिक रूप से विशिष्ट नहीं हैं।

क्या ऊपर सूचीबद्ध सभी बुलेट पॉइंट उस समस्या का हिस्सा हैं जिसे हम यहाँ हल करने का प्रयास कर रहे हैं?

लेकिन वे सभी बॉक्स चेक करते हैं

क्या आप बक्सों को सूचीबद्ध कर सकते हैं?

मैं अभी भी यह समझने में विफल हूं कि शीर्ष टिप्पणी ऐसा करने में कैसे विफल हो जाती है।

उदाहरण के लिए, ओपी स्पष्ट रूप से कहता है कि समस्या StatefulWidgets के बारे में है, लेकिन इस मुद्दे पर हाल की टिप्पणियों में से एक ने कहा कि एक विशेष सुझाव अच्छा नहीं था क्योंकि यह StatelessWidgets के साथ काम नहीं करता था।

ओपी में आप कहते हैं:

State तर्क का पुन: उपयोग करना मुश्किल है। हम या तो एक जटिल और गहराई से नेस्टेड build विधि के साथ समाप्त होते हैं या तर्क को कई विजेट्स में कॉपी-पेस्ट करना पड़ता है।

तो इससे मुझे लगता है कि आवश्यकताओं में शामिल हैं:

• समाधान गहराई से नेस्टेड नहीं होना चाहिए।
• समाधान के लिए उन स्थानों पर बहुत सारे समान कोड की आवश्यकता नहीं होनी चाहिए जो राज्य जोड़ने का प्रयास करते हैं।

पहला बिंदु (घोंसले के बारे में) ठीक लगता है। निश्चित रूप से यह सुझाव देने की कोशिश नहीं की जा रही है कि हमें ऐसे काम करने चाहिए जो गहराई से निहित हों। (उस ने कहा, हम गहराई से नेस्टेड के बारे में असहमत हो सकते हैं; जिसे यहां परिभाषित नहीं किया गया है। बाद में अन्य टिप्पणियों का अर्थ है कि बिल्डर्स गहराई से नेस्टेड कोड का कारण बनते हैं, लेकिन मेरे अनुभव में बिल्डर्स बहुत अच्छे हैं, जैसा कि मैंने पहले उद्धृत कोड में दिखाया था।)

दूसरा बिंदु सीधे तौर पर एक आवश्यकता प्रतीत होता है कि हमारे पास वाचालता नहीं है। लेकिन फिर आपने कई बार समझाया है कि यह शब्दशः के बारे में नहीं है।

अगला कथन जो ओपी बनाता है वह एक समस्या का वर्णन कर रहा है:

एकाधिक StatefulWidget में State तर्क का पुन: उपयोग करना बहुत मुश्किल है, जैसे ही वह तर्क कई जीवन-चक्रों पर निर्भर करता है।

ईमानदारी से मैं वास्तव में नहीं जानता कि इसका क्या अर्थ है। मेरे लिए "मुश्किल" का आमतौर पर मतलब है कि किसी चीज़ में बहुत से जटिल तर्क शामिल हैं जिन्हें समझना मुश्किल है, लेकिन जीवन-चक्र की घटनाओं को आवंटित करना, निपटाना और प्रतिक्रिया करना बहुत सरल है। अगला कथन जो एक समस्या देता है (यहाँ मैं उस उदाहरण को छोड़ रहा हूँ जिसे स्पष्ट रूप से "जटिल नहीं" के रूप में वर्णित किया गया है और इसलिए संभवतः समस्या का विवरण नहीं है) है:

समस्या तब शुरू होती है जब हम उस दृष्टिकोण को मापना चाहते हैं।

इसने मुझे सुझाव दिया कि "बहुत कठिन" से आपका मतलब "बहुत क्रिया" से है और यह कि कठिनाई समान कोड की बहुत सारी घटनाओं से आई है, क्योंकि आपके द्वारा दिए गए "जटिल नहीं" उदाहरण और "बहुत कठिन" के बीच एकमात्र अंतर है। "उदाहरण को स्केल करने का परिणाम शाब्दिक रूप से सिर्फ इतना है कि एक ही कोड कई बार होता है (यानी वर्बोसिटी, बॉयलरप्लेट कोड)।

यह आगे अगले कथन द्वारा समर्थित है जो एक समस्या का वर्णन करता है:

इस तर्क को हर जगह कॉपी-पेस्ट करना "काम करता है", लेकिन हमारे कोड में कमजोरी पैदा करता है:

• किसी एक चरण को फिर से लिखना भूलना आसान हो सकता है (जैसे dispose पर कॉल करना भूल जाना)

तो शायद यह बहुत मुश्किल है क्योंकि कोड को कॉपी और पेस्ट करते समय वर्बोसिटी गलती करना आसान बनाता है? लेकिन फिर, जब मैंने इस समस्या का समाधान करने की कोशिश की, जिसे मैं "शब्दशः" के रूप में वर्णित करता हूं, तो आपने कहा कि समस्या वाचालता नहीं है।

• यह कोड में बहुत अधिक शोर जोड़ता है

फिर से यह मुझे वर्बोसिटी/बॉयलरप्लेट कहने जैसा लगता है, लेकिन फिर से आपने समझाया है कि ऐसा नहीं है।

शेष ओपी केवल उन समाधानों का वर्णन कर रहा है जो आपको पसंद नहीं हैं, इसलिए संभवतः यह समस्या का वर्णन नहीं कर रहा है।

क्या यह बताता है कि ओपी समस्या की व्याख्या करने में कैसे विफल रहता है? ओपी में सब कुछ जो वास्तव में किसी समस्या का वर्णन करता है, वर्बोसिटी का वर्णन करता प्रतीत होता है, लेकिन हर बार जब मैं सुझाव देता हूं कि यह समस्या है, तो आप कहते हैं कि यह नहीं है और एक और समस्या है।

मुझे लगता है कि गलतफहमी शब्द के अर्थ तक उबलती है।
उदाहरण के लिए:

यह कोड में बहुत अधिक शोर जोड़ता है

फिर से यह मुझे वर्बोसिटी/बॉयलरप्लेट कहने जैसा लगता है, लेकिन फिर से आपने समझाया है कि ऐसा नहीं है।

यह बिंदु controller.dispose() की संख्या के बारे में नहीं है, बल्कि उस मूल्य के बारे में है जो कोड की ये पंक्तियाँ पाठक के लिए लाती हैं।
वह रेखा हमेशा बनी रहनी चाहिए और हमेशा वैसी ही होनी चाहिए। जैसे, पाठक के लिए इसका मूल्य लगभग शून्य है।

जो मायने रखता है वह इस रेखा की उपस्थिति नहीं है, बल्कि इसकी अनुपस्थिति है।

समस्या यह है कि हमारे पास जितने अधिक controller.dispose() हैं, उतनी ही अधिक संभावना है कि हम अपने निपटान पद्धति में एक वास्तविक मुद्दे को याद करेंगे।
अगर हमारे पास 1 कंट्रोलर और 0 डिस्पोजल है, तो इसे पकड़ना आसान है
यदि हमारे पास १०० नियंत्रक हैं और ९९ निपटान करते हैं, तो एक लापता को ढूंढना मुश्किल है।

तो हमारे पास हैं:

तो शायद यह बहुत मुश्किल है क्योंकि कोड को कॉपी और पेस्ट करते समय वर्बोसिटी गलती करना आसान बनाता है? लेकिन फिर, जब मैंने इस समस्या का समाधान करने की कोशिश की, जिसे मैं "शब्दशः" के रूप में वर्णित करता हूं, तो आपने कहा कि समस्या वाचालता नहीं है।

जैसा कि मैंने पिछले बिंदु में उल्लेख किया है, कोड की सभी पंक्तियाँ समान नहीं हैं।

अगर हम तुलना करें:

+ 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 _simpler_.

यह भी है कि ये पंक्तियाँ क्या नहीं कहती हैं:
ValueListenableBuilder समय के साथ बदलते हुए valueListenable को संभालता है।
उस परिदृश्य में भी जहां widget.valueNotifier समय के साथ नहीं बदलता जैसा कि हम बोलते हैं, यह चोट नहीं करता है।
एक दिन, वह कथन बदल सकता है। इस मामले में, ValueListenableBuilder नए व्यवहार को इनायत से संभालता है, जबकि, पहले स्निपेट के साथ, अब हमारे पास एक बग है।

तो न केवल ValueListenableBuilder सरल है, बल्कि यह कोड में परिवर्तन के लिए भी अधिक लचीला है - ठीक उसी संख्या में लाइनों के लिए।

इसके साथ, मुझे लगता है कि हम दोनों सहमत हो सकते हैं कि ValueListenableBuilder बेहतर है।
सवाल यह है कि, "हर पुन: प्रयोज्य राज्य तर्क के लिए ValueListenableBuilder के बराबर क्यों नहीं है?"

उदाहरण के लिए, इसके बजाय:

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

हमारे पास होगा:

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

  },
);

अतिरिक्त लाभ के साथ जो initialText बदलता है उसे हॉट-रीलोड किया जा सकता है।

यह उदाहरण थोड़ा छोटा हो सकता है, लेकिन हम इस सिद्धांत का उपयोग थोड़े अधिक उन्नत पुन: प्रयोज्य राज्य तर्कों (जैसे आपके ModeratorBuilder ) के लिए कर सकते हैं।

यह छोटे स्निपेट में "ठीक" है। लेकिन यह कुछ समस्याओं का कारण बनता है क्योंकि हम दृष्टिकोण को मापना चाहते हैं:

• बिल्डर्स "बहुत अधिक शोर" के मुद्दे पर वापस आते हैं।

उदाहरण के लिए, मैंने देखा है कि कुछ लोग अपने मॉडल को इस तरह से प्रबंधित करते हैं:

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

लेकिन फिर, एक विजेट name , age और gender दोनों को एक साथ सुनना चाहेगा।
जिसका अर्थ है कि हमें करना होगा:

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

यह स्पष्ट रूप से आदर्श नहीं है। हमने अपनी build पद्धति को प्रदूषित करने के लिए initState / dispose अंदर के प्रदूषण को हटा दिया।

(उदाहरण के लिए Listenable.merge को अनदेखा करें। यहां कोई फर्क नहीं पड़ता; यह रचना के बारे में अधिक है)

यदि हम बड़े पैमाने पर बिल्डर्स का उपयोग करते हैं, तो इस सटीक परिदृश्य में खुद को देखना आसान है - और Listenable.merge बराबर नहीं है (ऐसा नहीं है कि मुझे यह कंस्ट्रक्टर पसंद है, 😛 से शुरू करने के लिए)

• एक कस्टम बिल्डर लिखना थकाऊ है

  बिल्डर बनाने का कोई आसान उपाय नहीं है। यहां कोई रिफैक्टरिंग टूल हमारी मदद नहीं करेगा - हम केवल "बिल्डर के रूप में निकालें" नहीं कर सकते हैं।
  इसके अलावा, यह जरूरी नहीं कि सहज ज्ञान युक्त हो। कस्टम बिल्डर बनाना पहली बात नहीं है जिसके बारे में लोग सोचेंगे - विशेष रूप से जितने बॉयलरप्लेट के खिलाफ होंगे (हालांकि मैं नहीं हूं)।

  लोग कस्टम राज्य-प्रबंधन समाधान को बेक करने की अधिक संभावना रखते हैं और संभावित रूप से खराब कोड के साथ समाप्त हो जाते हैं।

• बिल्डर्स के पेड़ में हेरफेर करना कठिन है

  मान लें कि हम अपने पिछले उदाहरण में एक 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);
}

... वास्तव में भ्रमित करने वाले तरीकों से छोटी गाड़ी बन जाएगी।

आप इसके आसपास कंपाइलर मैजिक के साथ काम कर सकते हैं (इस तरह कंपोज़ इसे करता है) लेकिन फ़्लटर के लिए जो हमारे कुछ मौलिक डिज़ाइन निर्णयों का उल्लंघन करता है। आप चाबियों के साथ इसके आसपास काम कर सकते हैं, लेकिन तब प्रदर्शन बहुत प्रभावित होता है (चूंकि वैरिएबल लुकअप में मैप लुकअप, हैश, और इसी तरह शामिल होता है), जो फ़्लटर के लिए हमारे कुछ मौलिक डिज़ाइन लक्ष्यों का उल्लंघन करता है।

संपत्ति समाधान जो मैंने पहले सुझाया था, या उससे प्राप्त कुछ, ऐसा लगता है कि यह संकलक जादू से बचता है जबकि अभी भी उन लक्ष्यों को प्राप्त करता है जिन्हें आपने एक ही स्थान पर सभी कोड रखने का वर्णन किया है। मैं वास्तव में समझ नहीं पा रहा हूं कि यह इसके लिए क्यों काम नहीं करेगा। (जाहिर है कि इसे didChangeनिर्भरता और इसी तरह एक पूर्ण समाधान के रूप में जोड़ने के लिए विस्तारित किया जाएगा।) (हम इसे आधार ढांचे में नहीं डालेंगे क्योंकि यह हमारी प्रदर्शन आवश्यकताओं का उल्लंघन करेगा।)

ठीक-ठीक बग के कारण, जैसा कि आप कहते हैं, यही कारण है कि हुक को सशर्त नहीं कहा जाना चाहिए। अधिक विवरण के लिए ReactJS से हुक दस्तावेज़ के build में शीर्ष स्तर पर कॉल करते हैं। JS संस्करण में, आप वापस आ जाते हैं

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

डार्ट समकक्ष समान हो सकता है, यह केवल जेएस की तरह अनपैकिंग नहीं होने के कारण लंबा है:

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

यदि आप सशर्त तर्क चाहते हैं, तो आप निर्माण विधि में title का उपयोग करने का निर्णय ले सकते हैं _उन्हें शीर्ष स्तर पर कॉल करने के बाद_, क्योंकि अब कॉल ऑर्डर अभी भी संरक्षित है। आपके द्वारा उठाए गए इन मुद्दों में से कई को ऊपर लिंक किए गए हुक दस्तावेज़ में समझाया गया है।

ज़रूर। और आप इसे एक पैकेज में कर सकते हैं। मैं सिर्फ इतना कह रहा हूं कि इस तरह की आवश्यकता हमारे डिजाइन दर्शन का उल्लंघन करेगी, यही वजह है कि हम इसे फ्रेमवर्क को स्पंदन में नहीं जोड़ेंगे। (विशेष रूप से, हम पठनीयता और डिबगेबिलिटी के लिए अनुकूलित करते हैं; ऐसा कोड होने से ऐसा लगता है कि यह काम करता है, लेकिन एक सशर्त (जो कोड में स्पष्ट नहीं हो सकता है) के कारण कभी-कभी काम नहीं करता है, ऐसा कुछ नहीं है जिसे हम प्रोत्साहित करना या सक्षम करना चाहते हैं मुख्य ढांचा।)

डिबगिंग/सशर्त व्यवहार कोई समस्या नहीं है। इसलिए एक विश्लेषक प्लगइन महत्वपूर्ण है। ऐसा प्लगइन होगा:

• चेतावनी दें कि क्या कोई फ़ंक्शन useMyFunction नाम के बिना हुक का उपयोग करता है
• चेतावनी दें कि क्या हुक सशर्त रूप से उपयोग किया जाता है
• चेतावनी दें कि लूप/कॉलबैक में हुक का उपयोग किया जाता है।

इसमें सभी संभावित गलतियों को शामिल किया गया है। प्रतिक्रिया ने साबित कर दिया कि यह एक व्यवहार्य बात है।

तब हम लाभों के साथ रह जाते हैं:

• अधिक पठनीय कोड (जैसा कि पहले दिखाया गया है)
• बेहतर हॉट-रीलोड
• अधिक पुन: प्रयोज्य / रचना योग्य कोड
• अधिक लचीला - हम आसानी से गणना की गई अवस्थाएँ बना सकते हैं।

गणना की गई अवस्थाओं के बारे में, किसी वस्तु के उदाहरण को कैश करने के लिए हुक काफी शक्तिशाली होते हैं। इसका उपयोग विजेट के पुनर्निर्माण के लिए तभी किया जा सकता है जब उसका पैरामीटर बदल जाए।

उदाहरण के लिए, हमारे पास हो सकता है:

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 + अपडेट दोनों को संभालने की अनुमति देता है, जो बग से भी बचा जाता है।

यह कुछ ऐसा है कि 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 कोड हो सकता है कई स्थानों पर पुन: उपयोग। इसलिए हमने एक बार फिर से पुन: प्रयोज्यता खो दी।

एफडब्ल्यूआईडब्ल्यू यह स्निपेट इसके बराबर है:

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 ने Vue की बाधाओं को देखते हुए अपना संस्करण बनाया है। मैं नियमित रूप से रिएक्ट के हुक का उपयोग करता हूं और मैं कहूंगा कि कभी-कभी एक विश्लेषक प्लगइन होना पर्याप्त नहीं हो सकता है, इसे शायद भाषा में अधिक एकीकृत किया जाना चाहिए।

किसी भी मामले में, मुझे नहीं लगता कि हम कभी आम सहमति तक पहुंच पाएंगे। ऐसा लगता है कि हम जो पढ़ा जा सकता है उस पर भी असहमत हैं

एक अनुस्मारक के रूप में, मैं इसे केवल इसलिए साझा कर रहा हूं क्योंकि मैं जानता हूं कि समुदाय को इस समस्या से कुछ समस्याएं हैं। मुझे व्यक्तिगत रूप से कोई आपत्ति नहीं है अगर फ़्लटर इस बारे में कुछ नहीं करता है (हालाँकि मुझे इस तरह का दुख होता है), जब तक हमारे पास है:

• एक उचित विश्लेषक प्लगइन सिस्टम
• डार्टपैड के अंदर संकुल का उपयोग करने की क्षमता

यदि आप हुक प्लग इन को आगे बढ़ाना चाहते हैं, जिसे मैं दृढ़ता से प्रोत्साहित करता हूं, लेकिन कुछ समस्याओं में चल रहा हूं, तो मैं उन समस्याओं के लिए मुद्दों को दर्ज करने और उन मुद्दों को ठीक करने के लिए पीआर दाखिल करने की सलाह देता हूं। हम उस पर आपके साथ काम करके अधिक खुश हैं।

यहां पहले के 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);
      },
    );
  }
}

सुविधा के लिए आप एनिमेशन कंट्रोलर जैसी चीजों के लिए तैयार संपत्ति उपवर्ग बना सकते हैं और इसी तरह,

आप शायद इसका एक संस्करण बना सकते हैं जो State.build विधियों में भी काम करेगा ...

मैं कुछ संदेह साझा करता हूं जो @Hixie मेज पर लाता है। दूसरी तरफ मैं हुक के स्पष्ट फायदे देखता हूं और ऐसा लगता है कि कई डेवलपर्स इसे पसंद करते हैं।
पैकेज दृष्टिकोण के साथ मेरी समस्या है कि @timsneath ने प्रस्तावित किया है कि हुक का उपयोग करने वाला कोड बिना कोड के नाटकीय रूप से अलग दिखता है। यदि वे उन्हें आधिकारिक कैनन में नहीं लाते हैं, तो हम फ़्लटर कोड के साथ समाप्त हो जाएंगे जो फ़्लटर कैनन का अनुसरण करने वाले लोगों के लिए पढ़ने योग्य नहीं है।
यदि पैकेज उन चीजों को लागू करना शुरू करते हैं जो ढांचे की प्रतिक्रियात्मकता होनी चाहिए, तो हमें कई अलग-अलग स्पंदन बोलियाँ मिलेंगी जो नए कोड आधारों को सीखना मुश्किल बनाती हैं। तो मेरे लिए शायद मैं हुक का उपयोग उस पल से शुरू कर दूंगा जब इसे स्पंदन का हिस्सा मिल जाएगा।
यह फ्रीज किए गए पैकेज पर मेरे वर्तमान दृश्य जैसा है। मुझे कार्यक्षमता पसंद है लेकिन जब तक यूनियन और डेटा वर्ग डार्ट का हिस्सा नहीं हैं, मैं उन्हें अपने कोड बेस में शामिल नहीं करना चाहता क्योंकि इससे लोगों के लिए मेरा कोड पढ़ना मुश्किल हो जाएगा।

@escamoteur बस इतना मैं समझता हूं, क्या आप सुझाव दे रहे हैं कि हम मौलिक रूप से बदलते हैं कि विजेट कैसे काम करते हैं? या आप सुझाव दे रहे हैं कि कुछ विशिष्ट नई क्षमताएं होनी चाहिए? यह देखते हुए कि मुख्य ढांचे में किसी भी बदलाव के बिना हुक और संपत्ति प्रस्ताव जैसी चीजें कैसे संभव हैं, यह मेरे लिए स्पष्ट नहीं है कि आप वास्तव में क्या बदलना चाहते हैं।

यह किसी भी प्रस्तावित परिवर्तन के बारे में बातचीत से ऑर्थोगोनल है, लेकिन मुझे लगता है कि मैंने @escamoteur , @rrousselGit और अन्य दोनों से यहां और अन्य जगहों से जो सुना है, वह यह है कि _in_ होने के नाते ढांचे को किसी विशेष की वैधता स्थापित करने का एक महत्वपूर्ण तरीका माना जाता है। पहुंचना। अगर आप असहमत हैं तो मुझे सुधारें।

मैं उस सोच की रेखा को समझता हूं - चूंकि ढांचे में होने से बहुत कुछ आता है (उदाहरण के लिए डार्टपैड आज तीसरे पक्ष के पैकेज का समर्थन नहीं करता है, कुछ ग्राहक एनपीएम के साथ जलने के बाद कितने पैकेज पर निर्भर हैं, इस बारे में चिंतित हैं, यह अधिक 'आधिकारिक' लगता है, यह अशक्त-सुरक्षा जैसे परिवर्तनों के साथ आगे बढ़ने की गारंटी है)।

लेकिन इसमें शामिल होने की महत्वपूर्ण लागतें भी हैं: विशेष रूप से, यह एक दृष्टिकोण और एक एपीआई को दर्शाता है। यही कारण है कि हम जो जोड़ते हैं, उसके लिए हम दोनों एक बहुत ही उच्च बार रखते हैं, खासकर जब सर्वसम्मति से समझौता नहीं होता है (सीएफ राज्य प्रबंधन), जहां विकास की संभावना है, या जहां हम आसानी से पैकेज के रूप में कुछ जोड़ सकते हैं।

मुझे आश्चर्य है कि क्या हमें अपने पैकेज-प्रथम दर्शन को दस्तावेज करने की आवश्यकता है, लेकिन फिर से, _कहां_ यह जाता है _what_ के बारे में चर्चा से अलग है जिसे हम राज्य तर्क पुन: उपयोग में सुधार के लिए बदलना चाहते हैं।

हमारी पैकेज नीति यहां प्रलेखित है: https://github.com/flutter/flutter/wiki/Style-guide-for-Flutter-repo#deciding -where-to-put-code

मैं पैकेज-प्रथम दृष्टिकोण को पूरी तरह से समझता हूं और मानता हूं कि यह एक महत्वपूर्ण बात है।
लेकिन मेरा यह भी मानना ​​है कि कुछ समस्याओं को पैकेजों से नहीं, बल्कि मूल में हल करने की जरूरत है।

यही कारण है कि मैं यह तर्क नहीं दे रहा हूं कि provider को स्पंदन में विलय किया जाना चाहिए, लेकिन यह भी मानना ​​​​है कि यह समस्या एक समस्या का वर्णन करती है जिसे फ़्लटर को मूल रूप से हल करना चाहिए (जरूरी नहीं कि हुक के साथ)।

प्रदाता के साथ, फ़्लटर इस तरह की समस्या को हल करने के लिए एक अंतर्निहित आदिम जहाज करता है: इनहेरिटेडविजेट्स।
प्रदाता इसे ""अच्छे" बनाने के लिए केवल शीर्ष पर एक राययुक्त परत जोड़ता है।

हुक अलग हैं। वे _are_ आदिम। वे एक विशिष्ट समस्या के लिए एक निर्विवाद निम्न-स्तरीय समाधान हैं: कई राज्यों में तर्क का पुन: उपयोग करना।
वे अंतिम उत्पाद नहीं हैं, लेकिन कुछ ऐसा है जो लोगों से कस्टम पैकेज बनाने के लिए उपयोग करने की उम्मीद है (जैसे मैंने हुक_रिवरपॉड के साथ किया था)

यह मेरे लिए मददगार होगा (यहाँ इच्छाओं को समझने के संदर्भ में, और ज़रूरतें जो हुक मिलती हैं और इसी तरह) अगर कोई इस बात की विस्तृत समीक्षा प्रदान कर सकता है कि ऊपर मैंने जिस संपत्ति दृष्टिकोण को डूडल किया है, वह हुक की तुलना में कैसे है। (संपत्ति विचार के साथ मेरा लक्ष्य कई राज्यों में तर्क का पुन: उपयोग करने की समस्या को हल करने के लिए ढांचे के शीर्ष पर राय परत करना है।)

मुझे लगता है कि संपत्ति प्रस्ताव इस मुद्दे के एक प्रमुख लक्ष्य को हल करने में विफल रहता है: राज्य के तर्क को इस बात की परवाह नहीं करनी चाहिए कि पैरामीटर कहां से आ रहे हैं और किस स्थिति में वे अपडेट हो रहे हैं।

यह प्रस्ताव सभी तर्कों को एक स्थान पर पुनर्समूहित करके कुछ हद तक पठनीयता बढ़ाता है; लेकिन यह पुन: प्रयोज्य मुद्दे को हल करने में विफल रहता है

अधिक विशेष रूप से, हम नहीं निकाल सकते:

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

_ExampleState और इसे एक अलग विजेट में पुन: उपयोग करें, क्योंकि तर्क Example और initState + didUpdateWidget लिए बाध्य है

यह हुक के साथ कैसा दिखेगा?

रस्ट समुदाय में कुछ ऐसा ही देखने के बाद मैं @timsneath से सहमत हूं। एक बार बाहर आने के बाद कोर से कुछ निकालना बहुत मुश्किल है। बीएलओसी पैटर्न प्रदाता के आने से पहले निर्दिष्ट किया गया था लेकिन अब प्रदाता अनुशंसित संस्करण है। शायद Flutter_hooks उसी तरह "धन्य" संस्करण हो सकता है। मैं ऐसा इसलिए कह रहा हूं क्योंकि भविष्य में लोगों द्वारा लाए गए हुक में सुधार हो सकता है। प्रतिक्रिया, अब हुक होने के कारण, वास्तव में उन्हें बदल नहीं सकता है या उनसे बाहर नहीं निकल सकता है। उन्हें उनका समर्थन करना चाहिए, जैसा कि वे वर्ग घटकों का करते हैं, अनिवार्य रूप से हमेशा के लिए, क्योंकि वे मूल में हैं। इसलिए, मैं पैकेज दर्शन से सहमत हूं।

समस्या यह प्रतीत होती है कि गोद लेने की संख्या कम होगी और लोग जो भी उपयुक्त हो उसका उपयोग करेंगे। इसे हल किया जा सकता है जैसा कि मैं लोगों को 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 आंतरिक रूप से प्रबंधित करता है। हो सकता है कि यह इसके बजाय एक इनहेरिटेड विजेट से userId प्राप्त करेगा।

इस वाक्य-विन्यास से यह स्पष्ट हो जाना चाहिए कि हुक अपने स्वयं के जीवन-चक्र के साथ स्वतंत्र State वस्तुओं की तरह हैं।

एक साइड-नोट के रूप में, पैकेज-प्रथम दृष्टिकोण का एक दोष यह है: पैकेज लेखक समस्याओं को हल करने के लिए हुक पर निर्भर पैकेज प्रकाशित करने की संभावना कम है।

उदाहरण के लिए, एक सामान्य समस्या जिसका प्रदाता उपयोगकर्ताओं को सामना करना पड़ता है, वे स्वचालित रूप से एक प्रदाता की स्थिति का निपटान करना चाहते हैं जब इसका उपयोग नहीं किया जाता है।
मुद्दा यह है कि, प्रदाता उपयोगकर्ता context.watch / context.select सिंटैक्स के काफी शौकीन हैं, वर्बोज़ Consumer(builder: ...) / Selector(builder:...) सिंटैक्स के विपरीत।
लेकिन हमारे पास यह अच्छा सिंटैक्स दोनों नहीं हो सकते हैं _and_ बिना हुक के पहले बताई गई समस्या को हल करें (या https://github.com/flutter/flutter/pull/33213, जिसे अस्वीकार कर दिया गया था)।

यह समस्या है:
प्रदाता इस समस्या को हल करने के लिए flutter_hooks पर निर्भर नहीं रह सकता है।
प्रदाता कितना लोकप्रिय है, इसके कारण हुक पर निर्भर रहना अनुचित होगा।

तो अंत में, मैंने चुना:

• फोर्किंग प्रदाता ( तहत )
• परिणामस्वरूप स्वेच्छा से "स्पंदन पसंदीदा"/Google अनुशंसा खो देते हैं
• इस समस्या को हल करें (और कुछ और)
• एक सिंटैक्स की पेशकश करने के लिए हुक पर निर्भरता जोड़ें जो context.watch आनंद लेने वाले लोग पसंद करेंगे।

मैं जो लेकर आया हूं उससे मैं काफी संतुष्ट हूं, क्योंकि मुझे लगता है कि यह प्रदाता पर एक महत्वपूर्ण सुधार लाता है (यह इनहेरिटेड विजेट्स को संकलित-सुरक्षित बनाता है)।
लेकिन वहां पहुंचने के रास्ते ने मुझे बुरा स्वाद दिया।

जहां तक ​​​​मैं हुक संस्करण और संपत्ति संस्करण के बीच बता सकता हूं, मूल रूप से तीन अंतर हैं:

• हुक संस्करण बहुत अधिक समर्थन कोड है
• संपत्ति संस्करण बहुत अधिक बॉयलरप्लेट कोड है
• हुक संस्करण में निर्माण विधियों में समस्या है जहां यदि आप गलत क्रम में हुक कहते हैं तो चीजें खराब हो जाती हैं और कोड से तुरंत इसे देखने का कोई तरीका नहीं है।

क्या बॉयलरप्लेट कोड वास्तव में इतना बड़ा सौदा है? मेरा मतलब है, अब आप आसानी से संपत्ति का पुन: उपयोग कर सकते हैं, कोड एक ही स्थान पर है। तो यह वास्तव में _only_ अब एक क्रियात्मक तर्क है।

मुझे लगता है कि एक अच्छा समाधान इसके बारे में जानने वाले अन्य पैकेजों पर निर्भर नहीं होना चाहिए। इससे कोई फर्क नहीं पड़ता कि यह ढांचे में है या नहीं। इसका उपयोग नहीं करने वाले लोगों को कोई समस्या नहीं होनी चाहिए। यदि लोग इसका उपयोग नहीं कर रहे हैं तो यह एक समस्या है, आईएमएचओ, एपीआई के लिए एक लाल झंडा है।

मेरा मतलब है, अब आप आसानी से संपत्ति का पुन: उपयोग कर सकते हैं, कोड एक ही स्थान पर है।

कोड एक ही स्थान पर होने का मतलब यह नहीं है कि यह पुन: प्रयोज्य है।
क्या आप एक द्वितीयक विजेट बनाना चाहेंगे जो वर्तमान में _ExampleState अंदर स्थित कोड को किसी भिन्न विजेट में पुन: उपयोग करता है?
एक मोड़ के साथ: उस नए विजेट को अपने राज्य के अंदर आंतरिक रूप से अपने उपयोगकर्ता आईडी का प्रबंधन करना चाहिए, जैसे कि हमारे पास है:

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

यदि लोग इसका उपयोग नहीं कर रहे हैं तो यह एक समस्या है, आईएमएचओ, एपीआई के लिए एक लाल झंडा है।

लोग कुछ का उपयोग नहीं कर रहे हैं क्योंकि यह आधिकारिक नहीं है इसका मतलब यह नहीं है कि एपीआई खराब है।

अतिरिक्त निर्भरता नहीं जोड़ना पूरी तरह से वैध है क्योंकि यह बनाए रखने के लिए अतिरिक्त काम है (संस्करण, लाइसेंस, मूल्यह्रास और अन्य चीजों के कारण)।
मुझे जो याद है, उससे स्पंदन को यथासंभव कम निर्भरता की आवश्यकता होती है।

यहां तक ​​​​कि प्रदाता के साथ भी, जिसे व्यापक रूप से स्वीकार किया जाता है और अब लगभग आधिकारिक है, मैंने लोगों को यह कहते हुए देखा है कि "मैं निर्भरता जोड़ने से बचने के लिए अंतर्निहित इनहेरिटेड विजेट्स का उपयोग करना पसंद करता हूं"।

क्या आप एक द्वितीयक विजेट बनाना चाहेंगे जो वर्तमान में _ExampleState अंदर स्थित कोड को किसी भिन्न विजेट में पुन: उपयोग करता है?

विचाराधीन कोड एक विजेट से उपयोगकर्ता आईडी प्राप्त करने और इसे एक fetchUser विधि में पास करने के बारे में है। उपयोगकर्ता के प्रबंधन के लिए कोड एक ही वस्तु में स्थानीय रूप से बदलना अलग होगा। ऐसा लगता है कि ठीक है? मुझे सच में यकीन नहीं है कि आप यहां किस समस्या को हल करने का प्रयास कर रहे हैं।

रिकॉर्ड के लिए मैं संपत्ति का उपयोग आपके द्वारा वर्णित करने के लिए नहीं करूंगा, यह ऐसा दिखेगा:

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

लोग कुछ का उपयोग नहीं कर रहे हैं क्योंकि यह आधिकारिक नहीं है इसका मतलब यह नहीं है कि एपीआई खराब है।

माना।

तथ्य यह है कि लोग स्वयं कुछ खराब होने का उपयोग नहीं करते हैं, इसका मतलब है कि एपीआई खराब है। जब आप कहते हैं, "पैकेज लेखकों द्वारा समस्याओं को हल करने के लिए हुक पर निर्भर पैकेज प्रकाशित करने की संभावना कम है", तो यह इंगित करता है कि हुक आपके लिए उपयोगी होने के लिए इसका उपयोग करने वाले अन्य लोगों पर निर्भर करता है। एक अच्छा एपीआई, आईएमएचओ, खराब नहीं होता है अगर कोई और इसे नहीं अपनाता है; इसे रुकना चाहिए, भले ही किसी और को इसके बारे में पता न हो। उदाहरण के लिए, ऊपर दिया गया Property उदाहरण अन्य पैकेजों पर निर्भर नहीं करता है जो इसका उपयोग स्वयं उपयोगी होने के लिए करते हैं।

यहां तक ​​​​कि प्रदाता के साथ भी, जिसे व्यापक रूप से स्वीकार किया जाता है और अब लगभग आधिकारिक है, मैंने लोगों को यह कहते हुए देखा है कि "मैं निर्भरता जोड़ने से बचने के लिए अंतर्निहित इनहेरिटेड विजेट्स का उपयोग करना पसंद करता हूं"।

InheritedWidget का उपयोग करना पसंद करने वाले लोगों के साथ क्या गलत है? मैं लोगों पर कोई समाधान थोपना नहीं चाहता। वे जो उपयोग करना चाहते हैं उसका उपयोग करना चाहिए। आप सचमुच एक गैर-समस्या का वर्णन कर रहे हैं। InheritedWidget का उपयोग करना पसंद करने वाले लोगों के लिए समाधान यह है कि वे अपने रास्ते से हट जाएं और उन्हें InheritedWidget का उपयोग करने दें।

. एक अच्छा एपीआई, आईएमएचओ, खराब नहीं होता है अगर कोई और इसे नहीं अपनाता है; इसे रुकना चाहिए, भले ही किसी और को इसके बारे में पता न हो। उदाहरण के लिए, ऊपर दिया गया संपत्ति उदाहरण अन्य पैकेजों पर निर्भर नहीं करता है जो इसका उपयोग स्वयं उपयोगी होने के लिए करते हैं।

एक गलतफहमी है।

समस्या उन लोगों के बारे में नहीं है जो सामान्य रूप से हुक का उपयोग नहीं करते हैं।
यह प्रदाता के बारे में है कि वह समस्याओं को ठीक करने के लिए हुक का उपयोग करने में सक्षम नहीं है क्योंकि हुक आधिकारिक नहीं हैं जबकि प्रदाता है।

उपयोगकर्ता के प्रबंधन के लिए कोड एक ही वस्तु में स्थानीय रूप से बदलना अलग होगा। ऐसा लगता है कि ठीक है? मुझे सच में यकीन नहीं है कि आप यहां किस समस्या को हल करने का प्रयास कर रहे हैं।

रिकॉर्ड के लिए मैं संपत्ति का उपयोग आपके द्वारा वर्णित करने के लिए नहीं करूंगा, यह ऐसा दिखेगा:

यह प्रश्न का उत्तर नहीं देता है। मैंने इसे विशेष रूप से हुक बनाम संपत्ति के बीच कोड पुन: प्रयोज्यता की तुलना करने के लिए कहा।

हुक के साथ, हम FetchUser पुन: उपयोग कर सकते हैं:

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

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

हुक के साथ, हम FetchUser पुन: उपयोग कर सकते हैं:

मुझे समझ में नहीं आता कि यह वांछनीय क्यों है। FetchUser में कोई दिलचस्प कोड नहीं है, यह केवल हुक से fetchUser फ़ंक्शन के लिए एक एडेप्टर है। क्यों न केवल fetchUser सीधे कॉल करें? आप जिस कोड का पुन: उपयोग कर रहे हैं वह दिलचस्प कोड नहीं है।

यह प्रदाता के बारे में है कि वह समस्याओं को ठीक करने के लिए हुक का उपयोग करने में सक्षम नहीं है क्योंकि हुक आधिकारिक नहीं हैं जबकि प्रदाता है।

IMHO कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान है जिसे प्रदाता द्वारा बिल्कुल भी अपनाने की आवश्यकता नहीं होगी। वे पूरी तरह से ऑर्थोगोनल अवधारणाएं होंगी। यह कुछ ऐसा है जिसके बारे में फ़्लटर स्टाइल गाइड "संकलन से बचें" शीर्षक के बारे में बात करता है।

मुझे समझ में नहीं आता कि यह वांछनीय क्यों है। FetchUser के पास कोई दिलचस्प कोड नहीं है, यह केवल हुक से fetchUser फ़ंक्शन के लिए एक एडेप्टर है। क्यों न केवल fetchUser को सीधे कॉल करें? आप जिस कोड का पुन: उपयोग कर रहे हैं वह दिलचस्प कोड नहीं है।

कोई फर्क नहीं पड़ता। हम कोड-पुन: प्रयोज्यता प्रदर्शित करने का प्रयास कर रहे हैं। fetchUser कुछ भी हो सकता है - उदाहरण के लिए ChangeNotifier.addListener सहित।

हमारे पास एक वैकल्पिक कार्यान्वयन हो सकता है जो fetchUser पर निर्भर नहीं है, और केवल अंतर्निहित डेटा-फ़ेचिंग करने के लिए एक एपीआई प्रदान करता है:

int userId;

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

IMHO कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान है जिसे प्रदाता द्वारा बिल्कुल भी अपनाने की आवश्यकता नहीं होगी। वे पूरी तरह से ऑर्थोगोनल अवधारणाएं होंगी। यह कुछ ऐसा है जिसके बारे में फ़्लटर स्टाइल गाइड "संकलन से बचें" शीर्षक के बारे में बात करता है।

इसलिए मैंने उल्लेख किया है कि हुक आदिम हैं

एक रूपक के रूप में:
package:animations Animation पर निर्भर करता है। लेकिन यह कोई समस्या नहीं है, क्योंकि यह मूल आदिम है।
यह एक अलग मामला होगा यदि इसके बजाय package:animations समुदाय द्वारा बनाए गए Animation कांटे का उपयोग कर रहा था

@escamoteur बस इतना मैं समझता हूं, क्या आप सुझाव दे रहे हैं कि हम मौलिक रूप से बदलते हैं कि विजेट कैसे काम करते हैं? या आप सुझाव दे रहे हैं कि कुछ विशिष्ट नई क्षमताएं होनी चाहिए? यह देखते हुए कि मुख्य ढांचे में किसी भी बदलाव के बिना हुक और संपत्ति प्रस्ताव जैसी चीजें कैसे संभव हैं, यह मेरे लिए स्पष्ट नहीं है कि आप वास्तव में क्या बदलना चाहते हैं।

@ हिक्सी नहीं, मेरी बात यह है कि यदि हुक और भी लोकप्रिय हो जाते हैं तो हमें उन्हें ढांचे में शामिल करने के बारे में सोचना चाहिए और उन्हें सभी को सिखाना चाहिए ताकि हम एक सामान्य समझ रखें कि स्पंदन कोड कैसा दिखता है और व्यवहार करता है।
मैं आपकी चिंताओं को बहुत साझा करता हूं लेकिन दूसरी तरफ हुक वाला विजेट वास्तव में सुरुचिपूर्ण दिखता है।
यह पहले की तरह चीजों को करने से मना नहीं करेगा।

यह पहले की तरह चीजों को करने से मना नहीं करेगा।

मुझे लगता है कि ऐसा होगा, मुझे नहीं लगता कि फ़्लटर टीम के लिए यह कहना एक अच्छा विचार होगा कि "अरे अब हम स्पंदन हुक की सलाह देते हैं लेकिन आप अभी भी पहले की तरह काम कर सकते हैं" लोग इस बारे में भ्रमित हो जाएंगे। इसके अलावा, अगर स्पंदन टीम भविष्य में हुक की सिफारिश करती है, तो उन्हें वास्तविक स्पंदन कोड को उदाहरण के रूप में प्रकाशित करना बंद करना होगा।

लोग हमेशा चीजों को करने के "आधिकारिक तरीके" का पालन करते हैं और मुझे लगता है कि फ़्लटर का उपयोग करने के दो आधिकारिक तरीके नहीं होने चाहिए।

कोई फर्क नहीं पड़ता। हम कोड-पुन: प्रयोज्यता प्रदर्शित करने का प्रयास कर रहे हैं। fetchUser कुछ भी हो सकता है - उदाहरण के लिए ChangeNotifier.addListener सहित।

ज़रूर। यही कार्य इसके लिए अच्छे हैं: कोड को सारणित करना। लेकिन हमारे पास पहले से ही फ़ंक्शन हैं। उपरोक्त संपत्ति कोड, और उपरोक्त _setUserId कोड, यह दर्शाता है कि आप उन सभी कोडों को एक स्थान पर ला सकते हैं जो फ्रेमवर्क से किसी विशेष सहायता की आवश्यकता के बिना उन कार्यों को कॉल करते हैं। हमें उन कार्यों में कॉल को लपेटने के लिए हुक की आवश्यकता क्यों है?

IMHO कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान है जिसे प्रदाता द्वारा बिल्कुल भी अपनाने की आवश्यकता नहीं होगी। वे पूरी तरह से ऑर्थोगोनल अवधारणाएं होंगी। यह कुछ ऐसा है जिसके बारे में फ़्लटर स्टाइल गाइड "संकलन से बचें" शीर्षक के बारे में बात करता है।

इसलिए मैंने उल्लेख किया है कि हुक आदिम हैं

वे एक सुविधा हैं, वे आदिम नहीं हैं। यदि वे आदिम थे, तो प्रश्न "समस्या क्या है" का उत्तर देना बहुत आसान होगा। आप कहेंगे "यहाँ एक चीज़ है जो मैं करना चाहता हूँ और मैं यह नहीं कर सकता"।

एक रूपक के रूप में:
package:animations Animation पर निर्भर करता है। लेकिन यह कोई समस्या नहीं है, क्योंकि यह मूल आदिम है।
यह एक अलग मामला होगा यदि इसके बजाय package:animations समुदाय द्वारा बनाए गए Animation कांटे का उपयोग कर रहा था

एनिमेशन वर्ग पदानुक्रम कुछ मौलिक करता है: यह टिकर और उन्हें नियंत्रित करने और उनकी सदस्यता लेने का एक तरीका पेश करता है। एनिमेशन वर्ग पदानुक्रम के बिना, आपको एनिमेशन करने के लिए एनिमेशन वर्ग पदानुक्रम जैसी किसी चीज़ का आविष्कार करना होगा। (आदर्श रूप से कुछ बेहतर। यह हमारा सबसे अच्छा काम नहीं है।) हुक एक नई मौलिक विशेषता पेश नहीं करता है। यह सिर्फ एक ही कोड को अलग तरीके से लिखने का एक तरीका प्रदान करता है। यह हो सकता है कि वह कोड सरल हो, या उससे भिन्न रूप से भिन्न हो, लेकिन यह एक आदिम नहीं है। आपको कोड लिखने के लिए एक हुक-जैसे ढांचे की आवश्यकता नहीं है जो वही काम करता है जो हुक-उपयोग कोड करता है।

मूल रूप से, मुझे नहीं लगता कि इस मुद्दे में वर्णित समस्या कुछ ऐसी है जिसे ढांचे को ठीक करने की आवश्यकता है। इसे कैसे संबोधित किया जाए, इसके लिए अलग-अलग लोगों की बहुत अलग ज़रूरतें होंगी। इसे ठीक करने के कई तरीके हैं, हमने इस बग में पहले से ही कई पर चर्चा की है; कुछ तरीके बहुत सरल हैं और कुछ ही मिनटों में लिखे जा सकते हैं, इसलिए यह शायद ही कोई समस्या है जिसे हल करना इतना कठिन है कि यह हमारे लिए समाधान का स्वामित्व और रखरखाव करने के लिए मूल्य प्रदान करता है। प्रत्येक प्रस्ताव में ताकत और कमजोरियां हैं; कमजोरियां प्रत्येक मामले में ऐसी चीजें हैं जो किसी के लिए उनका उपयोग करने के लिए अवरोधक होंगी। यह वास्तव में स्पष्ट भी नहीं है कि हर कोई इस बात से सहमत है कि समस्या को ठीक करने की आवश्यकता है।

हुक _are_ आदिम
यहाँ डैन का एक सूत्र है: https://twitter.com/dan_abramov/status/1093698629708251136 इसे समझाते हुए। कुछ शब्द अलग-अलग हैं, लेकिन रिएक्ट क्लास कंपोनेंट्स और फ़्लटर स्टेटफुलविजेट्स के बीच समानता के कारण तर्क ज्यादातर फ़्लटर पर लागू होता है

अधिक विशेष रूप से, आप flutter_hooks को गतिशील राज्य मिश्रण के रूप में सोच सकते हैं।

यदि वे आदिम थे, तो प्रश्न "समस्या क्या है" का उत्तर देना बहुत आसान होगा। आप कहेंगे "यहाँ एक चीज़ है जो मैं करना चाहता हूँ और मैं यह नहीं कर सकता"।

यह ओपी में है:

राज्य तर्क का पुन: उपयोग करना मुश्किल है। हम या तो एक जटिल और गहरी नेस्टेड बिल्ड पद्धति के साथ समाप्त होते हैं या तर्क को कई विजेट्स में कॉपी-पेस्ट करना पड़ता है।
इस तरह के तर्क को मिक्सिन और न ही कार्यों के माध्यम से पुन: उपयोग करना संभव नहीं है।

यह हो सकता है कि वह कोड सरल हो, या उससे भिन्न रूप से भिन्न हो, लेकिन यह एक आदिम नहीं है। आपको कोड लिखने के लिए एक हुक-जैसे ढांचे की आवश्यकता नहीं है जो वही काम करता है जो हुक-उपयोग कोड करता है।

प्रोग्राम लिखने के लिए आपको कक्षाओं की आवश्यकता नहीं है। लेकिन कक्षाएं आपको अपने कोड की संरचना करने और इसे सार्थक तरीके से कारक बनाने की अनुमति देती हैं।
और वर्ग आदिम हैं।

मिक्सिन के साथ भी यही बात है, जो कि आदिम भी हैं

हुक एक ही चीज है।

हमें उन कार्यों में कॉल को लपेटने के लिए हुक की आवश्यकता क्यों है?

जब हमें इस तर्क को _one_ स्थान पर नहीं बल्कि _two_ स्थानों पर कॉल करने की आवश्यकता होती है।

इस तरह के तर्क को मिक्सिन और न ही कार्यों के माध्यम से पुन: उपयोग करना संभव नहीं है।

कृपया मुझे एक ठोस उदाहरण दें जहां यह मामला है। अब तक हमने जितने भी उदाहरण पढ़े हैं वे सभी बिना हुक के सरल रहे हैं।

अब तक इस धागे में मैंने @rrousselGit हुक के अलावा कोई अन्य समाधान नहीं देखा है जो हल करता है और इसे पुन: उपयोग करना और राज्य तर्क लिखना आसान बनाता है।

माना कि मैं हाल ही में ज्यादा डार्ट और स्पंदन नहीं कर रहा हूं, इसलिए मुझे उपरोक्त संपत्ति समाधान कोड नमूने में चीजें याद आ रही हैं, लेकिन क्या कोई समाधान है? आज ऐसे कौन से विकल्प हैं जिन्हें पुन: उपयोग के बजाय कॉपी पेस्ट की आवश्यकता नहीं है?
@rrousselGit प्रश्न का उत्तर क्या है:

क्या आप एक द्वितीयक विजेट बनाना चाहेंगे जो वर्तमान में _ExampleState के अंदर स्थित कोड को किसी भिन्न विजेट में पुन: उपयोग करता है?
एक मोड़ के साथ: उस नए विजेट को अपने उपयोगकर्ता आईडी को अपने राज्य के अंदर आंतरिक रूप से प्रबंधित करना चाहिए

यदि उपरोक्त संपत्ति समाधान के साथ इस तरह के एक आसान राज्य तर्क का पुन: उपयोग करना संभव नहीं है तो अन्य विकल्प क्या हैं?
क्या इसका उत्तर केवल इतना है कि स्पंदन में इसे पुन: प्रयोज्य आसान नहीं होना चाहिए? जो पूरी तरह से ठीक है लेकिन थोड़ा दुखी IMHO है।

बीटीडब्लू, क्या स्विफ्टयूआई इसे एक नए/अन्य प्रेरक तरीके से करता है? या क्या उनके पास एक ही राज्य तर्क पुन: प्रयोज्यता की कमी है? मैंने खुद स्विफ्टुई का इस्तेमाल बिल्कुल नहीं किया। शायद यह बहुत अलग है?

सभी बिल्डर्स, मूल रूप से। इस समय राज्य का पुन: उपयोग करने का एकमात्र तरीका बिल्डर्स हैं।
हुक बिल्डर्स को अधिक पठनीय और बनाने में आसान बनाता है

यहां विभिन्न परियोजनाओं के लिए पिछले महीने बनाए गए कस्टम हुक मी या कुछ क्लाइंट का संग्रह है:

• useQuery - जो मेरे द्वारा पहले दिए गए ImplicitFetcher हुक के बराबर है, लेकिन इसके बजाय एक GraphQL क्वेरी बनाता है।
• useOnResume जो बिना के AppLifecycleState.resumed पर कस्टम कार्रवाई करने के लिए कॉलबैक देता है
  विजेट बाइंडिंग ऑब्जर्वर बनाने की समस्या पर जाएं
• useDebouncedListener जो सुनने योग्य (आमतौर पर टेक्स्टफिल्ड या स्क्रॉलकंट्रोलर) को सुनता है, लेकिन श्रोता पर बहस के साथ
• useAppLinkService जो विगेट्स को AppLifecycleState.resumed समान कस्टम ईवेंट पर कुछ तर्क करने की अनुमति देता है लेकिन व्यावसायिक नियमों के साथ
• useShrinkUIForKeyboard कीबोर्ड की उपस्थिति को सुचारू रूप से संभालने के लिए। यह एक बूलियन लौटाता है जो इंगित करता है कि UI को नीचे की पैडिंग के अनुकूल होना चाहिए या नहीं (जो फोकसनोड को सुनने पर आधारित है)
• 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 बीच डुप्लिकेट से बचा जाता है।

वे रिवरपॉड से बहुत सारे useProvider का भी उपयोग करते हैं, जो अन्यथा StreamBuilder / ValueListenableBuilder

महत्वपूर्ण हिस्सा यह है कि विजेट शायद ही कभी "सिर्फ एक हुक" का उपयोग करते हैं।
उदाहरण के लिए, एक विजेट कर सकता है

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

यह संक्षिप्त और बहुत पठनीय है (मान लीजिए कि आपको निश्चित रूप से एपीआई का बुनियादी ज्ञान है)।
ऊपर से नीचे तक सभी तर्क पढ़े जा सकते हैं - कोड को समझने के तरीकों के बीच कोई छलांग नहीं है।
और यहां उपयोग किए गए सभी हुक कोडबेस में कई स्थानों पर पुन: उपयोग किए जाते हैं

अगर हम बिना हुक के ठीक वही काम करते, तो हमारे पास होता:

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 स्तर हैं - 12 यदि हम फ़िल्टर तर्क का पुन: उपयोग करने के लिए FilterBuilder बनाते हैं
• फ़िल्टर तर्क पुन: प्रयोज्य नहीं है क्योंकि यह खड़ा है।
  
  
  
  • हम गलती से timer रद्द करना भूल सकते हैं
  
  
• build पद्धति का आधा भाग पाठक के लिए उपयोगी नहीं है। बिल्डर्स हमें उन चीज़ों से विचलित करते हैं जो मायने रखती हैं
• मैंने यह समझने की कोशिश में 5 मिनट का अच्छा समय खो दिया है कि लापता कोष्ठक के कारण कोड संकलित क्यों नहीं होता है

स्वयं flutter_hooks उपयोगकर्ता के रूप में, मैं अपनी राय का योगदान दूंगा। हुक का उपयोग करने से पहले मैं स्पंदन से खुश था। मैंने ऐसी किसी चीज़ की ज़रूरत नहीं देखी। इसके बारे में पढ़ने और इसके बारे में एक यूट्यूब वीडियो देखने के बाद, मुझे अभी भी यकीन नहीं हुआ, यह अच्छा लग रहा था, लेकिन मुझे वास्तव में इसे प्रेरित करने के लिए कुछ अभ्यास या उदाहरणों की आवश्यकता थी। लेकिन फिर मैंने कुछ नोटिस किया। मैं हर कीमत पर स्टेटफुल विजेट्स से बच रहा था, इसमें बहुत सारे बॉयलरप्लेट शामिल थे, और चीजों को खोजने की कोशिश कर रहे वर्ग के चारों ओर लंघन। उसके कारण मैंने अपने अधिकांश अल्पकालिक राज्य को बाकी ऐप राज्य के साथ एक राज्य प्रबंधन समाधान में स्थानांतरित कर दिया था, और केवल स्टेटलेस विजेट्स का उपयोग किया था। हालाँकि, यह व्यावसायिक तर्क को Navigator , या BuildContext लिए InheritedWidget s / Providers उच्चतर प्राप्त करने पर निर्भरता के कारण जल्दी से स्पंदन पर निर्भर करता है। पेड़। यह नहीं कह रहा कि यह एक अच्छा राज्य प्रबंधन दृष्टिकोण था, मुझे पता है कि यह नहीं था। लेकिन यूआई में राज्य प्रबंधन के बारे में चिंता न करने के लिए मैं कुछ भी कर सकता था।

थोड़ी देर के लिए हुक का उपयोग करने के बाद, मैंने खुद को बहुत अधिक उत्पादक पाया, फ़्लटर का उपयोग करके बहुत अधिक खुश, ऐप स्थिति के बजाय अल्पकालिक स्थिति को सही जगह (यूआई के साथ) में रखा।

मेरे लिए, यह क्षणिक राज्य/नियंत्रकों के लिए कचरा संग्रहकर्ता की तरह है। मुझे UI में सभी सब्सक्रिप्शन का निपटान याद रखने की आवश्यकता नहीं है, हालांकि मैं अभी भी इस तथ्य के प्रति बहुत सचेत हूं कि flutter_hooks मेरे लिए यही करता है। यह मेरे कोड को बनाए रखने और पुन: सक्रिय करने के लिए एक टन आसान बनाता है। मेरे स्नातक अनुसंधान और मनोरंजन के लिए पिछले एक साल में ~ 10 ऐप लिखने की बात करें।

दूसरों की तरह, मुझे नहीं पता कि फ़्लटर एसडीके में इसे शामिल करने के लिए मुख्य प्रेरणा क्या होनी चाहिए। हालाँकि, यहाँ उस विषय पर दो विचार हैं।

1. कभी-कभी मैं ऐसे पैकेज का उपयोग करना आसान बनाने के लिए एक हुक बनाउंगा जिसमें नियंत्रक होते हैं जिन्हें प्रारंभ/निपटान करने की आवश्यकता होती है। (उदाहरण के लिए golden_layout , या zefyr )। मेरा मानना ​​है कि flutter_hooks का उपयोग करने वाले अन्य उपयोगकर्ता ऐसे पैकेज से लाभान्वित होंगे। हालांकि, मैं ऐसे पैकेज को प्रकाशित करने का औचित्य साबित नहीं कर सकता जिसमें सचमुच 1-3 कार्य शामिल हैं। विकल्प यह होगा कि एक किचन-सिंक पैकेज बनाया जाए जिसमें मेरे द्वारा उपयोग किए जाने वाले विभिन्न पैकेजों के लिए बहुत सारे हुक हों, मैं तब केवल एक git निर्भरता का उपयोग कर सकता हूं, लेकिन फिर उन अन्य पैकेजों का उपयोग करने वाले किसी भी व्यक्ति + flutter_hooks को मेरे git पर निर्भर रहना होगा। लाभ के लिए आदेश (जो कम खोजने योग्य है, और संभावित रूप से उन पैकेजों पर निर्भरता है जिनकी वे परवाह नहीं करते हैं), या ऐसे पैकेज पर जिसमें 3 फ़ंक्शन शामिल हैं या मैं pub.dev पर गार्डन-सिंक पैकेज प्रकाशित करता हूं। सभी विचार हास्यास्पद लगते हैं, और बहुत खोजे जाने योग्य नहीं हैं। flutter_hooks अन्य उपयोगकर्ता आसानी से उन कार्यों को अपने कोड में कॉपी और पेस्ट कर सकते हैं या तर्क को स्वयं समझने का प्रयास कर सकते हैं, लेकिन यह पूरी तरह से कोड/पैकेज साझा करने के बिंदु को याद करता है। फ़ंक्शंस मूल पैकेज में बेहतर तरीके से जाएंगे, न कि कुछ 'एक्सटेंशन पैकेज' में। यदि flutter_hooks ढांचे का हिस्सा था, या यहां तक ​​​​कि सिर्फ एक पैकेज का इस्तेमाल किया गया था या characters जैसे ढांचे से निर्यात किया गया था, तो मूल पैकेज के लेखक सरल हुक के लिए पुल अनुरोध स्वीकार करने की अधिक संभावना रखते हैं फ़ंक्शन, और हमारे पास 1-3 फ़ंक्शन पैकेज की गड़बड़ी नहीं होगी।
   यदि फ़्लटर द्वारा flutter_hooks को नहीं अपनाया जाता है तो मुझे 1-3 फ़ंक्शन पैकेजों का एक समूह दिखाई देता है जो pub.dev खोज परिणामों को अव्यवस्थित कर देता है। तथ्य यह है कि ये पैकेज वास्तव में छोटे होंगे, मुझे वास्तव में @rrousselGit से सहमत हैं कि यह एक आदिम है। यदि flutter_hooks भंडार पर 1228 सितारे @rrousselGit द्वारा उल्लिखित समस्याओं को हल करने का कोई संकेत नहीं है, तो मुझे नहीं पता कि क्या है।

2. मैं फ़्लटर रेपो में योगदान के बारे में एक यूट्यूब वीडियो देख रहा था क्योंकि मुझे यह देखने में दिलचस्पी है कि मैं मदद करने के लिए क्या कर सकता हूं। जैसा कि मैं देख रहा था, वीडियो बनाने वाला व्यक्ति नई संपत्ति में काफी आसानी से जुड़ गया लेकिन dispose , didUpdateWidget , और debugFillProperties को अपडेट करना लगभग भूल ही गया। एक स्टेटफुल विजेट की सभी जटिलताओं को फिर से देखकर, और किसी चीज़ को याद करना कितना आसान है, मुझे उन पर फिर से विश्वास हो गया, और मुझे मुख्य फ़्लटर रिपॉजिटरी में योगदान करने के लिए उतना उत्साहित नहीं किया। यह नहीं कह रहा हूं कि इसने मुझे पूरी तरह से रोक दिया है, मुझे अभी भी योगदान देने में दिलचस्पी है, लेकिन ऐसा लगता है कि मैं बॉयलरप्लेट कोड बना रहा हूं जिसे बनाए रखना और समीक्षा करना मुश्किल है। यह कोड लिखने की जटिलता के बारे में नहीं है, बल्कि कोड को पढ़ने और यह सत्यापित करने की जटिलता के बारे में है कि आपने ठीक से निपटाया है और क्षणिक स्थिति का ख्याल रखा है।

लंबे समय से चली आ रही प्रतिक्रिया के लिए क्षमा करें, हालांकि, मैं समय-समय पर इस मुद्दे को देख रहा हूं, और स्पंदन टीम की प्रतिक्रिया से कुछ हद तक चकित हूं। ऐसा लगता है कि आपने किसी ऐप को दोनों तरह से आज़माने के लिए समय नहीं निकाला है, और अपने लिए अंतर देखें। मैं एक अतिरिक्त निर्भरता को बनाए रखने या इसे ढांचे में बहुत अधिक एकीकृत नहीं करने की इच्छा को समझता हूं। हालांकि, flutter_hook ढांचे का मुख्य भाग बहुत अच्छी तरह से प्रलेखित कोड की केवल 500ish लाइनें है। दोबारा, क्षमा करें यदि यह बातचीत के लिए स्पर्शरेखा है और मुझे आशा है कि मैं अपने 2 सेंट देने और बोलने के लिए किसी को नाराज नहीं कर रहा हूं। मैंने पहले बात नहीं की क्योंकि मुझे लगा कि @rrousselGit बहुत अच्छे अंक बना रहा है और स्पष्ट हो रहा है।

लंबे समय से चली आ रही प्रतिक्रिया के लिए क्षमा करें, हालांकि, मैं समय-समय पर इस मुद्दे को देख रहा हूं, और स्पंदन टीम की प्रतिक्रिया से कुछ हद तक चकित हूं। ऐसा लगता है कि आपने किसी ऐप को दोनों तरह से आज़माने के लिए समय नहीं निकाला है, और अपने लिए अंतर देखें।

निष्पक्ष होने के लिए, यह एक अविश्वसनीय रूप से लंबा धागा है और ढांचे के संस्थापक ने कई बार सक्रिय रूप से योगदान दिया है, कई समाधानों के साथ, उन पर प्रतिक्रिया का अनुरोध किया है, और उनके साथ जुड़ा हुआ है और साथ ही यह समझने के लिए काम किया है कि क्या अनुरोध किया जा रहा है। मैं एक अनुरक्षक के मददगार होने के स्पष्ट उदाहरण के बारे में सोचने के लिए ईमानदारी से संघर्ष करता हूं।

काश यह इस मुद्दे के साथ थोड़ा और धैर्य था - मैं इस धागे को पढ़ने के बाद और अधिक गहराई से नहीं समझता, सिवाय इसके कि वे एक राज्य के लिए डिस्पोजेबल के जीवनकाल को बांधने का एक और तरीका हैं। मैं उस दृष्टिकोण को शैलीगत रूप से पसंद नहीं करता, और मुझे लगता है कि कुछ मौलिक रूप से त्रुटिपूर्ण है यदि स्थिति है 'बस प्रतिमान में एक नया ऐप लिखने के लिए समय निकालें, तो आप समझ जाएंगे कि इसे ढांचे में शूहॉर्न करने की आवश्यकता क्यों है! ' - जैसा कि रिएक्ट इंजीनियर ने इस थ्रेड में उल्लेख किया है, यह वास्तव में फ़्लटर के लिए उचित नहीं होगा, और इस थ्रेड में वर्णित लाभ रीवायरिंग की लागत की तुलना में छोटे हैं, जिसका अर्थ है कि लाभ देखने के लिए आपको एक नए कोडबेस की आवश्यकता है।

मैं एक अनुरक्षक के मददगार होने के स्पष्ट उदाहरण के बारे में सोचने के लिए ईमानदारी से संघर्ष करता हूं।

माना। इस चर्चा में भाग लेने के लिए समय निकालने के लिए मैं हिक्सी का आभारी हूं।

मैं इस सूत्र को पढ़ने के बाद और गहराई से समझ नहीं पा रहा हूं

निष्पक्ष होने के लिए यह मुद्दा विशेष रूप से हुक के बारे में बात करने से बचने की कोशिश कर रहा है।
यह समाधान के बजाय समस्या को समझाने की कोशिश करने के बारे में अधिक है

क्या आपको लगता है कि यह ऐसा करने में विफल है?

मैं यहां दोनों पक्षों ( @rrousselGit और @Hixie) को महसूस कर सकता

flutter_hooks दृष्टिकोण बॉयलरप्लेट को काफी कम कर देता है (बस यहां दिखाए गए उदाहरणों से क्योंकि हम ऐसे राज्य कॉन्फ़िगरेशन का पुन: उपयोग कर सकते हैं) और संसाधनों को प्रारंभ/निपटान के बारे में सक्रिय रूप से सोचने के बिना जटिलता को कम करता है। सामान्यतया यह विकास के प्रवाह/गति में सुधार और समर्थन के लिए एक अच्छा काम करता है... भले ही यह फ़्लटर के "मूल" (विषयपरक रूप से) में इतनी अच्छी तरह से फिट नहीं होता है।

कोड के कम से कम> 95% की तरह मैं केवल घोषणात्मक होने के लिए बिल्ड विधि में परिणाम लिखता हूं, कोई स्थानीय चर या लौटाए गए विजेट उपट्री के बाहर कॉल नहीं करता है, सभी तर्क भाग उन राज्य कार्यों के अंदर हैं जो संसाधनों को प्रारंभ करने, असाइन करने और निपटाने के लिए हैं और जोड़ें श्रोताओं (मेरे मामले में MobX प्रतिक्रियाएं) और ऐसी तार्किक सामग्री। चूंकि फ़्लटर में अधिकांश भाग के लिए यह दृष्टिकोण भी है, यह बहुत ही मूल लगता है। ऐसा करने से आपको डेवलपर को हमेशा स्पष्ट और खुले रहने का अवसर मिलता है कि आप क्या करते हैं - यह मुझे हमेशा ऐसे विजेट्स को StatefulWidget में बदलने और initState/निपटान में समान कोड लिखने के लिए मजबूर करता है, लेकिन यह भी हमेशा उस विजेट में ठीक वही लिखा जाता है जो आप सीधे उस विजेट में करना चाहते हैं जिसका उपयोग किया जा रहा है। मेरे लिए व्यक्तिगत रूप से, जैसे @Hixie ने पहले ही खुद का उल्लेख किया है, यह मुझे किसी भी तरह से इस तरह के बॉयलरप्लेट कोड को लिखने से परेशान नहीं करता है और मुझे डेवलपर के रूप में यह तय करने की अनुमति देता है कि flutter_hooks जैसी किसी चीज़ पर भरोसा करने के बजाय इसे सही तरीके से कैसे संभालना है। flutter_hooks मुझे अभी भी यह सोचने की आवश्यकता होगी कि किस तरह के राज्य एक हुक होने के लिए लिखे जाने लायक हैं और इसलिए पुन: उपयोग किए जाते हैं - विभिन्न स्वादों के परिणामस्वरूप या तो विभिन्न "एकल" उपयोग हुक या कोई हुक नहीं हो सकता है क्योंकि मैं कर सकता हूं बहुत बार कॉन्फ़िगरेशन का पुन: उपयोग न करें, लेकिन अधिक कस्टम वाले लिखने की प्रवृत्ति रखते हैं।

मुझे गलत मत समझो, ऐसे हुक में दृष्टिकोण बहुत अच्छा और उपयोगी लगता है, लेकिन मेरे लिए यह एक बहुत ही मौलिक अवधारणा की तरह लगता है जो इसे कैसे संभालना है इसकी मूल अवधारणा को बदल देता है। यह एक पैकेज के रूप में बहुत अच्छा लगता है, अगर वे इसे "मूल रूप से" करने के तरीके से खुश नहीं हैं, तो देवों को इस तरह के दृष्टिकोण का उपयोग करने का अवसर देना बहुत अच्छा लगता है, लेकिन इसे स्पंदन ढांचे का हिस्सा बनाना, कम से कम साफ होना / एकीकृत, इस अवधारणा (बहुत सारे काम) का उपयोग करने के लिए या तो फ़्लटर के बड़े हिस्सों को फिर से लिखना या भविष्य/चयनित सामग्री के लिए इसका उपयोग करना (जो इस तरह के मिश्रित दृष्टिकोण के लिए भ्रमित हो सकता है)।

यदि इसे फ़्लटर ढांचे में ही एकीकृत किया जाएगा और समर्थित/सक्रिय रूप से उपयोग किया जाएगा, तो मैं स्पष्ट रूप से इसमें आशा करता हूं। चूंकि मैं समझता हूं और यहां तक ​​​​कि वर्तमान दृष्टिकोण को पसंद करता हूं और इसे मूल रूप से लागू करने के लिए आवश्यक (संभव) कार्यों को देखता हूं, मैं झिझक को समझ सकता हूं और / या इसे क्यों नहीं किया जाना चाहिए और इसे एक पैकेज के रूप में रखना चाहिए।

अगर मैं गलत हूं तो मुझे सुधारें लेकिन यह धागा एक पठनीय और रचना योग्य तरीके से कई विगेट्स में राज्य तर्क का पुन: उपयोग करने की समस्याओं के बारे में है। विशेष रूप से हुक नहीं। मेरा मानना ​​​​है कि यह धागा समस्या के बारे में एक खुले दृष्टिकोण के साथ चर्चा करने की इच्छा के कारण खोला गया था कि समाधान क्या होना चाहिए।

हुक का उल्लेख किया गया है, हालांकि वे एक समाधान हैं और मेरा मानना ​​​​है कि @rrousselGit उनका उपयोग यहां समस्या/समस्या को हल करने और समझाने के लिए कर रहा है (क्योंकि वे एक समाधान हैं) ताकि एक और समाधान शायद स्पंदन के लिए और अधिक मूल हो सके के साथ और प्रस्तुत किया। अब तक मेरे ज्ञान के लिए इस धागे में कोई अन्य समाधान प्रस्तुत नहीं किया गया है, हालांकि यह पुन: प्रयोज्य मुद्दों को हल करता है?

इसके साथ ही, मुझे नहीं पता कि इस समय धागा कहाँ जा रहा है।
मुझे लगता है कि मुद्दा वास्तव में मौजूद है। या हम इस पर बहस कर रहे हैं?
यदि हम सभी इस बात से सहमत हैं कि आज स्पंदन के मूल के साथ कई विगेट्स में एक संयोजन योग्य तरीके से राज्य तर्क का पुन: उपयोग करना कठिन है, तो ऐसे कौन से समाधान हैं जो एक मुख्य समाधान हो सकते हैं? चूंकि बिल्डर्स वास्तव में हैं (उद्धरण के लिए)

काफी कम पठनीय

संपत्ति समाधान इतनी आसानी से पुन: प्रयोज्य प्रतीत नहीं होता है या यह एक गलत निष्कर्ष है जिसे मैंने खींचा है (?) क्योंकि इसका उपयोग करने के तरीके पर कोई जवाब नहीं था:

एक द्वितीयक विजेट बनाना जो वर्तमान में एक अलग विजेट में _ExampleState के अंदर स्थित कोड का पुन: उपयोग करता है?
एक मोड़ के साथ: उस नए विजेट को अपने उपयोगकर्ता आईडी को अपने राज्य के अंदर आंतरिक रूप से प्रबंधित करना चाहिए

जैसा कि @timsneath ने सुझाव दिया है, मैं एक डिज़ाइन दस्तावेज़ के साथ मदद करने को तैयार हूँ। मुझे लगता है कि यह शायद कुछ केस स्टडी उदाहरणों के साथ समस्या की व्याख्या करने के लिए एक बेहतर प्रारूप है, साथ ही विभिन्न समाधानों का उल्लेख करता है और यह पता लगाता है कि क्या हम ऐसा समाधान ढूंढ सकते हैं जो स्पंदन के अनुकूल हो और यह कहां है। मैं मानता हूं कि इस मुद्दे पर चर्चा थोड़ी खो रही है।

मैं इस समय एक डिज़ाइन दस्तावेज़ बनाने के विचार को लेकर काफी संशय में हूँ।
यह स्पष्ट है कि अभी के लिए, @Hixie इस समस्या को सीधे

मेरे लिए, ऐसा लगता है कि हम समस्या के महत्व और उस समस्या को हल करने में Google की भूमिका पर असहमत हैं।
यदि दोनों पक्ष इस पर सहमत नहीं होते हैं, तो मुझे समझ नहीं आता कि हम इस समस्या से कैसे निपटा जाए, इस पर उत्पादक चर्चा कैसे कर सकते हैं - समाधान चाहे जो भी हो।

यह अंक सूत्र बहुत दिलचस्प पढ़ा गया और मुझे यह देखकर खुशी हो रही है कि विचारों का आदान-प्रदान सभ्य बना हुआ है। हालांकि मैं मौजूदा गतिरोध से थोड़ा हैरान हूं।

जब हुक की बात आती है, तो मेरा विचार यह है कि जबकि फ़्लटर को

समान क्षमताओं की पेशकश करने वाले किसी भी अन्य व्यवहार्य प्रस्तावों की कमी के कारण और इस तथ्य को देखते हुए कि हुक का रिएक्ट में एक अच्छी तरह से सिद्ध ट्रैक रिकॉर्ड है, और यह कि एक मौजूदा समाधान है कि यह स्पंदन के लिए आधारित हो सकता है, मुझे नहीं लगता कि यह होगा ऐसा करने के लिए एक बुरा विकल्प। मुझे नहीं लगता कि हुक अवधारणा, एक आदिम के रूप में जो स्पंदन एसडीके (या उससे भी कम) में शामिल है, स्पंदन से कुछ भी दूर ले जाएगा। मेरी राय में यह केवल इसे समृद्ध करेगा और फ़्लटर के साथ बनाए रखने योग्य और आनंदमय ऐप्स को विकसित करना और भी आसान बना देगा।

जबकि यह तर्क कि हुक उन लोगों के लिए एक पैकेज के रूप में उपलब्ध है जो इसके लाभ प्राप्त करना चाहते हैं, एक मान्य बिंदु है, मुझे लगता है कि यह हुक जैसे आदिम के लिए इष्टतम नहीं है। यहाँ क्यों है।

बहुत बार आंतरिक रूप से पुन: प्रयोज्य पैकेज बनाते समय, हम बहस करते हैं कि क्या पैकेज को "शुद्ध" होने की आवश्यकता है, इस अर्थ में कि यह केवल डार्ट + स्पंदन एसडीके पर निर्भर हो सकता है, या यदि हम इसमें कुछ अन्य पैकेजों की अनुमति देते हैं और यदि ऐसा है, तो कौन सा वाले। यहां तक ​​​​कि प्रदाता "शुद्ध" पैकेज के लिए बाहर है, लेकिन अक्सर उच्च-स्तरीय पैकेज के लिए अनुमति दी जाती है। एक ऐप के लिए हमेशा एक ही बहस होती है कि कौन से पैकेज ठीक हैं और कौन से नहीं। प्रदाता हरा है, लेकिन हुक जैसा कुछ अभी भी एक पैकेज के रूप में एक प्रश्न चिह्न है।

यदि समाधान की तरह एक हुक एसडीके का हिस्सा होगा, तो यह उन क्षमताओं का उपयोग करने के लिए एक स्पष्ट विकल्प होगा जो यह प्रदान करता है। जबकि मैं हुक का उपयोग करना चाहता हूं और इसे पहले से ही एक पैकेज के रूप में अनुमति देना चाहता हूं, मुझे यह भी चिंता है कि यह एक स्पंदन कोड शैली बनाता है और उन अवधारणाओं का परिचय देता है जो फ़्लटर देवों से परिचित नहीं हो सकते हैं जो इसका उपयोग नहीं कर रहे हैं। अगर हम एसडीके में समर्थन के बिना इस रास्ते से नीचे जाते हैं तो यह सड़क में कांटे जैसा लगता है। छोटी व्यक्तिगत परियोजनाओं के लिए, हुक का उपयोग करना एक आसान विकल्प है। मैं इसे रिवरपॉड के साथ मिलकर आज़माने की सलाह देता हूँ।

(हमारा पैकेज रूढ़िवाद आता है, मुझे लगता है कि अतीत में अन्य पैकेज प्रबंधकों पर पैकेज और निर्भरता गड़बड़ी से जला दिया जा रहा है, शायद अद्वितीय नहीं है।)

मैं यह नहीं कह रहा हूं कि वर्तमान समस्या को हल करने का एकमात्र तरीका हुक होगा, भले ही यह अब तक एकमात्र कामकाजी प्रदर्शन समाधान है। समाधान के लिए प्रतिबद्ध होने से पहले अधिक सामान्य स्तर पर विकल्पों की जांच करने के लिए यह निश्चित रूप से दिलचस्प और वैध दृष्टिकोण हो सकता है। ऐसा होने के लिए उस स्पंदन एसडीके की मान्यता की आवश्यकता है _currently में एक दोष है जब यह आसान पुन: प्रयोज्य राज्य तर्क_ की बात आती है, जो कि विस्तृत स्पष्टीकरण के बावजूद वर्तमान में प्रतीत नहीं होता है।

मेरे लिए मुख्य ढांचे में हुक न लगाने के दो मुख्य कारण हैं। पहला यह कि एपीआई में खतरनाक ट्रैप हैं। मुख्य रूप से, यदि आप किसी तरह हुक को गलत क्रम में बुलाते हैं तो चीजें टूट जाएंगी। यह मेरे लिए एक घातक समस्या की तरह लगता है। मैं समझता हूं कि अनुशासन और प्रलेखन का पालन करने से आप इससे बच सकते हैं लेकिन IMHO इस कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान नहीं होगा।

दूसरा यह है कि वास्तव में कोई कारण नहीं होना चाहिए कि लोग इस समस्या को हल करने के लिए केवल हुक (या अन्य पुस्तकालय) का उपयोग न करें। अब, हुक के साथ विशेष रूप से यह काम नहीं करता है, जैसा कि लोगों ने चर्चा की है, क्योंकि हुक लिखना इतना भारी है कि लोग चाहते हैं कि असंबंधित पुस्तकालय हुक का समर्थन करेंगे। लेकिन मुझे लगता है कि इस समस्या के अच्छे समाधान के लिए इसकी आवश्यकता नहीं होगी। एक अच्छा समाधान अकेला खड़ा होगा और इसके बारे में जानने के लिए हर दूसरे पुस्तकालय की आवश्यकता नहीं होगी।

हमने हाल ही में रेस्टोरेबलप्रॉपर्टीज को फ्रेमवर्क में जोड़ा है। यह देखना दिलचस्प होगा कि क्या उन्हें किसी तरह यहां लीवरेज किया जा सकता है ...

मैं सहमत हूं @Hixie एपीआई पर छिपी हुई समस्याएं हैं जिन्हें हल करने के लिए एक विश्लेषक या लिंटर की आवश्यकता होती है। मुझे लगता है कि हमें, जैसा कि कोई भी भाग लेना चाहता है, हमें पुन: प्रयोज्य जीवन चक्र प्रबंधन की समस्या पर विभिन्न समाधानों पर गौर करना चाहिए, शायद डिजाइन डॉक्टर सुझाव के माध्यम से, या अन्यथा। आदर्श रूप से यह अधिक स्पंदन-विशिष्ट और लीवरेज फ़्लटर एपीआई होगा जबकि हुक एपीआई की समस्याओं को भी हल करेगा। मुझे लगता है कि Vue संस्करण शुरू करने के लिए एक अच्छा मॉडल है, जैसा कि मैंने पहले उल्लेख किया है, क्योंकि यह हुक कॉल ऑर्डर पर निर्भर नहीं करता है। क्या किसी और को मेरे साथ जांच-पड़ताल करने में दिलचस्पी है?

@ हिक्सी लेकिन आप इस मुद्दे से सहमत हैं कि विगेट्स के बीच एक रचनात्मक तरीके से राज्य तर्क का पुन: उपयोग करने का कोई अच्छा तरीका नहीं है? इसलिए आपने किसी तरह ResuableProperties का लाभ उठाने के बारे में सोचना शुरू किया?

मेरे लिए मुख्य ढांचे में हुक न लगाने के दो मुख्य कारण हैं। पहला यह कि एपीआई में खतरनाक ट्रैप हैं। मुख्य रूप से, यदि आप किसी तरह हुक को गलत क्रम में बुलाते हैं तो चीजें टूट जाएंगी। यह मेरे लिए एक घातक समस्या की तरह लगता है। मैं समझता हूं कि अनुशासन और प्रलेखन का पालन करने से आप इससे बच सकते हैं लेकिन IMHO इस कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान नहीं होगा।

हुक के साथ काम करने और हुक का उपयोग करने वाले अन्य लोगों के साथ काम करने से यह वास्तव में इतना बड़ा मुद्दा IMHO नहीं है। और सभी बड़े लाभ (देव गति, पुन: प्रयोज्य, कंपोज़ेबिलिटी और आसानी से पठनीय कोड में बड़े लाभ) की तुलना में वे तालिका में लाते हैं।
एक हुक एक हुक है, जैसे एक वर्ग एक वर्ग है, न कि केवल एक फ़ंक्शन, और आप इसे सशर्त रूप से उपयोग नहीं कर सकते। आप इतनी तेजी से सीखते हैं। और आपका संपादक भी इस मुद्दे में मदद कर सकता है।

दूसरा यह है कि वास्तव में कोई कारण नहीं होना चाहिए कि लोग इस समस्या को हल करने के लिए केवल हुक (या अन्य पुस्तकालय) का उपयोग न करें। अब, हुक के साथ विशेष रूप से यह काम नहीं करता है, जैसा कि लोगों ने चर्चा की है, क्योंकि हुक लिखना इतना भारी है कि लोग चाहते हैं कि असंबंधित पुस्तकालय हुक का समर्थन करेंगे। लेकिन मुझे लगता है कि इस समस्या के अच्छे समाधान के लिए इसकी आवश्यकता नहीं होगी। एक अच्छा समाधान अकेला खड़ा होगा और इसके बारे में जानने के लिए हर दूसरे पुस्तकालय की आवश्यकता नहीं होगी।

हुक लिखना बोझिल नहीं है।
यह अब उपलब्ध समाधानों की तुलना में अभी भी आसान है IMHO (उस वाक्यांश का फिर से उपयोग करने के लिए 😉)।
हो सकता है कि आप जो लिख रहे हैं उसका मैं गलत अर्थ निकाल रहा हूं। लेकिन मुझे नहीं लगता कि किसी ने ऐसा कहा है?
मैंने इसे ऐसे पढ़ा जैसे लोग वास्तव में उन सभी लाभों की सराहना करते हैं जो हुक समाधान मेज पर लाते हैं और चाहते हैं कि वे इसे हर जगह इस्तेमाल कर सकें। सभी लाभ प्राप्त करने के लिए। चूंकि एक हुक पुन: प्रयोज्य है, यह बहुत अच्छा होगा यदि तीसरे पक्ष के डेवलपर्स कोड के लिए आत्मविश्वास महसूस कर सकें और सभी को अपने स्वयं के रैपर लिखने की आवश्यकता के बिना अपने स्वयं के हुक भेज सकें। राज्य तर्क की पुन: प्रयोज्यता का लाभ उठाएं।
मुझे लगता है कि @rrousselGit और @gaearon ने आदिम बात पहले ही
हो सकता है कि मुझे यह कथन न मिले क्योंकि मैं यह नहीं देख सकता कि यह इस सूत्र में लोगों ने जो लिखा है उसका एक अच्छा सारांश है। मुझे क्षमा करें।

आशा है कि आगे कोई रास्ता निकलेगा। लेकिन मुझे लगता है कि यह कम से कम इस बात से सहमत होने का समय है कि यह एक मुद्दा है और या तो वैकल्पिक समाधानों के साथ आगे बढ़ें जो बेहतर हैं क्योंकि हुक टेबल पर भी नहीं लगते हैं।
या बस स्पंदन कोर में समस्या को ठीक करने को छोड़ने का निर्णय लें।

आगे का रास्ता कौन तय करता है?
अगला कदम क्या है?

यह मेरे लिए एक घातक समस्या की तरह लगता है। मैं समझता हूं कि अनुशासन और प्रलेखन का पालन करने से आप इससे बच सकते हैं लेकिन IMHO इस कोड के पुन: उपयोग की समस्या का एक अच्छा समाधान नहीं होगा।

रिएक्ट में, हम इसे एक लिटर-स्थिर विश्लेषण के साथ हल करते हैं। हमारे अनुभव में यह दोष एक बड़े कोडबेस में भी महत्वपूर्ण नहीं रहा है। ऐसी अन्य समस्याएं हैं जिन पर हम खामियों पर विचार कर सकते हैं, लेकिन मैं सिर्फ यह बताना चाहता था कि लगातार कॉल ऑर्डर पर निर्भरता लोगों को सहज रूप से एक समस्या होगी, लेकिन संतुलन व्यवहार में बहुत अलग होता है।

मैं इस टिप्पणी को लिखने का असली कारण यह है कि स्पंदन हालांकि एक संकलित भाषा का उपयोग करता है। "अस्तर" वैकल्पिक नहीं है। इसलिए, यदि मेजबान भाषा और यूआई ढांचे के बीच एक संरेखण है, तो यह निश्चित रूप से लागू करना संभव है कि "सशर्त" समस्या कभी भी स्थिर रूप से सामने नहीं आती है। लेकिन यह तभी काम करता है जब UI फ्रेमवर्क भाषा परिवर्तन (जैसे कंपोज़ + कोटलिन) को प्रेरित कर सकता है।

@ हिक्सी लेकिन आप इस मुद्दे से सहमत हैं कि विगेट्स के बीच एक रचनात्मक तरीके से राज्य तर्क का पुन: उपयोग करने का कोई अच्छा तरीका नहीं है? इसलिए आपने किसी तरह ResuableProperties का लाभ उठाने के बारे में सोचना शुरू किया?

यह निश्चित रूप से कुछ लोगों ने उठाया है। यह ऐसा कुछ नहीं है जिसके साथ मुझे आंत का अनुभव है। यह ऐसा कुछ नहीं है जिसे मैंने महसूस किया है कि फ़्लटर के साथ अपने स्वयं के ऐप्स लिखते समय एक समस्या थी। इसका मतलब यह नहीं है कि कुछ लोगों के लिए यह वास्तविक समस्या नहीं है।

चूंकि एक हुक पुन: प्रयोज्य है, यह बहुत अच्छा होगा यदि तीसरे पक्ष के डेवलपर्स कोड के लिए आत्मविश्वास महसूस कर सकें और सभी को अपने स्वयं के रैपर लिखने की आवश्यकता के बिना अपने स्वयं के हुक भेज सकें।

मेरा कहना यह है कि यहां एक अच्छे समाधान के लिए किसी को रैपर लिखने की आवश्यकता नहीं होगी।

अगला कदम क्या है?

कई अगले चरण हैं, उदाहरण के लिए:

• यदि स्पंदन के साथ विशिष्ट समस्याएं हैं जिनके बारे में हमने यहां बात नहीं की है, तो समस्याओं को दर्ज करें और समस्याओं का वर्णन करें।
• यदि आपके पास इस मुद्दे की समस्या को हल करने के तरीके के बारे में एक अच्छा विचार है जो हुक से बेहतर है, तो ऐसा पैकेज बनाएं जो ऐसा करता है।
• अगर ऐसी चीजें हैं जो हुक को बेहतर बनाने के लिए की जा सकती हैं, तो ऐसा करें।
• यदि स्पंदन के साथ ऐसी समस्याएं हैं जो हुक को अपनी पूरी क्षमता तक पहुंचने से रोकती हैं, तो उन्हें नए मुद्दों के रूप में दर्ज करें।
  आदि।

यह अंक सूत्र बहुत दिलचस्प पढ़ा गया और मुझे यह देखकर खुशी हो रही है कि विचारों का आदान-प्रदान सभ्य बना हुआ है।

मुझे यह देखने से नफरत होगी कि एक असभ्य धागा कैसा दिखता है। इस सूत्र में इतनी कम सहानुभूति है कि इसे पढ़ना और किनारे से पालन करना कठिन हो गया है

मेरा कहना यह है कि यहां एक अच्छे समाधान के लिए किसी को रैपर लिखने की आवश्यकता नहीं होगी।

हालांकि आपको रैपर लिखने की जरूरत नहीं है। लेकिन आप अपने स्वयं के कोड में लाभ और पुन: प्रयोज्य सामग्री प्राप्त करना चाह सकते हैं, जिसके आप आदी हो गए हैं। आप निश्चित रूप से अभी भी पुस्तकालयों का उपयोग कर सकते हैं। यदि आप एक हुक रैपिंग स्टफ लिखते हैं (यदि संभव हो तो) शायद ऐसा इसलिए नहीं है क्योंकि आपको लगता है कि यह बोझ है लेकिन यह विकल्प से बेहतर है।

यह वास्तव में एक अच्छा कारण है और एक कारण का उल्लेख किया गया है कि इस धागे में इस मुद्दे का समाधान कोर में क्यों अच्छा होगा। कोर में एक पुन: प्रयोज्य कंपोज़ेबल स्टेट लॉजिक सॉल्यूशन का मतलब होगा कि लोगों को रैपर लिखने की ज़रूरत नहीं होगी क्योंकि इस तरह के पुन: प्रयोज्य तर्क को निर्भरता को जोड़े बिना सभी पैकेजों में सुरक्षित रूप से भेज दिया जा सकता है।

कोर में एक पुन: प्रयोज्य कंपोज़ेबल स्टेट लॉजिक सॉल्यूशन का मतलब होगा कि लोगों को रैपर लिखने की ज़रूरत नहीं होगी क्योंकि इस तरह के पुन: प्रयोज्य तर्क को निर्भरता को जोड़े बिना सभी पैकेजों में सुरक्षित रूप से भेज दिया जा सकता है।

जिस बिंदु को मैं बनाने की कोशिश कर रहा हूं वह यह है कि आईएमएचओ एक अच्छा समाधान के लिए उस तर्क को लिखने के लिए _anyone_ की आवश्यकता नहीं होगी। पुन: उपयोग करने के लिए कोई अनावश्यक तर्क नहीं होगा। उदाहरण के लिए, पहले से "fetchUser" उदाहरण को देखते हुए, "fetchUser" फ़ंक्शन को कॉल करने के लिए किसी को भी हुक या इसके समकक्ष लिखने की आवश्यकता नहीं होगी, आप सीधे "fetchUser" फ़ंक्शन को कॉल करेंगे। इसी तरह "fetchUser" को हुक (या जो कुछ भी हम उपयोग करते हैं) के बारे में कुछ भी जानने की आवश्यकता नहीं होगी और हुक (या जो भी हम उपयोग करते हैं) को "fetchUser" के बारे में कुछ भी जानने की आवश्यकता नहीं होगी। सभी इस तर्क को ध्यान में रखते हुए कि आप तुच्छ लिखते हैं, जैसे कि यह हुक के साथ होता है।

वर्तमान प्रतिबंध इस तथ्य के कारण हैं कि हुक भाषा सीमाओं के शीर्ष पर एक पैच हैं।

कुछ भाषा में, हुक एक भाषा निर्माण होते हैं, जैसे:

state count = 0;

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

यह async /sync फ़ंक्शन का एक प्रकार होगा, जो कॉल के दौरान कुछ राज्यों को बनाए रख सकता है।

इसे अब गैर-सशर्त उपयोग की आवश्यकता नहीं है, क्योंकि भाषा के हिस्से के रूप में, हम प्रत्येक चर को उनके प्रकार के बजाय उनकी पंक्ति संख्या से अलग कर सकते हैं।

मैं जोड़ूंगा कि हुक सीमाएं --track-widget-creation सीमाओं के समान हैं।

यह ध्वज विगेट्स के लिए कॉन्स्टेबल कंस्ट्रक्टर कैनालाइज़ेशन को तोड़ता है। लेकिन यह कोई समस्या नहीं है क्योंकि विजेट घोषणात्मक होते हैं।

उस अर्थ में, हुक समान हैं। सीमाएं वास्तव में मायने नहीं रखतीं, क्योंकि उन्हें घोषणात्मक रूप से हेरफेर किया जाता है।
हम दूसरे को पढ़े बिना एक बहुत विशिष्ट हुक प्राप्त नहीं करेंगे।

हो सकता है कि भ्रूण का उदाहरण आदर्श नहीं है।
लेकिन यूजस्ट्रीम, यूजएनिमस्टियन या यूजस्ट्रीमसिंट्रोलर विजेट ट्री को ज्यादा साफ-सुथरा बनाता है और आपको डिस्पोजल भूलने या डडचेंज डिपेंडेंस की देखभाल करने से रोकता है।
इसलिए वर्तमान तरीका अपने जाल में है जिसमें आप फंस सकते हैं। इसलिए मुझे लगता है कि कॉल अनुक्रम के साथ संभावित समस्या उतनी बड़ी नहीं है।
मुझे यकीन नहीं है कि मैं अपने स्वयं के हुक लिखना शुरू कर दूंगा, लेकिन ढांचे के अंदर उपयोग करने के लिए अक्सर आवश्यक संग्रह का संग्रह अच्छा होगा।
यह उनसे निपटने का एक वैकल्पिक तरीका होगा।

@ हिक्सी , जो आप वर्णन करने की कोशिश कर रहे हैं उसे समझने में सक्षम नहीं होने के लिए वास्तव में खेद है, मैं दोष देता हूं कि यहां शाम को देर हो चुकी है लेकिन शायद यह सिर्फ मैं हूं .. लेकिन आपके द्वारा वर्णित अच्छे समाधान में, राज्य मूल्य कहां होगा, राज्य व्यापार तर्क और आजीवन घटना तर्क है कि समस्या का समाधान आसानी से संगत होने के लिए लपेटता है/एनकैप्सुलेट करता है और विजेट्स के बीच साझा किया जाता है? क्या आप थोड़ा विस्तार से बता सकते हैं कि एक अच्छा समाधान क्या करता है और आप इसे कैसे देखते हैं कि यह आदर्श रूप से काम करेगा?

यहाँ थोड़ा सा हस्तक्षेप करते हुए, यह देखते हुए कि इस चर्चा की सभ्यता के बारे में उल्लेख है। मुझे व्यक्तिगत रूप से नहीं लगता कि यहां कोई असभ्य हो रहा है।

उस ने कहा, मुझे लगता है कि यह ध्यान देने योग्य है कि यह एक ऐसा विषय है जिस पर हर तरफ से लोग गहराई से ध्यान देते हैं।

• @rrousselGit कई वर्षों से StackOverflow और package:provider इश्यू ट्रैकर पर राज्य प्रबंधन के बारे में शुरुआती सवालों के जवाब दे रहा है। मैं केवल इन फायरहोज के बाद का अनुसरण कर रहा हूं, और मेरे पास रेमी के परिश्रम और धैर्य के लिए सम्मान के अलावा कुछ नहीं है।
• फ़्लटर टीम के फ़्लटर के एपीआई, इसकी स्थिरता, सतह, रखरखाव और पठनीयता के बारे में गहराई से ध्यान रखते हैं। यह इसके लिए धन्यवाद है कि फ़्लटर का डेवलपर अनुभव वह है जहाँ वह आज है।
• स्पंदन डेवलपर्स राज्य प्रबंधन के बारे में गहराई से परवाह करते हैं, क्योंकि वे अपने विकास के समय का एक महत्वपूर्ण हिस्सा यही कर रहे हैं।

यह स्पष्ट है कि इस चर्चा में शामिल सभी पक्षों के पास इस बात पर बहस करने का एक अच्छा कारण है कि वे क्या करते हैं। यह भी समझ में आता है कि संदेशों तक पहुँचने में समय लगता है।

इसलिए, अगर चर्चा जारी रहती है, तो मुझे खुशी होगी, या तो यहां या किसी अन्य रूप में। अगर मैं किसी भी तरह से मदद कर सकता हूं, जैसे औपचारिक डॉक्टर के साथ, तो बस मुझे बताएं।

अगर, दूसरी ओर, लोगों को लगता है कि यहां चर्चा हाथ से निकल रही है, तो आइए रुकें और देखें कि संवाद करने का कोई बेहतर तरीका है या नहीं।

(अलग से, मैं इस चर्चा में शामिल होने के लिए @gaearon को चिल्लाना चाहता हूं। इस संबंध में रिएक्ट का अनुभव अमूल्य है।)

@ इमैनुएल-लुंडमैन

लेकिन आपके द्वारा वर्णित अच्छे समाधान में, राज्य मूल्य, राज्य व्यापार तर्क और आजीवन घटना तर्क कहां होगा कि समस्या का समाधान आसानी से संगत होने के लिए लपेटता है/एनकैप्सुलेट करता है और विजेट्स के बीच साझा किया जाता है? क्या आप थोड़ा विस्तार से बता सकते हैं कि एक अच्छा समाधान क्या करता है और आप इसे कैसे देखते हैं कि यह आदर्श रूप से काम करेगा?

दुर्भाग्य से मैं विस्तार से नहीं बता सकता क्योंकि मुझे नहीं पता। :-)

@escamoteur

हो सकता है कि भ्रूण का उदाहरण आदर्श नहीं है।
लेकिन यूजस्ट्रीम, यूजएनिमस्टियन या यूजस्ट्रीमसिंट्रोलर विजेट ट्री को ज्यादा साफ-सुथरा बनाता है और आपको डिस्पोजल भूलने या डडचेंज डिपेंडेंस की देखभाल करने से रोकता है।

इस मुद्दे में कठिनाइयों में से एक है "गोलपोस्टों का हिलना" जहां एक समस्या का वर्णन किया गया है, फिर जब इसका विश्लेषण किया जाता है, तो समस्या को वास्तविक समस्या के रूप में खारिज नहीं किया जाता है और एक नई समस्या का वर्णन किया जाता है, और इसी तरह। कुछ विहित उदाहरणों के साथ आना वास्तव में उपयोगी हो सकता है, उदाहरण के लिए एक डेमो फ़्लटर एप्लिकेशन जिसमें समस्या का एक वास्तविक उदाहरण है, जिसे प्रदर्शनी के लिए अत्यधिक सरलीकृत नहीं किया गया है। फिर हम हुक और अन्य प्रस्तावों का उपयोग करके इसे फिर से लागू कर सकते हैं, और वास्तव में एक दूसरे के खिलाफ ठोस शब्दों में उनका मूल्यांकन कर सकते हैं। (मैं इसे स्वयं करूंगा, सिवाय इसके कि मैं वास्तव में यह नहीं समझता कि समस्या क्या है, इसलिए यह शायद सबसे अच्छा है यदि कोई व्यक्ति जो हुक की वकालत करता है, वह ऐसा करेगा।)

कुछ विहित उदाहरणों के साथ आना वास्तव में उपयोगी हो सकता है, उदाहरण के लिए एक डेमो फ़्लटर एप्लिकेशन जिसमें समस्या का वास्तविक उदाहरण है, जो कि प्रदर्शनी के लिए अत्यधिक सरलीकृत नहीं है

मैंने यहां जो उदाहरण दिया है, उसके बारे में आप क्या सोचते हैं? https://github.com/flutter/flutter/issues/51752#issuecomment -669626522

यह एक वास्तविक दुनिया कोड-स्निपेट है।

मुझे लगता है कि यह एक अच्छी शुरुआत होगी। क्या हम इसे ऐसी स्थिति में ला सकते हैं जहां यह एक स्टैंड-अलोन ऐप के रूप में चलता है, एक ऐसे संस्करण के साथ जो हुक का उपयोग नहीं करता है और एक संस्करण जो करता है?

क्षमा करें, मेरा मतलब कोड-स्निपेट के रूप में था, ऐप के रूप में नहीं।

मुझे लगता है कि "डेमो स्पंदन एप्लिकेशन" विचार के साथ एक मुद्दा यह है कि इस धागे में किए गए उदाहरण बहुत वास्तविक हैं।
वे अति सरलीकृत नहीं हैं।
हुक का प्राथमिक उपयोग-मामला यदि सूक्ष्म राज्यों, जैसे कि बहस, घटना संचालकों, सदस्यताओं, या निहित साइड-इफेक्ट्स को कारक बनाना है - जो अधिक उपयोगी तर्क प्राप्त करने के लिए एक साथ संयुक्त होते हैं।

मेरे पास रिवरपॉड पर कुछ उदाहरण हैं, जैसे https://marvel.riverpod.dev/#/ जहां स्रोत कोड यहां है: https://github.com/rrousselGit/river_pod/tree/master/examples/marvel/lib
लेकिन यह अब तक जो उल्लेख किया गया था, उससे बहुत अलग नहीं होगा।

@ हिक्सी

मुझे वास्तव में यह समझने में परेशानी होती है कि यह समस्या क्यों है। मैंने बहुत सारे स्पंदन अनुप्रयोग लिखे हैं, लेकिन यह वास्तव में इतना बड़ा मुद्दा नहीं लगता है? यहां तक ​​​​कि सबसे खराब स्थिति में, संपत्ति घोषित करने, इसे प्रारंभ करने, इसे निपटाने और इसे डीबग डेटा पर रिपोर्ट करने के लिए चार लाइनें हैं (और वास्तव में यह आमतौर पर कम है, क्योंकि आप आमतौर पर इसे उसी लाइन पर घोषित कर सकते हैं जिसे आप इसे प्रारंभ करते हैं, आम तौर पर ऐप्स डीबग गुणों में राज्य जोड़ने के बारे में चिंता करने की आवश्यकता नहीं है, और इनमें से कई वस्तुओं में राज्य नहीं है जिसे निपटाने की आवश्यकता है)।

मैं एक ही नाव में हूँ।
मैं मानता हूँ, मैं यहाँ वर्णित मुद्दों को भी वास्तव में नहीं समझता हूँ। मैं यह भी नहीं समझता कि "राज्य तर्क" क्या है जिसका लोग उल्लेख करते हैं, जिसे पुन: प्रयोज्य करने की आवश्यकता है।

मेरे पास कई स्टेटफुल फॉर्म विजेट हैं, जिनमें से कुछ में दसियों फॉर्म फ़ील्ड हैं, और मुझे टेक्स्ट कंट्रोलर और फोकसनोड्स को स्वयं प्रबंधित करना है। मैं उन्हें स्टेटलेसविजेट की जीवनचक्र विधियों में बनाता और उनका निपटान करता हूं। हालांकि यह काफी थकाऊ है, मेरे पास ऐसा कोई विजेट नहीं है जो समान मात्रा में नियंत्रकों/फोकस नोड्स या समान उपयोग के मामले का उपयोग करता हो। उनके बीच एकमात्र सामान्य बात स्टेटफुल होने और एक रूप होने की सामान्य अवधारणा है। सिर्फ इसलिए कि यह एक पैटर्न है इसका मतलब यह नहीं है कि कोड दोहराया गया है।
मेरा मतलब है, मेरे कोड के बहुत से हिस्सों में मुझे सरणी के माध्यम से लूप करना है, मैं अपने ऐप दोहराने वाले कोड में "(चीजों में var चीज़)" करने के लिए कॉल नहीं करूंगा।

मुझे StatefulWidget की शक्ति पसंद है जो इसके जीवनचक्र एपीआई की सादगी से आती है। यह मुझे StatefulWidgets लिखने की अनुमति देता है जो एक काम करते हैं और इसे बाकी ऐप से अलग करते हैं। मेरे विजेट्स की "स्थिति" हमेशा स्वयं के लिए निजी होती है, इसलिए मेरे विजेट्स का पुन: उपयोग करना कोई समस्या नहीं है, न ही कोड का पुन: उपयोग करना है।

मेरे पास यहां लाए गए उदाहरणों के साथ कुछ मुद्दे हैं, जो कुछ हद तक आपके बिंदुओं के अनुरूप हैं:

• ठीक उसी "स्टेट लॉजिक" के साथ कई स्टेटफुल विजेट्स बनाना गलत लगता है और विजेट्स के स्व-निहित होने के विचार के विपरीत है। लेकिन फिर, मैं उलझन में हूं कि आम "राज्य तर्क" से लोगों का क्या मतलब है।
• हुक ऐसा कुछ भी नहीं करते हैं जो मैं पहले से ही सादे डार्ट और बुनियादी प्रोग्रामिंग अवधारणाओं (जैसे फ़ंक्शन) का उपयोग करके नहीं कर सकता
• समस्याएं प्रोग्रामिंग की एक निश्चित शैली से संबंधित या संबंधित प्रतीत होती हैं, एक शैली जो "पुन: प्रयोज्य वैश्विक स्थिति" के पक्ष में प्रतीत होती है।
• कोड की कुछ पंक्तियों को दूर करने से "समयपूर्व कोड अनुकूलन" की गंध आती है और एक ऐसे मुद्दे को हल करने के लिए जटिलता जोड़ता है जिसका ढांचे से कोई लेना-देना नहीं है और लोग इसका उपयोग कैसे करते हैं।

यह काफी कम पठनीय है।

• हमारे पास इंडेंटेशन के 10 स्तर हैं - 12 यदि हम फ़िल्टर तर्क का पुन: उपयोग करने के लिए FilterBuilder बनाते हैं

• फ़िल्टर तर्क पुन: प्रयोज्य नहीं है क्योंकि यह खड़ा है।

  • हम गलती से timer रद्द करना भूल सकते हैं
• build पद्धति का आधा भाग पाठक के लिए उपयोगी नहीं है। बिल्डर्स हमें उन चीज़ों से विचलित करते हैं जो मायने रखती हैं
• मैंने यह समझने की कोशिश में 5 मिनट का अच्छा समय खो दिया है कि लापता कोष्ठक के कारण कोड संकलित क्यों नहीं होता है

आपका उदाहरण इस बात का अधिक प्रदर्शन है कि वर्बोज़ प्रदाता कैसा है और हर चीज़ के लिए इनहेरिटेडविजेट्स का दुरुपयोग क्यों करना एक बुरी बात है, बजाय इसके कि फ़्लटर के स्टेटलेसविजेट और स्टेट लाइफसाइकल एपीआई के साथ कोई वास्तविक समस्या है।

@rrousselGit क्षमा करें अगर मैं स्पष्ट नहीं था। मैं ऊपर जो सुझाव दे रहा था, वह विशेष रूप से वेनिला फ़्लटर एप्लिकेशन (स्टेटफुलविजेट आदि का उपयोग करके) बनाने के लिए था जो यथार्थवादी हैं और आपके द्वारा बताई जा रही समस्याओं को दिखाते हैं, ताकि हम वास्तविक पूर्ण एप्लिकेशन के आधार पर प्रस्ताव बना सकें। हमने यहां जिन ठोस उदाहरणों पर चर्चा की है, जैसे "fetchUser" उदाहरण, हमेशा "अच्छी तरह से आप उस मामले को इस तरह से संभाल सकते हैं और यह आसान होगा और हुक की आवश्यकता नहीं होगी" की तर्ज पर चर्चा के साथ समाप्त हुआ है। "ठीक है, यह बहुत सरल है, वास्तविक दुनिया में आपको हुक की आवश्यकता है"। तो मेरा कहना है, आइए एक वास्तविक दुनिया का उदाहरण बनाएं कि वास्तव में _does_ को हुक की आवश्यकता है, जो कि अधिक सरलीकृत नहीं है, जो कोड के पुन: उपयोग में कठिनाई को दर्शाता है, इस तरह से हम देख सकते हैं कि क्या बिना किसी नए कोड का उपयोग किए इन समस्याओं से बचना संभव है। , या यदि हमें नए कोड की आवश्यकता है, और बाद के मामले में, क्या इसे हुक की तरह आकार देना है या यदि हम इससे भी बेहतर समाधान ढूंढ सकते हैं।

मैं यह भी नहीं समझता कि "राज्य तर्क" क्या है जिसका लोग उल्लेख करते हैं, जिसे पुन: प्रयोज्य करने की आवश्यकता है।

काफी उचित
राज्य तर्क के समानांतर यूआई तर्क होगा, और विजेट तालिका में क्या लाएगा।

हम तकनीकी रूप से विजेट परत को हटा सकते हैं। उस स्थिति में, जो कुछ बचा होगा वह है 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 अनुरोध करना,...

आपका उदाहरण इस बात का अधिक प्रदर्शन है कि वर्बोज़ प्रदाता कैसा है और हर चीज़ के लिए इनहेरिटेडविजेट्स का दुरुपयोग क्यों करना एक बुरी बात है, बजाय इसके कि फ़्लटर के स्टेटलेसविजेट और स्टेट लाइफसाइकल एपीआई के साथ कोई वास्तविक समस्या है।

यह प्रदाता से असंबंधित है (यह कोड प्रदाता का उपयोग नहीं करता है)।
यदि कुछ भी हो, तो प्रदाता के पास यह बेहतर है क्योंकि इसमें context.watch बजाय Consumer ।

मानक समाधान Consumer को ValueListenableBuilder से बदलना होगा - जो ठीक उसी समस्या की ओर ले जाता है।

मैं सहमत हूं @ हिक्सी , मुझे लगता है कि हुक के साथ बनाम स्पंदन की प्रभावशीलता का न्याय करने के लिए हमें दो तरफ तुलना करने की आवश्यकता है। यह दूसरों को यह समझाने में भी मदद करेगा कि हुक बेहतर है या नहीं, या शायद एक और समाधान और भी बेहतर है यदि वेनिला ऐप इस तीसरे समाधान के साथ बनाया गया है। यह वेनिला ऐप अवधारणा कुछ समय के लिए आसपास रही है, जिसमें टोडोएमवीसी जैसी चीजें विभिन्न फ्रंट-एंड फ्रेमवर्क के बीच अंतर दिखाती हैं, इसलिए यह जरूरी नहीं कि नया हो। मैं इन उदाहरण ऐप्स को बनाने में मदद कर सकता हूं।

@satvikpendem
मैं मदद करने को तैयार हूं।
मुझे लगता है कि flutter_hooks रेपो में उदाहरण ऐप शायद कई अलग-अलग हुक दिखाता है और वे क्या आसान/समस्याएं हल करते हैं, और यह एक अच्छी शुरुआत होगी।

मैं यह भी सोचता हूं कि हम इस अंक में प्रस्तुत किए गए कुछ उदाहरणों और दृष्टिकोणों का भी उपयोग कर सकते हैं।

अद्यतन: कोड यहाँ है, https://github.com/TimWhiting/local_widget_state_approaches
मुझे यकीन नहीं है कि भंडार के लिए उचित नाम है, इसलिए यह न मानें कि यही वह समस्या है जिसे हम हल करने का प्रयास कर रहे हैं। मैंने मूल काउंटर ऐप को स्टेटफुल और हुक में किया है। मेरे पास आज रात के बाद ज्यादा समय नहीं है, लेकिन मैं अधिक उपयोग के मामलों को जोड़ने की कोशिश करूंगा जो इस बात का अधिक उदाहरण हैं कि समस्या क्या हो सकती है। जो कोई भी योगदान देना चाहता है, कृपया पहुंच का अनुरोध करें।

हमने यहां जिन ठोस उदाहरणों पर चर्चा की है, जैसे "fetchUser" उदाहरण, हमेशा "अच्छी तरह से आप उस मामले को इस तरह से संभाल सकते हैं और यह आसान होगा और हुक की आवश्यकता नहीं होगी" की तर्ज पर चर्चा के साथ समाप्त हुआ है। "ठीक है, यह बहुत सरल है, वास्तविक दुनिया में आपको हुक की आवश्यकता है"।

मैं असहमत हूं। मुझे नहीं लगता कि मैंने ऐसा देखा है "आप इस तरह से उस मामले को संभाल सकते हैं" और सहमत हुए कि परिणामी कोड हुक संस्करण से बेहतर था।

मेरा कहना यह था कि जब हम चीजों को अलग तरह से कर सकते हैं, तो परिणामी कोड त्रुटि-प्रवण और/या कम पठनीय है।
यह fetchUser भी लागू होता है

हुक ठीक यही काम करते हैं।
लेकिन इसके बजाय Text , आपको स्टेट लॉजिक्स के लिए कस्टम हुक मिलते हैं। जिसमें श्रोता, बहस करना, HTTP अनुरोध करना,...

नहीं, मुझे अभी भी समझ में नहीं आया कि यह सामान्य राज्य तर्क क्या होना चाहिए। मेरा मतलब है कि मेरे पास कई विजेट हैं जो डेटाबेस से उनके "initState/didUpdateDependency" विधियों में पढ़ते हैं, लेकिन मुझे दो विजेट नहीं मिल रहे हैं जो सटीक वही क्वेरी बनाते हैं इसलिए उनका "तर्क" समान नहीं है।

HTTP अनुरोध करने के उदाहरण का उपयोग करना। मान लें कि मेरे पास मेरी सेवा कक्षा में कहीं "मेकएचटीटीपीआरक्वेट (यूआरएल, पैरामीटर्स)" है कि मेरे कुछ विजेट्स का उपयोग करने की आवश्यकता है, जब भी मुझे इसकी आवश्यकता होती है तो मैं सीधे विधि को कॉल करने के बजाय हुक का उपयोग क्यों करूं? इस मामले में सादे विधि कॉल से अलग हुक का उपयोग कैसे कर रहा है?

श्रोताओं। मेरे पास समान बातें सुनने वाले विजेट नहीं हैं। मेरे प्रत्येक विजेट के लिए उन्हें जो कुछ भी चाहिए उसकी सदस्यता लेने और यह सुनिश्चित करने के लिए जिम्मेदार है कि वे सदस्यता समाप्त करें। अधिकांश चीजों के लिए हुक वाक्यात्मक चीनी हो सकते हैं, लेकिन चूंकि मेरे विजेट वस्तुओं के समान संयोजन को नहीं सुनेंगे, इसलिए हुक को किसी भी तरह "पैरामीट्रिज्ड" करना होगा। फिर, हुक एक सादे पुराने फ़ंक्शन से कैसे भिन्न होते हैं?

यह प्रदाता से असंबंधित है (यह कोड प्रदाता का उपयोग नहीं करता है)।
यदि कुछ भी हो, तो प्रदाता के पास यह बेहतर है क्योंकि इसमें context.watch बजाय Consumer ।

हुह? आपके "चैटस्क्रीन" हुकविजेट को हल करने के लिए आपका प्रतिरूप यह था:

<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) {

यह प्रदाता से कैसे असंबंधित है? मैं उलझन में हूं। मैं प्रदाता में कोई विशेषज्ञ नहीं हूं, लेकिन यह निश्चित रूप से प्रदाता का उपयोग कर कोड जैसा लगता है।

मैं इस बात पर जोर देना चाहूंगा कि यह मुद्दा जटिल राज्यों का नहीं है।
यह छोटे वेतन वृद्धि के बारे में है जिसे पूरे कोडबेस पर लागू किया जा सकता है।

यदि हम यहां दिए गए उदाहरणों के मूल्य से असहमत हैं, तो एक एप्लिकेशन बातचीत में कुछ भी नहीं लाएगा - क्योंकि ऐसा कुछ भी नहीं है जो हम हुक के साथ कर सकते हैं जो हम स्टेटफुलविजेट के साथ नहीं कर सकते।

मेरी अनुशंसा है कि इसके बजाय ImplicitFetcher जैसे साइड-बाय-साइड माइक्रो-स्निपेट की तुलना करें, और _objectively_ यह निर्धारित करें कि मापने योग्य मीट्रिक का उपयोग करके कौन सा कोड बेहतर है, और इसे विभिन्न प्रकार के छोटे स्निपेट के लिए करें।

यह प्रदाता से कैसे असंबंधित है? मैं उलझन में हूं। मैं प्रदाता में कोई विशेषज्ञ नहीं हूं, लेकिन यह निश्चित रूप से प्रदाता का उपयोग कर कोड जैसा लगता है।

यह कोड प्रदाता से नहीं बल्कि एक अलग प्रोजेक्ट से है जो इनहेरिटेडविड्ज का उपयोग नहीं करता है।
प्रदाता के Consumer में provider पैरामीटर नहीं है।

और जैसा कि मैंने उल्लेख किया है, आप Consumer -> ValueListenableBuilder/StreamBuilder/BlocBuilder/ऑब्जर्वर/...

उनके "initState/didUpdateDependency" विधियों में, लेकिन मुझे दो विजेट नहीं मिल रहे हैं जो सटीक वही क्वेरी बनाते हैं इसलिए उनका "तर्क" समान नहीं है।

हम जिस राज्य तर्क का पुन: उपयोग करना चाहते हैं, वह "एक प्रश्न पूछें" नहीं है, बल्कि "जब x बदलता है तो कुछ करें"। "कुछ करो" बदल सकता है, लेकिन "जब एक्स बदलता है" आम है

ठोस उदाहरण:
हम चाहते हैं कि जब भी आईडी में बदलाव आए तो विजेट एक 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);
}

बनाम

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

इस परिदृश्य में, अनुरोध करने और इसे रद्द करने से संबंधित सभी तर्क साझा किए जाते हैं। हमारे पास केवल एक सार्थक अंतर रह गया है, जो fetchUser बनाम fetchMessage ।
हम इसमें से एक पैकेज भी बना सकते हैं useUnaryCancelableOperation , और अब हर कोई अपने ऐप में इसका पुन: उपयोग कर सकता है।

यदि हम यहां दिए गए उदाहरणों के मूल्य से असहमत हैं, तो एक एप्लिकेशन बातचीत में कुछ भी नहीं लाएगा - क्योंकि ऐसा कुछ भी नहीं है जो हम हुक के साथ कर सकते हैं जो हम स्टेटफुलविजेट के साथ नहीं कर सकते।

अगर वास्तव में ऐसा है तो मुझे लगता है कि हमें इस बग को बंद कर देना चाहिए, क्योंकि हम यहां दिए गए उदाहरणों पर पहले ही चर्चा कर चुके हैं और वे सम्मोहक नहीं हैं। मैं वास्तव में स्थिति को बेहतर ढंग से समझना चाहता हूं, हालांकि, और यह इस बग में पहले की टिप्पणियों से लग रहा था जैसे कि लाभ आवेदन स्तर पर हैं, इसलिए मेरा सुझाव है कि हम अनुप्रयोगों के उदाहरणों का अध्ययन करें।

फर्क सिर्फ इतना है कि हमने fetchUser को fetchMessage । तर्क अन्यथा 100% समान है। लेकिन हम इसका पुन: उपयोग नहीं कर सकते, जो त्रुटि-प्रवण है।

त्रुटि प्रवण क्या है और पुन: उपयोग करने के लिए क्या है? अमूर्तता और वर्ग पदानुक्रम की एक पूरी नई परत को लागू करना ताकि हमें कक्षा में तीन विधियों को लागू करने की आवश्यकता न हो और यह बहुत अधिक है।

दोबारा, सिर्फ इसलिए कि कुछ एक सामान्य पैटर्न है इसका मतलब यह नहीं है कि आपको इसके लिए एक नई सुविधा बनाने की आवश्यकता है। इसके अलावा, यदि आप इस मामले में दोहराव वाले कोड को कम करना चाहते हैं तो आप केवल StatefulWidget* वर्ग का विस्तार कर सकते हैं और सामान्य बिट्स के साथ initstate/didUpdateWidget विधियों को ओवरराइड कर सकते हैं।

हुक के साथ, हम इसे useUnaryCancelableOperation हुक में कारक बना सकते हैं।

जिसका अर्थ है कि समान दो विजेट इसके बजाय करेंगे:

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

बनाम

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

इस परिदृश्य में, अनुरोध करने और इसे रद्द करने से संबंधित सभी तर्क साझा किए जाते हैं। हमारे पास केवल एक सार्थक अंतर रह गया है, जो fetchUser बनाम fetchMessage ।
हम इसमें से एक पैकेज भी बना सकते हैं useUnaryCancelableOperation , और अब हर कोई अपने ऐप में इसका पुन: उपयोग कर सकता है।

मुझे खेद है, लेकिन यह मेरी ओर से निश्चित नहीं है। इस तथ्य के अलावा कि यह कोड अतिरेक की केवल एक छोटी राशि को बचाता है, एक कोड को "कारक बनाना" जो कि अवधारणात्मक रूप से "initState" और "अपडेट" जीवनचक्र विधियों से संबंधित है, निर्माण विधि में एक बड़ी संख्या है।

मुझे उम्मीद है कि मेरे निर्माण के तरीके केवल लेआउट का निर्माण करेंगे और कुछ नहीं। निर्भरताओं को स्थापित करना और तोड़ना निश्चित रूप से निर्माण विधि से संबंधित नहीं है, और मुझे अपने भविष्य के स्वयं और अन्य लोगों के लिए यह स्पष्ट करने के लिए एक ही प्रकार के कोड को स्पष्ट रूप से फिर से लिखने में मुझे बहुत खुशी है कि मेरा विजेट क्या कर रहा है। और चलिए सब कुछ बिल्ड मेथड में नहीं रखते हैं।

अगर वास्तव में ऐसा है तो मुझे लगता है कि हमें इस बग को बंद कर देना चाहिए

@ हिक्सी कृपया मत करो। लोग इस मुद्दे की परवाह करते हैं। मैंने आपके साथ reddit पर उसी चीज़ के बारे https://github.com/szotp/SwiftUI_vs_Flutter

यह हुक के बारे में नहीं है, यह किसी भी तरह स्टेटफुल विजेट्स में सुधार करने के बारे में है। लोग बस बॉयलरप्लेट लिखने से नफरत करते हैं। स्विफ्टयूआई कोड लिखने वाले देवों के लिए, जो आरएआईआई के लिए उपयोग किए जाते हैं और दृश्यों के शब्दार्थ की नकल करते हैं, मैन्युअल रूप से डिस्पोजेबल का प्रबंधन करना बंद लगता है।

इसलिए मैं स्पंदन टीम को कम से कम इसे एक समस्या के रूप में देखने और वैकल्पिक समाधान/सुधार के बारे में सोचने के लिए प्रोत्साहित करता हूं।

मुझे उम्मीद है कि मेरे निर्माण के तरीके केवल लेआउट का निर्माण करेंगे और कुछ नहीं। निर्भरताओं को स्थापित करना और तोड़ना निश्चित रूप से निर्माण विधि में नहीं है,
यह एक महत्वपूर्ण बिंदु है। निर्माण विधियां शुद्ध होनी चाहिए। फिर भी मैं चाहता था कि हमें बिना किसी कठिनाई के लाभ मिल सके

मैं वास्तव में यहां अधिक उदाहरणों के लिए धक्का नहीं समझता। यह उसके चेहरे पर स्पष्ट है।

हुक द्वारा हल की गई समस्या सरल और स्पष्ट है, यह कोड को DRY रखता है। इसके लाभ स्पष्ट हैं, कम कोड == कम बग, रखरखाव आसान है, बग को छिपाने के लिए कम जगह, निचली लाइन की गिनती समग्र रूप से पठनीयता में वृद्धि करती है, जूनियर प्रोग्रामर बेहतर इंसुलेटेड हैं आदि।

यदि आप एक वास्तविक दुनिया के उपयोग के मामले की बात कर रहे हैं, तो यह एक ऐसा ऐप है जहां आप 12 अलग-अलग दृश्यों में 12 एनिमेटर नियंत्रकों को स्थापित और फाड़ रहे हैं, हर बार, एक निपटान () कॉल को गायब करने या कुछ को ओवरराइड करने के लिए दरवाजा खोलते हैं। अन्य जीवनचक्र विधि। फिर इसे दर्जनों अन्य स्टेटफुल इंस्टेंस पर लागू करें, और आप आसानी से कोड की सैकड़ों या हजारों व्यर्थ पंक्तियों को देख रहे हैं।

स्पंदन इन मामलों से भरा हुआ है जहां हमें लगातार खुद को दोहराने, स्थापित करने और छोटी वस्तुओं की स्थिति को फाड़ने की आवश्यकता होती है, जो कि बग के लिए सभी प्रकार के अवसर पैदा करते हैं, जो मौजूद नहीं हैं, लेकिन करते हैं, क्योंकि वर्तमान में कोई सुरुचिपूर्ण दृष्टिकोण नहीं है इस रॉट सेटअप/टियरडाउन/सिंक लॉजिक को साझा करना।

आप इस मुद्दे को शाब्दिक रूप से _any_ अवस्था में देख सकते हैं जिसमें एक सेटअप और टियरडाउन चरण है, या कुछ जीवनचक्र हुक है जिसे हमेशा बंधा रहने की आवश्यकता होती है।

मुझे लगता है कि विजेट्स का उपयोग करना सबसे अच्छा तरीका है, मैं शायद ही कभी एनिमेटर कंट्रोलर का उपयोग करता हूं उदाहरण के लिए सेटअप/टियरडाउन इतना परेशान, वर्बोज़ और बग प्रवण है, इसके बजाय मैं हर जगह ट्विनएनीमेशनबिल्डर का उपयोग कर सकता हूं। लेकिन इस दृष्टिकोण की अपनी सीमाएं हैं क्योंकि आप किसी दिए गए दृश्य में अधिक संख्या में स्टेटफुल ऑब्जेक्ट्स प्राप्त करते हैं, घोंसले और वर्बोसिटी को मजबूर करते हैं जहां वास्तव में किसी की आवश्यकता नहीं होनी चाहिए।

@szotp मैंने नहीं किया है ... मैं एक या अधिक आधारभूत ऐप्स स्थापित करना चाहता हूं जो समस्या का प्रदर्शन करते हैं ताकि हम समाधानों का मूल्यांकन कर सकें। मैं इसे स्वयं करूँगा लेकिन मुझे समझ में नहीं आता कि हम क्या हल करने की कोशिश कर रहे हैं इसलिए मैं इसे करने के लिए गलत व्यक्ति हूं।

@escamoteur बेसलाइन ऐप्स हमें ऐसे समाधान तैयार करने में मदद करेंगे जिनमें कठिनाइयां नहीं हैं।

@esDotDev हमने अब तक इस बग में इस तरह के मामलों पर चर्चा की है, लेकिन हर बार हमारे पास, हुक के अलावा अन्य समाधान खारिज कर दिए जाते हैं क्योंकि वे कुछ समस्या का समाधान नहीं करते हैं जो उस उदाहरण में शामिल नहीं थे जिसे समाधान संबोधित किया गया था। इसलिए, समस्याओं का सरल विवरण पूर्ण सीमा तक कब्जा करने के लिए पर्याप्त नहीं लगता। उदाहरण के लिए, "12 एनिमेटर नियंत्रक" मामले को एनीमेशन नियंत्रकों की एक सरणी और डार्ट में कार्यात्मक सुविधाओं द्वारा हल किया जा सकता है। TweenAnimationBuilder एक और समाधान हो सकता है। उनमें से कोई भी हुक शामिल नहीं है। लेकिन मुझे यकीन है कि अगर मैं सुझाव देता हूं, तो कोई मुझे कुछ याद करेगा और कहेगा "यह काम नहीं करता क्योंकि ..." और उस (नया, उदाहरण के संदर्भ में) समस्या को सामने लाएगा। इसलिए एक आधारभूत ऐप की आवश्यकता जिससे हम सभी सहमत हैं, समस्या के पूर्ण प्रसार को कवर करता है।

अगर कोई इसे आगे बढ़ाना चाहता है तो मुझे लगता है कि इसे करने का सबसे अच्छा तरीका है जो मैंने ऊपर वर्णित किया है (https://github.com/flutter/flutter/issues/51752#issuecomment-670249755 and https://github.com /स्पंदन/स्पंदन/मुद्दों/51752#इश्यूकमेंट-670232842)। यह हमें एक प्रारंभिक बिंदु देगा जिससे हम सभी सहमत हो सकते हैं कि उस समस्या की सीमा का प्रतिनिधित्व करता है जिसे हम हल करने का प्रयास कर रहे हैं; फिर, हम उन समाधानों को डिज़ाइन कर सकते हैं जो उन समस्याओं का समाधान करते हैं जो सभी इच्छाओं को संबोधित करते हैं (उदाहरण के लिए @rrousselGit की पुन: उपयोग की आवश्यकता, @Rudiksz की स्वच्छ निर्माण विधियों की आवश्यकता, आदि), और सबसे महत्वपूर्ण बात यह है कि हम उन समाधानों का मूल्यांकन कर सकते हैं बेसलाइन ऐप्स का संदर्भ।

मुझे लगता है कि हम सभी उसकी समस्या पर काफी आसानी से सहमत हो सकते हैं:
_स्ट्रीम, एनिमेटर कंट्रोलर आदि जैसी चीजों से जुड़े सेटअप / टियरडाउन कार्यों को साझा करने का कोई शानदार तरीका नहीं है। इससे अनावश्यक वर्बोसिटी, बग के लिए उद्घाटन और कम पठनीयता होती है।

क्या कोई इससे सहमत नहीं है? क्या हम वहां से शुरू नहीं कर सकते और समाधान की तलाश में आगे नहीं बढ़ सकते? हमें इस बात से सहमत होना होगा कि पहले एक मुख्य समस्या है, जो ऐसा लगता है जैसे हम अभी भी नहीं करते हैं।

जैसा कि मैंने लिखा है कि हालांकि, मुझे इस मुद्दे के नाम से बिल्कुल मेल खाता है, जो खुला है और चर्चा के लिए जगह छोड़ देता है:
" राज्य तर्क का पुन: उपयोग करना या तो बहुत कठिन है या बहुत कठिन है "

मेरे लिए यह एक बहुत ही स्पष्ट समस्या है, और हमें जल्दी से बहस के चरण से आगे बढ़ना चाहिए और इस बारे में विचार-मंथन करना चाहिए कि क्या काम करेगा, अगर हुक नहीं तो क्या। हमें सूक्ष्म-राज्यों की आवश्यकता है जो पुन: उपयोग योग्य हों... मुझे विश्वास है कि हम कुछ पता लगा सकते हैं। यह वास्तव में दिन के अंत में बहुत सारे स्पंदन विचारों को साफ कर देगा और उन्हें और अधिक मजबूत बना देगा।

@ हिक्सी कृपया मत करो। लोग इस मुद्दे की परवाह करते हैं। मैंने आपके साथ reddit पर उसी चीज़ के बारे https://github.com/szotp/SwiftUI_vs_Flutter

आपके स्विफ्टयूआई उदाहरण को डार्ट में कोड की कुछ पंक्तियों में दोहराया जा सकता है, बस StatefulWidget वर्ग का विस्तार करके।

मेरे पास StatefulWidgets हैं जो किसी भी नोटिफ़ायर की सदस्यता नहीं लेते हैं और/या कोई बाहरी कॉल नहीं करते हैं, और वास्तव में उनमें से अधिकांश ऐसे ही हैं। मेरे पास लगभग १०० कस्टम विजेट हैं (हालाँकि सभी स्टेटफुल नहीं हैं), और शायद उनमें से १५ के पास किसी भी प्रकार का "सामान्य राज्य तर्क" है, जैसा कि यहाँ उदाहरणों द्वारा वर्णित है।

लंबे समय में, अनावश्यक ओवरहेड से बचने के लिए कोड की कुछ पंक्तियाँ (उर्फ बॉयलरप्लेट) लिखना एक छोटा ट्रेडऑफ़ है। और फिर, initState/didUpdate विधियों को लागू करने का यह मुद्दा बहुत अधिक लगता है। जब मैं एक विजेट बनाता हूं जो यहां वर्णित किसी भी पैटर्न का उपयोग करता है, तो शायद मैं जीवन चक्र विधियों को "कार्यान्वयन" करने पर पहले 5-10 मिनट खर्च करता हूं और फिर कुछ दिन वास्तव में विजेट को लिखने और पॉलिश करने के दौरान कभी भी जीवन चक्र विधियों को स्पर्श नहीं करता हूं। तथाकथित बॉयलरप्लेट सेटअप/टियरडाउन कोड लिखने में जितना समय मैं खर्च करता हूं, वह मेरे ऐप कोड की तुलना में बहुत कम है।

जैसा कि मैंने कहा कि StatefulWidgets इस बारे में बहुत कम धारणाएँ बनाते हैं कि उनका उपयोग किस लिए किया जाता है, जो उन्हें इतना शक्तिशाली और कुशल बनाता है।

फ़्लटर में एक नया प्रकार का विजेट जोड़ना जो इस विशेष उपयोग के मामले के लिए StatefulWidget (या नहीं) को उपवर्गित करता है, ठीक होगा, लेकिन इसे StatefulWidget में ही बेक न करें। मेरे पास बहुत सारे विजेट हैं जिन्हें "हुक" सिस्टम या माइक्रोस्टेट के साथ आने वाले ओवरहेड की आवश्यकता नहीं है।

@esDotDev मैं मानता हूँ कि यह एक ऐसी समस्या है जिसका कुछ लोग सामना कर रहे हैं; मैंने इस मुद्दे में पहले भी कुछ समाधान प्रस्तावित किए थे ( Property वर्ग के मेरे विभिन्न संस्करणों की खोज करें, अब दफन हो सकता है क्योंकि गिटहब सभी टिप्पणियों को दिखाना पसंद नहीं करता है)। कठिनाई यह है कि उन प्रस्तावों को खारिज कर दिया गया क्योंकि उन्होंने विशिष्ट मुद्दों को हल नहीं किया था (उदाहरण के लिए, एक मामले में, हॉट रीलोड को हैंडल नहीं किया, दूसरे में, didUpdateWidget को हैंडल नहीं किया)। तो फिर मैंने और प्रस्ताव दिए, लेकिन फिर उन्हें खारिज कर दिया गया क्योंकि उन्होंने कुछ और नहीं संभाला (मैं भूल गया क्या)। यही कारण है कि किसी प्रकार की आधार रेखा होना महत्वपूर्ण है जिससे हम सहमत हैं कि _entire_ समस्या का प्रतिनिधित्व करता है ताकि हम उस समस्या का समाधान ढूंढ सकें।

लक्ष्य कभी नहीं बदला। की गई आलोचना यह है कि सुझाए गए समाधानों में लचीलेपन की कमी है। उनमें से कोई भी उस स्निपेट के बाहर काम करना जारी नहीं रखता जिसके लिए उन्हें लागू किया गया था।

यही कारण है कि इस अंक में शीर्षक "कठिन" का उल्लेख करता है: क्योंकि वर्तमान में हम जिस तरह से समस्याओं को हल करते हैं उसमें वर्तमान में कोई लचीलापन नहीं है।

इसे देखने का एक और तरीका है:

यह मुद्दा मूल रूप से यह तर्क दे रहा है कि हमें स्टेट लॉजिक के लिए एक विजेट लेयर को लागू करने की आवश्यकता है।
सुझाए गए समाधान हैं "लेकिन आप इसे RenderObjects के साथ कर सकते हैं"।

_लंबे समय में, अनावश्यक ओवरहेड से बचने के लिए कोड की कुछ पंक्तियाँ (उर्फ बॉयलरप्लेट) लिखना एक छोटा ट्रेडऑफ़ है।

इस कथन के साथ युगल निट्स:

1. यह वास्तव में कुछ पंक्तियाँ नहीं हैं, यदि आप कोष्ठक, रेखा रिक्ति @overides आदि को Thing.DOTween() )। 15 हास्यास्पद है।

1. यह टाइपिंग के बारे में नहीं है, हालांकि यह एक दर्द है। यह 50 लाइन क्लास होने की मूर्खता के बारे में है, जहां इसकी 30 लाइनें रॉट बॉयलरप्लेट है। इसकी उलझन। यह इस तथ्य के बारे में है कि यदि आप _dont_ बॉयलरप्लेट लिखते हैं, तो कोई चेतावनी या कुछ भी नहीं है, आपने अभी एक बग जोड़ा है।
2. मुझे हुक जैसी किसी चीज़ के साथ चर्चा करने लायक कोई ओवरहेड नहीं दिख रहा है। हम वस्तुओं की एक सरणी के बारे में बात कर रहे हैं, प्रत्येक पर मुट्ठी भर fxns के साथ। डार्ट में, जो बहुत तेज है। यह एक लाल हेरिंग इमो है।

@esDotDev

मेरे लिए यह एक बहुत ही स्पष्ट समस्या है, और हमें जल्दी से बहस के चरण से आगे बढ़ना चाहिए और इस बारे में विचार-मंथन करना चाहिए कि क्या काम करेगा, अगर हुक नहीं तो क्या।

विगेट्स का विस्तार। जिस तरह ValueNotifier एक सामान्य उपयोग पैटर्न को सरल बनाने के लिए ChangeNotifier का विस्तार करता है, वैसे ही हर कोई अपने विशिष्ट उपयोग के मामलों के लिए StatelessWidgets के अपने स्वयं के स्वाद लिख सकता है।

हां, मैं मानता हूं कि यह एक प्रभावी तरीका है, लेकिन यह वांछित होने के लिए कुछ छोड़ देता है। अगर मेरे पास 1 एनिमेटर है, तो मैं सिर्फ एक ट्विनएनीमेशनबिल्डर का उपयोग कर सकता हूं। बढ़िया, यह अभी भी कोड की 5 पंक्तियों की तरह है, लेकिन जो भी हो। यह काम करता है... बहुत बुरा नहीं है। लेकिन अगर मेरे पास 2 या 3 हैं? अब मैं घोंसले के शिकार नरक में हूं, अगर मेरे पास किसी कारण से सीपीएल अन्य स्टेटफुल ऑब्जेक्ट्स हैं, तो यह सब थोड़े इंडेंटेशन की गड़बड़ी बन गया है, या मैं कुछ बहुत ही विशिष्ट विजेट बना रहा हूं जो सेटअप, अपडेट और टियरडाउन के यादृच्छिक संग्रह को समाहित करता है। तर्क।

विगेट्स का विस्तार। जिस तरह ValueNotifier एक सामान्य उपयोग पैटर्न को सरल बनाने के लिए ChangeNotifier का विस्तार करता है, वैसे ही हर कोई अपने विशिष्ट उपयोग के मामलों के लिए StatelessWidgets के अपने स्वयं के स्वाद लिख सकता है।

आप एक समय में केवल एक बेस-क्लास का विस्तार कर सकते हैं। यह पैमाना नहीं है

मिक्सिंस अगला तार्किक प्रयास है। लेकिन जैसा कि ओपी का उल्लेख है, वे या तो स्केल नहीं करते हैं।

@esDotDev

या मैं कुछ बहुत ही विशिष्ट विजेट बना रहा हूं जो सेटअप, अपडेट और टियरडाउन तर्क के यादृच्छिक संग्रह को समाहित करता है।

एक प्रकार का विजेट जिसे 3-4 प्रकार के एनिमेशन कंट्रोलर सेट करना होता है, एक बहुत ही विशिष्ट उपयोग के मामले की तरह लगता है और सेटअप/टियरडाउन तर्क के यादृच्छिक संग्रह का समर्थन निश्चित रूप से ढांचे का हिस्सा नहीं होना चाहिए। वास्तव में यही कारण है कि initState/didUpdateWidget विधियों को पहले स्थान पर उजागर किया गया है, ताकि आप अपने दिल की इच्छा के लिए सेटअप का अपना यादृच्छिक संग्रह कर सकें।

मेरी सबसे लंबी initState विधि कोड की 5 पंक्तियाँ हैं, मेरे विजेट अत्यधिक घोंसले के शिकार नहीं हैं, इसलिए हमारे पास निश्चित रूप से अलग-अलग ज़रूरतें और उपयोग के मामले हैं। या एक अलग विकास शैली।

@esDotDev

3. मुझे हुक जैसी किसी चीज़ के साथ चर्चा करने लायक कोई ओवरहेड नहीं दिख रहा है। हम वस्तुओं की एक सरणी के बारे में बात कर रहे हैं, प्रत्येक पर मुट्ठी भर fxns के साथ। डार्ट में, जो बहुत तेज है। यह एक लाल हेरिंग इमो है।

यदि प्रस्तावित समाधान flutter_hooks पैकेज जैसा कुछ है जो पूरी तरह से असत्य है। हां, अवधारणात्मक रूप से यह इसमें कार्यों के साथ एक सरणी है, लेकिन कार्यान्वयन कहीं भी तुच्छ या कुशल नहीं है।

मेरा मतलब है, मैं गलत हो सकता हूं, लेकिन ऐसा लगता है कि हुक एलीमेंट जांचता है कि उसे अपनी निर्माण विधि में खुद को पुनर्निर्माण करना चाहिए ?!
यह भी जांचना कि प्रत्येक विजेट निर्माण पर हुक को प्रारंभ, पुन: प्रारंभ या निपटान किया जाना चाहिए या नहीं, यह एक महत्वपूर्ण ओवरहेड की तरह लगता है। यह सही नहीं लगता, इसलिए मुझे आशा है कि मैं गलत हूँ।

क्या तुलना के लिए आधार ऐप के रूप में @brianegan के आर्किटेक्चर उदाहरणों में से एक को लेना समझ में आता है?

अगर मैं यहां हस्तक्षेप कर सकता हूं, तो यकीन नहीं होता कि यह पहले ही कहा जा चुका है। लेकिन रिएक्ट में हम वास्तव में हुक के साथ जीवनचक्र के बारे में नहीं सोचते हैं, और यह डरावना लग सकता है यदि आप घटक/विजेट बनाने के अभ्यस्त हैं, लेकिन यहां जीवनचक्र वास्तव में मायने नहीं रखता है।

ज्यादातर बार, जब आप राज्य के साथ घटक/विजेट बना रहे होते हैं या प्रोप के आधार पर कार्रवाई करते हैं, तो आप चाहते हैं कि कुछ ऐसा हो जब वह राज्य/प्रॉप्स बदल जाए (उदाहरण के लिए, जैसा कि मैंने इस धागे में उल्लेख किया है, आप फिर से करना चाहेंगे -उपयोगकर्ता का विवरण प्राप्त करें जब userId प्रोप बदल गया हो)। यह आमतौर पर उपयोगकर्ता के परिवर्तन के "प्रभाव" के रूप में सोचने के लिए बहुत अधिक स्वाभाविक है, न कि कुछ ऐसा होता है जब विजेट के सभी प्रोप बदलते हैं।

सफाई के लिए एक ही बात, यह आमतौर पर सोचने के लिए बहुत अधिक स्वाभाविक है "मुझे इस राज्य/श्रोता/नियंत्रक को साफ करने की आवश्यकता है जब यह प्रोप/राज्य बदलता है" के बजाय "मुझे एक्स को साफ करने के लिए याद रखना होगा जब सभी प्रोप/राज्य बदलते हैं या जब पूरा घटक नष्ट हो जाता है"।

मैंने थोड़ी देर में स्पंदन नहीं लिखा है, इसलिए मैं ऐसा ध्वनि करने की कोशिश नहीं कर रहा हूं जैसे मुझे पता है कि वर्तमान जलवायु या सीमाएं इस दृष्टिकोण की वर्तमान स्पंदन मानसिकता पर होंगी, मैं अलग-अलग राय के लिए खुला हूं। मुझे लगता है कि बहुत से लोग जो रिएक्ट हुक से परिचित नहीं हैं, उन्हें वही भ्रम हो रहा है, जब मुझे उनसे मिलवाया गया था, क्योंकि मेरी मानसिकता जीवनचक्र के प्रतिमान में इतनी अंतर्निहित थी।

@escamoteur @Rudiksz @Hixie वहाँ @TimWhiting है कि मैं जहां हम इन उदाहरणों बनाने के लिए शुरू कर रहे हैं करने के लिए आमंत्रित किया गया है के द्वारा बनाई गई एक GitHub परियोजना किया गया है। प्रत्येक व्यक्ति/समूह यह बना सकता है कि वे पूर्वनिर्धारित समस्या को कैसे हल करेंगे। वे पूर्ण विकसित ऐप्स नहीं हैं, अधिक पेजों को पसंद करते हैं, लेकिन यदि वे अधिक जटिल उदाहरण दिखाने के लिए काम करते हैं, तो हम ऐप्स भी जोड़ सकते हैं। तब हम समस्याओं पर चर्चा कर सकते हैं और एक बेहतर API बना सकते हैं। @TimWhiting मेरे अनुमान में रुचि रखने वाले किसी भी व्यक्ति को आमंत्रित कर सकता है।

https://github.com/TimWhiting/local_widget_state_approaches

जेटपैक कंपोज़ भी हुक के समान है, जिसकी तुलना यहाँ प्रतिक्रिया से की

@satvikpendem @TimWhiting यह बहुत अच्छा है! धन्यवाद।

@esDotDev
बहुत विशिष्ट उपयोग केस और सेटअप/टियरडाउन तर्क के यादृच्छिक संग्रह का समर्थन निश्चित रूप से ढांचे का हिस्सा नहीं होना चाहिए।

यह वह कील है जो सिर पर लगाती है। प्रत्येक प्रकार की वस्तु अपने स्वयं के सेटअप और टियरडाउन के लिए जिम्मेदार होती है। एनिमेटर जानते हैं कि कैसे खुद को बनाना, अपडेट करना और नष्ट करना है, जैसा कि स्ट्रीम करते हैं, और इसी तरह। हुक विशेष रूप से आपके पूरे दृश्य में बिखरे हुए राज्य मचान के 'यादृच्छिक संग्रह' के इस मुद्दे को हल करता है। दृश्य कोड के थोक को व्यावसायिक तर्क और लेआउट स्वरूपण पर ध्यान केंद्रित करने की अनुमति देता है, जो एक जीत है। यह आपको कस्टम विजेट बनाने के लिए बाध्य नहीं करता है, बस कुछ सामान्य बॉयलरप्लेट को छिपाने के लिए जो हर प्रोजेक्ट में समान है।

मेरी सबसे लंबी initState विधि कोड की 5 पंक्तियाँ हैं, मेरे विजेट अत्यधिक घोंसले के शिकार नहीं हैं, इसलिए हमारे पास निश्चित रूप से अलग-अलग ज़रूरतें और उपयोग के मामले हैं। या एक अलग विकास शैली।

मेरा भि। लेकिन यह initState () + निपटान () + didUpdateनिर्भरता () है, और पिछले 2 में से किसी एक के लापता होने से बग हो सकते हैं।

मुझे लगता है कि विहित उदाहरण कुछ ऐसा होगा: एक ऐसा दृश्य लिखें जो 1 स्ट्रीमकंट्रोलर और 2 एनिमेटर नियंत्रकों का उपयोग करता हो।

जहाँ तक मैं देख सकता हूँ आपके पास 3 विकल्प हैं:

1. अपनी कक्षा में ३० या अधिक बॉयलरप्लेट और कुछ मिश्रण जोड़ें। जो न केवल वर्बोज़ है, बल्कि शुरू में पालन करना काफी कठिन है।
2. अपने व्यू कोड तक पहुंचने से पहले, लगभग 15 इंडेंटेशन स्तरों के लिए 2 ट्विनएनीमेशनबिल्डर और स्ट्रीमबिल्डर का उपयोग करें, और आपके पास स्ट्रीम के लिए अभी भी बहुत सारे बॉयलरप्लेट हैं।
3. अपनी 3 स्टेटफुल सब-ऑब्जेक्ट्स प्राप्त करने के लिए बिल्ड () के शीर्ष पर गैर-इंडेंट कोड की 6 पंक्तियों की तरह जोड़ें, और किसी भी कस्टम इनिट/नष्ट कोड को परिभाषित करें

हो सकता है कि एक चौथा विकल्प है जो सिंगलस्ट्रीमबिल्डर डबलएनीमेशन विजेट है, लेकिन यह डेवलपर्स के लिए सिर्फ एक मेक-वर्क चीज है और सामान्य रूप से बहुत परेशान है।

यह भी ध्यान देने योग्य है कि एक नए डेवलपर के लिए 3 का संज्ञानात्मक भार अन्य 2 की तुलना में काफी कम है। अधिकांश नए देव यह भी नहीं जानते हैं कि TweenAnimationBuilder मौजूद है, और केवल SingleTickerProvider की अवधारणा को सीखना अपने आप में एक कार्य है। केवल यह कहना, "कृपया मुझे एक एनिमेटर दें", एक आसान और अधिक मजबूत तरीका है।

मैं आज कुछ कोशिश करूँगा और कोड करूँगा।

2. अपने व्यू कोड तक पहुंचने से पहले, लगभग 15 इंडेंटेशन स्तरों के लिए 2 ट्विनएनीमेशनबिल्डर और स्ट्रीमबिल्डर का उपयोग करें, और आपके पास स्ट्रीम के लिए अभी भी बहुत सारे बॉयलरप्लेट हैं।

सही। हमें कोड का एक वास्तविक विश्व उदाहरण दिखाएं जो इंडेंटेशन के 15 स्तरों का उपयोग करता है।

किसी पुस्तकालय में कोड की 30 पंक्तियों को 6 पंक्तियों + सैकड़ों पंक्तियों से बदलने से संज्ञानात्मक भार कैसे कम होता है? हाँ, मैं सिर्फ "जादू" को अनदेखा कर सकता हूँ जो पुस्तकालय करता है, लेकिन इसके नियम नहीं। उदाहरण के लिए हुक पैकेज आपको बिना किसी अनिश्चित शब्दों के बताता है कि हुक का उपयोग केवल निर्माण विधियों में किया जाना चाहिए। अब आपके पास चिंता करने के लिए एक अतिरिक्त बाधा है।

मेरे पास कोड की 200 से कम लाइनें हैं जिनमें कोड की 15k लाइनों वाले प्रोजेक्ट में फोकसनोड्स, टेक्स्टकंट्रोलर, सिंगलटिकरप्रोवाइडर या मेरे स्टेटफुल विजेट्स के विभिन्न जीवन चक्र विधियां शामिल हैं। आप किस संज्ञानात्मक अधिभार के बारे में बात कर रहे हैं?

@Rudiksz कृपया निष्क्रिय आक्रामक होना बंद करें।
हम बिना लड़े असहमत हो सकते हैं।

हुक की कमी मेरी चिंताओं में सबसे कम है।

हम विशेष रूप से हुक के बारे में बात नहीं कर रहे हैं, लेकिन समस्या के बारे में।
अगर हमें करना है, तो हम एक अलग समाधान के साथ आ सकते हैं।

क्या मायने रखता है वह समस्या जिसे हम हल करना चाहते हैं।

इसके अलावा, विजेट का उपयोग केवल निर्माण के अंदर और बिना शर्त के किया जा सकता है (या हम अन्यथा पेड़ की गहराई को बदल रहे हैं, जो कि नहीं है)

यह हुक बाधाओं के समान है, लेकिन मुझे नहीं लगता कि लोगों ने इसके बारे में शिकायत की है।

इसके अलावा, विजेट का उपयोग केवल निर्माण के अंदर और बिना शर्त के किया जा सकता है (या हम अन्यथा पेड़ की गहराई को बदल रहे हैं, जो कि नहीं है)

यह हुक बाधाओं के समान है, लेकिन मुझे नहीं लगता कि लोगों ने इसके बारे में शिकायत की है।

नहीं, यह समान नहीं है। यहां जो समस्या प्रस्तुत की गई है वह उस कोड से संबंधित प्रतीत होती है जो _prepares_ विगेट्स _before_ (पुनः) बनाया जा रहा है। पेड़ की संरचना में राज्य, निर्भरता, धाराएं, नियंत्रक, क्या नहीं, और परिवर्तनों को संभालना तैयार करना। इनमें से कोई भी बिल्ड मेथड में नहीं होना चाहिए, भले ही वह सिंगल फंक्शन कॉल के पीछे छिपा हो।
उस तर्क के लिए प्रवेश बिंदु कभी भी निर्माण विधि में नहीं होना चाहिए।

मुझे किसी भी प्रकार के प्रारंभिक तर्क को निर्माण विधि में डालने के लिए मजबूर करना कहीं भी बिल्ड विधि में विजेट पेड़ लिखने के लिए "मजबूर" जैसा ही नहीं है। निर्माण विधि का पूरा कारण मौजूदा स्थिति (चर का सेट) लेना और एक विजेट पेड़ बनाना है जो तब चित्रित हो जाता है।

इसके विपरीत, मैं मुझे कोड जोड़ने के लिए मजबूर करने के खिलाफ भी हूं जो initState/didUpdateWidget विधियों के अंदर विजेट बनाता है।

जैसा कि अभी है, स्टेटफुलविजेट जीवनचक्र विधियों की एक बहुत स्पष्ट भूमिका है और यह पूरी तरह से अलग चिंताओं के साथ कोड को अलग करने के लिए बहुत आसान और आसान बनाती है।

संकल्पनात्मक रूप से मैं उन समस्याओं को समझना शुरू कर रहा हूं जिनका वर्णन यहां किया जा रहा है, लेकिन मैं अभी भी इसे एक वास्तविक समस्या के रूप में देखने में विफल हूं। हो सकता है कि कुछ वास्तविक उदाहरण (जो काउंटर ऐप नहीं हैं) मुझे अपना विचार बदलने में मदद कर सकते हैं।

एक साइड-नोट के रूप में, 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);
  }
}

मुख्य मुद्दा यह है कि यह एक प्रकार की वस्तु के लिए विशिष्ट है, और यह इस तथ्य पर भरोसा करके काम करता है कि ऑब्जेक्ट इंस्टेंस में पुनर्निर्माण के दौरान लगातार हैशकोड होता है।

तो हम अभी भी हुक के लचीलेपन से दूर हैं

@rrousselGit मैं विस्तार के बिना लगता है StatelessWidget / StatefulWidget वर्गों और ConsumerStatelessWidget की तरह कुछ बनाने, यह कुछ ऐसा करना संभव है context.watch पर विस्तार तरीकों का उपयोग करके BuildContext क्लास और प्रदाता के पास इनहेरिटेडविड्ज के साथ वॉच फंक्शन प्रदान करना।

वह अलग विषय है। लेकिन tl; dr, हम इस मुद्दे के समाधान के रूप में इनहेरिटेडविड्ज पर भरोसा नहीं कर सकते: https://github.com/flutter/flutter/issues/30062

उस समस्या को हल करने के लिए, https://github.com/flutter/flutter/issues/12992 और https://github.com/flutter/flutter/pull/33213 के कारण InheritedWidgets का उपयोग करना हमें ब्लॉक कर देगा

संकल्पनात्मक रूप से मैं उन समस्याओं को समझना शुरू कर रहा हूं जिनका वर्णन यहां किया जा रहा है, लेकिन मैं अभी भी इसे एक वास्तविक समस्या के रूप में देखने में विफल हूं।

स्पंदन की तुलना स्विफ्टयूआई से करना, मेरे लिए यह स्पष्ट है कि वास्तविक समस्या है, या यों कहें - चीजें उतनी महान नहीं हैं जितनी वे हो सकती हैं।

यह देखना मुश्किल हो सकता है, क्योंकि फ़्लटर और अन्य ने इसके चारों ओर कड़ी मेहनत की है: हमारे पास प्रत्येक विशिष्ट मामले के लिए रैपर हैं: एनिमेटेडबिल्डर, स्ट्रीमबिल्डर, उपभोक्ता, एनिमेटेड ओपेसिटी इत्यादि। StatefulWidget इन छोटी पुन: प्रयोज्य उपयोगिताओं को लागू करने के लिए बहुत अच्छा काम करता है, लेकिन यह बहुत कम स्तर है गैर-पुन: प्रयोज्य, डोमेन विशिष्ट घटकों के लिए, जहां आपके पास बहुत सारे टेक्स्ट कंट्रोलर, एनिमेशन, या जो भी व्यावसायिक तर्क कॉल हो सकते हैं। सामान्य समाधान यह है कि या तो गोली को काट दिया जाए और वह सब बॉयलरप्लेट लिख दिया जाए, या प्रदाताओं और श्रोताओं का सावधानीपूर्वक निर्मित पेड़ बनाया जाए। कोई भी दृष्टिकोण संतोषजनक नहीं है।

यह ऐसा है जैसे @rrousselGit कहते हैं, पुराने दिनों (UIKit) में हमें अपने UIViews (RenderObjects के समतुल्य) को मैन्युअल रूप से प्रबंधित करने के लिए मजबूर किया गया था, और मॉडल से देखने और वापस करने के लिए मूल्यों की प्रतिलिपि बनाना याद रखें, अप्रयुक्त विचारों को हटाएं, रीसायकल करें, और इसी तरह। यह कोई रॉकेट साइंस नहीं था, और कई लोगों ने इस पुरानी समस्या को नहीं देखा, लेकिन मुझे लगता है कि यहां हर कोई इस बात से सहमत होगा कि फ़्लटर ने स्थिति में स्पष्ट रूप से सुधार किया है।
स्टेटफुलनेस के साथ, यह मुद्दा बहुत ही समान है: यह उबाऊ, त्रुटि प्रवण कार्य है जिसे स्वचालित किया जा सकता है।

और, वैसे, मुझे नहीं लगता कि हुक इसे बिल्कुल हल करते हैं। यह सिर्फ इतना है कि हुक ही एकमात्र दृष्टिकोण है जो स्पंदन के आंतरिक को बदले बिना संभव है।

StatefulWidget इन छोटी पुन: प्रयोज्य उपयोगिताओं को लागू करने के लिए बहुत अच्छा काम करता है, लेकिन यह गैर-पुन: प्रयोज्य, डोमेन विशिष्ट घटकों के लिए बहुत कम स्तर है, जहां आपके पास टेक्स्ट कंट्रोलर, एनिमेशन, या जो भी व्यावसायिक तर्क कॉल हो सकता है।

जब आप कहते हैं कि आपके गैर-पुन: प्रयोज्य डोमेन विशिष्ट घटकों के निर्माण के लिए मैं उलझन में हूं, तो आपको उच्च-स्तरीय विजेट की आवश्यकता है। आमतौर पर यह ठीक विपरीत होता है।

AnimatedBuilder, StreamBuilder, Consumer, AnimatedOpacity सभी विजेट हैं जो एक निश्चित उपयोग के मामले को लागू करते हैं। जब मुझे ऐसे विजेट की आवश्यकता होती है जिसमें इतना विशिष्ट तर्क होता है कि मैं इनमें से किसी भी उच्च स्तरीय विजेट का उपयोग नहीं कर सकता, तब मैं निचले स्तर के एपीआई तक जाता हूं ताकि मैं अपना विशिष्ट उपयोग केस लिख सकूं। तथाकथित बॉयलरप्लेट कार्यान्वित कर रहा है कि कैसे मेरा अनूठा विजेट धाराओं, नेटवर्क कॉल, नियंत्रकों और क्या नहीं के अपने अद्वितीय संयोजन का प्रबंधन करता है।

हुक, हुक जैसे व्यवहार या यहां तक ​​​​कि सिर्फ "ऑटोमेशन" की वकालत करना यह कहने जैसा है कि हमें एक निम्न स्तर के विजेट की आवश्यकता है जो उच्च स्तर , गैर-पुन: प्रयोज्य तर्क को संभाल सके जिसे कोई भी तथाकथित बॉयलरप्लेट कोड लिखे बिना कभी भी रखना चाहेगा।

स्टेटफुलनेस के साथ, यह मुद्दा बहुत ही समान है: यह उबाऊ, त्रुटि प्रवण कार्य है जिसे स्वचालित किया जा सकता है।

फिर से। आप __"गैर-पुन: प्रयोज्य, डोमेन विशिष्ट घटकों को स्वचालित करना चाहते हैं, जहां आपके पास बहुत सारे टेक्स्ट कंट्रोलर, एनिमेशन, या जो भी व्यावसायिक तर्क कॉल करता है"__?!

यह ऐसा है जैसे @rrousselGit कहते हैं, पुराने दिनों (UIKit) में हमें अपने UIViews (RenderObjects के समतुल्य) को मैन्युअल रूप से प्रबंधित करने के लिए मजबूर किया गया था, और मॉडल से देखने और वापस करने के लिए मूल्यों की प्रतिलिपि बनाना याद रखें, अप्रयुक्त विचारों को हटाएं, रीसायकल करें, और इसी तरह। यह कोई रॉकेट साइंस नहीं था, और कई लोगों ने इस पुरानी समस्या को नहीं देखा, लेकिन मुझे लगता है कि यहां हर कोई इस बात से सहमत होगा कि फ़्लटर ने स्थिति में स्पष्ट रूप से सुधार किया है।

मैंने 6-7 साल पहले आईओएस और एंड्रॉइड विकास किया था (लगभग उस समय एंड्रॉइड ने अपने सामग्री डिजाइन पर स्विच किया था) और मुझे इस प्रबंधन और रीसाइक्लिंग विचारों में से कोई भी एक मुद्दा याद नहीं है और स्पंदन बेहतर या बदतर नहीं लगता है। मैं करंट अफेयर्स के बारे में बात नहीं कर सकता, जब मैंने स्विफ्ट और कोटलिन को लॉन्च किया तो मैंने छोड़ दिया।

मेरे StatefulWidgets में लिखने के लिए मजबूर बॉयलरप्लेट मेरे कोड बेस का लगभग 1% है। क्या यह त्रुटि प्रवण है? कोड की प्रत्येक पंक्ति बग का एक संभावित स्रोत है, इसलिए सुनिश्चित करें। क्या यह बोझिल है? 15000 के कोड की 200 लाइनें? मैं वास्तव में ऐसा नहीं सोचता, लेकिन यह सिर्फ मेरी राय है। स्पंदन के पाठ/एनीमेशन नियंत्रक, फोकसनोड्स में सभी मुद्दे हैं जिन पर सुधार किया जा सकता है, लेकिन वर्बोज़ होना एक नहीं है।

मैं वास्तव में यह देखने के लिए उत्सुक हूं कि लोग क्या विकसित कर रहे हैं कि उन्हें इतनी अधिक बॉयलरप्लेट की आवश्यकता है।

यहां कुछ टिप्पणियों को सुनकर ऐसा लगता है कि 1 के बजाय कोड की 5 पंक्तियों को प्रबंधित करना 5 गुना कठिन है। यह।

क्या आप इस बात से सहमत नहीं होंगे कि उदाहरण के लिए प्रत्येक एनीमेशन नियंत्रक के लिए initState और निपटान की स्थापना के बजाय इसे केवल एक बार करने और उस तर्क का पुन: उपयोग करने से अधिक त्रुटि प्रवण हो सकती है? कार्यों, पुन: प्रयोज्य का उपयोग करने के समान सिद्धांत। मैं मानता हूं कि बिल्ड फंक्शन में हुक लगाना समस्याग्रस्त है, हालांकि निश्चित रूप से एक बेहतर तरीका है।

यह वास्तव में उन लोगों के बीच अंतर की तरह लगता है जो यहां समस्या को देखते हैं और नहीं देखते हैं कि पूर्व ने हुक जैसे निर्माणों का उपयोग किया है, जैसे कि रिएक्ट, स्विफ्ट और कोटलिन में, और बाद वाले ने नहीं किया है, जैसे कि शुद्ध जावा में काम करना या एंड्रॉइड। मुझे लगता है कि मेरे अनुभव में आश्वस्त होने का एकमात्र तरीका हुक का प्रयास करना है और देखें कि क्या आप मानक तरीके से वापस जा सकते हैं। कई बार, मेरे अनुभव में, बहुत से लोग दोबारा नहीं कर सकते। जब आप इसका इस्तेमाल करते हैं तो आप इसे जानते हैं।

इसके लिए, मैं उन लोगों को प्रोत्साहित करूंगा जो एक छोटी परियोजना के लिए flutter_hooks का उपयोग करने के लिए संशय में हैं और देखें कि इसका किराया कैसा है, फिर इसे डिफ़ॉल्ट तरीके से फिर से करें। यह पर्याप्त नहीं है कि हम केवल @Hixie के सुझाव के

यह पर्याप्त नहीं है कि हम केवल @Hixie के सुझाव के

मैंने प्रदाता की कोशिश करने में दिन बर्बाद किए, और भी अधिक दिन ब्लॉक करने की कोशिश कर रहे थे, मुझे नहीं मिला कि उनमें से कोई भी एक अच्छा समाधान था। अगर यह आपके लिए काम करता है, तो बढ़िया।

आदेश के लिए मुझे भी एक समस्या यह है कि आप कर रहे हैं करने के लिए अपने प्रस्तावित समाधान की कोशिश करने के लिए आपको इसके फायदे का प्रदर्शन करने की जरूरत है। मैंने स्पंदन हुक के साथ उदाहरणों को देखा और मैंने इसके कार्यान्वयन को देखा। बस नहीं।

ढांचे में जो भी बॉयलरप्लेट कम करने वाला कोड जोड़ा जाता है, मुझे आशा है कि स्टेटफुल/स्टेटलेस विजेट्स अपरिवर्तित छोड़े जाएंगे। मैं इस बातचीत में और कुछ नहीं जोड़ सकता।

आइए फिर से शुरू करते हैं, एक काल्पनिक दुनिया में जहां हम डार्ट को बदल सकते हैं, बिना हुक के बारे में बात किए।

बहस की समस्या है:

Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}

यह कोड पठनीय नहीं है।

हम एक नया कीवर्ड पेश करके पठनीयता की समस्या को ठीक कर सकते हैं जो सिंटैक्स को इसमें बदल देता है:

Widget build(context) {
  final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);
  final value2 = keyword StreamBuilder(stream: someStream);
  final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

  return Text('$value $value2 $value3');
}

यह कोड काफी अधिक पठनीय है, हुक से असंबंधित है, और इसकी सीमाओं से ग्रस्त नहीं है।
पठनीयता लाभ लाइनों की संख्या के बारे में ज्यादा नहीं है, बल्कि स्वरूपण और इंडेंटेशन है।

लेकिन क्या होगा जब बिल्डर रूट विजेट नहीं है?

उदाहरण:

Widget build(context) {
  return Scaffold(
    body: StreamBuilder(
      stream: stream,
      builder: (context, value) {
        return Consumer<Value2>(
          builder: (context, value2, child) {
            return Text('${value.data} $value2');
          },
        );
      },
    ),
  );
}

हमारे पास हो सकता है:

Widget build(context) {
  return Scaffold(
    body: {
      final value = keyword StreamBuilder(stream: stream);
      final value2 = keyword Consumer<Value2>();
      return Text('${value.data} $value2');
    }
  );
}

लेकिन यह पुन: प्रयोज्य मुद्दे से कैसे संबंधित है?

इसका कारण यह है कि, बिल्डर्स तकनीकी रूप से राज्य तर्क का पुन: उपयोग करने का एक तरीका है। लेकिन उनका मुद्दा यह है कि यदि हम _many_ बिल्डरों का उपयोग करने की योजना बनाते हैं, तो वे कोड को बहुत पठनीय नहीं बनाते हैं, जैसे कि इस टिप्पणी में 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);
  }
)

जिसे हम नए कीवर्ड के साथ उपयोग कर सकते हैं:

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

  <strong i="15">@override</strong>
  Widget build(BuildContext context) {
    final filter = keyword FilterBuilder(debounceDuration: const Duration(seconds: 2));
    final userId = keyword Consumer(authProvider).userId;
    final chatId = keyword Consumer(selectedChatProvider);
    final chat = keyword QueryBuilder(ChatQuery(userId: userId, chatId: chatId, filter: filter.value));

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

कस्टम हुक/बिल्डर्स बनाने के लिए हमने "एक्सट्रेक्ट ऐज़ फंक्शन" के बारे में क्या बात की, जिसके बारे में हमने हुक के साथ बात की थी?

फ़ंक्शन में बिल्डर्स के संयोजन को निकालकर हम ऐसे कीवर्ड के साथ भी ऐसा ही कर सकते हैं:

Builder<Chat> ChatBuilder()  {
  final filter = keyword FilterBuilder(debounceDuration: const Duration(seconds: 2));
  final userId = keyword Consumer(authProvider).userId;
  final chatId = keyword Consumer(selectedChatProvider);
  final chat = keyword QueryBuilder(ChatQuery(userId: userId, chatId: chatId, filter: filter.value));

  return Builder(chat);
}

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

  <strong i="21">@override</strong>
  Widget build(BuildContext context) {
    final chat = keyword ChatBuilder();

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

जाहिर है, इस तरह के वाक्य-विन्यास के सभी निहितार्थों पर ज्यादा विचार नहीं किया गया था। लेकिन यह मूल विचार है।

हुक यह विशेषता है।
हुक की सीमाएं मौजूद हैं क्योंकि उन्हें भाषा सुविधा के बजाय पैकेज के रूप में लागू किया जाता है।

और कीवर्ड use , जैसे कि keyword StreamBuilder use StreamBuilder बन जाता है, जिसे अंततः useStream रूप में लागू किया जाता है

यह कोड काफी अधिक पठनीय है

मुझे लगता है कि यह राय का मामला है। मैं मानता हूं कि कुछ लोग सोचते हैं कि आपके द्वारा वर्णित संस्करण अधिक पठनीय हैं; व्यक्तिगत रूप से मैं अधिक स्पष्ट जादू-कम संस्करण पसंद करता हूं। लेकिन दूसरी शैली को संभव बनाने में मुझे कोई आपत्ति नहीं है।

उस ने कहा, अगला कदम @TimWhiting के ऐप (https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/stateful/counter.dart) पर काम करना है ताकि इसे कुछ ऐसा बनाया जा सके जिसमें सभी समस्याएं हों। जिसे हम सुलझाना चाहते हैं।

इसके लायक क्या है, इसके लिए https://github.com/flutter/flutter/issues/51752#issuecomment -670959424 हुक्स इन रिएक्ट के लिए प्रेरणा के समान है। बिल्डर पैटर्न रेंडर प्रॉप्स पैटर्न के समान लगता है जो रिएक्ट में प्रचलित हुआ करता था (लेकिन इसी तरह गहरे पेड़ों का नेतृत्व करता था)। बाद में @trueadm ने रेंडर प्रॉप्स के लिए सिंटैक्स शुगर का सुझाव दिया, और बाद में इससे हुक (अनावश्यक रनटाइम ओवरहेड को हटाने के लिए) का नेतृत्व किया।

`Widget build(context) {
  return ValueListenableBuilder<String>(
    valueListenable: someValueListenable,
    builder: (context, value, _) {
      return StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) {
          return TweenAnimationBuilder<double>(
            tween: Tween(...),
            builder: (context, value3) {
              return Text('$value $value2 $value3');
            },
          );
        },
      );
    },
  );
}`

यदि पठनीयता और इंडेंटेशन मुद्दा है तो इसे फिर से लिखा जा सकता है

  <strong i="8">@override</strong>
  Widget build(context) {
    return ValueListenableBuilder<String>(
      valueListenable: someValueListenable,
      builder: (context, value, _) => buildStreamBuilder(value),
    );
  }

  StreamBuilder<int> buildStreamBuilder(String value) => StreamBuilder<int>(
        stream: someStream,
        builder: (context, value2) => buildTweenAnimationBuilder(value, value2),
      );

  Widget buildTweenAnimationBuilder(String value, AsyncSnapshot<int> value2) =>
      TweenAnimationBuilder<double>(
        duration: Duration(milliseconds: 500),
        tween: Tween(),
        builder: (context, value3, _) => Text('$value $value2 $value3'),
      );

यदि फ़ंक्शन आपकी चीज़ नहीं हैं, या आपको पुन: प्रयोज्य की आवश्यकता है तो उन्हें विजेट के रूप में निकालें

class NewWidget extends StatelessWidget {
  var someValueListenable;

  var someStream;

  <strong i="12">@override</strong>
  Widget build(context) {
    return ValueListenableBuilder<String>(
      valueListenable: someValueListenable,
      builder: (context, value, _) {
        return MyStreamedWidget(value, someStream);
      },
    );
  }
}

class MyStreamedWidget extends StatelessWidget {
  const MyStreamedWidget(
    this.value,
    this.someStream, {
    Key key,
  }) : super(key: key);

  final String value;
  final Stream someStream;

  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    return StreamBuilder<int>(
      stream: someStream,
      builder: (context, value2) => MyAnimatedWidget(value, value2),
    );
  }
}

class MyAnimatedWidget extends StatelessWidget {
  final String value;
  final AsyncSnapshot<int> value2;

  const MyAnimatedWidget(
    this.value,
    this.value2, {
    Key key,
  }) : super(key: key);

  <strong i="14">@override</strong>
  Widget build(BuildContext context) {
    return TweenAnimationBuilder<double>(
      tween: Tween(),
      builder: (context, value3, _) {
        return Text('$value $value2 $value3');
      },
    );
  }
}

आपके उदाहरण में ऐसा कुछ भी नहीं है जो किसी नए कीवर्ड या विशेषता की गारंटी देता हो।

मुझे पता है कि आप क्या कहने जा रहे हैं। 'वैल्यू' वेरिएबल को सभी विजेट्स/फ़ंक्शन कॉल्स के माध्यम से पारित किया जाना है, लेकिन यह सिर्फ इस बात का परिणाम है कि आप अपने एप्लिकेशन को कैसे आर्किटेक्ट करते हैं। मैं उपयोग के मामले के आधार पर "बिल्ड" विधियों और कस्टम विजेट दोनों के साथ अपना कोड तोड़ता हूं, और कभी भी एक ही चर को तीन कॉल की श्रृंखला में पास नहीं करना पड़ता है।

पुन: प्रयोज्य कोड पुन: प्रयोज्य होता है जब यह बाहरी साइड इफेक्ट्स (जैसे इनहेरिटेडविजेट्स, या (अर्ध) वैश्विक स्थिति) पर जितना संभव हो उतना कम निर्भर करता है।

@Rudiksz मुझे नहीं लगता कि आप यहां चर्चा में कुछ भी जोड़ रहे हैं। हम इन मुद्दों को कम करने के लिए रणनीतियों से अवगत हैं क्योंकि हम उन्हें पूरे दिन करते हैं। यदि आपको ऐसा नहीं लगता कि यह कोई समस्या है, तो आप चीजों का उपयोग वैसे ही करना जारी रख सकते हैं जैसे वे हैं और यह आपको बिल्कुल भी प्रभावित नहीं करता है।

स्पष्ट रूप से ऐसे बहुत से लोग हैं जो इसे एक मूलभूत दर्द बिंदु के रूप में देखते हैं, और केवल आगे-पीछे साइकिल चलाना व्यर्थ है। आप विभिन्न तर्कों के माध्यम से लोगों को यह समझाने नहीं जा रहे हैं कि वे जो चाहते हैं वह नहीं चाहते हैं या यहां किसी का विचार नहीं बदलते हैं। इस चर्चा में हर किसी के पास स्पंदन में स्पष्ट रूप से सैकड़ों या हजारों घंटे हैं, और यह उम्मीद नहीं है कि हम सभी चीजों पर सहमत हों।

मुझे लगता है कि यह राय का मामला है। मैं मानता हूं कि कुछ लोग सोचते हैं कि आपके द्वारा वर्णित संस्करण अधिक पठनीय हैं; व्यक्तिगत रूप से मैं अधिक स्पष्ट जादू-कम संस्करण पसंद करता हूं। लेकिन दूसरी शैली को संभव बनाने में मुझे कोई आपत्ति नहीं है।

अगर यह राय की बात है, तो मुझे लगता है कि यह एक दिशा में काफी एकतरफा है।

1. दोनों में जादू है। मैं जरूरी नहीं जानता कि इनमें से कोई भी बिल्डर आंतरिक रूप से क्या कर रहा है। गैर-जादू संस्करण इन बिल्डरों के अंदर वास्तविक बॉयलरप्लेट लिख रहा है। सिंगलएनीमेशनटिकरप्रोवाइडर मिक्सिन का उपयोग करना स्पंदन देवों के 95% के लिए भी जादू है।
2. एक बहुत महत्वपूर्ण चर नामों को अस्पष्ट करता है जिनका उपयोग बाद में पेड़ में किया जाएगा, जो कि value1 और value2 , दूसरे में उन्हें निर्माण के शीर्ष पर सामने और केंद्र में रखा गया है। यह एक स्पष्ट पार्सिंग/रखरखाव जीत है।
3. विजेट ट्री शुरू होने से पहले एक में इंडेंटेशन के 6 स्तर होते हैं, दूसरे में 0
4. एक 5 खड़ी रेखाएं हैं, दूसरी 15
5. एक वास्तविक सामग्री के टुकड़े को प्रमुखता से दिखाता है (पाठ ()) दूसरा इसे छुपाता है, नेस्टेड, नीचे पेड़ में। एक और स्पष्ट पार्सिंग जीत।

एक सामान्य अर्थ में मैं देख सकता था कि यह शायद स्वाद का मामला है। लेकिन स्पंदन में विशेष रूप से लाइन काउंट, इंडेंटेशन और सिग्नल के साथ एक समस्या है शोर अनुपात। जबकि मैं पूरी तरह से डार्ट कोड में एक पेड़ बनाने की क्षमता _love_ करता हूं, यह कुछ बेहद अपठनीय/वर्बोज़ कोड को जन्म दे सकता है, खासकर जब आप लिपटे बिल्डरों की कई परतों पर भरोसा करते हैं। तो फ़्लटर के संदर्भ में, जहां हम लगातार इस लड़ाई से लड़ रहे हैं, इस प्रकार का अनुकूलन एक हत्यारा विशेषता है, क्योंकि यह हमें सामान्य वर्बोसिटी के कुछ हद तक व्यापक मुद्दे से निपटने के लिए वास्तव में एक उत्कृष्ट उपकरण प्रदान करता है।

टीएल; डीआर - स्पंदन में निहित इंडेंटेशन और लाइन काउंट को काफी कम करने वाली कोई भी चीज दोगुनी मूल्यवान है, क्योंकि आमतौर पर हाई लाइन काउंट और इंडेंटेशन स्पंदन में निहित होता है।

@Rudiksz मुझे नहीं लगता कि आप यहां चर्चा में कुछ भी जोड़ रहे हैं। हम इन मुद्दों को कम करने के लिए रणनीतियों से अवगत हैं क्योंकि हम उन्हें पूरे दिन करते हैं। यदि आपको ऐसा नहीं लगता कि यह कोई समस्या है, तो आप चीजों का उपयोग वैसे ही करना जारी रख सकते हैं जैसे वे हैं और यह आपको बिल्कुल भी प्रभावित नहीं करता है।

सिवाय अगर यह मूल ढांचे में बदलाव है तो यह मुझे प्रभावित करता है, नहीं?

स्पष्ट रूप से ऐसे बहुत से लोग हैं जो इसे एक मूलभूत दर्द बिंदु के रूप में देखते हैं, और केवल आगे-पीछे साइकिल चलाना व्यर्थ है। आप विभिन्न तर्कों के माध्यम से लोगों को यह समझाने नहीं जा रहे हैं कि वे जो चाहते हैं वह नहीं चाहते हैं या यहां किसी का विचार नहीं बदलते हैं। इस चर्चा में हर किसी के पास स्पंदन में स्पष्ट रूप से सैकड़ों या हजारों घंटे हैं, और यह उम्मीद नहीं है कि हम सभी चीजों पर सहमत हों।

ठीक है, इस घोड़े को पहले ही अनगिनत बार पीटा जा चुका है, इसलिए मैं किसी और टिप्पणी का जवाब देने के चक्कर में नहीं पड़ूंगा।

बिल्डर्स तकनीकी रूप से राज्य के तर्क का पुन: उपयोग करने का एक तरीका है। लेकिन उनका मुद्दा यह है कि वे कोड को बहुत पठनीय नहीं बनाते हैं।

यह बखूबी बताता है। स्पंदन के संदर्भ में इसके बारे में सोचने के लिए, हमें सिंगल-लाइन बिल्डरों की आवश्यकता है।

बिल्डर्स जिन्हें दर्जनों टैब और लाइनों की आवश्यकता नहीं होती है, लेकिन फिर भी कुछ कस्टम बॉयलरप्लेट को विजेट जीवनचक्र में जोड़ने की अनुमति देते हैं।

"सब कुछ एक विजेट है" मंत्र विशेष रूप से यहां अच्छी बात नहीं है। एक बिल्डर में प्रासंगिक कोड आमतौर पर सिर्फ इसका सेटअप प्रॉप्स होता है, और स्टेटफुल चीज जो वह लौटाती है जिसे बिल्ड fxn की जरूरत होती है। हर एक लाइन ब्रेक और टैब मूल रूप से व्यर्थ है।

सिवाय अगर यह मूल ढांचे में बदलाव है तो यह मुझे प्रभावित करता है, नहीं?

@Rudiksz मुझे नहीं लगता कि कोई यह प्रस्तावित कर रहा है कि हम स्टेटफुल विजेट्स को बदलते हैं। आप चाहें तो हमेशा उनके वर्तमान स्वरूप में उनका उपयोग कर सकते हैं। हम जो भी समाधान लेकर आ सकते हैं, वह या तो बिना किसी बदलाव के स्टेटफुल विजेट्स का उपयोग करेगा, या किसी अन्य प्रकार के विजेट का पूरी तरह से उपयोग करेगा। हम यह नहीं कह रहे हैं कि स्टेटफुल विजेट खराब हैं, बस हम एक अन्य प्रकार का विजेट चाहते हैं जो अधिक कंपोजेबल विजेट स्थिति की अनुमति देता है। इसे एक स्टेटफुल विजेट के रूप में सोचें कि इससे जुड़ी एक स्टेट ऑब्जेक्ट के बजाय कई स्टेट ऑब्जेक्ट हैं, और एक बिल्ड फंक्शन जो अलग है लेकिन उन स्टेट ऑब्जेक्ट्स तक पहुंच है। इस तरह, आप उनके 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
  }

इससे बेहतर वर्णन करने का कोई बेहतर तरीका नहीं है। आप इस उपयोग के मामले को किसी भी नियंत्रक प्रकार की वस्तु तक बढ़ा सकते हैं। एनिमेटर कंट्रोलर, फोकसकंट्रोलर और टेक्स्टएडिटिंग कंट्रोलर शायद दिन-प्रतिदिन के उपयोग में प्रबंधित करने के लिए सबसे आम और कष्टप्रद हैं। अब सिर्फ ५०, या १०० चित्र मेरे कोड बेस पर छिड़के गए हैं।

• आपके पास लगभग 1000-2000 लाइनें हैं जो अभी गायब हो सकती हैं।
• आपके पास शायद दर्जनों बग और आरटीई (विकास के विभिन्न बिंदुओं पर) हैं जिन्हें कभी अस्तित्व में रखने की आवश्यकता नहीं थी क्योंकि कुछ ओवरराइड या कोई अन्य गायब था।
• आपके पास ऐसे विजेट हैं, जिन्हें जब ठंडी आँखों से देखा जाता है, तो एक नज़र में टटोलना बहुत कठिन होता है। मुझे इनमें से प्रत्येक ओवरराइड को पढ़ने की ज़रूरत है, मैं बस यह नहीं मान सकता कि वे बॉयलरप्लेट हैं।

और आप निश्चित रूप से इसे कस्टम नियंत्रकों तक बढ़ा सकते हैं। फ़्लटर में नियंत्रकों का उपयोग करने की पूरी अवधारणा कम आकर्षक है क्योंकि आप जानते हैं कि आपको उन्हें इस तरह से बूटस्ट्रैप, प्रबंधित और नष्ट करना होगा, जो कष्टप्रद और बग प्रवण है। यह आपको अपना खुद का बनाने से बचने और इसके बजाय कस्टम स्टेटफुल विजेट/बिल्डर बनाने की ओर ले जाता है। यह अच्छा होगा यदि नियंत्रक प्रकार की वस्तुओं का उपयोग करना आसान और अधिक मजबूत था, क्योंकि बिल्डरों के पास पठनीयता के मुद्दे हैं (या कम से कम, काफी अधिक क्रिया और सफेद-स्थान से लदी हैं)।

यह मुश्किल है

हाँ, एपीआई डिजाइन मुश्किल है। मेरी जिंदगी में स्वागत है।

तो मुझे नहीं पता कि इनमें से 30 उदाहरणों को देखने से क्या पता चलेगा, 1 नहीं।

यह 30 उदाहरण नहीं हैं जो मदद करेंगे, यह 1 उदाहरण है जो पर्याप्त विस्तृत है कि इसे इस तरह से सरल नहीं किया जा सकता है कि आप कहेंगे "ठीक है, निश्चित रूप से, इस उदाहरण के लिए जो काम करता है, लेकिन यह _real_ उदाहरण के लिए नहीं है"।

यह 30 उदाहरण नहीं हैं जो मदद करेंगे, यह 1 उदाहरण है जो पर्याप्त विस्तृत है कि इसे उन तरीकों से सरल नहीं किया जा सकता है जो आप कहेंगे "ठीक है, निश्चित रूप से, इस उदाहरण के लिए जो काम करता है, लेकिन यह वास्तविक उदाहरण के लिए नहीं है"।

मैंने इसे पहले ही कई बार कहा है, लेकिन हुक को आंकने का यह तरीका अनुचित है।
हुक कुछ ऐसा संभव बनाने के बारे में नहीं हैं जो पहले असंभव था। यह इस तरह की समस्या को हल करने के लिए एक सुसंगत एपीआई प्रदान करने के बारे में है।

एक आवेदन का अनुरोध करना जो कुछ ऐसा दिखाता है जिसे अलग तरीके से सरल नहीं किया जा सकता है, एक मछली को पेड़ों पर चढ़ने की क्षमता से आंकना है।

हम केवल हुक का न्याय करने की कोशिश नहीं कर रहे हैं, हम यह देखने के लिए विभिन्न समाधानों का मूल्यांकन करने की कोशिश कर रहे हैं कि क्या कोई ऐसा है जो सभी की जरूरतों को पूरा करता है।

(मैं उत्सुक हूं कि आप यहां विभिन्न प्रस्तावों का मूल्यांकन कैसे करेंगे, यदि वास्तव में प्रत्येक प्रस्तावों में आवेदन लिखकर और उनकी तुलना करके नहीं। इसके बजाय आप किस मूल्यांकन मीट्रिक का प्रस्ताव देंगे?)

इस समस्या के समाधान का न्याय करने का एक उचित तरीका एक आवेदन नहीं है (क्योंकि एपीआई के प्रत्येक व्यक्तिगत उपयोग को यहां के उदाहरणों की तरह खारिज कर दिया जाएगा)।

हमें प्रस्तावित समाधान को किस आधार पर आंकना चाहिए:

• क्या परिणामी कोड वस्तुनिष्ठ रूप से डिफ़ॉल्ट सिंटैक्स से बेहतर है?
  
  
  
  • क्या यह गलतियों से बचता है?
  
  
  • क्या यह अधिक पठनीय है?
  
  
  • क्या लिखना आसान है?
  
  
• कोड का पुन: उपयोग कैसे किया जाता है?
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  
  
  
  • क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  
  

जब इस ग्रिड पर मूल्यांकन किया जाता है, तो Property / addDispose प्रस्ताव में अच्छा हो सकता है "क्या परिणामी कोड बेहतर है?" स्कोर, लेकिन पुन: प्रयोज्य और लचीलेपन दोनों के खिलाफ खराब मूल्यांकन करें।

मैं नहीं जानता कि वास्तव में प्रत्येक प्रस्ताव को वास्तविक उपयोग में देखे बिना उन प्रश्नों का उत्तर कैसे दिया जाए।

क्यों?

मुझे यह जानने के लिए Property का उपयोग करके आवेदन करने की आवश्यकता नहीं थी कि इस प्रस्ताव को वास्तव में पुन: प्रयोज्य कोड बनाने और कई समस्याओं को हल करने में कठिनाई होगी।

हम किसी भी मौजूदा *बिल्डर को ले सकते हैं और प्रस्तावित समाधान का उपयोग करके उन्हें फिर से लागू करने का प्रयास कर सकते हैं।
हम इस धागे में सूचीबद्ध हुक या रिएक्ट समुदाय में बने कुछ हुक को भी आजमा सकते हैं और फिर से लागू कर सकते हैं (ऑनलाइन उपलब्ध हुक के कई संकलन हैं)।

मुझे यह जानने के लिए Property का उपयोग करके आवेदन करने की आवश्यकता नहीं थी कि इस प्रस्ताव को वास्तव में पुन: प्रयोज्य कोड बनाने और कई समस्याओं को हल करने में कठिनाई होगी।

दुर्भाग्य से, मैं आपकी प्रवृत्ति को यहां साझा नहीं करता (जैसा कि इस तथ्य से प्रदर्शित होता है कि मैंने सोचा था कि संपत्ति (https://github.com/flutter/flutter/issues/51752#issuecomment-667737471) ने तब तक बहुत अच्छा काम किया जब तक आपने कहा कि इसे मूल्यों को संभालना है एक ही एपीआई के साथ एक विजेट और स्थानीय राज्य दोनों से, जो मुझे पता नहीं था, जब तक आप इसे नहीं लाते थे तब तक एक बाधा थी)। अगर मैं संपत्ति का एक संस्करण प्रदान करता हूं जो उस समस्या को भी हल करता है, तो क्या यह निश्चित रूप से ठीक होगा, या क्या कोई नई समस्या होगी जो इसमें शामिल नहीं है? लक्ष्य के बिना हम सभी सहमत हैं कि लक्ष्य है, मुझे नहीं पता कि हम किसके लिए समाधान तैयार कर रहे हैं।

हम किसी भी मौजूदा *बिल्डर को ले सकते हैं और प्रस्तावित समाधान का उपयोग करके उन्हें फिर से लागू करने का प्रयास कर सकते हैं।

स्पष्ट रूप से _any_ नहीं। उदाहरण के लिए, आपने ओपी में एक दिया था, और जब मैंने अपना पहला संपत्ति प्रस्ताव (https://github.com/flutter/flutter/issues/51752#issuecomment-664787791) बनाया था, तो आपने इसके साथ समस्याओं की ओर इशारा किया था जो कि सचित्र नहीं थे मूल निर्माता।

हम इस धागे में सूचीबद्ध हुक या रिएक्ट समुदाय में बने कुछ हुक को भी आजमा सकते हैं और फिर से लागू कर सकते हैं (ऑनलाइन उपलब्ध हुक के कई संकलन हैं)।

मुझे कोई फर्क नहीं पड़ता कि हम कहां से शुरू करते हैं। यदि आपके पास एक विशेष रूप से अच्छा उदाहरण है जो आपको लगता है कि समस्या को दिखाता है और यह हुक का उपयोग करता है, तो बढ़िया, चलिए इसे @TimWhiting के भंडार में

यह 30 उदाहरण नहीं हैं जो मदद करेंगे, यह 1 उदाहरण है जो पर्याप्त विस्तृत है कि इसे इस तरह से सरल नहीं किया जा सकता है कि आप कहेंगे "ठीक है, निश्चित रूप से, इस उदाहरण के लिए जो काम करता है, लेकिन यह _real_ उदाहरण के लिए नहीं है"।

एक अपठनीय बिल्डर या बग-प्रवण जीवनचक्र बॉयलरप्लेट के एक समूह के बिना एक एनिमेटरकंट्रोलर (या कोई अन्य पुन: उपयोग करने योग्य स्टेटफुल घटक जिसके बारे में आप सोच सकते हैं) का उपयोग करने की सरल इच्छा से अधिक विस्तृत कुछ भी नहीं होगा।

ऐसा कोई समाधान प्रस्तावित नहीं किया गया है जो सामान्य प्रयोजन के तरीके से अनुरोधित पठनीयता और मजबूती के लाभों को संबोधित करता हो।

मैं इस तथ्य पर जोर देता हूं कि _any_ बिल्डर करेगा, क्योंकि इस मुद्दे का नाम बदलकर "हमें बिल्डर्स के लिए सिंटैक्स चीनी की आवश्यकता है" और उसी चर्चा का नेतृत्व किया जा सकता है।

अन्य सभी तर्क (जैसे AnimationController बनाना और निपटाना) इस आधार पर किए जाते हैं कि उन्हें भी एक निर्माता में निकाला जा सकता है:

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

    }
  );
}

अंत में, मुझे लगता है कि आदर्श उदाहरण StreamBuilder को पूरी तरह से फिर से लागू करने का प्रयास कर रहा है, और विभिन्न परिदृश्यों में इसका परीक्षण कर रहा है:

• धारा Widget से आती है
• // एक इनहेरिटेडविजेट से
• स्थानीय राज्य से

और "समय के साथ धारा बदल सकती है" के खिलाफ प्रत्येक व्यक्तिगत मामले का परीक्षण करें, इसलिए:

• एक नई स्ट्रीम के साथ didUpdateWidget
• इनहेरिटेडविजेट अपडेट किया गया
• हमने सेटस्टेट कहा है

यह वर्तमान में Property या onDispose

@esDotDev क्या आप "अनुरोधित पठनीयता और मजबूती लाभों" की गणना कर सकते हैं? अगर कोई ऐसा प्रस्ताव बनाता है जो एनिमेशन कंट्रोलर को उन पठनीयता और मजबूती के लाभों के साथ संभालता है, तो हम यहां कर रहे हैं?

@rrousselGit मैं संपत्ति की वकालत नहीं कर रहा हूं, जैसा कि आपने पहले कहा है कि यह आपकी समस्याओं का समाधान नहीं करता है। लेकिन अगर कोई ऐसा समाधान तैयार करता है जो StreamBuilder करता है, लेकिन इंडेंटेशन के बिना, क्या यह होगा? आप खुश होंगे?

लेकिन अगर कोई ऐसा समाधान तैयार करता है जो StreamBuilder करता है, लेकिन इंडेंटेशन के बिना, क्या यह होगा? आप खुश होंगे?

सबसे अधिक संभावना हां

हमें इस समाधान की तुलना निश्चित रूप से अन्य समाधानों से करनी होगी। लेकिन यह स्वीकार्य स्तर तक पहुंच जाएगा।

@esDotDev क्या आप "अनुरोधित पठनीयता और मजबूती लाभों" की गणना कर सकते हैं?

इसमें मजबूती है कि यह निर्भरता और जीवनचक्र के आसपास बॉयलरप्लेट को पूरी तरह से घेर सकता है। अर्थात। मुझे हर बार fetchUser को यह नहीं बताना चाहिए कि आईडी बदलने पर इसे शायद पुनर्निर्माण करना चाहिए, यह आंतरिक रूप से ऐसा करना जानता है। हर बार माता-पिता विजेट का निपटारा होने पर खुद को निपटाने के लिए एनिमेशन को बताने की आवश्यकता नहीं होनी चाहिए, आदि। (मुझे पूरी तरह से समझ में नहीं आता कि संपत्ति यह टीबीएच कर सकती है या नहीं)। यह डेवलपर्स को रॉट कार्यों के लिए गलतियाँ करने से रोकता है, पूरे कोड बेस में (वर्तमान में बिल्डर्स का उपयोग करने के मुख्य लाभों में से एक imo)

पठनीयता यह है कि हम गैर-इंडेंट कोड की एक पंक्ति के साथ स्टेटफुल चीज़ प्राप्त कर सकते हैं, और चीज़ के लिए वेरिएबल फहराया जाता है और स्पष्ट रूप से दिखाई देता है।

@esDotDev अगर कोई ऐसा प्रस्ताव बनाता है जो उन पठनीयता और मजबूती के लाभों के साथ

यदि आपका मतलब विशेष रूप से एनिमेशन कंट्रोलर नं। यदि आपका मतलब किसी एनिमेशन कंट्रोलर/फोकस कंट्रोलर/टेक्स्टएडिटिंग कंट्रोलर जैसी वस्तु से है, तो हाँ।

एक फ़ंक्शन-जैसी एपीआई होना जो एक ऐसा मान लौटाता है जिसमें एक परिभाषित जीवन-समय होता है जो स्पष्ट नहीं होता है

मुझे लगता है कि यह एक महत्वपूर्ण गलत समझ है। हुक का जीवनकाल स्पष्ट है, क्योंकि वे परिभाषा के अनुसार उप-राज्य हैं। वे _हमेशा_ उस राज्य के जीवनकाल के लिए मौजूद रहते हैं जो उनका "उपयोग" करता है। यह वास्तव में अधिक स्पष्ट नहीं हो सका। वाक्य रचना शायद अजीब और अपरिचित है, लेकिन इसमें निश्चित रूप से स्पष्टता की कमी नहीं है।

इसी तरह एक TweenAnimationBuilder() का जीवनकाल भी स्पष्ट है। जब इसके माता-पिता चले जाएंगे तो यह चला जाएगा। चाइल्ड विजेट की तरह, ये चाइल्ड स्टेट्स हैं। वे पूरी तरह से स्वतंत्र राज्य "घटक" हैं, हम आसानी से इकट्ठा और पुन: उपयोग कर सकते हैं और हम स्पष्ट रूप से उनके जीवनकाल का प्रबंधन नहीं करते हैं क्योंकि हम चाहते हैं कि यह स्वाभाविक रूप से उस स्थिति से बंधे रहें जिसमें इसे घोषित किया गया है, एक विशेषता बग नहीं है।

@esDotDev

आदि

क्या आप अधिक विशिष्ट हो सकते हैं? (यही कारण है कि मैंने एक डेमो एप्लिकेशन के साथ आने का सुझाव दिया जिसमें सभी आधार शामिल थे। मुझे लगता है कि यह ऐसा करने का सबसे अच्छा तरीका है।) क्या ऐसी विशेषताएं हैं जो केवल प्रारंभकर्ता को कॉल करने के अलावा अन्य मायने रखती हैं जब तक कि कॉन्फ़िगरेशन बदल न जाए और स्वचालित रूप से निपटारा न हो जाए आवंटित संसाधन जब मेजबान तत्व का निपटारा किया जाता है?

टेक्स्टएडिटिंगकंट्रोलर जैसी वस्तु

क्या आप अधिक विशिष्ट हो सकते हैं? क्या टेक्स्ट एडिटिंग कंट्रोलर किसी भी तरह से एनिमेशन कंट्रोलर से अधिक विस्तृत है?

@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 कोई भी इससे अधिक नहीं मांग रहा है। एक बिल्डर विजेट से जुड़ सकता है। जो भी हो, एक बिल्डर पूरी तरह से विजेट ट्री के संदर्भ में जो भी आंतरिक स्थिति की आवश्यकता होती है, उसे पूरी तरह से प्रबंधित कर सकता है। यह सब एक हुक कर सकता है, और वह सब जो कोई भी सूक्ष्म-राज्य के लिए पूछ रहा है या जिसे आप इसे कॉल करना चाहते हैं।

क्या आप अधिक विशिष्ट हो सकते हैं? क्या टेक्स्ट एडिटिंग कंट्रोलर किसी भी तरह से एनिमेशन कंट्रोलर से अधिक विस्तृत है?

नहीं, लेकिन यह init/निपटान में अलग-अलग चीजें कर सकता है, या यह अलग-अलग गुणों से बंधेगा, और मैं उस विशिष्ट बॉयलरप्लेट को समाहित करना चाहता हूं।

@esDotDev तो आप एक निर्माता के रूप में एक ही चीज़ चाहते हैं, लेकिन

(एफडब्ल्यूआईडब्ल्यू, मुझे नहीं लगता कि बिल्डर्स, या बिल्डरों की तरह कुछ, लेकिन एक लाइन पर, एक अच्छा समाधान है, क्योंकि उन्हें इसकी आवश्यकता होती है कि प्रत्येक डेटा प्रकार के लिए अपना खुद का निर्माता बनाया जाए; फ्लाई पर सिर्फ एक बनाने का कोई अच्छा तरीका नहीं है ।)

(एफडब्ल्यूआईडब्ल्यू, मुझे नहीं लगता कि बिल्डर्स, या बिल्डरों की तरह कुछ, लेकिन एक लाइन पर, एक अच्छा समाधान है, क्योंकि उन्हें इसकी आवश्यकता होती है कि प्रत्येक डेटा प्रकार के लिए अपना खुद का निर्माता बनाया जाए; फ्लाई पर सिर्फ एक बनाने का कोई अच्छा तरीका नहीं है ।)

मुझे समझ नहीं आता इसका क्या मतलब है। क्या आप इसे फिर से लिख सकते हैं? 🙏

आपको एनिमेशन के लिए एनिमेशनबिल्डर और स्ट्रीम के लिए स्ट्रीमबिल्डर बनाना होगा। जब आप अपना 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)]);
}

यह सब कोड है। और कुछ नहीं होगा, क्योंकि स्ट्रीम हमारे लिए बनाई गई है, हमारे लिए स्ट्रीम का निपटारा किया गया है, हम अपने आप को पैर में गोली नहीं मार सकते हैं और कोड बहुत अधिक पठनीय है।

आपको एनिमेशन के लिए एनिमेशनबिल्डर और स्ट्रीम के लिए स्ट्रीमबिल्डर बनाना होगा।

मैं इसे एक मुद्दे के रूप में नहीं देखता। हमारे पास रिस्टोरेबलइंट बनाम रिस्टोरेबलस्ट्रिंग बनाम रिस्टोरेबलडबल पहले से ही है

और जेनरिक इसे हल कर सकते हैं:

GenericBuilder<Stream<int>>(
  create: (ref) {
    var controller = StreamController<int>();
    ref.onDispose(controller.close);
    return controller.stream;
  }
  builder: (context, Stream<int> stream) {

  }
)

इसी तरह, फ़्लटर या डार्ट में Disposable इंटरफ़ेस शामिल हो सकता है यदि यह वास्तव में एक समस्या है।

@esDotDev

मुझे लगता है कि जो अनुरोध किया जा रहा है वह कुछ ऐसा है:

यह कुछ बहुत ही उचित बाधाओं का उल्लंघन करेगा जिन्हें दूसरों ने सूचीबद्ध किया है (उदाहरण के लिए @Rudiksz), अर्थात् यह गारंटी देता है कि निर्माण विधि के लिए कॉल के दौरान कोई प्रारंभिक कोड कभी नहीं होता है।

@rrousselGit

मैं इसे एक मुद्दे के रूप में नहीं देखता। हमारे पास रिस्टोरेबलइंट बनाम रिस्टोरेबलस्ट्रिंग बनाम रिस्टोरेबलडबल पहले से ही है

और हमारे पास एनिमेशनबिल्डर और स्ट्रीमबिल्डर वगैरह हैं, हां। दोनों ही मामलों में यह दुर्भाग्यपूर्ण है।

जेनेरिकबिल्डर

यह वैसा ही है जैसा मैंने संपत्ति के लिए प्रस्तावित किया था, लेकिन अगर मैं वहां आपकी चिंताओं को समझता हूं तो आप मानते हैं कि यह बहुत ही वर्बोज़ है।

इससे पहले, आपने कहा था कि अगर कोई ऐसा समाधान तैयार करता है जो 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 विजेट/राज्य/जीवन-चक्र से बंधा नहीं है, इसलिए यह पास_
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  _हम कस्टम निर्माता बना सकते हैं, और इस पैटर्न का उपयोग कर सकते हैं। तो यह पास_. मैं
• क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  _नहीं, वाक्य रचना अपेक्षाकृत सुसंगत है_। मैं

1. यह सुविधा आईएमओ उदाहरण के लिए लेआउटबिल्डर समेत सभी बिल्डर विजेट्स तक विस्तारित हो सकती है।
2. सुनने को अक्षम करने का एक तरीका होना चाहिए, ताकि आप 10x नियंत्रक बना सकें और उन्हें पुनर्निर्माण के लिए लीफ्स में पास कर सकें, या स्पंदन को किसी तरह यह जानने की जरूरत है कि पेड़ के किस हिस्से ने बिल्डर द्वारा प्राप्त मूल्य का उपयोग किया है।
3. इसका उपयोग करना अधिक क्रियात्मक नहीं होना चाहिए जो हुक करता है।
4. इसे ठीक से संभालने के लिए कंपाइलर को बढ़ाया जाना चाहिए।
5. डिबगिंग सहायकों की आवश्यकता है। मान लें कि आप अपने किसी ऐसे विजेट में ब्रेकप्वाइंट डालते हैं जो इसका उपयोग करता है। बिल्ड विधि के अंदर ब्रेकपॉइंट तक पहुंचने पर, क्योंकि बिल्डरों में से एक ट्रिगर हो गया था, आईडीई प्रत्येक बिल्डर के लिए अतिरिक्त जानकारी प्रदर्शित कर सकता था जिसका उपयोग किया गया था:

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

इसके अलावा, @ हिक्सी

यह कुछ बहुत ही उचित बाधाओं का उल्लंघन करेगा जिन्हें दूसरों ने सूचीबद्ध किया है (उदाहरण के लिए @Rudiksz), अर्थात् यह गारंटी देता है कि निर्माण विधि के लिए कॉल के दौरान कोई प्रारंभिक कोड कभी नहीं होता है।

हम पहले से ही *बिल्डर्स का उपयोग करके ऐसा कर रहे हैं। हमें उन्हें डिडेंट करने के लिए बस एक सिंटैक्स शुगर चाहिए। यह बहुत कुछ एसिंक/प्रतीक्षा और वायदा जैसा है, मुझे लगता है।

@esDotDev आप जो वर्णन करते हैं वह बहुत कुछ वैसा ही लगता है जैसा मैंने पहले संपत्ति के साथ प्रस्तावित किया था (उदाहरण के लिए देखें https://github.com/flutter/flutter/issues/51752#issuecomment-664787791 या https://github.com/flutter/flutter/ मुद्दे/51752#मुद्दा टिप्पणी-667737471)। क्या ऐसा कुछ है जो इस तरह के समाधान को पैकेज के रूप में बनने से रोकता है? यानी, आपको इस तरह की सुविधा का उपयोग करने की अनुमति देने के लिए मूल ढांचे में क्या बदलाव करने की आवश्यकता होगी?

@rrousselGit शॉन के साथ के रूप में मैं आपसे वही बात पूछूंगा। यदि वर्तमान स्ट्रीमबिल्डर सुविधा और आपकी आवश्यकताओं को पूरा करने वाले के बीच एकमात्र अंतर एक अलग वाक्यविन्यास है, तो आपको ऐसी सुविधा का उपयोग करने में सक्षम बनाने के लिए कोर सिंटैक्स की क्या आवश्यकता है? क्या केवल उस वाक्य रचना को बनाना पर्याप्त नहीं होगा जिसे आप पसंद करेंगे और उसका उपयोग करेंगे?

आपके ग्रिड के साथ मेरी समस्या यह है कि अगर मैं इसे अब तक के समाधानों पर लागू करता, तो मुझे यह मिल जाता, जो मुझे लगता है कि आपको जो मिलेगा उससे बहुत अलग है:

स्टेटफुलविजेट

• क्या परिणामी कोड वस्तुनिष्ठ रूप से डिफ़ॉल्ट सिंटैक्स से बेहतर है?
  
  
  
  • क्या यह गलतियों से बचता है?
    
    _यह डिफ़ॉल्ट सिंटैक्स के समान है, जो विशेष रूप से त्रुटि-प्रवण नहीं है।_
  
  
  • क्या यह अधिक पठनीय है?
    
    _यह वही है, इसलिए यह समान रूप से पठनीय है, जो यथोचित रूप से पठनीय है।_
  
  
  • क्या लिखना आसान है?
    
    _यह वही है, इसलिए इसे लिखना भी उतना ही आसान है, जो काफी आसान है।_
  
  
• कोड का पुन: उपयोग कैसे किया जाता है?
  _पुन: उपयोग करने के लिए बहुत कम कोड है।_
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  _यह आधार रेखा है।_
• क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  _ऐसा नहीं लगता।_

संपत्ति पर बदलाव

• क्या परिणामी कोड वस्तुनिष्ठ रूप से डिफ़ॉल्ट सिंटैक्स से बेहतर है?
  
  
  
  • क्या यह गलतियों से बचता है?
    
    _यह कोड को एक अलग स्थान पर ले जाता है, लेकिन विशेष रूप से गलतियों की संख्या को कम नहीं करता है।_ 🔷
  
  
  • क्या यह अधिक पठनीय है?
    
    _यह इनिशियलाइज़ेशन कोड और क्लीनअप कोड और अन्य जीवनचक्र कोड को एक ही स्थान पर रखता है, इसलिए यह कम स्पष्ट है।_
  
  
  • क्या लिखना आसान है?
    
    _यह इनिशियलाइज़ेशन कोड और क्लीनअप कोड और अन्य जीवनचक्र कोड को मिलाता है, इसलिए इसे लिखना कठिन है।_
  
  
• कोड का पुन: उपयोग कैसे किया जाता है?
  _ बिल्कुल अलग-अलग जगहों पर StatefulWidget के रूप में पुन: प्रयोज्य के रूप में।_
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  _यह StatefulWidget के लिए वाक्यात्मक चीनी है, इसलिए कोई अंतर नहीं है।_ 🔷
• क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  _प्रदर्शन और स्मृति उपयोग को थोड़ा नुकसान होगा।_

बिल्डर्स पर बदलाव

• क्या परिणामी कोड वस्तुनिष्ठ रूप से डिफ़ॉल्ट सिंटैक्स से बेहतर है?
  
  
  
  • क्या यह गलतियों से बचता है?
    
    _यह मूल रूप से StatefulWidget समाधान है लेकिन तथ्यात्मक है; गलतियाँ समकक्ष के बारे में होनी चाहिए।_
  
  
  • क्या यह अधिक पठनीय है?
    
    _बिल्ड विधियां अधिक जटिल हैं, बाकी तर्क एक अलग विजेट पर चले जाते हैं, इसलिए लगभग उसी के बारे में।_ 🔷
  
  
  • क्या लिखना आसान है?
    
    _पहली बार लिखना कठिन (बिल्डर विजेट बनाना), उसके बाद थोड़ा आसान, तो उसी के बारे में।_
  
  
• कोड का पुन: उपयोग कैसे किया जाता है?
  _ बिल्कुल अलग-अलग जगहों पर StatefulWidget के रूप में पुन: प्रयोज्य के रूप में।_
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  _यह StatefulWidget के लिए वाक्यात्मक चीनी है, इसलिए अधिकतर कोई अंतर नहीं है। कुछ पहलुओं में यह वास्तव में बेहतर है, उदाहरण के लिए, यह उस कोड की मात्रा को कम करता है जिसे एक निर्भरता परिवर्तन को संभालते समय चलाना होता है।_
• क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  _ऐसा नहीं लगता।_

हुक की तरह समाधान

• क्या परिणामी कोड वस्तुनिष्ठ रूप से डिफ़ॉल्ट सिंटैक्स से बेहतर है?
  
  
  
  • क्या यह गलतियों से बचता है?
    
    _खराब पैटर्न को प्रोत्साहित करता है (उदाहरण के लिए निर्माण विधि में निर्माण), अगर गलती से सशर्त के साथ उपयोग किया जाता है तो बग का जोखिम होता है।_
  
  
  • क्या यह अधिक पठनीय है?
    
    _बिल्ड विधि को समझने के लिए ज्ञात अवधारणाओं की संख्या को बढ़ाता है।_
  
  
  • क्या लिखना आसान है?
    
    _डेवलपर को हुक लिखना सीखना होगा, जो एक नई अवधारणा है, इतना कठिन।_ ❌
  
  
• कोड का पुन: उपयोग कैसे किया जाता है?
  _ बिल्कुल अलग-अलग जगहों पर StatefulWidget के रूप में पुन: प्रयोज्य के रूप में।_
• इस एपीआई से कितनी समस्याओं का समाधान किया जा सकता है?
  _यह StatefulWidget के लिए वाक्यात्मक चीनी है, इसलिए कोई अंतर नहीं है।_ 🔷
• क्या हम कुछ विशिष्ट समस्याओं के लिए कुछ लाभ खो देते हैं?
  _प्रदर्शन और स्मृति उपयोग भुगतना पड़ता है।_

मुझे समझ में नहीं आता कि हम वाचालता पर वापस क्यों आते रहते हैं।
मैंने कई बार स्पष्ट रूप से कहा कि यह समस्या नहीं है और समस्या पुन: प्रयोज्य बनाम पठनीयता बनाम लचीलापन है।

क्षमा करें, मुझे गलत याद आया कि वह कौन था जिसने कहा था कि संपत्ति बहुत क्रियात्मक थी। आप सही हैं, आपकी चिंता सिर्फ यह थी कि एक नया उपयोग मामला था जिसे पहले सूचीबद्ध नहीं किया गया था, हालांकि मुझे लगता है कि उस उपयोग के मामले को संभालने के लिए संपत्ति का विस्तार करना छोटा होगा (मैं हेवन कोशिश नहीं की, तब तक इंतजार करना बेहतर लगता है जब तक कि हमारे पास एक स्पष्ट डेमो ऐप न हो ताकि हम चीजों को एक बार और सभी के लिए हल कर सकें, बजाय इसके कि बार-बार पुनरावृति की आवश्यकता हो क्योंकि आवश्यकताओं को समायोजित किया जाता है)।

@szotp

1. यह सुविधा आईएमओ उदाहरण के लिए लेआउटबिल्डर समेत सभी बिल्डर विजेट्स तक विस्तारित हो सकती है।

अधिकांश बिल्डरों, एफडब्ल्यूआईडब्ल्यू की तुलना में लेआउटबिल्डर एक बहुत अलग विजेट है। अब तक जिन प्रस्तावों पर चर्चा की गई है, उनमें से कोई भी लेआउटबिल्डर जैसी समस्याओं के लिए काम नहीं करेगा, और आपकी टिप्पणी से पहले वर्णित किसी भी आवश्यकता में लेआउटबिल्डर शामिल नहीं है। अगर हमें लेआउटबिल्डर को संभालने के लिए इस नई सुविधा का भी उपयोग करना चाहिए जो जानना महत्वपूर्ण है; मैं यह सुनिश्चित करने के लिए @TimWhiting के साथ काम करने की सलाह देता हूं कि हम जिस नमूना ऐप पर प्रस्तावों को आधार बनाने जा रहे हैं,

1. सुनने को अक्षम करने का एक तरीका होना चाहिए, ताकि आप 10x नियंत्रक बना सकें और उन्हें पुनर्निर्माण के लिए लीफ्स में पास कर सकें, या स्पंदन को किसी तरह यह जानने की जरूरत है कि पेड़ के किस हिस्से ने बिल्डर द्वारा प्राप्त मूल्य का उपयोग किया है।

मुझे यकीन नहीं है कि इसका क्या मतलब है। जहां तक ​​​​मैं कह सकता हूं, आप इसे आज श्रोताओं और बिल्डरों के साथ कर सकते हैं (उदाहरण के लिए मैं ऐप में ValueListenableBuilder का उपयोग करता हूं जिसे मैंने पहले ऐसा करने के लिए उद्धृत किया था)।

यह कुछ बहुत ही उचित बाधाओं का उल्लंघन करेगा जिन्हें दूसरों ने सूचीबद्ध किया है (उदाहरण के लिए @Rudiksz), अर्थात् यह गारंटी देता है कि निर्माण विधि के लिए कॉल के दौरान कोई प्रारंभिक कोड कभी नहीं होता है।

हम पहले से ही *बिल्डर्स का उपयोग करके ऐसा कर रहे हैं।

मुझे नहीं लगता कि यह सही है। यह बिल्डर पर निर्भर करता है, लेकिन कुछ लोग initState, didChangeनिर्भरता, didUpdateWidget, और लॉजिक को अलग करने के लिए बहुत मेहनत करते हैं, ताकि जो कुछ बदला है उसके आधार पर प्रत्येक बिल्ड को चलाने के लिए केवल न्यूनतम मात्रा में कोड की आवश्यकता हो। उदाहरण के लिए, ValueListenableBuilder केवल पहली बार बनाए जाने पर श्रोताओं को पंजीकृत करता है, इसका निर्माता या तो माता-पिता या बिल्डर के initState के बिना फिर से चला सकता है। यह ऐसा कुछ नहीं है जो हुक कर सकता है।

@esDotDev आप जो वर्णन करते हैं वह बहुत कुछ वैसा ही लगता है जैसा मैंने पहले संपत्ति के साथ प्रस्तावित किया था (उदाहरण के लिए #51752 (टिप्पणी) या #51752 (टिप्पणी) देखें )।

अगर मैं सही समझता हूं, तो हम UserProperty जो स्वचालित रूप से UserId, या AnimationProperty , या किसी अन्य संपत्ति के लिए डिडडिपेंडेंसी चेंज को संभालता है, जिसे हमें उस प्रकार के लिए init/update/dispose को संभालने की आवश्यकता होती है? तब यह मुझे अच्छा लगता है। सबसे आम उपयोग के मामले जल्दी से बनाए जा सकते हैं।

केवल एक चीज जो मुझे फेंक रही है, वह है यहां का भविष्य का निर्माता। लेकिन मुझे लगता है कि यह सिर्फ आपके द्वारा चुने गए उदाहरण के कारण है?

उदाहरण के लिए, क्या मैं इसे बना सकता हूं?

class _ExampleState extends State<Example> with PropertyManager {
  AnimationProperty animProp1;
  AnimationProperty animProp2;

  <strong i="15">@override</strong>
  void initProperties() {
    super.initProperties();
    anim1= register(anim1, AnimationProperty (
      AnimationController(duration: Duration(seconds: 1)),
      initState: (animator) => animator.forward()
      // Not dealing with updates or dispose here, cause AnimationProperty handles it
    ));
   anim2 = register(anim2, AnimationProperty(
       AnimationController(duration: Duration(seconds: 2))..forward(),
   ));
  }

  <strong i="16">@override</strong>
  Widget build(BuildContext context) {
    return Column(children: [
       FadeTransition(opacity: anim1, child: ...),
       FadeTransition(opacity: anim2, child: ...),
   ])
  }
}

यदि हां, तो यह पूरी तरह से LGTM है! ढांचे में जोड़ने के मामले में, यह एक मामला है कि क्या इसे प्रथम श्रेणी के वाक्य रचनात्मक दृष्टिकोण में बढ़ावा दिया जाना चाहिए (जिसका अर्थ है कि यह एक वर्ष या उससे भी अधिक समय में सामान्य अभ्यास बन जाता है), या क्या यह एक प्लगइन के रूप में मौजूद है कि डेवलपर्स का कुछ एकल अंक प्रतिशत उपयोग।

यह एक बात है कि क्या आप वर्बोज़ को अपडेट करने में सक्षम होना चाहते हैं और (थोड़ा?) त्रुटि प्रवण उदाहरणों को बेहतर और संक्षिप्त वाक्यविन्यास के साथ अपडेट करना चाहते हैं। गुणों को मैन्युअल रूप से सिंक करने और मैन्युअल रूप से निपटान() चीजों को करने से बग और संज्ञानात्मक भार होता है।

इमो यह अच्छा होगा यदि कोई डेवलपर एनिमेटरों का उपयोग कर सकता है, उचित अद्यतन और निपटान और डिबगफिलप्रॉपर्टीज और पूरे कार्यों के साथ, इसके बारे में दो बार सोचने के बिना (ठीक उसी तरह जैसे हम करते हैं जब हम ट्विनएनीमेशनबिल्डर का उपयोग करते हैं, जो मुख्य कारण है जिसकी हम अनुशंसा करते हैं हमारे सभी डेवलपर्स इसे मैन्युअल रूप से एनिमेटर्स को प्रबंधित करने के लिए उपयोग करने के लिए डिफ़ॉल्ट हैं)।

यदि हां, तो यह पूरी तरह से LGTM है! ढांचे में जोड़ने के मामले में, यह एक मामला है कि क्या इसे प्रथम श्रेणी के वाक्य रचनात्मक दृष्टिकोण में बढ़ावा दिया जाना चाहिए (जिसका अर्थ है कि यह एक वर्ष या उससे भी अधिक समय में सामान्य अभ्यास बन जाता है), या क्या यह एक प्लगइन के रूप में मौजूद है कि डेवलपर्स का कुछ एकल अंक प्रतिशत उपयोग।

यह देखते हुए कि Property कितना तुच्छ है, उस शैली को पसंद करने वाले किसी व्यक्ति के लिए मेरी सिफारिश सिर्फ अपना खुद का बनाना होगा (शायद मेरे कोड से शुरू होने पर यह मदद करता है) और इसे सीधे अपने ऐप में उपयोग करना, जैसा कि वे फिट देखते हैं, इसे समायोजित करना उनकी जरूरतों को पूरा करने के लिए। इसे एक पैकेज में बनाया जा सकता है यदि बहुत से लोग इसे पसंद करते हैं, हालांकि फिर से कुछ तुच्छ के लिए यह मेरे लिए स्पष्ट नहीं है कि यह कितना फायदेमंद है बनाम इसे किसी के कोड में कॉपी करना और इसे आवश्यकतानुसार समायोजित करना।

केवल एक चीज जो मुझे फेंक रही है, वह है यहां का भविष्य का निर्माता। लेकिन मुझे लगता है कि यह सिर्फ आपके द्वारा चुने गए उदाहरण के कारण है?

मैं @rrousselGit द्वारा दिए गए एक उदाहरण को संबोधित करने का प्रयास कर रहा था। सिद्धांत रूप में इसे किसी भी चीज के लिए काम करने के लिए अनुकूलित किया जा सकता है।

उदाहरण के लिए, क्या मैं इसे बना सकता हूं?

आप एनिमेशन कंट्रोलर कंस्ट्रक्टर को एक क्लोजर में ले जाना चाहते हैं, जिसे हर बार कॉल करने के बजाय कॉल किया जाएगा, क्योंकि initProperties को नए क्लोजर प्राप्त करने के लिए हॉट रीलोड के दौरान कॉल किया जाता है, लेकिन आम तौर पर आप बनाना नहीं चाहते हैं हॉट रीलोड के दौरान एक नया नियंत्रक (उदाहरण के लिए यह एनिमेशन को रीसेट करेगा)। लेकिन हाँ, इसके अलावा यह ठीक लगता है। आप एक AnimationControllerProperty भी बना सकते हैं जो AnimationController कंस्ट्रक्टर तर्क लेता है और उनके साथ सही काम करता है (उदाहरण के लिए अगर यह बदल गया है तो हॉट रीलोड पर अवधि को अपडेट करना)।

इमो यह अच्छा होगा यदि कोई डेवलपर एनिमेटरों का उपयोग कर सकता है, उचित अद्यतन और निपटान और डिबगफिलप्रॉपर्टीज और पूरे कार्यों के साथ, इसके बारे में दो बार सोचने के बिना (ठीक उसी तरह जैसे हम करते हैं जब हम ट्विनएनीमेशनबिल्डर का उपयोग करते हैं, जो मुख्य कारण है जिसकी हम अनुशंसा करते हैं हमारे सभी डेवलपर्स इसे मैन्युअल रूप से एनिमेटर्स को प्रबंधित करने के लिए उपयोग करने के लिए डिफ़ॉल्ट हैं)।

डेवलपर्स के बारे में नहीं सोचने के बारे में मेरी चिंता यह है कि यदि आप इस बारे में नहीं सोचते हैं कि कब चीजें आवंटित और निपटाई जाती हैं, तो आप बहुत सी चीजों को आवंटित करने की अधिक संभावना रखते हैं जिनकी आपको हमेशा आवश्यकता नहीं होती है, या तर्क चल रहा है ' t को चलाने, या अन्य काम करने की आवश्यकता नहीं है जो कम कुशल कोड की ओर ले जाते हैं। यही कारण है कि मैं इसे एक डिफ़ॉल्ट अनुशंसित शैली बनाने के लिए अनिच्छुक हूं।

आप एक एनिमेशनकंट्रोलरप्रॉपर्टी भी बना सकते हैं जो एनिमेशनकंट्रोलर कंस्ट्रक्टर तर्क लेता है और उनके साथ सही काम करता है (उदाहरण के लिए अगर यह बदल गया है तो हॉट रीलोड पर अवधि को अपडेट करना)।

धन्यवाद @ हिक्सी यह वास्तव में अच्छा है और मुझे लगता है कि इस मुद्दे को काफी अच्छी तरह से संबोधित करता है।

मैं सुझाव नहीं दे रहा हूं कि देवों को इन चीजों के बारे में कभी नहीं सोचना चाहिए, लेकिन मुझे लगता है कि 99% उपयोग के मामले में ये चीजें लगभग हमेशा स्टेटफुल विजेट से जुड़ी होती हैं, और इसके अलावा कुछ भी करने से आपको पहले से ही मध्यवर्ती डेवलपर भूमि में लाया जा रहा है।

दोबारा, मैं नहीं देखता कि कच्चे एनिमेटर कंट्रोलर पर TweenAnimationBuilder की सिफारिश करने से यह मौलिक रूप से अलग कैसे है। यह मूल रूप से विचार है कि यदि आप चाहते हैं कि राज्य इस अन्य राज्य में पूरी तरह से निहित/प्रबंधित हो (और आमतौर पर आप यही चाहते हैं), तो इसे इस तरह से सरल और अधिक मजबूत करें।

इस बिंदु पर, हमें एक कॉल का आयोजन करना चाहिए और विभिन्न इच्छुक पार्टियों के साथ मिलकर इस पर चर्चा करनी चाहिए।
क्योंकि यह चर्चा आगे नहीं बढ़ रही है, क्योंकि हम एक ही प्रश्न का उत्तर बार-बार दे रहे हैं।

मुझे समझ में नहीं आता कि इतनी लंबी चर्चा के बाद, इतने सारे तर्कों के साथ, हम अभी भी यह तर्क दे सकते हैं कि बिल्डर्स स्टेटफुलविजेट की तुलना में गलतियों से नहीं बचते हैं, या यह कि हुक कच्चे स्टेटफुल विजेट्स की तुलना में अधिक पुन: प्रयोज्य नहीं हैं।

यह विशेष रूप से निराशाजनक है कि सभी प्रमुख घोषणात्मक ढांचे (रिएक्ट, वीयू, स्विफ्ट यूआई, जेटपैक कंपोज़) पर विचार करने के लिए इस समस्या को हल करने के लिए एक या दूसरा तरीका है।
ऐसा लगता है कि केवल स्पंदन ही इस समस्या पर विचार करने से इनकार करता है।

@esDotDev एनिमेशनबिल्डर या ट्वीनएनीमेशनबिल्डर या ValueListenableBuilder का उपयोग करने के लिए IMHO का मुख्य कारण यह है कि वे अपने बाकी होस्ट विजेट के पुनर्निर्माण के बिना , मूल्य में परिवर्तन होने पर ही

@rrousselGit

ऐसा लगता है कि केवल स्पंदन ही इस समस्या पर विचार करने से इनकार करता है।

मैंने इस सप्ताह के अंत में अपने स्वयं के समय के सचमुच घंटे बिताए हैं, इससे पहले 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.

दिलचस्प। हमारे लिए हमने वास्तव में इस तरह के छोटे पुनर्निर्माणों को बचाने से प्रदर्शन में सुधार को कभी भी मापा या नहीं देखा है। कोड को संक्षिप्त, पठनीय, और किसी भी नियमित त्रुटि से मुक्त रखने के लिए एक बड़े ऐप कोड बेस पर यह बहुत अधिक महत्वपूर्ण है जो तब हो सकता है जब आप हर दो सप्ताह में सैकड़ों क्लास फाइलें निकाल रहे हों।

हमारे अनुभव से, पिक्सेल को फिर से रंगने की लागत, जो कि पूर्ण पेड़ के साथ होती प्रतीत होती है, जब तक कि आप अपनी रिपेंट सीमाओं को परिभाषित करने के बारे में उद्देश्यपूर्ण न हों, आंशिक विजेट लेआउट लागतों की तुलना में वास्तविक दुनिया के प्रदर्शन में एक कारक बहुत अधिक महत्वपूर्ण है। खासकर जब आप 4k मॉनिटर रेंज में आते हैं।

लेकिन यह एक अच्छा उदाहरण है जब बिल्डर्स वास्तव में इस तरह की चीज के लिए समझ में आता है। अगर मैं एक उप-संदर्भ बनाना चाहता हूं, तो एक निर्माता समझ में आता है और वहां पहुंचने का एक अच्छा तरीका है।

कई बार हम नहीं करते हैं, और इस मामले में, बिल्डर सिर्फ अव्यवस्था जोड़ रहा है, लेकिन हम इसे स्वीकार करते हैं, क्योंकि विकल्प सिर्फ एक अलग प्रकार की अव्यवस्था है, और कम से कम बिल्डर के साथ, चीजें कम या ज्यादा गारंटीकृत बग मुक्त हैं। ऐसे मामलों में जहां पूरा दृश्य पुनर्निर्माण करता है, या जरूरी नहीं है कि एक बिल्डर का उपयोग करके पुनर्निर्माण (टेक्स्टएडिटिंग कंट्रोलर, फोकसकंट्रोलर) बिल्कुल भी न हो, और सभी मामलों में, बॉयलरप्लेट को हाथ से रोल करना मूल रूप से डीआरवाई नहीं है।

यह निश्चित रूप से बहुत ही स्थिति-विशिष्ट है, क्योंकि प्रदर्शन के मुद्दे अक्सर होते हैं। मुझे लगता है कि अगर लोगों को वह शैली पसंद है तो हुक या संपत्ति जैसी किसी चीज़ का उपयोग करना समझ में आता है। यह आज संभव है और ऐसा लगता है कि ढांचे से अतिरिक्त कुछ भी नहीं चाहिए (और जैसा कि संपत्ति दिखाता है, इसे वास्तव में अधिक कोड की आवश्यकता नहीं होती है)।

नहीं, लेकिन यह समुदाय को TweenAnimationBuilder और ValueListenableBuilder बनाने के लिए कहने जैसा है और उन्हें बनाने के लिए एक StatefulWidget प्रदान नहीं करना है।

ऐसा नहीं है कि आप पूछ रहे हैं, लेकिन इस प्रकार की वास्तुकला के प्राथमिक लाभों में से एक यह है कि यह स्वाभाविक रूप से छोटे छोटे घटकों को उधार देता है जिन्हें आसानी से साझा किया जा सकता है। यदि आप एक छोटा सा मूलभूत टुकड़ा रखते हैं ...

StatefulWidget संपत्ति की तुलना में कोड का एक _lot_ है, और यह गैर-तुच्छ है (संपत्ति के विपरीत, जो अधिकतर गोंद कोड है)। उस ने कहा, अगर संपत्ति कुछ ऐसा है जो व्यापक रूप से पुन: उपयोग करने के लिए समझ में आता है (जैसा कि इसकी सटीक जरूरतों के आधार पर प्रत्येक एप्लिकेशन या टीम के लिए बीस्पोक संस्करणों को क्राफ्ट करने के विपरीत), तो मैं किसी ऐसे व्यक्ति को प्रोत्साहित करूंगा जो पैकेज बनाने और इसे अपलोड करने के लिए इसके उपयोग की वकालत करता है। pub । वही, वास्तव में, हुक पर लागू होता है। अगर यह कुछ ऐसा है जिसे समुदाय पसंद करता है तो यह प्रदाता की तरह ही बहुत उपयोग करेगा। यह स्पष्ट नहीं है कि हमें ढांचे में ही ऐसा कुछ क्यों रखना होगा।

मुझे लगता है क्योंकि यह स्वाभाविक रूप से एक्स्टेंसिबल है। प्रदाता नहीं है, यह सिर्फ एक साधारण उपकरण है। यह कुछ ऐसा है जिसे स्टेटफुलविजेट की तरह बढ़ाया जाता है, लेकिन स्टेटफुल कॉम्पोनेंट्स के लिए। तथ्य यह है कि यह अपेक्षाकृत तुच्छ है जरूरी नहीं कि इसके खिलाफ आयोजित किया जाना चाहिए?

"जो लोग इस शैली को पसंद करते हैं" पर एक नोट। यदि आप 3 ओवरराइड और 15-30 लाइनों को सहेज सकते हैं, तो यह ज्यादातर मामलों में पठनीयता की जीत होगी। निष्पक्ष रूप से इमो बोल रहा हूँ। यह त्रुटियों के 2 संपूर्ण वर्गों को भी निष्पक्ष रूप से समाप्त करता है (चीजों को निपटाना भूल जाना, डीपीएस को अपडेट करना भूल जाना)।

भयानक चर्चा के लिए बहुत-बहुत धन्यवाद, यह देखने के लिए उत्साहित हूं कि यह कहां जाता है, मैं निश्चित रूप से इसे यहां छोड़ दूंगा :)

मुझे यह कहते हुए खेद है कि यह धागा मुझे वापस स्पंदन में मोहभंग कर देता है जो कि एक और परियोजना को पूरा करते समय योजना थी जिस पर मैं काम कर रहा हूं। मुझे इस वजह से भी निराशा होती है

यह विशेष रूप से निराशाजनक है कि सभी प्रमुख घोषणात्मक ढांचे (रिएक्ट, वीयू, स्विफ्ट यूआई, जेटपैक कंपोज़) पर विचार करने के लिए इस समस्या को हल करने के लिए एक या दूसरा तरीका है।

मैं @rrousselGit से सहमत हूं कि मुझे नहीं लगता कि हमें स्पंदन उदाहरण ऐप्स बनाने में समय बिताना चाहिए क्योंकि इस धागे में इस मुद्दे को बार-बार स्पष्ट रूप से वर्णित किया गया है। मैं नहीं देख सकता कि इसे वही प्रतिक्रिया कैसे नहीं मिलेगी। क्योंकि यह वही चीजें होंगी जो यहां प्रस्तुत की गई हैं। इस सूत्र के बारे में मेरा विचार यह है कि स्पंदन ढांचे के दृष्टिकोण से स्पंदन डेवलपर्स के लिए एक ही जीवनकाल कोड को केवल एक बार लिखने के बजाय एकाधिक विजेट्स में दोहराना बेहतर होता है और इसके साथ किया जाता है।
इसके अलावा, अगर हम एक समाधान की तलाश में हैं तो हम स्पंदन में एक ऐप नहीं लिख सकते हैं क्योंकि हमें ऐप लिखने के लिए समाधान की आवश्यकता है। चूंकि इस बातचीत में फड़फड़ाने वाले लोग कम से कम स्पष्ट थे कि उन्हें हुक पसंद नहीं है। और स्पंदन के पास ओपी में वर्णित समस्या का कोई अन्य समाधान नहीं है। यह भी कैसे लिखा जाना चाहिए।

लगता है (कम से कम मेरे लिए) कि इसे गंभीरता से नहीं लिया गया है, मुझे खेद है @ हिक्सी , मेरा मतलब है कि इसे इस अर्थ में गंभीरता से नहीं लिया गया है: We understand the problem and want to solve it । अन्य घोषणात्मक ढांचे की तरह जाहिरा तौर पर ऐसा लगता है।
एक और लेकिन एक ही तरह की चीजों पर इस तरह की चीजें:

क्या लिखना आसान है?
डेवलपर को हुक लिखना सीखना होगा, जो एक नई अवधारणा है, इतना कठिन

मुझे दुखी करता है। क्यों कभी कुछ सुधारें या बदलें? आप हमेशा वह तर्क दे सकते हैं चाहे कुछ भी हो। भले ही एक बार सीखने के बाद नए समाधान बहुत आसान और सुखद हों। आप उस कथन के हुक को कई चीजों से बदल सकते हैं। मेरी माँ 30 साल पहले माइक्रोवेव के बारे में उस तरह के वाक्य का इस्तेमाल कर सकती थीं। उदाहरण के लिए, यदि आप "हुक" को वाक्य में "स्पंदन" या "डार्ट" से प्रतिस्थापित करते हैं तो यह वही काम करता है।

क्या लिखना आसान है?
यह वही है, इसलिए इसे लिखना भी उतना ही आसान है, जो काफी आसान है

मुझे नहीं लगता कि is it easier to write? (एक बूलियन उत्तर प्रश्न) के साथ @rrousselGit का क्या false / undefined ।

मैं यह नहीं देख सकता कि हम कभी भी कहीं कैसे पहुंच पाएंगे क्योंकि हम इस बात से सहमत भी नहीं हैं कि कोई समस्या है, केवल यह कि बहुत से लोग इसे एक समस्या पाते हैं। जैसे:

यह निश्चित रूप से कुछ लोगों ने उठाया है। यह ऐसा कुछ नहीं है जिसके साथ मुझे आंत का अनुभव है। यह ऐसा कुछ नहीं है जिसे मैंने महसूस किया है कि फ़्लटर के साथ अपने स्वयं के ऐप्स लिखते समय एक समस्या थी। इसका मतलब यह नहीं है कि कुछ लोगों के लिए यह वास्तविक समस्या नहीं है।

और भले ही कई लोगों ने कई बार बहुत सारे तर्क दिए हों कि ओपी के समाधान को मूल में क्यों होना चाहिए।
उदाहरण के लिए, तीसरे पक्ष को इसे उतनी ही आसानी से और स्वाभाविक रूप से उपयोग करने में सक्षम बनाने के लिए इसे मूल में होना चाहिए जितना वे आज उपयोग करते हैं और विजेट बनाते हैं। और कई अन्य कारण। मंत्र लगता है, बस एक पैकेज में डाल दिया। लेकिन हुक के रूप में पहले से ही पैकेज हैं। अगर यह तय हो गया है तो क्यों न सिर्फ धागा बंद करें।

मैं वास्तव में आशा करता हूं कि आप उनके प्रस्ताव पर @rrousselGit को लेंगे और एक कॉल का आयोजन करेंगे, हो सकता है कि हर समय आगे और पीछे सामान लिखने के बजाय इस बारे में रीयलटाइम चर्चा करना आसान हो। यदि अन्य ढांचे के किसी भी व्यक्ति ने ओपी में वर्णित समस्या को हल किया है, यदि उनमें से एक वास्तव में दयालु है तो वे थोड़ी देर के लिए कॉल में भी आ सकते हैं और आने वाले सामान के बारे में 5-सेंट साझा कर सकते हैं। कोई हमेशा पूछ सकता था।

वैसे भी, मैं अब सदस्यता समाप्त कर रहा हूं क्योंकि मैं इस धागे के बाद थोड़ा दुखी हूं क्योंकि मैं इसे कहीं भी नहीं देख रहा हूं। लेकिन मुझे उम्मीद है कि यह धागा सहमत होने की स्थिति में पहुंच जाएगा कि कोई समस्या है ताकि यह ओपी के संभावित समाधानों पर ध्यान केंद्रित कर सके। चूंकि समाधान प्रस्तावित करना थोड़ा व्यर्थ लगता है यदि आप लोगों की समस्या को समझ नहीं पाते हैं, जैसा कि @ हिक्सी शायद सहमत हैं, मेरा मतलब है, क्योंकि समस्या वाले लोग आपको बताएंगे कि समाधान बाद में क्यों काम नहीं करता है।

मैं वास्तव में आपको इस धागे को समाप्त करने के लिए शुभकामनाएं देता हूं या तो केवल सपाट रूप से यह कहकर कि लोगों के चाहने के बावजूद स्पंदन इस समस्या को मूल रूप से हल नहीं करना चाहिए। या समाधान ढूंढ़कर। मैं

अधिकांश बिल्डरों, एफडब्ल्यूआईडब्ल्यू की तुलना में लेआउटबिल्डर एक बहुत अलग विजेट है। अब तक जिन प्रस्तावों पर चर्चा की गई है, उनमें से कोई भी लेआउटबिल्डर जैसी समस्याओं के लिए काम नहीं करेगा, और आपकी टिप्पणी से पहले वर्णित किसी भी आवश्यकता में लेआउटबिल्डर शामिल नहीं है। अगर हमें लेआउटबिल्डर को संभालने के लिए इस नई सुविधा का भी उपयोग करना चाहिए जो जानना महत्वपूर्ण है; मैं यह सुनिश्चित करने के लिए @TimWhiting के साथ काम करने की सलाह देता हूं कि हम जिस नमूना ऐप पर प्रस्तावों को आधार बनाने जा रहे हैं,

@ हिक्सी हां, हमें निश्चित रूप से कुछ नमूने चाहिए। मैं कुछ तैयार करूँगा (लेकिन मुझे अभी भी लगता है कि संकलक परिवर्तनों की आवश्यकता है इसलिए नमूना अधूरा हो सकता है)। सामान्य विचार है - एक वाक्य रचना चीनी जो बिल्डरों को समतल करती है और इस बात की परवाह नहीं करती है कि बिल्डर को कैसे लागू किया जाता है।

फिर भी, मुझे यह आभास हो रहा है कि फ़्लटर टीम में किसी ने भी स्विफ्टयूआई पर गहराई से नज़र नहीं डाली, मुझे लगता है कि हमारी चिंताओं को अन्यथा समझना आसान होगा। ढांचे के भविष्य के लिए यह महत्वपूर्ण है कि अन्य प्लेटफार्मों से पलायन करने वाले लोगों के पास जितना संभव हो उतना आसान सवारी हो, और इसलिए, अन्य प्लेटफार्मों की अच्छी समझ और पेशेवरों और विपक्षों के ज्ञान की आवश्यकता है। और यह देखते हुए कि क्या फ़्लटर के कुछ विपक्षों को ठीक किया जा सकता है। स्पष्ट रूप से स्पंदन ने रिएक्ट से बहुत सारे अच्छे विचार लिए और मैं नए ढांचे के साथ भी ऐसा ही कर सकता था।

@ इमैनुएल-लुंडमैन

लगता है (कम से कम मेरे लिए) कि इसे गंभीरता से नहीं लिया गया है, मुझे खेद है @ हिक्सी , मेरा मतलब है कि इसे इस अर्थ में गंभीरता से नहीं लिया गया है: We understand the problem and want to solve it । अन्य घोषणात्मक ढांचे की तरह जाहिरा तौर पर ऐसा लगता है।

मैं पूरी तरह से सहमत हूं कि मुझे समस्या समझ में नहीं आ रही है। इसलिए मैं इस मुद्दे पर उलझा रहता हूं, इसे समझने की कोशिश करता हूं। यही कारण है कि मैंने एक डेमो ऐप बनाने का सुझाव दिया है जो समस्या को समाहित करता है। क्या यह कुछ ऐसा है जिसे अंत में हम ढांचे को मौलिक रूप से बदलकर, या ढांचे में एक छोटी सी सुविधा जोड़कर, या एक पैकेज द्वारा ठीक करने का निर्णय लेते हैं, या बिल्कुल नहीं, वास्तव में समस्या वास्तव में क्या है इस पर निर्भर करता है।

@szotp

फिर भी, मुझे यह आभास हो रहा है कि फ़्लटर टीम में किसी ने भी स्विफ्टयूआई पर गहराई से नज़र नहीं डाली, मुझे लगता है कि हमारी चिंताओं को अन्यथा समझना आसान होगा।

मैंने स्विफ्ट यूआई का अध्ययन किया है। फ़्लटर कोड की तुलना में स्विफ्ट UI कोड लिखना निश्चित रूप से कम क्रिया है, लेकिन पठनीयता लागत बहुत अधिक IMHO है। बहुत सारे "जादू" हैं (तर्क के अर्थ में, जो उन तरीकों से काम करता है जो उपभोक्ता कोड में स्पष्ट नहीं हैं)। मैं पूरी तरह से विश्वास कर सकता हूं कि यह एक ऐसी शैली है जिसे कुछ लोग पसंद करते हैं, लेकिन मैं यह भी मानता हूं कि Flutter की एक खूबी यह है कि इसमें बहुत कम जादू है। इसका मतलब यह है कि आप कभी-कभी अधिक कोड लिखते हैं, लेकिन इसका मतलब यह भी है कि उस कोड को डिबग करना _much_ आसान है।

मुझे लगता है कि ढांचे की कई शैलियों के लिए जगह है। एमवीसी-स्टाइल, रिएक्ट-स्टाइल, सुपर टर्स जादुई, जादू-मुक्त लेकिन वर्बोज़ ... फ़्लटर की वास्तुकला के फायदों में से एक यह है कि पोर्टेबिलिटी पहलू पूरी तरह से ढांचे से अलग है, इसलिए हमारे सभी टूलिंग का लाभ उठाना संभव है - क्रॉस प्लेटफॉर्म सपोर्ट, हॉट रीलोड, आदि - लेकिन एक पूरी तरह से नया फ्रेमवर्क बनाएं। (अन्य स्पंदन ढांचे हैं, उदाहरण के लिए flutter_sprites, पहले से ही।) इसी तरह ढांचे को एक स्तरित फैशन में डिज़ाइन किया गया है ताकि उदाहरण के लिए आप हमारे सभी रेंडरऑब्जेक्ट तर्क का पुन: उपयोग कर सकें लेकिन विजेट परत के प्रतिस्थापन के साथ, इसलिए यदि वर्बोसिटी की वर्बोसिटी विजेट बहुत अधिक हैं, कोई व्यक्ति वैकल्पिक ढांचा बना सकता है जो इसे बदल देता है। और निश्चित रूप से पैकेजिंग सिस्टम है ताकि किसी भी मौजूदा फ्रेमवर्क कोड को खोए बिना सुविधाओं को जोड़ा जा सके।

वैसे भी, यहाँ मेरे विषयांतर की बात यह है कि यह सब या कुछ नहीं है। भले ही लंबे समय तक हम ऐसा समाधान न अपनाएं जिससे आपको खुशी मिले, इसका मतलब यह नहीं है कि आप पेशकश के उन हिस्सों से लाभ प्राप्त करना जारी नहीं रख सकते जो आपको पसंद हैं।

मैं इस समस्या में रुचि रखने वाले लोगों से एक ऐप बनाने के लिए @TimWhiting के साथ काम करने का आग्रह करता हूं जो दर्शाता है कि आप कोड का पुन: उपयोग क्यों करना चाहते हैं और यह आज कैसा दिखता है जब आप नहीं कर सकते (https://github.com/TimWhiting/local_widget_state_approaches)। यह सीधे तौर पर हमें इस समस्या को हल करने के लिए प्रस्ताव बनाने में मदद करेगा जो कि यहां टिप्पणी करने वाले _all_ की जरूरतों को पूरा करता है (उन लोगों सहित जो हुक पसंद करते हैं और जो हुक पसंद नहीं करते हैं)।

यह समझना वास्तव में इतना कठिन नहीं हो सकता है कि "_a सिंटैक्स चीनी जो बिल्डरों को समतल करती है और इस बात की परवाह नहीं करती है कि बिल्डर को कैसे लागू किया जाता है।_" प्रथम श्रेणी की सुविधा के रूप में देवों द्वारा वांछित है। हमने वैकल्पिक दृष्टिकोणों के साथ मुद्दों को बार-बार रेखांकित किया है।

संक्षेप में, बिल्डर्स पुन: प्रयोज्य मुद्दे को हल करते हैं, लेकिन पढ़ना और लिखना कठिन होता है। "समस्या" बस यह है कि हम बिल्डर जैसी कार्यक्षमता चाहते हैं जो पढ़ने में काफी आसान हो।

कोई भी ऐप अधिक स्पष्ट रूप से नहीं दिखा सकता है, यदि आप मूल रूप से इस बात से सहमत नहीं हैं कि 3 नेस्टेड बिल्डरों को पढ़ना मुश्किल है, या सामान्य रूप से बिल्डर्स वास्तव में कोड-पुन: उपयोग के उद्देश्य की पूर्ति नहीं करते हैं। यह सुनना अधिक महत्वपूर्ण है कि हम में से बहुत से वास्तव में घोंसले में कटौती करना पसंद करते हैं, और वास्तव में हमारे पूरे आवेदन में कोड डुप्लिकेट करना पसंद नहीं करते हैं, और इसलिए हम 2 गैर-आदर्श विकल्पों के बीच फंस गए हैं।

मैंने इस सप्ताह के अंत में अपने स्वयं के समय के सचमुच घंटे बिताए हैं, इससे पहले Google के कई घंटों का उल्लेख नहीं करने के लिए, इस समस्या पर विचार करते हुए, संभावित समाधानों का वर्णन करते हुए, और जो हम हल करने का प्रयास कर रहे हैं उसे ठीक से निकालने का प्रयास कर रहे हैं।

मैं उसके लिए आभारी हूँ

कृपया इस पर विचार करने से इनकार करने में समस्या क्या है, इस पर समझ की कमी को भ्रमित न करें

मैं समझ की कमी से ठीक हूं, लेकिन वर्तमान स्थिति निराशाजनक लगती है।
हम अभी भी उन मुद्दों पर बहस कर रहे हैं जो चर्चा की शुरुआत में किए गए थे।

मेरे दृष्टिकोण से, मुझे ऐसा लगता है कि मैंने विभिन्न समस्याओं को प्रदर्शित करने और सवालों के जवाब देने के लिए विस्तृत टिप्पणियाँ लिखने में घंटों बिताए, लेकिन मेरी टिप्पणियों को खारिज कर दिया गया और फिर से वही सवाल पूछा गया।

उदाहरण के लिए, वर्तमान वाक्य रचना की पठनीयता की कमी चर्चा के केंद्र में है।
मैंने इसे वापस करने के लिए पठनीयता समस्या के कई विश्लेषण किए:

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

यह जानते हुए कि यह पढ़ने योग्य नहीं है

इन दो टिप्पणियों से हम यह निष्कर्ष निकाल सकते हैं कि:

• हम असहमत हैं कि एक पठनीयता मुद्दा है
• यह अभी भी स्पष्ट नहीं है कि पठनीयता इस मुद्दे के दायरे का हिस्सा है या नहीं

यह सुनना निराशाजनक है, हुक के एकमात्र उद्देश्य पर विचार करना बिल्डर्स के सिंटैक्स में सुधार करना है - जो पुन: प्रयोज्य के चरम पर हैं, लेकिन खराब पठनीयता / लेखन क्षमता है
अगर हम इस तरह के बुनियादी तथ्य पर सहमत नहीं हैं, तो मुझे यकीन नहीं है कि हम क्या कर सकते हैं।

@ हिक्सी धन्यवाद, यह आपकी बात को समझने में बहुत मदद करता है। मैं मानता हूं कि वे कोड जादू के साथ ओवरबोर्ड गए होंगे, लेकिन मुझे यकीन है कि कम से कम कुछ चीजें हैं जो उन्हें सही लगीं।

और मुझे फ़्लटर की लेयर्ड आर्किटेक्चर बहुत पसंद है। मैं विगेट्स का उपयोग करना भी जारी रखना चाहूंगा। तो शायद इसका उत्तर सिर्फ डार्ट और स्पंदन की एक्स्टेंसिबिलिटी में सुधार करना है, जो मेरे लिए होगा:

कोड जनरेशन को अधिक सहज बनाएं - डार्ट में स्विफ्टयूआई जादू को लागू करना संभव हो सकता है, लेकिन सामान्य सेटअप की आवश्यकता बहुत बड़ी और बहुत धीमी है।

यदि कोड जनरेशन का उपयोग करना पैकेज आयात करने और कुछ एनोटेशन को थप्पड़ मारने जैसा सरल था, तो जिन लोगों के पास चर्चा की गई समस्या है, वे बस ऐसा करेंगे और शिकायत करना बंद कर देंगे। बाकी अच्छे पुराने StatefulWidgets का सीधे उपयोग करना जारी रखेंगे।

संपादित करें: मुझे लगता है कि flutter generate अच्छी दिशा में एक कदम था, शर्म की बात है कि इसे हटा दिया गया।

मुझे लगता है कि यह अगले स्पंदन डेवलपर सर्वेक्षण में पूछने के लिए एक बहुत ही दिलचस्प सवाल होगा।

यह एक अच्छी शुरुआत होगी। इस समस्या को विभिन्न भागों/प्रश्नों में विभाजित करें और देखें कि क्या यह एक वास्तविक समस्या है जिसे फ़्लटर डेवलपर्स हल करना चाहते हैं।

एक बार यह स्पष्ट हो जाने पर, यह बातचीत अधिक धाराप्रवाह और समृद्ध होगी

मेरे दृष्टिकोण से, मुझे ऐसा लगता है कि मैंने विभिन्न समस्याओं को प्रदर्शित करने और सवालों के जवाब देने के लिए विस्तृत टिप्पणियाँ लिखने में घंटों बिताए, लेकिन मेरी टिप्पणियों को खारिज कर दिया गया और फिर से वही सवाल पूछा गया।

अगर मैं वही सवाल पूछ रहा हूं तो ऐसा इसलिए है क्योंकि मुझे जवाब समझ में नहीं आ रहे हैं।

उदाहरण के लिए, अपनी पिछली टिप्पणी पर वापस जाना (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 का पुनर्निर्माण कर रहे हैं, भले ही सामान्य रूप से उन्हें ट्रिगर नहीं किया जाएगा ; इनिशियलाइज़र लॉजिक को भी अब दर्ज करना होगा और हर बिल्ड को छोड़ना होगा।)

आपने कहा है कि वर्बोजिटी मुद्दा नहीं है, इसलिए यह अधिक संक्षिप्त होने के कारण यह अधिक पठनीय नहीं है, मुझे लगता है (हालांकि मैं इसके बारे में भी भ्रमित हूं क्योंकि आपने इस मुद्दे के शीर्षक में "बहुत वर्बोज़" डाला है और इसमें मुद्दे का मूल विवरण)। आपने कम इंडेंटिंग चाहने का उल्लेख किया है, लेकिन आपने बिना इंडेंट किए बिना बिल्डरों का उपयोग करने के संस्करण को अपठनीय के रूप में वर्णित किया है, इसलिए संभवतः यह मूल में इंडेंटिंग नहीं है जो समस्या है।

आप कहते हैं कि बिल्डर्स पुन: प्रयोज्य के शिखर हैं और आप केवल एक वैकल्पिक सिंटैक्स चाहते हैं, लेकिन आपके द्वारा सुझाए गए प्रस्ताव बिल्डरों की तरह कुछ भी नहीं हैं (वे विजेट या तत्व नहीं बनाते हैं), इसलिए यह विशेष रूप से बिल्डर पहलू नहीं है कि आप की तलाश में।

आपके पास एक समाधान है जो आपको पसंद है (हुक), जहां तक ​​​​मैं कह सकता हूं कि यह बहुत अच्छा काम करता है, लेकिन आप ढांचे में कुछ बदलना चाहते हैं ताकि लोग हुक का उपयोग कर सकें? जो मुझे समझ में नहीं आता है, क्योंकि अगर लोग हुक को पैकेज के रूप में उपयोग करने के लिए पर्याप्त पसंद नहीं करते हैं, तो शायद यह ढांचे के लिए एक अच्छा समाधान नहीं है (सामान्य तौर पर, हम पैकेज का उपयोग करने की दिशा में और आगे बढ़ रहे हैं, यहां तक ​​​​कि सुविधाएं भी फ़्लटर टीम बनाता है, इसके लायक क्या है)।

मैं समझता हूं कि आसान कोड पुन: उपयोग की इच्छा है। मुझे नहीं पता कि इसका क्या मतलब है।

निम्नलिखित दो संस्करणों की पठनीयता में तुलना कैसे करता है?

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 यदि हमारे वर्तमान कोडजन समाधान के आसपास बहुत अधिक घर्षण है, तो कृपया वहां सुधार के लिए बग फाइल करने में संकोच न करें।

@jamesblasco मुझे नहीं लगता कि इसमें कोई संदेह है कि यहां एक वास्तविक समस्या है जिसे लोग हल करना चाहते हैं। मेरे लिए प्रश्न वास्तव में वह समस्या क्या है, ताकि हम समाधान तैयार कर सकें।

मैं हुक की खामियों या कोड में शामिल किए जाने की इच्छा के बारे में चिंताओं का जवाब दे सकता था, लेकिन मुझे नहीं लगता कि हमें अभी इस पर ध्यान देना चाहिए।

हमें पहले इस बात पर सहमत होना चाहिए कि समस्या क्या है। यदि हम नहीं करते हैं, तो मुझे नहीं लगता कि हम अन्य विषयों पर कैसे सहमत हो सकते हैं।

मैं वास्तव में नहीं देखता कि इसके बारे में क्या पठनीय नहीं है। यह वास्तव में बताता है कि क्या हो रहा है। चार विजेट हैं, तीन विजेट में बिल्डर विधियां हैं, एक में बस एक स्ट्रिंग है। मैं व्यक्तिगत रूप से प्रकारों को नहीं छोड़ूंगा, मुझे लगता है कि इसे पढ़ना कठिन हो जाता है क्योंकि मैं यह नहीं बता सकता कि सभी चर क्या हैं, लेकिन यह एक बड़ी समस्या नहीं है।

मुझे लगता है कि यहां इस मुद्दे का एक बड़ा हिस्सा यह है कि जिस तरह से आप कोड करते हैं वह ज्यादातर लोगों के कोड से काफी अलग है।

उदाहरण के लिए, स्पंदन और ऐप उदाहरण आपने दोनों को दिया:

• dartfmt का प्रयोग न करें
• हमेशा_निर्दिष्ट_प्रकार का उपयोग करें

केवल इन दो बिंदुओं के साथ, मुझे आश्चर्य होगा यदि यह समुदाय के 1% से अधिक का प्रतिनिधित्व करता है।

जैसे कि आप जो पठनीय के रूप में मूल्यांकन करते हैं, वह संभवतः उस चीज़ से बहुत भिन्न होता है जिसे अधिकांश लोग पठनीय समझते हैं।

मैं वास्तव में नहीं देखता कि इसके बारे में क्या पठनीय नहीं है। यह वास्तव में बताता है कि क्या हो रहा है। चार विजेट हैं, तीन विजेट में बिल्डर विधियां हैं, एक में बस एक स्ट्रिंग है। मैं व्यक्तिगत रूप से प्रकारों को नहीं छोड़ूंगा, मुझे लगता है कि इसे पढ़ना कठिन हो जाता है क्योंकि मैं यह नहीं बता सकता कि सभी चर क्या हैं, लेकिन यह एक बड़ी समस्या नहीं है।

यह अपठनीय क्यों है?

मेरी सिफारिश यह विश्लेषण करने की होगी कि किसी विशिष्ट चीज़ की खोज करते समय आपकी आंख कहां देख रही है, और वहां पहुंचने के लिए कितने कदम उठाए जाते हैं।

आइए एक प्रयोग करें:
मैं तुम्हें दो विजेट ट्री दूंगा। एक रैखिक सिंटैक्स का उपयोग करता है, दूसरा एक नेस्टेड सिंटैक्स वाला।
मैं आपको उस स्निपेट में देखने के लिए आवश्यक विशिष्ट चीजें भी दूंगा।

क्या रैखिक सिंटैक्स या नेस्टेड सिंटैक्स का उपयोग करने का उत्तर खोजना आसान है?

सवालों के जवाब:

• इस निर्माण विधि द्वारा लौटाया गया गैर-बिल्डर विजेट क्या है?
• चर bar कौन बनाता है?
• हमारे पास कितने बिल्डर हैं?

बिल्डरों का उपयोग करना:

 विजेट निर्माण (संदर्भ) {
 वापसी ValueListenableBuilder(
 valueListenable: someValueListenable,
 निर्माता: (संदर्भ, फू, _) {
 रिटर्न स्ट्रीमबिल्डर(
 स्ट्रीम: कुछ स्ट्रीम,
 बिल्डर: (संदर्भ, बाज) {
 वापसी ट्वीनएनीमेशनबिल्डर(
 बीच: बीच (...),
 निर्माता: (संदर्भ, बार) {
 वापसी कंटेनर ();
 },
 );
 },
 );
 },
 );
 }

 विजेट निर्माण (संदर्भ) {
 अंतिम फू = कीवर्ड ValueListenableBuilder (valueListenable: someValueListenable);
 अंतिम बार = कीवर्ड स्ट्रीमबिल्डर (स्ट्रीम: कुछस्ट्रीम);
 अंतिम बाज़ = कीवर्ड ट्वीनएनीमेशनबिल्डर (ट्वीन: ट्वीन (...));

 वापसी छवि ();
 }

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/प्रतीक्षा वहाँ एक विजेता है।

मेरी सिफारिश यह विश्लेषण करने की होगी कि किसी विशिष्ट चीज़ की खोज करते समय आपकी आंख कहां देख रही है, और वहां पहुंचने के लिए कितने कदम उठाए जाते हैं।

मैं 25 वर्षों से 10 से अधिक विभिन्न भाषाओं में प्रोग्रामिंग कर रहा हूं और कोड को पठनीय बनाने के मूल्यांकन के लिए यह आसानी से सबसे खराब तरीका है। स्रोत कोड की पठनीयता मुश्किल है, लेकिन यह "जहां मेरी आंखें देख रही हैं" या कोड की कितनी पंक्तियों का उपयोग करता है, इसके बजाय यह प्रोग्रामिंग अवधारणाओं और तर्क को कितनी अच्छी तरह व्यक्त करता है।

या यों कहें, मुझे ऐसा लगता है कि आप लोग पठनीयता पर बहुत अधिक ध्यान केंद्रित कर रहे हैं और रखरखाव पर कम।

आपके उदाहरण कम पठनीय हैं, क्योंकि कोड का __इरादा__ कम स्पष्ट है और विभिन्न चिंताओं को एक ही स्थान पर छिपाए जाने से इसे बनाए रखना कठिन हो जाता है।

final value = keyword ValueListenableBuilder(valueListenable: someValueListenable);

मूल्य भी क्या होगा? एक विजेट? एक स्ट्रिंग चर? मेरा मतलब है कि इसका उपयोग a . के अंदर किया जाता है
return Text('$value $value2 $value3');

मूल रूप से आप जो चाहते हैं वह यह है कि विजेट बी की निर्माण विधि में चर ए को संदर्भित करके, जब भी ए का मान बदलता है तो बी को पुनर्निर्माण करना चाहिए? यही वास्तव में mobx करता है, और यह ठीक सही मात्रा में जादू/बॉयलरप्लेट के साथ करता है।

final value2 = keyword StreamBuilder(stream: someStream);

यह क्या लौटना चाहिए? एक विजेट? एक धारा? एक स्ट्रिंग मान?

फिर से, यह एक स्ट्रिंग मान की तरह दिखता है। तो आप केवल एक बिल्ड विधि में एक स्ट्रीम को संदर्भित करने में सक्षम होना चाहते हैं, जब भी स्ट्रीम एक मान उत्सर्जित करता है तो उस विजेट को पुनर्निर्माण करने का कारण बनता है और उत्सर्जित मूल्य तक पहुंच प्राप्त करता है और जब भी विजेट बनाया/अपडेट किया जाता है तो स्ट्रीम का निर्माण/अपडेट/निपटान /नष्ट किया हुआ? कोड की एक ही पंक्ति में? निर्माण विधि के अंदर?

हां, मोबक्स के साथ आप अपनी निर्माण विधियों को अपने "अधिक पठनीय" उदाहरण की तरह दिख सकते हैं (आप संदर्भ अवलोकनों को छोड़कर)। आपको अभी भी वास्तविक कोड लिखना है जो सभी काम करता है, जैसे आप हुक के साथ करते हैं। वास्तविक कोड लगभग 10 पंक्तियों का है, और यह किसी भी विजेट में पुन: प्रयोज्य है।

final value3 = keyword TweenAnimationBuilder(tween: Tween(...));

"ट्वीनएनीमेशनबिल्डर" नामक एक वर्ग एक स्ट्रिंग लौटा रहा है ?! मैं पास भी नहीं जा रहा हूं कि यह एक भयानक विचार क्यों है।

इंडेंट/पठनीयता में कोई अंतर नहीं है:

Future<double> future;

AsyncSnapshot<double> value = keyword FutureBuilder<double>(future: future);

तथा:

Future<double> future;

double value = await 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);

कोई कह सकता है कि लिखने का पहला तरीका यह स्पष्ट करता है कि वादे हुड के तहत बनाए जा रहे हैं, और वास्तव में श्रृंखला कैसे बनती है। मुझे आश्चर्य है कि क्या आप इसकी सदस्यता लेते हैं, या यदि आप वादों को बिल्डर्स से मौलिक रूप से अलग मानते हैं, तो वे एक वाक्य रचना के लायक हैं।

"ट्वीनएनीमेशनबिल्डर" नामक एक वर्ग एक स्ट्रिंग लौटा रहा है ?! मैं पास भी नहीं जा रहा हूं कि यह एक भयानक विचार क्यों है।

आप वादे/वायदा के बारे में एक ही तर्क दे सकते हैं, और कह सकते हैं कि await इस तथ्य को अस्पष्ट करता है कि यह एक वादा देता है।

मुझे ध्यान रखना चाहिए कि वाक्य रचना के माध्यम से चीजों को "अलिखित" करने का विचार शायद ही नया हो। हां, मुख्यधारा की भाषाओं में यह एसिंक/प्रतीक्षा के माध्यम से आया था, लेकिन, उदाहरण के लिए, एफ # में कुछ कट्टर एफपी भाषाओं में do नोटेशन के समान कम्प्यूटेशनल अभिव्यक्तियां हैं। वहां, इसमें बहुत अधिक शक्ति है और कुछ कानूनों को पूरा करने वाले किसी भी रैपर के साथ काम करने के लिए सामान्यीकृत है। मैं डार्ट में मोनाड्स को जोड़ने का सुझाव नहीं दे रहा हूं, लेकिन मुझे लगता है कि यह लाने लायक है कि "अनरैपिंग" चीजों के लिए टाइप-सेफ सिंटैक्स के लिए निश्चित रूप से मिसाल है जो जरूरी नहीं कि एसिंक्रोनस कॉल के अनुरूप हो।

एक कदम पीछे हटते हुए, मुझे लगता है कि एक बात यहाँ बहुत से लोग (स्वयं शामिल) से जूझ रहे हैं, यह पठनीयता के बारे में सवाल है। जैसा कि @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. पहला कोड ब्लॉक नेस्टिंग के सबसे गहरे हिस्से में build पद्धति के सबसे महत्वपूर्ण भाग को छुपाता है

मैं मानता हूं कि इस build पद्धति के सभी भाग महत्वपूर्ण हैं, लेकिन मैंने पाया है कि जब मैं घोषणात्मक यूआई कोड की इस शैली को पढ़ रहा हूं, तो मैं आमतौर पर जिस चीज की तलाश कर रहा हूं वह वह है जो प्रदर्शित होती है उपयोगकर्ता, जो इस मामले में सबसे गहरे नेस्टेड बिल्डर में एम्बेडेड Text विजेट है। सामने और केंद्र होने के बजाय, उस Text विजेट को इंडेंटेशन, सिंटैक्स और इंटेंट की कई परतों में दफनाया गया है। यदि आप इनमें से किसी एक परत में Column या Row फेंकते हैं तो यह और भी गहरा घोंसला बन जाता है, और उस बिंदु पर आपको केवल सबसे इंडेंटेड सेक्शन को ट्रेस करने का लाभ नहीं होता है .

दूसरे कोड ब्लॉक में, वास्तविक रेंडर-सक्षम Widget लौटाया जा रहा है, जो फ़ंक्शन के निचले भाग में है, जो तुरंत स्पष्ट है। इसके अलावा, मैंने पाया है कि जब आपके पास प्रस्तावित सिंटैक्स ओपी जैसा कुछ होता है, तो आप दृश्य Widget हमेशा फ़ंक्शन के निचले भाग पर भरोसा कर सकते हैं, जो कोड को अधिक अनुमानित और पढ़ने में आसान बनाता है।

नेस्टिंग के संबंध में, _tree_ को व्यक्त करने वाले नेस्टिंग और _sequence_ को व्यक्त करने वाले नेस्टिंग के बीच अंतर है।

सामान्य View -> Text घोंसले के शिकार के मामले में और इस तरह, घोंसला बनाना महत्वपूर्ण है क्योंकि यह स्क्रीन पर माता-पिता के संबंधों का प्रतिनिधित्व

हालांकि, बिल्डर्स के नेस्टिंग (रिएक्ट में उर्फ ​​"रेंडर प्रॉप्स") या वादों के नेस्टिंग के साथ, नेस्टिंग को परिवर्तनों / संवर्द्धन के अनुक्रम को संप्रेषित करना माना जाता है। पेड़ स्वयं उतना महत्वपूर्ण नहीं है - उदाहरण के लिए, स्वतंत्र ABuilder -> BBuilder -> CBuilder घोंसला बनाते समय, उनके माता-पिता के रिश्ते अतिरिक्त अर्थ व्यक्त नहीं करते हैं।

जब तक तीनों मान नीचे के दायरे में उपलब्ध हैं, तब तक उनकी वृक्ष संरचना वास्तव में प्रासंगिक नहीं है। यह अवधारणात्मक रूप से "फ्लैट" है, और नेस्टिंग सिंटैक्स का केवल एक आर्टिफैक्ट है। बेशक, वे एक-दूसरे के मूल्यों का उपयोग कर सकते हैं (जिस स्थिति में उनका ऑर्डर मायने रखता है), लेकिन अनुक्रमिक फ़ंक्शन कॉल के मामले में भी यही स्थिति है, और यह बिना किसी नेस्टिंग के किया जा सकता है।

यही कारण है कि async/await सम्मोहक है। यह अतिरिक्त जानकारी (वादों के माता-पिता-बाल संबंध) को हटा देता है जो निम्न-स्तरीय तंत्र का वर्णन करता है, और इसके बजाय आपको उच्च-स्तरीय इरादे (एक अनुक्रम का वर्णन) पर ध्यान केंद्रित करने देता है।

एक पेड़ एक सूची की तुलना में अधिक लचीली संरचना है। लेकिन जब प्रत्येक माता-पिता के पास केवल एक बच्चा होता है, तो यह एक रोग-संबंधी वृक्ष बन जाता है - अनिवार्य रूप से, एक सूची। Async/Await और Hooks पहचानते हैं कि हम किसी ऐसी चीज़ पर सिंटैक्स बर्बाद कर रहे हैं जो जानकारी नहीं देती है, और इसे हटा दें।

यह वास्तव में दिलचस्प है क्योंकि मैंने पहले कहा था "यह बॉयलरप्लेट के बारे में नहीं है" और अब ऐसा लगता है कि मैं खुद का खंडन कर रहा हूं। मुझे लगता है कि यहां दो चीजें हैं।

अपने आप से, बिल्डर्स (या कम से कम प्रॉप्स प्रस्तुत प्रतिक्रिया में) समाधान (AFAIK) "पुन: प्रयोज्य तर्क" समस्या के लिए कर रहे हैं। यह सिर्फ इतना है कि यदि आप उनमें से बहुत से उपयोग करते हैं तो वे बहुत एर्गोनोमिक नहीं हैं। आप स्वाभाविक रूप से एक ही घटक में उनमें से 4 या 5 से अधिक का उपयोग करने के लिए इंडेंटेशन से हतोत्साहित होते हैं। प्रत्येक अगला स्तर एक पठनीयता हिट है।

तो जो हिस्सा मुझे अनसुलझा लगता है, वह नेस्टिंग की पाठक लागत को कम कर रहा है। और वह तर्क ठीक वैसा ही तर्क है जैसा कि async / await ।

यह निम्नलिखित कारणों से पढ़ने योग्य नहीं है:

• व्हाइटस्पेस का अत्यधिक उपयोग अच्छी तरह से स्केल नहीं करता है। हमारे मॉनिटर पर केवल इतनी ही लाइनें हैं, और जबरन स्क्रॉल करने से पठनीयता कम हो जाती है और सकारात्मक भार बढ़ जाता है। कल्पना कीजिए कि हमारे पास पहले से ही 60 लाइन विजेट पेड़ है, और आपने बिल्डरों के लिए मुझ पर अतिरिक्त 15 को मजबूर किया, आदर्श नहीं।
• यह Hz स्पेस को बर्बाद करता है, जिसे हम अतिरिक्त रैपिंग तक सीमित कर देते हैं, जो लाइन स्पेस को और बर्बाद कर देता है।
• यह लीफ नोड, उर्फ ​​​​सामग्री, बाईं ओर से आगे और उस पेड़ में धकेलता है जहां एक नज़र से देखना मुश्किल है
• एक नज़र में 'प्रमुख खिलाड़ियों' या 'गैर बॉयलरप्लेट' की पहचान करना काफी कठिन है। मेरे तर्क शुरू होने से पहले मुझे "महत्वपूर्ण सामान ढूंढना" है।

इसे देखने का एक और तरीका यह है कि गैर-बॉयलरप्लेट कोड को केवल हाइलाइट किया जाए, और क्या यह आपकी आंख के लिए आसानी से दावत देने के लिए एक साथ समूहीकृत किया गया है, या आपकी आंख को चारों ओर स्कैन करने के लिए हर जगह बिखरा हुआ है:

हाइलाइटिंग के साथ इसके बारे में तर्क करना बहुत आसान है। इसके बिना, मुझे यह पता लगाने से पहले कि कौन क्या और कहां उपयोग कर रहा है, मुझे वर्बोसिटी के पूरे हिस्से को पढ़ने की जरूरत है:

अब इसकी तुलना करें, हाइलाइटिंग मूल रूप से बेमानी है, क्योंकि मेरी आंखों के जाने के लिए और कहीं नहीं है:

ध्यान देने योग्य बात यह है कि पठनीयता बनाम ग्रोकेबिलिटी में शायद असहमति है। @ हिक्सी संभवतः अपना समय अखंड वर्ग की फाइलों में बिताता है, जहां उसे लगातार बड़े पेड़ों को पढ़ना और समझना चाहिए, जबकि आपका विशिष्ट ऐप डेवलपर सैकड़ों छोटे वर्गों के निर्माण के बारे में अधिक है, और जब आप कई छोटे वर्गों का प्रबंधन कर रहे हैं तो ग्रोक-क्षमता महत्वपूर्ण है . यह इतना नहीं है कि जब आप इसे धीमा करते हैं और इसे पढ़ते हैं तो कोड पठनीय होता है, लेकिन क्या मैं यह बता सकता हूं कि यह एक नज़र में क्या कर रहा है, इसलिए मैं इसमें कूद सकता हूं और कुछ बदल सकता हूं या ठीक कर सकता हूं।

संदर्भ के लिए, प्रतिक्रिया में संदर्भ के समतुल्य इनहेरिटिडविजेट्स/प्रदाता है

उनके बीच एकमात्र अंतर है, हुक से पहले प्रतिक्रिया में हम _had_ एक संदर्भ/विरासत विजेट का उपभोग करने के लिए बिल्डर पैटर्न का उपयोग करने के लिए

जबकि फ़्लटर के पास एक साधारण फ़ंक्शन कॉल के साथ पुनर्निर्माण को बाध्य करने का एक तरीका है।
इसलिए इनहेरिटेडविजेट्स का उपयोग करके पेड़ों को समतल करने के लिए हुक की कोई आवश्यकता नहीं है - बिल्डर्स की समस्या के आसपास किस तरह का काम करता है

शायद यही एक कारण है कि चर्चा कठिन क्यों है, क्योंकि हमें कम बार बिल्डर्स की आवश्यकता होती है।

लेकिन यह ध्यान देने योग्य है कि एक हुक जैसा समाधान शुरू करने से दोनों https://github.com/flutter/flutter/issues/30062 हल हो जाएंगे
और https://github.com/flutter/flutter/issues/12992

ऐसा भी प्रतीत होता है कि @Hixie गहरे घोंसले वाले पेड़ों को पढ़ने के लिए अधिक फ़्लटर मूल रूप से सभी पेड़ हैं, मेरी राय में अन्य भाषाओं की तुलना में बहुत अधिक है। फ़्लटर पर मुख्य डेवलपर्स में से एक के रूप में, निश्चित रूप से, उसके पास इसके साथ बहुत अधिक अनुभव होगा। स्पंदन अनिवार्य रूप से बाएं से दाएं ढांचे के रूप में सोचा जा सकता है, गहरे घोंसले के साथ, एचटीएमएल की तरह, जो मुझे लगता है कि @ हिक्सी को एचटीएमएल 5 स्पेक बनाने का अनुभव है। यह कहने के लिए, कोड ब्लॉक का सबसे दाहिना बिंदु वह है जहां मुख्य तर्क और वापसी मूल्य रहता है।

हालांकि, अधिकांश डेवलपर्स नहीं हैं, या अधिक ऊपर से नीचे की भाषाओं में आते हैं, जहां तर्क, फिर से, नेस्टेड पेड़ों के बजाय ऊपर से नीचे तक पढ़ा जाता है; यह कोड ब्लॉक के सबसे निचले बिंदु पर है। इसलिए, जो उसके लिए पठनीय है, जरूरी नहीं कि वह कई अन्य देवों के साथ हो, यही वजह है कि आप यहां पठनीयता पर राय के द्विभाजन को देखते हैं।

इसे देखने का एक और तरीका यह है कि मेरे दिमाग को नेत्रहीन रूप से फिर से काम करने के लिए कितना कोड चाहिए। मेरे लिए यह सटीक रूप से "ग्रंट वर्क" का प्रतिनिधित्व करता है, इससे पहले कि मैं पेड़ से लौटाया जा रहा हूं, उसे पार्स करने से पहले मेरे दिमाग को क्या करना चाहिए:

सीधे शब्दों में कहें, तो बिल्डर संस्करण में 4x लंबा ऊर्ध्वाधर पदचिह्न है, जबकि शाब्दिक रूप से कोई अतिरिक्त जानकारी या संदर्भ नहीं है, और कोड को कहीं अधिक विरल/बिखरे हुए तरीके से पैक करता है। मेरे दिमाग में, यह एक खुला और बंद मामला है, यह केवल उस कारण से निष्पक्ष रूप से कम पठनीय है, और वह इंडेंटेशन के आसपास अतिरिक्त संज्ञानात्मक भार पर भी विचार नहीं कर रहा है और घुंघराले ब्रेसिज़ को अस्तर कर रहा है जिसे हम सभी ने स्पंदन में निपटाया है।

मेरी आंख को एक भूखे सीपीयू के रूप में सोचें, जो प्रसंस्करण के लिए अधिक अनुकूलित है? :)

सामान्य View -> Text घोंसले के शिकार के मामले में और इस तरह, घोंसला बनाना महत्वपूर्ण है क्योंकि यह स्क्रीन पर _माता-पिता के रिश्ते_ का प्रतिनिधित्व करता है। संदर्भ जैसी सुविधाओं के लिए (सुनिश्चित नहीं है कि स्पंदन के पास है), यह संदर्भों के दायरे का प्रतिनिधित्व करता है। तो घोंसले के शिकार का उन मामलों में महत्वपूर्ण अर्थ अर्थ होता है और इसकी अवहेलना नहीं की जा सकती है। आप केवल माता-पिता और बच्चे के स्थानों की अदला-बदली नहीं कर सकते हैं और परिणाम समान होने की उम्मीद कर सकते हैं।

पूरी तरह से सहमत हूं और मैंने पहले इसका उल्लेख किया था। अर्थपूर्ण रूप से यह एक दृश्य प्रदर्शन पेड़ में अतिरिक्त संदर्भ परत बनाने के लिए शून्य समझ में आता है, क्योंकि मैं अतिरिक्त गैर-दृश्य नियंत्रकों का उपयोग कर रहा हूं जिनके पास राज्य है। ५ एनिमेटरों का उपयोग करते हुए, अब आपका विजेट ५ परतों में गहरा है? बस उस उच्च स्तर पर ही वर्तमान दृष्टिकोण थोड़े से बदबू आ रही है।

यहाँ दो मुद्दे मुझ पर कूद रहे हैं।

1. मुझे संदेह है कि कुछ महंगे संसाधनों का उपयोग करते समय यह कितना कठिन/स्पष्ट होना चाहिए, इस पर कुछ असहमति है। स्पंदन का दर्शन यह है कि वे इसे और अधिक कठिन/स्पष्ट होना चाहिए ताकि डेवलपर गंभीरता से सोचें कि उनका उपयोग कब और कैसे किया जाए। स्ट्रीम, एनिमेशन, लेआउट निर्माता, आदि गैर-तुच्छ लागतों का प्रतिनिधित्व करते हैं जिनका उपयोग अक्षम रूप से किया जा सकता है यदि वे बहुत आसान हैं।

2. बिल्ड सिंक है, लेकिन एक ऐप डेवलपर के रूप में आप जिन दिलचस्प चीजों से निपटते हैं, वे async हैं। बेशक हम बिल्ड एसिंक्स नहीं बना सकते। हमने स्ट्रीम/एनीमेशन/फ्यूचरबिल्डर जैसी इन उपयुक्तताओं को बनाया है लेकिन डेवलपर की आवश्यकता के लिए वे हमेशा पर्याप्त रूप से काम नहीं करते हैं। यह शायद बता रहा है कि हम ढांचे में स्ट्रीम या फ्यूचरबिल्डर का ज्यादा उपयोग नहीं करते हैं।

मुझे नहीं लगता कि समाधान यह है कि डेवलपर्स को हमेशा एसिंक्स ऑपरेशंस के साथ काम करते समय कस्टम रेंडर ऑब्जेक्ट्स लिखने के लिए कहें। लेकिन जिन उदाहरणों में मैं इस बग में देख रहा हूं, उनमें एसिंक्स और सिंक वर्क के मिश्रण हैं जिनका हम अभी इंतजार नहीं कर सकते हैं। बिल्ड को हर कॉल पर कुछ न कुछ बनाना होता है।

fwiw, रिएक्ट टीम ने पठनीयता के मुद्दे को 1 प्रेरणा के रूप में फिर से उपयोग करने के लिए संबोधित किया:
हुक प्रेरणा: घटकों के बीच स्टेटफुल लॉजिक का पुन: उपयोग करना कठिन है
प्रतिक्रिया एक घटक के लिए पुन: प्रयोज्य व्यवहार को "संलग्न" करने का एक तरीका प्रदान नहीं करता है ... आप पैटर्न से परिचित हो सकते हैं ... जो इसे हल करने का प्रयास करते हैं। लेकिन इन पैटर्नों के लिए आपको अपने घटकों का उपयोग करते समय उन्हें पुनर्गठित करने की आवश्यकता होती है, जो बोझिल हो सकता है और कोड का पालन करना कठिन बना सकता है ।

यह बहुत कुछ वैसा ही है जैसा कि फ़्लटर वर्तमान में हमें मूल रूप से 'राज्य की रचना' करने का कोई तरीका नहीं देता है। यह भी प्रतिध्वनित होता है कि जब हम बिल्डर होते हैं, जो हमारे लेआउट ट्री को संशोधित कर रहा है और इसके साथ काम करने के लिए अधिक बोझिल बना रहा है, और "अनुसरण करना कठिन", पेड़ ने कहा।

@dnfield अगर build को हर बार कॉल किया जाना चाहिए, तो शायद हम हुक को build विधि में नहीं बना सकते हैं ताकि बिल्ड हमेशा सिंक हो, यानी उन्हें उस वर्ग के अंदर रखें जहां initState और dispose हैं। क्या हुक लिखने वालों से ऐसा करने में कोई समस्या है?

आप वादे/वायदा के बारे में एक ही तर्क दे सकते हैं, और कह सकते हैं कि await इस तथ्य को अस्पष्ट करता है कि यह एक वादा देता है।

नहीं तुम नहीं। प्रतीक्षा वस्तुतः एक ही विशेषता के लिए वाक्यात्मक चीनी है। जिस मौसम में आप वर्बोज़ फ्यूचर्स, या डिक्लेरेटिव सिंटैक्स का उपयोग करते हैं, कोड का __intent__ समान होता है।

यहां मांगें हैं स्रोत कोड को स्थानांतरित करना जो एक ही छतरी के नीचे पूरी तरह से अलग-अलग चिंताओं से संबंधित है, एक ही कीवर्ड के पीछे सभी प्रकार के विभिन्न व्यवहारों को छुपाता है और दावा करता है कि किसी तरह यह संज्ञानात्मक भार को कम करता है।

यह पूरी तरह से झूठ है, क्योंकि अब हर बार जब मैं उस कीवर्ड का उपयोग करता हूं तो मुझे इस बारे में आश्चर्य करने की आवश्यकता होती है कि क्या परिणाम कोई भी अतुल्यकालिक ऑपरेशन करेगा, अनावश्यक पुनर्निर्माण को ट्रिगर करेगा, लंबे समय तक रहने वाली वस्तुओं को शुरू करेगा, नेटवर्क कॉल करेगा, डिस्क से फाइलें पढ़ेगा या एक स्थिर मूल्य लौटाएगा . ये सभी बहुत अलग स्थितियां हैं और मुझे उस हुक के स्वाद से परिचित होना होगा जिसका मैं उपयोग कर रहा हूं।

मैं इस चर्चा से समझता हूं कि यहां अधिकांश डेवलपर्स इस प्रकार के विवरणों से परेशान होना पसंद नहीं करते हैं और आसान विकास चाहते हैं, केवल कार्यान्वयन विवरण के बारे में चिंता किए बिना इन "हुक" का उपयोग करने में सक्षम होने के कारण।
इस तथाकथित "हुक" का उपयोग पूरी तरह से समझने के बिना उनके पूर्ण निहितार्थ को समझने के बिना अक्षम और खराब कोड हो जाएगा, और लोगों को पैर में खुद को गोली मारने का कारण बन जाएगा - इसलिए यह "शुरुआती डेवलपर्स की सुरक्षा" के मुद्दे को भी हल नहीं करता है।

यदि आपके उपयोग के मामले सरल हैं तो हाँ, आप हुक विली-निली का उपयोग कर सकते हैं। आप अपनी इच्छानुसार बिल्डरों का उपयोग कर सकते हैं और घोंसला बना सकते हैं, लेकिन जैसे-जैसे आपका ऐप जटिल हो जाता है कि आपको कोड का पुन: उपयोग करने में कठिनाई होती है, मुझे लगता है कि अपने कोड और आर्किटेक्चर पर अधिक ध्यान देना जरूरी है। अगर मैं संभावित रूप से लाखों उपयोगकर्ताओं के लिए एक ऐप बना रहा था तो मुझे "जादू" का उपयोग करने में बहुत संकोच होगा जो मुझसे महत्वपूर्ण विवरण दूर करता है। अभी मुझे लगता है कि फ़्लटर का एपीआई बहुत ही सरल उपयोग के मामलों के लिए सरल होना सही है, और अभी भी लचीला है जो किसी को भी किसी भी तरह के जटिल तर्क को बहुत ही कुशल तरीके से लागू करने की अनुमति देता है।

@Rudiksz फिर से, कोई भी आपको हुक करने के लिए मजबूर नहीं कर रहा है। वर्तमान शैली अभी भी रहेगी। इस ज्ञान के सामने आपका क्या तर्क है?

और वैसे भी, लोग तब भी कुशल कोड लिख सकते हैं जब वे देखते हैं कि कई हुक किसी तरह उनके ऐप को अवरुद्ध कर रहे हैं; वे इसे तब देखेंगे जब वे प्रोफ़ाइल करेंगे या यहां तक ​​कि केवल ऐप चलाएंगे, जितना आप वर्तमान शैली के साथ करेंगे।

@Rudiksz फिर से, कोई भी आपको हुक करने के लिए मजबूर नहीं कर रहा है। वर्तमान शैली अभी भी रहेगी। इस ज्ञान के सामने आपका क्या तर्क है?

ओह प्रिय, यही तर्क उन लोगों पर भी लागू होता है जो ढांचे के साथ मुद्दों के बारे में शिकायत करते हैं। कोई भी उन्हें हुक पैकेज का उपयोग न करने के लिए मजबूर नहीं कर रहा है।

मैं यहाँ बहुत कुंद होने जा रहा हूँ।
यह मुद्दा वास्तव में हुक, स्टेटफुलविजेट और कौन क्या उपयोग करता है, के बारे में नहीं है, बल्कि कुछ लोगों के लिए कोड की 5 पंक्तियों को कम लिखने में सक्षम होने के लिए दशकों की सर्वोत्तम प्रथाओं को वापस करने के बारे में है।

आपका तर्क वास्तव में काम नहीं करता है। इस समस्या को बनाने का कारण यह था कि flutter_hooks पैकेज वह सब कुछ नहीं करता है जो ढांचे में कुछ होने के साथ संभव हो सकता है, जबकि वर्तमान मॉडल पहले से ही ढांचे में होने के आधार पर है। तर्क यह है कि फ़्लटर_हुक की सुविधाओं को मूल रूप से ढांचे में स्थानांतरित करना है। आपका तर्क बताता है कि मैं वर्तमान मॉडल के साथ जो कुछ भी कर सकता हूं, मैं हुक पैकेज के साथ भी कर सकता हूं, जो कि असत्य है, यह इस चर्चा में दूसरों की तरह लगता है। यदि वे सत्य थे, तो यह काम करेगा, जिसका अर्थ यह भी होगा कि हुक मूल रूप से ढांचे में थे, और इसलिए, फिर से, चूंकि हुक और गैर-हुक समकक्ष होंगे, आप वर्तमान मॉडल के साथ-साथ हुक आधारित का भी उपयोग कर सकते हैं मॉडल, जो मैं बहस कर रहा था।

मुझे यकीन नहीं है कि आपके सर्वोत्तम अभ्यास कहां से आ रहे हैं, क्योंकि मुझे पता है कि कोड को आसानी से पढ़ने योग्य रखना सबसे अच्छा अभ्यास है, और यह कि अत्यधिक नेस्टिंग एक विरोधी पैटर्न है। आप वास्तव में किन सर्वोत्तम प्रथाओं का जिक्र कर रहे हैं?

fwiw, रिएक्ट टीम ने पठनीयता के मुद्दे को 1 प्रेरणा के रूप में फिर से उपयोग करने के लिए संबोधित किया:
हुक प्रेरणा: घटकों के बीच स्टेटफुल लॉजिक का पुन: उपयोग करना कठिन है
प्रतिक्रिया एक घटक के लिए पुन: प्रयोज्य व्यवहार को "संलग्न" करने का एक तरीका प्रदान नहीं करता है ... आप पैटर्न से परिचित हो सकते हैं ... जो इसे हल करने का प्रयास करते हैं। लेकिन इन पैटर्नों के लिए आपको अपने घटकों का उपयोग करते समय उन्हें पुनर्गठित करने की आवश्यकता होती है, जो बोझिल हो सकता है और कोड का पालन करना कठिन बना सकता है ।

मैंने हर किसी को यह कहते हुए सुना है कि रिएक्ट की तुलना में फ़्लटर कितना अधिक आश्चर्यजनक है। शायद ऐसा इसलिए है क्योंकि यह सब कुछ नहीं करता जिस तरह से रिएक्ट करता है? आपके पास यह दोनों तरह से नहीं हो सकता है, आप यह नहीं कह सकते कि फ़्लटर प्रतिक्रिया से मीलों आगे है और यह भी पूछें कि यह सब कुछ ठीक उसी तरह करता है जैसे रिएक्ट करता है।

फ़्लटर किसी भी समस्या के लिए जो भी समाधान का उपयोग करने का निर्णय लेता है, उसे अपने गुणों पर खड़ा होना चाहिए। मैं रिएक्ट से परिचित नहीं हूं, लेकिन जाहिर तौर पर मैं तकनीक के कुछ अद्भुत टुकड़े को याद कर रहा हूं। :/

मुझे नहीं लगता कि कोई यह तर्क दे रहा है कि स्पंदन को रिएक्ट की तरह सब कुछ करना चाहिए।

लेकिन तथ्य यह है कि फ़्लटर की विजेट परत रिएक्ट से बहुत अधिक प्रेरित है। यह आधिकारिक दस्तावेज में कहा गया है।
और एक परिणाम के रूप में, विजेट्स में रिएक्ट कंपोनेंट्स की तुलना में समान लाभ और समान समस्याएं दोनों हैं।

इसका मतलब यह भी है कि इन मुद्दों से निपटने के लिए रिएक्ट के पास फ़्लटर की तुलना में अधिक अनुभव है।
इसने उनका अधिक समय तक सामना किया, और उन्हें बेहतर ढंग से समझता है।

इसलिए यह आश्चर्यजनक नहीं होना चाहिए कि फ़्लटर समस्याओं का समाधान प्रतिक्रिया समस्याओं के समाधान के समान है।

@Rudiksz Flutter का उपयोगकर्ता API रिएक्ट के वर्ग आधारित मॉडल के समान है, भले ही आंतरिक API भिन्न हो सकता है (मुझे नहीं पता कि क्या वे भिन्न हैं, मैं वास्तव में आंतरिक API में अधिक नहीं चलता)। मैं आपको यह देखने के लिए हुक के साथ रिएक्ट करने की कोशिश करने के लिए प्रोत्साहित करता हूं कि यह कैसा है, जैसा कि मैंने पहले कहा था कि लगभग विशेष रूप से उन लोगों पर आधारित राय का एक द्वंद्व प्रतीत होता है जिन्होंने अन्य ढांचे में हुक जैसी संरचनाओं का उपयोग नहीं किया है।

उनकी समानता को देखते हुए, इसमें कोई आश्चर्य नहीं होना चाहिए कि समस्याओं के समाधान समान दिखते हैं, जैसा कि ऊपर कहा गया है।

कृपया, हमारी पूरी कोशिश करें कि आपस में लड़ाई न करें।

केवल एक ही लड़ाई हमें इस चर्चा की ओर ले जाएगी और एक समाधान खोजने में विफल रही है।

मैंने हर किसी को यह कहते हुए सुना है कि रिएक्ट की तुलना में फ़्लटर कितना अधिक आश्चर्यजनक है। शायद ऐसा इसलिए है क्योंकि यह सब कुछ नहीं करता जिस तरह से रिएक्ट करता है? आपके पास यह दोनों तरह से नहीं हो सकता है, आप यह नहीं कह सकते कि फ़्लटर प्रतिक्रिया से मीलों आगे है और यह भी पूछें कि यह सब कुछ ठीक उसी तरह करता है जैसे रिएक्ट करता है।

यह इंगित करते हुए कि जब वे हुक के साथ आए तो रिएक्ट टीम की समान प्रेरणाएँ थीं, हम यहाँ व्यक्त की जा रही चिंताओं को मान्य करते हैं। यह निश्चित रूप से पुष्टि करता है कि इस प्रकार के घटक आधारित ढांचे के भीतर सामान्य स्टेटफुल लॉजिक का पुन: उपयोग और संयोजन करने में समस्या है, और कुछ हद तक आपके विचारों में "अव्यवस्था" के साथ पठनीयता, घोंसले और सामान्य समस्या पर चर्चा को मान्य करता है।

किसी भी चीज़ के लिए लालायित नहीं, मैंने कभी रिएक्ट में भी काम नहीं किया है, और मुझे फ़्लटर पसंद है। मैं यहां समस्या को आसानी से देख सकता हूं।

@Rudiksz हम यह सुनिश्चित नहीं कर सकते हैं कि जब तक हम इसे अभ्यास में नहीं डालते तब तक यह अभ्यास में प्रदर्शनकारी है। अभी फैसला करना बहुत आसान नहीं है।

@Hixie यह एक यात्रा के लिए एक उदाहरण है जो एक सामान्य स्पंदन उपयोगकर्ता के पास उपयोगकर्ता HookWidget और StatefulWidget दोनों के साथ दिखाने के लिए विजेट को लागू करने के लिए हो सकता है।

__हुक विजेट__

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

अब तक कुछ भी दिलचस्प नहीं है। दोनों समाधान बहुत स्वीकार्य, सीधे और प्रदर्शनकारी हैं।
अब हम एक ListView अंदर UserNickname का उपयोग करना चाहते हैं। जैसा कि आप देख सकते हैं, fetchNicknames केवल एक उपनाम नहीं, बल्कि उपनामों का नक्शा लौटाता है। इसलिए इसे हर बार कॉल करना बेमानी है। कुछ समाधान हम यहां लागू कर सकते हैं:

• fetchNicknames() तर्क को पैरेंट विजेट पर कॉल करें और परिणाम सहेजें।
• कैश मैनेजर का उपयोग करना।

पहला समाधान स्वीकार्य है लेकिन इसमें 2 समस्याएं हैं।
1 - यह UserNickname बेकार कर देता है क्योंकि यह अब केवल एक टेक्स्ट विजेट है और यदि आप इसे कहीं और उपयोग करना चाहते हैं तो आपको वही करना होगा जो आपने पैरेंट विजेट में किया था (जिसमें ListView ) . उपनाम दिखाने का तर्क UserNickname लेकिन हमें इसे अलग से स्थानांतरित करना होगा।
2 - हम कई अन्य उप पेड़ों में fetchNicknames() का उपयोग कर सकते हैं और इसे सभी ऐप के लिए कैश करना बेहतर है न केवल एप्लिकेशन का एक हिस्सा।

तो कल्पना कीजिए कि हम कैश मैनेजर चुनते हैं और CacheManager क्लास प्रदान करते हैं InheritedWidgets या Provider ।

कैशिंग के लिए समर्थन जोड़ने के बाद:

__हुक विजेट__

String useUserNickname(Id userid) {
  final context = useContext();
  final cache = Provider.of<CacheManager>(context);
  final name = useState("");
  useEffect(async () {
    name.value = "Loading...";
    var cachedValue = cache.get("nicknames");
    if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        cache.set("nicknames", result );
        cachedValue = result ;
    }
    final result = cachedValue[widget.userId];
    name.value = result ;
  }, [userId]);
  return name.value;
}

class UserNickname extends HookWidget {

  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    return Text(nickname);
  }
}

__स्टेटफुल विजेट__

class UserNickname extends Widget {
  final userId;
  // ... createState() ...
}

class UserNicknameState extends State {

  String nickname= "";
  CacheManager cache;

   initState() {
     super.initState();
     fetchAndUpdate();
     this.cache = Provider.of<CacheManager>(context);
   }

   fetchAndUpdate() async {
      setState(() { this.nickname = "Loading..." });
      var cachedValue = this.cache.get("nicknames");
      if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        this.cache.set("nicknames", result );
        cachedValue = result ;
      }
      final result = cachedValue [widget.userId];
      setState(() { this.nickname = result });
    }


 void didUpdateWidget(oldWidget) { 
     if (oldWidget.userId != widget.userId) {
        fetchAndUpdate();
     }
   }

  Widget build(BuildContext context) {
    return Text(this.nickname);
  }
}

हमारे पास एक सॉकेट सर्वर है जो उपनाम बदलने पर ग्राहकों को सूचित करता है।

__हुक विजेट__

String useUserNickname(Id userid) {
  final context = useContext();
  final cache = Provider.of<CacheManager>(context);
  final notifications = Provider.of<ServiceNotifications>(context);
  final name = useState("");

  fetchData() async {
    name.value = "Loading...";
    var cachedValue = cache.get("nicknames");
    if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        cache.set("nicknames", result );
        cachedValue = result ;
    }
    final result = cachedValue[widget.userId];
    name.value = result ;
   }

  useEffect(() {
     final sub = notifications.on("nicknameChanges", fetchData);
     return () => sub.unsubscribe();
   }, [])

  useEffect(fetchData, [userId]);
  return name.value;
}

class UserNickname extends HookWidget {

  final userId;

  Widget build(BuildContext context) {
    final nickname = useUserNickname(userId);
    return Text(nickname);
  }
}

__स्टेटफुल विजेट__

class UserNickname extends Widget {
  final userId;
  // ... createState() ...
}

class UserNicknameState extends State {

  String nickname= "";
  CacheManager cache;
  ServerNotification notifications;
  CancelableOperation sub;

   initState() {
     super.initState();
     fetchAndUpdate();
     this.cache = Provider.of<CacheManager>(context);
     this.notifications = Provider.of<ServerNotification>(context);
     this.sub = notifications.on("nicknameChanges", fetchAndUpdate);
   }

   dispose() {
      super.dispose();
      this.sub.unsubscribe();
   }

   fetchAndUpdate() async {
      setState(() { this.nickname = "Loading..." });
      var cachedValue = this.cache.get("nicknames");
      if (cachedValue == null || cachedValue[widget.userId] == null) {
        final result = await fetchNicknames();
        this.cache.set("nicknames", result );
        cachedValue = result ;
      }
      final result = cachedValue [widget.userId];
      setState(() { this.nickname = result });
    }


 void didUpdateWidget(oldWidget) { 
     if (oldWidget.userId != widget.userId) {
        fetchAndUpdate();
     }
   }

  Widget build(BuildContext context) {
    return Text(this.nickname);
  }
}

अब तक दोनों कार्यान्वयन स्वीकार्य और अच्छे हैं। स्टेटफुल में बॉयलरप्लेट आईएमओ कोई समस्या नहीं है। समस्या तब उत्पन्न होती है जब हमें UserInfo जैसे विजेट की आवश्यकता होती है जिसमें उपयोगकर्ता का उपनाम और अवतार दोनों हो। हम भी 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 को कॉल करना डरावना है क्योंकि एक एकल फ़ंक्शन इतना कुछ कर सकता है।
लेकिन प्रतिक्रिया में मेरे वर्षों के अनुभव में और 2 ऐप्स में flutter_hooks का उपयोग करना जो उत्पादन में हैं (जो हुक का भारी उपयोग कर रहे हैं) साबित करता है कि एक अच्छा राज्य प्रबंधन नहीं है (मैंने MobX और अन्य राज्य प्रबंधन समाधानों की भी कोशिश की लेकिन विजेट में गोंद हमेशा होता है) बहुत अधिक डरावना है। मुझे फ़्रंटएंड ऐप में प्रत्येक स्क्रीन के लिए 5 पेज डॉक्स लिखने की आवश्यकता नहीं है कि मेरे ऐप का एक पेज कैसे काम करता है, यह समझने के लिए मुझे पहली रिलीज के बाद कुछ महीनों में कुछ छोटी सुविधा जोड़ने की आवश्यकता हो सकती है। ऐप सेवर को बहुत ज्यादा कॉल करता है? आसान काम मैं संबंधित हुक पर जाता हूं और इसे बदल देता हूं और पूरा ऐप ठीक हो जाता है क्योंकि पूरा ऐप उस हुक का उपयोग करता है। हम एक अच्छे एब्स्ट्रैक्शन के साथ हुक का उपयोग किए बिना ऐप्स में समान चीजें रख सकते हैं लेकिन मैं जो कह रहा हूं वह यह है कि हुक वह अच्छा एब्स्ट्रैक्शन है।

मुझे पूरा यकीन है कि @gaearon इसे मुझसे बेहतर तरीके से

ऊपर दिए गए उदाहरण को देखते हुए, उपरोक्त विधियों में से कोई भी (स्टेटफुल और हुक विजेट) अन्य की तुलना में अधिक प्रदर्शनकारी नहीं है। लेकिन मुद्दा यह है कि उनमें से एक लोगों को परफॉर्मेंट कोड लिखने के लिए प्रोत्साहित करता है।

यह भी संभव है कि केवल उस सबट्री को अपडेट किया जाए जिसे हमें अपडेट करने की आवश्यकता है जैसे StreamBuilder जब बहुत अधिक अपडेट (जैसे एनिमेशन) हों:

1 - बस एक नया विजेट बनाना जो HookWidget और StatefulWidget/StatelessWidget दोनों के लिए पूरी तरह से व्यवहार्य विकल्प है
2 - HookWidgetBuilder में flutter_hooks पैकेज के समान कुछ का उपयोग करना क्योंकि माता-पिता और बच्चे के विजेट डेटा बहुत कसकर युग्मित होते हैं।

साइड नोट: मैं वास्तव में इस विषय पर चर्चा करने और इस मुद्दे में इतनी ऊर्जा डालने के लिए @Hixie और @rrousselGit की सराहना करता हूं । मैं वास्तव में इन वार्ताओं के परिणाम की प्रतीक्षा कर रहा हूं।

@Hixie के शुरुआती बिंदु के आधार पर मुझे लगता है कि मैं कुछ बहुत अच्छा/सुरुचिपूर्ण लेकर आ रहा हूं। अभी तक साझा करने के लिए तैयार नहीं है, लेकिन यह मुझे कुछ सुंदर सभ्य कोड नमूने बनाने की इजाजत दे रहा है, जो मुझे लगता है कि सेब की तुलना करना आसान होगा सेब जो इतना विदेशी दिखता है।

तो, कल्पना कीजिए कि हमारे पास इस हस्ताक्षर के साथ एक 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, इसलिए मुझे इस तर्क को डुप्लिकेट करना होगा, या बहुत ही एकल वर्ग में कुछ कस्टम फ़ंक्शन बनाना होगा जो एनिमेटर का उपयोग करना चाहता है।
4. यहां सिंगलटिकरप्रोवाइडरमिक्सिन को समझने की कोई आवश्यकता नहीं है, जो कि 'जादू' है और यह अस्पष्ट है कि महीनों के लिए एक टिकर मेरे लिए क्या है (आखिरकार, मुझे सिर्फ कक्षा पढ़नी चाहिए थी, लेकिन हर ट्यूटोरियल बस कहता है: इस जादू मिश्रण को जोड़ें)। यहां आप सीधे StatefulAnimationProperty के स्रोत कोड को देख सकते हैं, और देख सकते हैं कि एनीमेशन नियंत्रक सीधे और संदर्भ में टिकर प्रदाता का उपयोग कैसे करते हैं।

इसके बजाय आपको यह समझना होगा कि StatefulPropertyManager क्या करता है, लेकिन महत्वपूर्ण रूप से यह एक बार सीखा और किसी भी प्रकार की वस्तुओं पर लागू होता है, SingleTickerProviderMixin मुख्य रूप से एनिमेटर नियंत्रकों का उपयोग करने के लिए विशिष्ट है, और प्रत्येक नियंत्रक के पास उपयोग को आसान बनाने के लिए इसका अपना मिश्रण हो सकता है, जो गन्दा हो जाता है। बस असतत "स्टेटफुलऑब्जेक्ट्स" जो यह सब सामान जानता है (ठीक उसी तरह जैसे एक बिल्डर करता है!), बहुत साफ है और बेहतर है।

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 बिल्कुल नहीं। यह वह जगह है जहां बिल्डर्स आते हैं, लेकिन वे सरल उपयोग के मामलों के लिए ही अच्छे हैं।

मुझे लगता है कि इस बारे में जो बहुत दिलचस्प है, वह यह है कि कैसे सौ लाइनें और राज्य के लिए एक साधारण मिश्रण, मौजूदा वर्गों के एक समूह को बेमानी बना देता है। उदाहरण के लिए अब कभी भी TickerProviderMixins का उपयोग करने की कोई आवश्यकता नहीं है। TweenAnimationBuilder को लगभग कभी भी उपयोग नहीं किया जाना चाहिए, जब तक कि आप वास्तव में उप-संदर्भ बनाने के लिए _want_ नहीं करते। फोकस कंट्रोलर और टेक्स्ट इनपुट कंट्रोलर को मैनेज करने जैसे कई पारंपरिक दर्द बिंदुओं को काफी हद तक कम किया जाता है। स्ट्रीम का उपयोग करना अधिक आकर्षक और कम अटपटा हो जाता है। कोड बेस के पार, बिल्डर्स का उपयोग सामान्य रूप से कम किया जा सकता है जिससे अधिक आसानी से घूमने योग्य पेड़ बन जाएंगे।

साथ ही अपनी खुद की कस्टम स्टेट ऑब्जेक्ट बनाना _extremely_ आसान बनाता है, जैसे पहले सूचीबद्ध FetchUser उदाहरण, जिसके लिए वर्तमान में मूल रूप से एक बिल्डर की आवश्यकता होती है।

मुझे लगता है कि यह अगले स्पंदन डेवलपर सर्वेक्षण में पूछने के लिए एक बहुत ही दिलचस्प सवाल होगा।

यह एक अच्छी शुरुआत होगी। इस समस्या को विभिन्न भागों/प्रश्नों में विभाजित करें और देखें कि क्या यह एक वास्तविक समस्या है जिसे फ़्लटर डेवलपर्स हल करना चाहते हैं।

एक बार यह स्पष्ट हो जाने पर, यह बातचीत अधिक धाराप्रवाह और समृद्ध होगी

प्रत्येक टिप्पणी के तहत इमोजी प्रतिक्रिया एक स्पष्ट विचार देती है कि समुदाय इसे एक समस्या के रूप में देखता है या नहीं। इस मुद्दे के लिए 250+ लंबी टिप्पणियों को पढ़ने वाले डेवलपर्स की राय का बहुत मतलब है।

@esDotDev यह उन कुछ विचारों के समान है जिनके साथ मैं कर रहा हूं, हालांकि मुझे संपत्ति के टिकर प्रदाता होने का आपका विचार पसंद है, मैंने उस पर विचार नहीं किया था। एक बात यह है कि आपके कार्यान्वयन में कमी है कि मुझे लगता है कि हमें जोड़ने की आवश्यकता होगी TickerMode (जो कि TickerProviderStateMixin का बिंदु है) को संभालना है।

मैं जिस मुख्य चीज से जूझ रहा हूं, वह यह है कि इसे कुशल तरीके से कैसे किया जाए। उदाहरण के लिए, ValueListenableBuilder एक बाल तर्क लेता है जिसका उपयोग प्रदर्शन को मापने के लिए किया जा सकता है। मुझे संपत्ति दृष्टिकोण के साथ ऐसा करने का कोई तरीका नहीं दिख रहा है।

@ हिक्सी
मैं समझता हूं कि इस तरह के दृष्टिकोण के साथ दक्षता हानि अपरिहार्य प्रतीत होती है। लेकिन मुझे आपके कोड को प्रोफाइल करने के बाद ऑप्टिमाइज़ करने की फ़्लटर मानसिकता पसंद है। ऐसे बहुत से अनुप्रयोग हैं जो संपत्ति दृष्टिकोण की स्पष्टता और संक्षिप्तता से लाभान्वित होंगे। अपने कोड को प्रोफाइल करने का विकल्प, और बिल्डरों में रिफैक्टर या विजेट के एक टुकड़े को अपने विजेट में अलग करने का विकल्प हमेशा होता है।

दस्तावेज़ीकरण को केवल सर्वोत्तम प्रथाओं को प्रतिबिंबित करने और ट्रेडऑफ़ को स्पष्ट करने की आवश्यकता होगी।

मैं जिस मुख्य चीज से जूझ रहा हूं, वह यह है कि इसे कुशल तरीके से कैसे किया जाए। उदाहरण के लिए, ValueListenableBuilder एक बाल तर्क लेता है जिसका उपयोग प्रदर्शन को मापने के लिए किया जा सकता है। मुझे संपत्ति दृष्टिकोण के साथ ऐसा करने का कोई तरीका नहीं दिख रहा है।

एचएम, मुझे लगता है कि गुणों का पूरा बिंदु गैर-दृश्य वस्तुओं के लिए है। अगर कुछ पेड़ में संदर्भ स्लॉट रखना चाहता है, तो वह चीज एक निर्माता होनी चाहिए (वास्तव में ये केवल वही चीजें हैं जो अब मुझे लगता है कि बिल्डर्स होना चाहिए?)

तो हमारे पास एक StatefulValueListenableProperty होगा जिसका हम ज्यादातर समय उपयोग करते हैं जब हम पूरे दृश्य को बांधना चाहते हैं। इसके बाद हमारे पास एक ValueListenableBuilder भी है, इस अवसर पर कि हम अपने पेड़ के कुछ उप-खंड को पुनर्निर्माण करना चाहते हैं।

यह नेस्टिंग के मुद्दे को भी संबोधित करता है, क्योंकि एक बिल्डर को लीफ नोड के रूप में उपयोग करना, पठनीयता के लिए लगभग उतना विघटनकारी नहीं है, जितना कि आपके विजेट ट्री के शीर्ष पर नेस्टिंग 2 या 3।

@TimWhiting फ़्लटर के डिज़ाइन दर्शन का एक बड़ा हिस्सा लोगों को सही विकल्प की ओर मार्गदर्शन करना है। मैं लोगों को उस शैली का पालन करने के लिए प्रोत्साहित करने से बचना चाहता हूं जिसे बेहतर प्रदर्शन प्राप्त करने के लिए उन्हें दूर जाना होगा। हो सकता है कि सभी जरूरतों को एक साथ पूरा करने का कोई तरीका न हो, लेकिन हमें इसे जरूर आजमाना चाहिए।

@ हिक्सी
बिल्डरों के लिए ऐसा कुछ क्या है?

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

क्या आप विस्तार कर सकते हैं? मुझे यकीन नहीं है कि मैं प्रस्ताव को समझता हूं।

मुझे लगता है कि वह कह रहा है कि स्टेटफुलप्रॉपर्टी उन गुणों के लिए वैकल्पिक निर्माण विधि प्रदान कर सकती है जिनमें कुछ दृश्य घटक हैं:

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 मुझे आपका विचार पसंद है कि संपत्ति ही टिकर प्रदाता है, मैंने उस पर विचार नहीं किया था।

हां इस हुक-शैली के दृष्टिकोण के सबसे मजबूत पहलुओं में से एक यह है कि आप स्टेटफुल लॉजिक को _ful_ कर सकते हैं, जो भी हो। तो इन मामलों में एसी के लिए पूरी सूची है:

1. एसी बनाएं
2. इसे एक टिकर दें
3. विजेट परिवर्तन संभालें
4. एसी और टिकर की सफाई संभालें
5. टिक पर दृश्य पुनर्निर्माण करें

वर्तमान में चीजें डेवलपर्स के साथ विभाजित हैं (या हैंडलिंग नहीं) 1,3,4 मैन्युअल रूप से और दोहराव से, और अर्ध-जादुई सिंगलटिकरप्रोवाइडरमिक्सिन 2 और 5 की देखभाल कर रहा है (हमारे साथ 'इस' को बनाम के रूप में पास कर रहा है, जिसने मुझे महीनों तक भ्रमित किया! ) और सिंगलटिकरप्रोवाइडरमिक्सिन स्वयं स्पष्ट रूप से इस प्रकार की समस्या के लिए एक प्रयास है, अन्यथा क्यों न केवल सभी तरह से जाएं और हमें प्रत्येक वर्ग के लिए टिकरप्रोवाइडर लागू करें, यह और अधिक स्पष्ट होगा।

मान लीजिए आपके पास यह कोड था:

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 क्या आपने https://github.com/flutter/flutter/issues/51752#issuecomment -671104377 देखा है
मुझे लगता है कि वास्तव में कुछ अच्छे बिंदु हैं।
मैं आज बहुत सारे ValueListenableBuilder के साथ कुछ बनाता हूं और मैं केवल इतना कह सकता हूं कि इसे पढ़ना अच्छा नहीं है।

@ हिक्सी
उदाहरण के लिए धन्यवाद। मैंने इसे अपना सर्वश्रेष्ठ शॉट दिया। हो सकता है मुझे कुछ याद आ गया हो।

मुझे नहीं लगता कि यह काम करता है क्योंकि संपत्ति उस राज्य से जुड़ती है जिसे परिभाषित किया गया है, इसलिए महंगा माता-पिता हमेशा यहां पुनर्निर्माण कर रहा है। तब मुझे लगता है कि बच्चे का कैशिंग भी समस्याग्रस्त है, जैसा कि बिल्डर उदाहरण में यह पता चलेगा कि मूल राज्य बनने पर बच्चे को केवल पुनर्निर्माण करना है, लेकिन इस विधि में संपत्ति को यह नहीं पता कि उसके कैश को कब अमान्य करना है (लेकिन शायद यह हल करने योग्य है?)

लेकिन tbh, यह बिल्डरों के लिए एकदम सही उपयोग का मामला है, जब आप एक नया संदर्भ पेश करना चाहते हैं। मुझे लगता है कि यह केवल StatefulProperties (शुद्ध राज्य) और StatefulWidgets (राज्य और लेआउट का मिश्रण) का संदर्भ रखने के लिए काफी सुरुचिपूर्ण है।

जब भी आप जानबूझकर एक उप-संदर्भ बना रहे हैं, तो आप परिभाषा के अनुसार इसे अपने पेड़ के नीचे कर रहे होंगे, जो बिल्डरों को मुख्य कमियों में से एक का मुकाबला करने में मदद करता है (पूरे पेड़ में जबरन घोंसला बनाना)

@escamoteur (और @sahandevs जिन्होंने उस टिप्पणी को लिखा था) हाँ मैं पहले इसका अध्ययन कर रहा था। मुझे लगता है कि यह निश्चित रूप से उस तर्क को दिखाने में मदद करता है जिसे लोग हटाना चाहते हैं। मुझे लगता है, हालांकि, उदाहरण स्वयं थोड़ा संदिग्ध है कि मैं अधिकांश तर्क (उदाहरण के लिए कैशिंग के आसपास सब कुछ) ऐप राज्य व्यापार तर्क में होने की उम्मीद करता हूं, और कहीं भी विगेट्स के पास नहीं। मुझे हॉट रीलोड को तोड़े बिना उस टिप्पणी में प्रस्तावित संक्षिप्त रूप में सिंटैक्स प्राप्त करने का एक अच्छा तरीका नहीं दिख रहा है (उदाहरण के लिए यदि आप अपने द्वारा उपयोग किए जा रहे हुक की संख्या बदलते हैं, तो यह स्पष्ट नहीं है कि उन्हें रीलोड में कैसे स्टेटफुल रखा जा सकता है )

उस ने कहा, मुझे लगता है कि ऊपर @esDotDev और @TimWhiting शो बहुत दिलचस्प है और इन समस्याओं को हल कर सकता है। यह हुक जितना संक्षिप्त नहीं है, लेकिन यह अधिक विश्वसनीय है। मुझे लगता है कि ऐसा कुछ पैकेज करने के लिए यह सही समझ में आता है, अगर यह अच्छी तरह से काम करता है तो यह एक स्पंदन पसंदीदा भी हो सकता है। मुझे यकीन नहीं है कि यह कोर फ्रेमवर्क फीचर के रूप में समझ में आता है क्योंकि एक बार जब आप संपत्तियों के निर्माण और प्रदर्शन प्रभाव के आसपास की जटिलता को ध्यान में रखते हैं, और अलग-अलग लोग अलग-अलग शैलियों को कैसे पसंद करेंगे, तो सुधार _that_ पर्याप्त नहीं है। दिन के अंत में, अलग-अलग लोगों के लिए अलग-अलग शैलियों का उपयोग करना ठीक होना चाहिए, लेकिन हम नहीं चाहेंगे कि कोर फ्रेमवर्क में कई शैलियाँ हों, जो नए डेवलपर्स के लिए सिर्फ भ्रामक है।

एक तर्क यह भी दिया जाना चाहिए कि फ़्लटर सीखने का सही तरीका पहले विजेट्स को समझना है, और फिर उन उपकरणों को सीखना है जो उन्हें अमूर्त सिंटैक्स पर सीधे कूदने के बजाय (हुक या जो कुछ भी) दूर करते हैं। अन्यथा आप सिस्टम के काम करने के एक प्रमुख घटक को याद कर रहे हैं जो आपको परफॉर्मेंट कोड लिखने के मामले में भटका सकता है।

मुझे हॉट रीलोड को तोड़े बिना उस टिप्पणी में प्रस्तावित संक्षिप्त रूप में सिंटैक्स प्राप्त करने का एक अच्छा तरीका नहीं दिख रहा है (उदाहरण के लिए यदि आप अपने द्वारा उपयोग किए जा रहे हुक की संख्या बदलते हैं, तो यह स्पष्ट नहीं है कि उन्हें रीलोड में कैसे स्टेटफुल रखा जा सकता है )

हुक बिना किसी समस्या के हॉट-रीलोड के साथ काम करते हैं।
गैर-मिलान रनटाइम वाला पहला हुक बाद के सभी हुक को नष्ट करने का कारण बनता है।

यह जोड़ने, हटाने और पुन: व्यवस्थित करने का समर्थन करता है।

मुझे लगता है कि एक तर्क है कि पूर्ण अमूर्तता आंशिक रूप से बेहतर है जो वर्तमान में मौजूद है।

अगर मैं यह समझना चाहता हूं कि एक संपत्ति के संदर्भ में एनिमेटर कैसे काम करता है, तो मैं या तो इसे पूरी तरह से अनदेखा कर देता हूं, या इसमें कूद जाता हूं, और यह ठीक है, आत्म निहित और सुसंगत है।

अगर मैं यह समझना चाहता हूं कि एनिमेटरकंट्रोलर स्टेटफुलविजेट के संदर्भ में कैसे काम करता है, तो मुझे बुनियादी जीवनचक्र हुक को समझने के लिए (मजबूर) की जरूरत है, लेकिन फिर यह समझने से बच गया कि अंतर्निहित टिक तंत्र कैसे काम करता है। यह कुछ अर्थों में दोनों दुनियाओं में सबसे खराब है। इसे 'सिर्फ काम' करने के लिए पर्याप्त जादू नहीं है, लेकिन नए उपयोगकर्ताओं को भ्रमित करने के लिए पर्याप्त है और उन्हें कुछ मिश्रण (जो अपने आप में अधिकांश के लिए एक नई अवधारणा है) और एक जादुई बनाम सिंक संपत्ति पर आंख मूंदकर भरोसा करने के लिए मजबूर करता है।

मैं कोड आधार में अन्य उदाहरणों के बारे में निश्चित नहीं हूं, लेकिन यह किसी भी स्थिति पर लागू होगा जहां StatefulWidget के लिए कुछ सहायक मिश्रण प्रदान किए गए हैं, लेकिन अभी भी कुछ अन्य बूटस्ट्रैपिंग हैं जिन्हें हमेशा किया जाना चाहिए। देव बूटस्ट्रैपिंग (उबाऊ भाग) सीखेंगे और मिक्सिन (दिलचस्प/जटिल बिट) को अनदेखा करेंगे

उस ने कहा, मुझे लगता है कि ऊपर @esDotDev और @TimWhiting शो बहुत दिलचस्प है और इन समस्याओं को हल कर सकता है। यह हुक जितना संक्षिप्त नहीं है, लेकिन यह अधिक विश्वसनीय है

यह कैसे अधिक विश्वसनीय है?

हम अभी भी सशर्त या उसके जीवन-चक्र के बाहर गुण नहीं बना सकते/अपडेट नहीं कर सकते क्योंकि हम खराब स्थिति में प्रवेश कर सकते हैं। उदाहरण के लिए, किसी संपत्ति को सशर्त रूप से कॉल करने से स्थिति गलत होने पर संपत्ति का निपटान नहीं होगा।
और सभी संपत्तियों का अभी भी हर पुनर्निर्माण पर पुनर्मूल्यांकन किया जाता है।

लेकिन यह कई मुद्दों का कारण बनता है, जैसे कि NNBD के बाद उपयोगकर्ताओं को हर जगह ! का उपयोग करने के लिए मजबूर करना या संभावित रूप से उपयोगकर्ताओं को किसी संपत्ति को अपडेट करने से पहले एक्सेस करने की अनुमति देना।

उदाहरण के लिए, क्या होगा यदि कोई व्यक्ति didUpdateWidget अंदर किसी संपत्ति को पढ़ता है?

• क्या initProperties जीवन-चक्र से पहले निष्पादित किया गया था? लेकिन इसका मतलब है कि हमें प्रति बिल्ड कई बार गुणों को अपडेट करना पड़ सकता है।
• क्या initProperties didUpdateWidget के बाद निष्पादित किया गया था? फिर didUpdateWidget के अंदर गुणों का उपयोग करने से पुरानी स्थिति हो सकती है

तो अंत में, हमारे पास हुक के सभी मुद्दे हैं लेकिन:

• हम 'स्टेटलेसविजेट' के अंदर गुणों का उपयोग नहीं कर सकते हैं। तो 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),
                      );
                    });
              });
        });
  }
}

यह बहुत कठिन है (कम से कम मेरी आंख के लिए) उस कोड को खोजना जो मायने रखता है। इसके अलावा, मुझे इसे लिखते समय 3 बार की तरह शुरू करना पड़ा, क्योंकि मैं लगातार भ्रमित हो जाता था कि कौन सा ब्रैकेट कहां है, मेरे अर्ध-कॉलन कहां जाने चाहिए आदि। नेस्टेड बिल्डरों को लिखने या अंदर काम करने में कोई मज़ा नहीं है। एक गलत अर्धविराम और डार्टफएमटी बेल पूरी तरह से पूरी चीज को कुचल देता है।

यह कैसे अधिक विश्वसनीय है?

यह एक आदर्श उदाहरण है कि यह _ should_ एक कोर प्लगइन imo क्यों है। यहां आवश्यक डोमेन ज्ञान _deep_ है। मेरे पास इस तरह की एक साधारण कैशिंग प्रणाली को लागू करने के लिए स्क्रिप्टिंग ज्ञान है, मेरे पास हर किनारे के मामले को जानने के लिए डोमेन ज्ञान के करीब भी नहीं है, या खराब स्थिति में हम प्रवेश कर सकते हैं। रेमी के अलावा, मुझे लगता है कि फ़्लटर टीम के बाहर दुनिया में 4 डेवलपर्स हैं जो इस सामान को जानते हैं! (स्पष्ट रूप से अतिशयोक्ति)।

स्टेटलेस विजेट्स का समर्थन करने का मुद्दा एक अच्छा है। एक तरफ मैं समझ गया, StatefulWidgets अजीब तरह से क्रियात्मक हैं। दूसरी ओर, यहाँ हम वास्तव में शुद्ध वाचालता के बारे में बात कर रहे हैं। ऐसी कोई बग नहीं है जो 2 वर्गों को परिभाषित करने से हो सकती है, कोई रास्ता नहीं है कि आप इसे गड़बड़ कर सकते हैं, संकलक आपको अनुमति नहीं देता है, स्टेटलेसविजेट में कुछ भी दिलचस्प नहीं है जो मैं करना चाहता हूं। तो मैं इसे एक प्रमुख मुद्दा होने पर बेचा नहीं गया हूं ... निश्चित रूप से अच्छा होगा, लेकिन यह आखिरी 5% आईएमओ है, कुछ अटकने के लिए नहीं।

दूसरी ओर ... कीवर्ड समर्थन के साथ रेमी से सिंटैक्स बिल्कुल सुंदर और बेहद लचीला/शक्तिशाली है। और अगर यह आपको स्टेटलेसविजेट समर्थन मुफ्त में देता है, तो यह सिर्फ अतिरिक्त है

स्टेटलेसविजेट का समर्थन करना आईएमओ एक बड़ी बात है। वैकल्पिक, लेकिन फिर भी बहुत अच्छा।

जबकि मैं मानता हूं कि यह महत्वपूर्ण नहीं है, लोग पहले से ही StatelessWidget के बजाय फ़ंक्शंस का उपयोग करने के लिए लड़ रहे हैं।
लोगों को बिल्डर्स का उपयोग करने के लिए स्टेटफुलविजेट का उपयोग करने की आवश्यकता है (क्योंकि अधिकांश बिल्डर्स के पास संपत्ति समकक्ष होने की संभावना है) केवल संघर्ष को गहरा कर देगा।

इतना ही नहीं, ऐसी दुनिया में जहां हम डार्ट (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 का भी समर्थन करता है।

डार्ट में उच्च-क्रम के कार्यों के लिए समर्थन होने से अंतर इस तरह के सिंटैक्स का समर्थन करने के लिए कोड-जनरेशन की आवश्यकता को हटा देगा।

मैं अनुमान लगा रहा हूं कि @ हिक्सी का मतलब अधिक विश्वसनीय है, क्या यह संचालन/सशर्त समस्या के क्रम से ग्रस्त नहीं है, क्योंकि यह एक वास्तुशिल्प पीओवी से बहुत 'अविश्वसनीय' है (हालांकि मुझे एहसास है कि यह एक आसान नियम है सीखें और एक बार सीखे जाने के बाद उल्लंघन न करें)।

लेकिन कीवर्ड के साथ आपका प्रस्ताव भी नहीं है। मुझे लगता है कि नए कीवर्ड का मामला काफी मजबूत है:

• राज्य पर ग्राफ्टिंग की तुलना में अधिक लचीला और रचना योग्य
• और भी संक्षिप्त वाक्य रचना
• स्टेटलेस में काम करता है जो एक बहुत अच्छा विकल्प है

मुझे इसके बारे में क्या पसंद नहीं है, क्या हम किसी साधारण वस्तु पर कई बार/निर्माण गुणों को सेट करने की लागत के बारे में चिंता कर रहे हैं, लेकिन फिर ऐसे समाधान की वकालत कर रहे हैं जो मूल रूप से संदर्भ के लाखों स्तर और लेआउट लागत का एक गुच्छा तैयार करेगा। क्या मैं गलत समझ रहा हूँ?

दूसरा नकारात्मक पहलू जादू का यह विचार है। लेकिन अगर आप कुछ जादुई करने जा रहे हैं, तो मुझे लगता है कि इसे करने के लिए एक नया कीवर्ड एक प्रभावी तरीका है, क्योंकि यह समुदाय को हाइलाइट करना और कॉल करना आसान बनाता है, और समझाता है कि यह क्या है और यह कैसे काम करता है। यह मूल रूप से फ़्लटर में अगले वर्ष के लिए सभी के बारे में बात करेगा और मुझे यकीन है कि हम इससे बाहर निकलने वाले शांत प्लगइन्स का विस्फोट देखेंगे।

मैं अनुमान लगा रहा हूं कि @ हिक्सी का मतलब अधिक विश्वसनीय है, क्या यह संचालन/सशर्त समस्या के क्रम से ग्रस्त नहीं है, क्योंकि यह एक वास्तुशिल्प पीओवी से बहुत 'अविश्वसनीय' है (हालांकि मुझे एहसास है कि यह एक आसान नियम है सीखें और एक बार सीखे जाने के बाद उल्लंघन न करें)।

लेकिन हुक इस तरह के मुद्दे से ग्रस्त नहीं हैं, क्योंकि वे स्थिर रूप से विश्लेषण योग्य हैं, और इसलिए जब उनका दुरुपयोग किया जाता है तो हमें संकलन त्रुटि हो सकती है।

यह एक गैर-समस्या है

इसी तरह यदि कस्टम त्रुटियाँ नो-गो हैं, तो जैसा कि मैंने पहले उल्लेख किया है, संपत्ति ठीक उसी समस्या से ग्रस्त है।
हम यथोचित रूप से नहीं लिख सकते हैं:

Property property;

<strong i="12">@override</strong>
void initProperties() {
  if (condition) {
    property = init(property, MyProperty());
  }
}

condition को सत्य से असत्य में बदलने से संपत्ति का निपटान नहीं होगा।

हम वास्तव में इसे लूप में भी नहीं कह सकते। यह वास्तव में कोई मतलब नहीं है, क्योंकि यह एक बार का असाइनमेंट है। संपत्ति को लूप में चलाने का उपयोग-मामला क्या है?

और यह तथ्य कि हम गुणों को किसी भी क्रम में पढ़ सकते हैं, खतरनाक लगता है
उदाहरण के लिए हम लिख सकते हैं:

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 एनिमेशन का उपयोग करना है। बॉयलरप्लेट की मात्रा को उजागर करने के लिए एक्स को जानबूझकर उदाहरण में सरल बनाया गया है।

मैं उनका उपयोग कैसे कर रहा हूं, इस पर ध्यान केंद्रित न करें। एक वास्तविक उदाहरण में, विजेट "कोर" एक सौ लाइनें या कुछ और होगा, एनिमेटेड गुण इतने सरल नहीं होंगे, और हमारे पास कई हैंडलर और अन्य फ़ंक्शन परिभाषित होंगे। मान लें कि मैं कुछ ऐसा कर रहा हूं जो निहित विगेट्स में से किसी एक द्वारा नियंत्रित नहीं किया गया है (एनिमेटेड कंटेनर के अलावा अन्य कठिन नहीं है, वे बेहद एकल-उद्देश्य हैं)।

मुद्दा यह है कि इस तरह कुछ निर्माण करते समय, बिल्डर्स बहुत अच्छा काम नहीं करते हैं, क्योंकि वे आपको पठनीयता (और लिखने योग्यता) छेद में चिपकाते हैं, जैसे कि वे सरल उपयोग के मामलों के लिए उपयुक्त हैं, वे "रचना" नहीं करते हैं कुंआ। 2 या अधिक चीजों का संघटन होना।

मैं उनका उपयोग कैसे कर रहा हूं, इस पर ध्यान केंद्रित न करें। एक वास्तविक उदाहरण में,...

... और वापस एक वर्ग में। आप एक वास्तविक उदाहरण क्यों नहीं लाते?

आपको जटिल एनिमेशन का उपयोग करने का एक वास्तविक उदाहरण चाहिए?
https://github.com/gskinnerTeam/flutter_vignettes

कुछ मनमाना जटिल एनीमेशन दिखाने से उदाहरण के अलावा कुछ नहीं होगा। कहने के लिए पर्याप्त है, कुछ विजेट के अंदर कई एनिमेटरों (या किसी अन्य स्टेटफुल ऑब्जेक्ट की आप कल्पना कर सकते हैं) का उपयोग करने के लिए बहुत सारे उपयोग के मामले हैं

बेशक। यहां उदाहरण "X" करने के लिए कुछ विजेट में 3 एनिमेशन का उपयोग करना है। बॉयलरप्लेट की मात्रा को उजागर करने के लिए एक्स को जानबूझकर उदाहरण में सरल बनाया गया है।

विजेट "कोर" सौ लाइनें या कुछ और होगा

एक अन्य पोस्ट में आपने बॉयलरप्लेट के साथ एक उदाहरण पोस्ट किया जो "कोर" को अस्पष्ट करता है, लेकिन अब आप हमें बताते हैं कि कोर सैकड़ों लाइनें होगी? तो वास्तव में, कोर की तुलना में बॉयलरप्लेट माइनसक्यूल होगा? आपके पास यह दोनों तरीके नहीं हो सकते।
आप लगातार अपने तर्क बदल रहे हैं।

मैं उनका उपयोग कैसे कर रहा हूं, इस पर ध्यान केंद्रित न करें। एक वास्तविक उदाहरण में,...

... और वापस एक वर्ग में। आप एक वास्तविक उदाहरण क्यों नहीं लाते?

शायद इसलिए कि विभिन्न विचारों के साथ खिलवाड़ करते समय वास्तविक उदाहरण बनाने में बहुत समय लगता है। इरादा पाठक के लिए यह कल्पना करना है कि वास्तविक स्थिति में इसका उपयोग कैसे किया जा सकता है, इसका उल्लेख नहीं है कि इसके आसपास के तरीके हैं। बेशक कोई एनिमेटेड कंटेनर का उपयोग कर सकता है, लेकिन क्या होगा यदि वे नहीं कर सके? क्या होगा अगर यह सिर्फ एक एनिमेटेड कंटेनर के साथ बनाने के लिए बहुत जटिल था।

अब, जबकि लेखक वास्तव में वास्तविक उदाहरणों का उपयोग नहीं करते हैं, जिन्हें अच्छे या बुरे के रूप में दिखाया जा सकता है, इस पर मेरी कोई राय नहीं है, मैं केवल इस सूत्र में उन समस्याओं में सुधार लाने की प्रवृत्ति पर टिप्पणी कर रहा हूं जो नहीं करते हैं समस्या को पूरी तरह से हल करें। यह हुक समर्थकों और विरोधियों के बीच भ्रम का एक प्रमुख स्रोत प्रतीत होता है, क्योंकि प्रत्येक एक दूसरे से कुछ हद तक बात कर रहे हैं, इसलिए मैं कुछ वास्तविक ऐप बनाने के हिक्सी के प्रस्ताव का समर्थन करता हूं जैसे कि एक प्रतिद्वंद्वी यह नहीं कह सकता कि एक "वास्तविक" उदाहरण था दिखाया नहीं गया है और एक प्रस्तावक यह नहीं कह सकता कि किसी को केवल वास्तविक दुनिया के परिदृश्य की कल्पना करनी चाहिए।

मुझे लगता है कि मैंने कहा था कि 100 लाइन वाली कक्षा रखना मूर्खतापूर्ण होगा, जहां इसका आधा बॉयलरप्लेट है। जिसका मैं यहाँ वर्णन कर रहा हूँ। कोर, हालांकि बड़ा, शोर के एक समूह से बाधित नहीं होना चाहिए, जो निश्चित रूप से कई बिल्डरों का उपयोग करते समय होता है।

और इसका कारण एक बड़े कोडबेस में स्कैन-क्षमता, पठनीयता और रखरखाव है। यह पंक्तियों का लेखन नहीं है, हालांकि घुंघराले ब्रैकेट नरक में जाने की प्रवृत्ति के कारण बिल्डरों में लेखन एक उत्पादकता हारे हुए आईएमओ है।

एक अन्य पोस्ट में आपने बॉयलरप्लेट के साथ एक उदाहरण पोस्ट किया जो "कोर" को अस्पष्ट करता है, लेकिन अब आप हमें बताते हैं कि कोर सैकड़ों लाइनें होगी? तो वास्तव में, कोर की तुलना में बॉयलरप्लेट माइनसक्यूल होगा? आपके पास यह दोनों तरीके नहीं हो सकते।
आप लगातार अपने तर्क बदल रहे हैं।

फिर, यह मुद्दा बॉयलरप्लेट के बारे में नहीं है बल्कि पठनीयता और पुन: प्रयोज्य है।
इससे कोई फर्क नहीं पड़ता कि हमारे पास 100 लाइनें हैं।
क्या मायने रखता है कि ये लाइनें कितनी पठनीय/रखरखाव योग्य/पुन: प्रयोज्य हैं।

यहां तक ​​कि अगर तर्क बॉयलरप्लेट के बारे में था, तो मैं, उपयोगकर्ता, किसी भी मामले में ऐसे बॉयलरप्लेट को क्यों बर्दाश्त कर सकता हूं, जबकि एक ही बात को व्यक्त करने का पर्याप्त समकक्ष तरीका दिया गया हो? प्रोग्रामिंग अमूर्त बनाने और श्रम को स्वचालित करने के बारे में है, मैं वास्तव में विभिन्न वर्गों और फाइलों में एक ही चीज़ को बार-बार फिर से करने की बात नहीं देखता।

आपको जटिल एनिमेशन का उपयोग करने का एक वास्तविक उदाहरण चाहिए?
https://github.com/gskinnerTeam/flutter_vignettes

निश्चित रूप से, आप मुझसे आपकी पूरी परियोजना के बारे में जानने की उम्मीद नहीं कर सकते। मुझे वास्तव में कौन सी फाइल देखनी चाहिए?

कुछ मनमाना जटिल एनीमेशन दिखाने से उदाहरण के अलावा कुछ नहीं होगा।

ठीक इसके विपरीत। कुछ मनमाना जटिल एनीमेशन दिखाना जो किसी भी मौजूदा समाधान द्वारा हल नहीं किया जा सकता है , उदाहरण होगा, और यही हिक्सी पूछता रहता है, मेरा मानना ​​​​है।

बस gifs को स्कैन करें और कल्पना करना शुरू करें कि आप उनमें से कुछ कैसे बना सकते हैं। वह रेपो वास्तव में 17 स्टैंडअलोन ऐप है। आप यह भी उम्मीद नहीं कर सकते कि मैं आपको कुछ मनमाना एनीमेशन लिखूंगा, बस आपको यह साबित करने के लिए कि जटिल एनिमेशन मौजूद हो सकते हैं। मैं उन्हें 20 साल से फ्लैश में बना रहा हूं, हर एक पिछले से अलग है। और यह वैसे भी एनिमेशन के लिए विशिष्ट नहीं है, वे एक बड़े बिंदु को चित्रित करने के लिए सबसे सरल सबसे परिचित एपीआई हैं।

जैसा कि आप जानते हैं कि कैसे, जब आप एक एनिमेटर का उपयोग करते हैं, तो ऐसी 6 चीजें हैं जो आपको हर समय करने की आवश्यकता होती है, लेकिन इसके लिए जीवनचक्र के हुक की भी आवश्यकता होती है ?? ठीक है, तो अब इसे ऐसी किसी भी चीज़ तक बढ़ाएँ जिसमें आपको हर बार 6 चरण करने हों... और आपको इसे 2 स्थानों पर उपयोग करने की आवश्यकता है। या आपको उनमें से 3 का एक बार में उपयोग करने की आवश्यकता है। यह स्पष्ट रूप से इसके चेहरे पर एक मुद्दा है, मुझे नहीं पता कि मैं इसे समझाने के लिए और क्या जोड़ सकता हूं।

प्रोग्रामिंग अमूर्त बनाने और श्रम को स्वचालित करने के बारे में है, मैं वास्तव में विभिन्न वर्गों और फाइलों में एक ही चीज़ को बार-बार फिर से करने की बात नहीं देखता।

__सभी__? तो प्रदर्शन, रखरखाव प्रासंगिक नहीं है?

एक बिंदु आता है जब एक श्रम को "स्वचालित" करना और श्रम को "करना" समान होता है।

दोस्तों, यह ठीक है यदि आपके पास वास्तविक उदाहरण बनाने के लिए समय या झुकाव नहीं है, लेकिन कृपया, यदि आप समस्या को समझाने के लिए उदाहरण बनाने में रुचि नहीं रखते हैं, तो आपको यह भी उम्मीद नहीं करनी चाहिए कि लोग समस्या को हल करने के लिए मजबूर महसूस करें ( जो समस्या दिखाने के लिए उदाहरण बनाने की तुलना में बहुत अधिक काम है)। यहां किसी को भी किसी के लिए कुछ करने की आवश्यकता नहीं है, यह एक ओपन सोर्स प्रोजेक्ट है जहां हम सभी एक दूसरे की मदद करने की कोशिश कर रहे हैं।

@TimWhiting क्या आप अपने https://github.com/TimWhiting/local_widget_state_approaches रेपो में लाइसेंस फ़ाइल डालने पर ध्यान देंगे? कुछ लोग लागू लाइसेंस (बीएसडी, एमआईटी, या इसी तरह के आदर्श) के बिना योगदान करने में असमर्थ हैं।

मैं, उपयोगकर्ता, किसी भी मामले में ऐसे बॉयलरप्लेट को क्यों बर्दाश्त कर सकता हूं, जब एक ही बात को व्यक्त करने का पर्याप्त समकक्ष तरीका दिया गया हो?

हां, रखरखाव और प्रदर्शन निश्चित रूप से मायने रखता है। मेरा मतलब है कि जब एक समान समाधान होता है, तो हमें वह चुनना चाहिए जिसमें कम बॉयलरप्लेट हो, पढ़ने में आसान हो, अधिक पुन: प्रयोज्य हो, और इसी तरह। यह कहना नहीं है कि हुक जवाब हैं, क्योंकि मैंने उदाहरण के लिए उनके प्रदर्शन को नहीं मापा है, लेकिन वे मेरे अनुभव में अधिक रखरखाव योग्य हैं। मैं अभी भी आपके तर्क के बारे में अनिश्चित हूं कि यह आपके काम को कैसे प्रभावित करता है यदि हुक जैसी संरचना को फ़्लटर कोर में डाल दिया जाता है।

बस gifs को स्कैन करें और कल्पना करना शुरू करें कि आप उनमें से कुछ कैसे बना सकते हैं।

मैंने जीआईएफ स्कैन किया। मैं बिल्डर विजेट्स का उपयोग नहीं करूंगा।
कई एनिमेशन इतने जटिल हैं कि अगर मुझे पता होता कि आपने उन्हें उच्च स्तर के बिल्डरों का उपयोग करके लागू किया है, तो शायद मैं आपके पैकेज का उपयोग नहीं करूंगा।

वैसे भी यह चर्चा अधिक व्यक्तिगत असहमति के साथ हाथ से निकल रही है। हमें मुख्य कार्य पर ध्यान देना चाहिए। मुझे यकीन नहीं है कि यदि विरोधी, जैसा कि मैंने पहले कहा था, हुक समर्थक छोटे उदाहरण कैसे दिखा सकते हैं, ऐसे सुधार खोजें जो वास्तव में उत्पन्न समस्या का समाधान नहीं करते हैं। मुझे लगता है कि हमें अभी के लिए @TimWhiting के भंडार में योगदान देना चाहिए।

कुछ मनमाना जटिल एनीमेशन दिखाना जो किसी भी मौजूदा समाधान द्वारा हल नहीं किया जा सकता है, उदाहरण होगा, और यही हिक्सी पूछता रहता है, मुझे विश्वास है।

किसी ऐसी चीज का उदाहरण दिखाना जो आज संभव नहीं है, इस मुद्दे के दायरे से बाहर है।
यह मुद्दा जो पहले से ही संभव है, उसके सिंटैक्स में सुधार के बारे में है, न कि कुछ चीजों को अनब्लॉक करने के बारे में जो आज संभव नहीं हैं।

कुछ ऐसा प्रदान करने का कोई अनुरोध जो आज संभव नहीं है, विषय से परे है।

@TimWhiting क्या आप अपने https://github.com/TimWhiting/local_widget_state_approaches रेपो में लाइसेंस फ़ाइल डालने पर ध्यान देंगे? कुछ लोग लागू लाइसेंस (बीएसडी, एमआईटी, या इसी तरह के आदर्श) के बिना योगदान करने में असमर्थ हैं।

किया हुआ। क्षमा करें, मेरे पास उदाहरणों पर काम करने के लिए अधिक समय नहीं है, लेकिन शायद मैं इस सप्ताह किसी समय उस पर पहुंच जाऊंगा।

कुछ मनमाना जटिल एनीमेशन दिखाना जो किसी भी मौजूदा समाधान द्वारा हल नहीं किया जा सकता है, उदाहरण होगा, और यही हिक्सी पूछता रहता है, मुझे विश्वास है।

किसी ऐसी चीज का उदाहरण दिखाना जो आज संभव नहीं है, इस मुद्दे के दायरे से बाहर है।
यह मुद्दा जो पहले से ही संभव है, उसके सिंटैक्स में सुधार के बारे में है, न कि कुछ चीजों को अनब्लॉक करने के बारे में जो आज संभव नहीं हैं।

कुछ ऐसा प्रदान करने का कोई अनुरोध जो आज संभव नहीं है, विषय से परे है।

मैंने जो कहा है उसे दोबारा दोहराएं।

एनिमेशन, स्टेट्स आदि से जुड़े कुछ मनमाने जटिल , जिन्हें लिखना मुश्किल है और जिन्हें प्रदर्शन को

मैं कम बॉयलरप्लेट, अधिक पुन: प्रयोज्य, अधिक जादू के लिए धक्का को समझता हूं। मुझे कम कोड भी लिखना पसंद है, और अधिक काम करने वाली भाषा/ढांचा काफी स्वादिष्ट है।
अब तक यहां प्रस्तुत उदाहरणों/समाधान कॉम्बो में से कोई भी कोड में काफी सुधार नहीं करेगा। यही है, अगर हम इस बात से ज्यादा परवाह करते हैं कि हमें कोड की कितनी लाइनें लिखनी हैं।

दोस्तों, यह ठीक है यदि आपके पास वास्तविक उदाहरण बनाने के लिए समय या झुकाव नहीं है, लेकिन कृपया, यदि आप समस्या को समझाने के लिए उदाहरण बनाने में रुचि नहीं रखते हैं, तो आपको यह भी उम्मीद नहीं करनी चाहिए कि लोग समस्या को हल करने के लिए मजबूर महसूस करें ( जो समस्या दिखाने के लिए उदाहरण बनाने की तुलना में बहुत अधिक काम है)। यहां किसी को भी किसी के लिए कुछ करने की आवश्यकता नहीं है, यह एक ओपन सोर्स प्रोजेक्ट है जहां हम सभी एक दूसरे की मदद करने की कोशिश कर रहे हैं।

@TimWhiting क्या आप अपने https://github.com/TimWhiting/local_widget_state_approaches रेपो में लाइसेंस फ़ाइल डालने पर ध्यान देंगे? कुछ लोग लागू लाइसेंस (बीएसडी, एमआईटी, या इसी तरह के आदर्श) के बिना योगदान करने में असमर्थ हैं।

मैंने इन विभिन्न उदाहरणों और कोड स्निपेट्स को बनाने में लगभग 6 घंटे बिताए। लेकिन मैं वास्तव में यह साबित करने के लिए जटिल एनिमेशन के ठोस उदाहरण प्रदान करने का कोई मतलब नहीं देखता कि वे मौजूद हो सकते हैं।

अनुरोध मूल रूप से इसे किसी ऐसी चीज़ में बदलना है जिसे AnimatedContainer द्वारा नियंत्रित नहीं किया जा सकता है:

Container(margin: EdgeInsets.symmetric(vertical: value2 * 20, horizontal: value3 * 30), color: Colors.red.withOpacity(value1));

यह इतना तुच्छ है कि इस मुद्दे पर लगभग जानबूझकर उलझा हुआ है। क्या यह कल्पना करना इतना कठिन है कि मेरे पास कुछ पल्सिंग बटन हो सकते हैं, कुछ कण हिल रहे हैं, शायद कुछ टेक्स्ट फ़ील्ड जो स्केलिंग करते समय फीका हो जाते हैं, या कुछ कार्ड जो फ्लिप करते हैं? हो सकता है कि मैं 15 स्वतंत्र सलाखों के साथ एक साउंडबार बना रहा हूं, हो सकता है कि मैं एक मेनू को स्लाइड कर रहा हूं, लेकिन अलग-अलग आइटम को वापस स्लाइड करने की क्षमता की भी आवश्यकता है। चलता रहा और चलता ही रहा। और यह सिर्फ एनिमेशन के लिए है। यह किसी भी उपयोग के मामले पर लागू होता है जो विजेट के संदर्भ में बोझिल होता है।

मुझे लगता है कि मैंने दोनों बिल्डरों, और वेनिला राज्य-पुन: उपयोग के साथ समस्या के उत्कृष्ट विहित उदाहरण प्रदान किए हैं:
https://github.com/flutter/flutter/issues/51752#issuecomment -671566814
https://github.com/flutter/flutter/issues/51752#issuecomment -671489384

आपको बस इनमें से कई उदाहरणों की कल्पना करनी है (अपना जहर चुनें), 1000+ वर्ग फ़ाइलों की एक परियोजना में दूर-दूर तक फैले हुए हैं, और आपको पठनीयता और रखरखाव के मुद्दों की सही तस्वीर मिलती है जिनसे हम बचने की कोशिश कर रहे हैं।

क्या उदाहरण छवियां जो @esDotDev प्रदान करती हैं, यह दर्शाती हैं कि कैसे नेस्टिंग कोड को पढ़ने में कठिन बनाता है, आपके लिए पर्याप्त नहीं होगा, @Rudiksz ? उनमें क्या कमी है? मुझे लगता है कि वहां कोई प्रदर्शन मेट्रिक्स नहीं हैं लेकिन @rrousselGit यकीन है कि वे बिल्डरों की तुलना में कम प्रदर्शन नहीं कर रहे हैं।

@esDotDev मुझे लगता है कि बिंदु एक विलक्षण विहित उदाहरण है जिससे सभी जीवन चक्र प्रबंधन समाधानों की तुलना की जा सकती है (न केवल हुक बल्कि भविष्य में अन्य भी)। यह TodoMVC के समान सिद्धांत है, आप जरूरी नहीं कि React, Vue, Svelte, आदि में विभिन्न अन्य कार्यान्वयनों को इंगित करें, जैसा कि उनके बीच अंतर दिखाते हैं, आप चाहते हैं कि वे सभी एक ही एप्लिकेशन को लागू करें, _then_ आप तुलना कर सकते हैं।

यह मेरे लिए समझ में आता है, लेकिन मुझे समझ में नहीं आता कि इसे एक पृष्ठ से बड़ा क्यों होना चाहिए।

कई एनिमेशनों को प्रबंधित करना किसी ऐसी चीज़ का आदर्श उदाहरण है जो सामान्य है, इसके लिए बॉयलरप्लेट का एक गुच्छा चाहिए, त्रुटि प्रवण है, और वर्तमान में इसका कोई अच्छा समाधान नहीं है। अगर यह बात नहीं बना रही है, अगर लोग यह कहने जा रहे हैं कि वे यह भी नहीं समझते हैं कि एनिमेशन कैसे जटिल हो सकते हैं, तो स्पष्ट रूप से किसी भी उपयोग के मामले को उपयोग के मामले के संदर्भ में खारिज कर दिया जाएगा, न कि वास्तुशिल्प मुद्दे को हम दर्शाने का प्रयास कर रहे हैं।

निश्चित रूप से, @TimWhiting के रिपॉजिटरी में एक पूर्ण विकसित ऐप नहीं है, इसमें उदाहरण के रूप में एकवचन पृष्ठ हैं, जैसा कि आप कहते हैं, यदि आप उस रिपॉजिटरी के लिए एनीमेशन का एक विहित उदाहरण बना सकते हैं जिससे अन्य लोग अपना समाधान लागू कर सकते हैं, तो यह काम करेगा।

मुझे यह भी नहीं लगता कि हमें एक विशाल ऐप या कुछ भी चाहिए, लेकिन टोडोएमवीसी के समान पर्याप्त जटिलता होनी चाहिए। मूल रूप से यह इतना पर्याप्त होना चाहिए कि आपके विरोधी यह न कह सकें कि "ठीक है, मैं इसे इस तरह और इस तरह से बेहतर कर सकता हूं"।

@ हिक्सी वास्तविक ऐप्स के दृष्टिकोणों की तुलना करने का अनुरोध त्रुटिपूर्ण है।

दो दोष हैं:

• हम अभी तक समस्या पर सहमत नहीं हैं, जैसा कि आपने स्वयं कहा था कि आप इसे नहीं समझते हैं
• हम वास्तविक उत्पादन स्थितियों में उदाहरणों को लागू नहीं कर सकते, क्योंकि हमारे पास लापता टुकड़े होंगे।

उदाहरण के लिए, हम इसका उपयोग करके एक एप्लिकेशन नहीं लिख सकते हैं:

final snapshot = keyword StreamBuilder();

क्योंकि इस पर अमल नहीं हो रहा है।

हम प्रदर्शन को भी नहीं आंक सकते, क्योंकि यह POC बनाम प्रोडक्शन कोड की तुलना कर रहा है।

हम मूल्यांकन नहीं कर सकते हैं कि "हुक को सशर्त रूप से नहीं कहा जा सकता है" त्रुटि-प्रवण है, क्योंकि दुरुपयोग होने पर त्रुटियों को इंगित करने के लिए कोई कंपाइलर एकीकरण नहीं है।

डिजाइनों के प्रदर्शन को देखते हुए, एपीआई की उपयोगिता का मूल्यांकन, हमारे कार्यान्वयन से पहले चीजों को लागू करना ... ये सभी एपीआई डिजाइन का हिस्सा हैं। मेरी नौकरी में आपका स्वागत है। :-) (स्पंदन सामान्य ज्ञान: क्या आप जानते हैं कि डार्ट: ui बनाने से पहले RenderObject और RenderBox et al की पहली कुछ हज़ार पंक्तियों को लागू किया गया था?)

यह इस तथ्य को नहीं बदलता है कि आप असंभव का अनुरोध कर रहे हैं।

यहां किए गए कुछ प्रस्ताव भाषा या विश्लेषक का हिस्सा हैं। इसे लागू करना समाज के लिए संभव नहीं है।

मुझे यकीन नहीं है, अन्य ढांचे और भाषाएं हर समय एपीआई डिज़ाइन करती हैं, मुझे नहीं लगता कि यह यहां बहुत अलग है, या फ़्लटर में अन्य भाषाओं की तुलना में एपीआई डिज़ाइन के लिए कुछ भारी अंतर या कठिनाइयां हैं। जैसा कि, वे इसे संकलक या विश्लेषक समर्थन के बिना करते हैं, वे केवल अवधारणा के प्रमाण हैं।

मैंने एक 'जटिल' एनीमेशन परिदृश्य का एक उदाहरण रखा है जो 3 एनिमेशन का अच्छा उपयोग करता है और यह बॉयलरप्लेट और क्रॉफ्ट से काफी भरा हुआ है।

यह नोट करना महत्वपूर्ण है कि मैं अभी-अभी कोई भी एनीमेशन कर सकता था जिसके लिए प्रारंभिक स्थिति (सभी निहित विगेट्स को समाप्त करना), या z अक्ष पर रोटेशन, या एकल अक्ष पर स्केल, या आईडब्ल्यू द्वारा कवर नहीं किए गए किसी भी अन्य उपयोग के मामले में एक हार्ड स्नैप की आवश्यकता होती है। मुझे चिंता थी कि उन्हें गंभीरता से नहीं लिया जा सकता है (हालांकि मेरे डिजाइनर मुझे यह सामान पूरे दिन सौंप देंगे) इसलिए मैंने कुछ और 'वास्तविक दुनिया' बनाई।

तो यहाँ एक साधारण मचान है, इसमें 3 पैनल हैं जो खुले और बंद स्लाइड करते हैं। यह असतत राज्यों के साथ 3 एनिमेटरों का उपयोग करता है। इस मामले में मुझे वास्तव में AnimatorController के पूर्ण नियंत्रण की आवश्यकता नहीं है, TweenAnimationBuilder ठीक करेगा, लेकिन मेरे पेड़ में परिणामी घोंसला बहुत अवांछित होगा। मैं पेड़ के नीचे टैब को घोंसला नहीं बना सकता, क्योंकि पैनलों में एक-दूसरे के मूल्यों पर निर्भरता होती है। एनिमेटेडकंटेनर यहां कोई विकल्प नहीं है क्योंकि प्रत्येक पैनल को स्क्रीन से स्लाइड करने की आवश्यकता होती है, वे "स्क्विश" नहीं करते हैं।
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));

तो, उस शरीर में १०० पंक्तियों में से, लगभग ४०% या तो शुद्ध बॉयलरप्लेट है। विशेष रूप से 15 लाइनें, जहां कुछ भी गुम या गलत टाइप किया गया, हार्ड-टू-स्पॉट बग का कारण बन सकता है।

यदि हम StatefulProperty जैसी किसी चीज़ का उपयोग करते हैं, तो यह बॉयलरप्लेट को 15% या इससे भी कम कर देगा (लगभग 25 लाइनें बचाता है)। गंभीर रूप से, यह पूरी तरह से स्नीकी बग्स और डुप्लिकेट बिजनेस लॉजिक के मुद्दे को हल करेगा, लेकिन यह अभी भी थोड़ा वर्बोज़ है, खासकर क्योंकि इसके लिए स्टेटफुलविजेट की आवश्यकता होती है, जो ऊपर से 10 लाइन हिट है।

यदि हम 'कीवर्ड' जैसी किसी चीज़ का उपयोग करते हैं तो हम बॉयलरप्लेट लाइनों को अनिवार्य रूप से 0% तक कम कर देते हैं। कक्षा का पूरा ध्यान (अद्वितीय) व्यावसायिक तर्क और दृश्य वृक्ष तत्वों पर हो सकता है। हम सामान्य रूप से StatefulWIdgets का उपयोग बहुत अधिक दुर्लभ बनाते हैं, अधिकांश दृश्य 10 या 20% कम वर्बोज़ और अधिक केंद्रित हो जाते हैं।

साथ ही, यह ध्यान देने योग्य है कि उपरोक्त पैनल परिदृश्य वास्तविक दुनिया है, और वास्तविक दुनिया में स्पष्ट रूप से यह दृष्टिकोण वास्तव में अच्छा नहीं है, इसलिए हमने इसका उपयोग नहीं किया, और आप इसे कोड बेस में नहीं देख पाएंगे। न ही हम नेस्टेड बिल्डरों का उपयोग करेंगे, क्योंकि वे स्थूल दिखते हैं इसलिए आपको वह भी दिखाई नहीं देगा।

हमने एक समर्पित स्लाइडिंगपैनल विजेट बनाया है, जो एक IsOpen संपत्ति लेता है, और खुद को खोलता और बंद करता है। यह आम तौर पर इन उपयोग मामलों में से हर एक में समाधान होता है जहां आपको कुछ विशिष्ट व्यवहार की आवश्यकता होती है, आप राज्य के तर्क को कुछ अति-विशिष्ट विजेट में ले जाते हैं, और आप इसका उपयोग करते हैं। आप मूल रूप से अपना खुद का ImplicitlyAnimatedWidget लिखते हैं।

यह आम तौर पर ठीक काम करता है, लेकिन यह अभी भी समय और प्रयास है, और शाब्दिक रूप से इसका एकमात्र कारण यह है कि एनिमेशन का उपयोग करना इतना कठिन है (जो मौजूद है क्योंकि सामान्य रूप से राज्य के घटकों का पुन: उपयोग करना इतना कठिन है)। उदाहरण के लिए यूनिटी या एआईआर में, मैं केवल एक अक्ष पर एक पैनल को स्थानांतरित करने के लिए एक समर्पित वर्ग नहीं बनाऊंगा, यह केवल कोड की एक पंक्ति को खोलने या बंद करने के लिए होगा, समर्पित-विजेट के लिए कुछ भी नहीं होगा। स्पंदन में हमें एक समर्पित विजेट बनाना होता है, क्योंकि यह एनीमेटरकंट्रोलर के बूटस्ट्रैपिंग और टियरडाउन को एनकैप्सुलेट करने का एकमात्र उचित तरीका है (जब तक कि हम टैब के साथ घोंसला, घोंसला, घोंसला नहीं बनाना चाहते)

यहाँ मेरा मुख्य बिंदु यह है कि वास्तविक दुनिया के उदाहरणों को खोजना इतना कठिन क्यों है। डेवलपर्स के रूप में हम इन चीजों को अपने कोडबेस में बहुत अधिक मौजूद नहीं होने दे सकते हैं, इसलिए हम उनके आसपास कम-से-आदर्श-लेकिन-प्रभावी वर्कअराउंड के साथ काम करते हैं। फिर जब आप कोडबेस को देखते हैं, तो आप इन वर्कअराउंड को प्रभाव में देखते हैं और सब कुछ ठीक लगता है, लेकिन हो सकता है कि टीम जो बनाना चाहती थी, उसे वहां पहुंचने में उन्हें 20% अधिक समय लगा हो, यह कुल हो सकता है डिबग करने के लिए दर्द, इनमें से कोई भी कोड पर स्पष्ट नज़र नहीं है।

पूर्णता के लिए, यहां वही उपयोग मामला है, जो बिल्डरों के साथ बनाया गया है। लाइन की संख्या बहुत कम हो गई है, बग के लिए कोई मौका नहीं है, विदेशी अवधारणा आरई टिकरप्रोवाइडरमिक्सिन सीखने की कोई आवश्यकता नहीं है ... ) व्यावसायिक तर्क को पढ़ने में उसकी आवश्यकता से कहीं अधिक कठिन बनाता है।

``` डार्ट
वर्ग _SlidingPanelViewState राज्य का विस्तार करता है{
बूल isLeftMenuOpen = true;
बूल isRightMenuOpen = true;
बूल isBtmMenuOpen = true;

@ ओवरराइड
विजेट निर्माण (बिल्ड कॉन्टेक्स्ट संदर्भ) {
वापसी ट्वीनएनीमेशनबिल्डर(
बीच: बीच (शुरू: 0, अंत: isLeftMenuOpen? 1: 0),
अवधि: विजेट.स्लाइडअवधि,
बिल्डर: (_, लेफ्टएनीमवैल्यू, __) {
वापसी ट्वीनएनीमेशनबिल्डर(
बीच: बीच (शुरू: 0, अंत: isRightMenuOpen? 1: 0),
अवधि: विजेट.स्लाइडअवधि,
बिल्डर: (_, राइटएनीमवैल्यू, __) {
वापसी ट्वीनएनीमेशनबिल्डर(
बीच: बीच (शुरू: 0, अंत: isBtmMenuOpen? 1: 0),
अवधि: विजेट.स्लाइडअवधि,
निर्माता: (_, btmAnimValue, __) {
डबल लेफ्टपैनलसाइज = 320;
डबल लेफ्टपैनेलपोस = -लेफ्टपैनेलसाइज * (1 - लेफ्टएनिमवैल्यू);
डबल राइटपैनलसाइज = २३०;
डबल राइटपैनेलपोस = -राइटपैनेलसाइज * (1 - राइटएनीमवैल्यू);
डबल बॉटमपैनेलसाइज = ८०;
डबल बॉटमपैनेलपोस = -बॉटमपैनेलसाइज * (1 - btmAnimValue);
वापसी ढेर (
बच्चे: [
// बीजी
कंटेनर (रंग: रंग। सफेद),
// मुख्य सामग्री क्षेत्र
स्थित(
शीर्ष: 0,
लेफ्ट: लेफ्टपैनलपॉस + लेफ्टपैनल साइज,
नीचे: बॉटमपैनेलपॉस + बॉटमपैनेलसाइज,
दाएं: दाएंपैनलपोस + दाएंपैनेलसाइज,
बच्चा: ChannelInfoView (),
),
// लेफ्ट पैनल
स्थित(
शीर्ष: 0,
लेफ्ट: लेफ्टपैनलपोस,
बॉटम: बॉटमपैनलपॉस + बॉटमपैनेलसाइज,
चौड़ाई: बाएं पैनल आकार,
बच्चा: चैनलमेनू (),
),
//नीचे का पैनल
स्थित(
बाएं: 0,
दाएं: 0,
नीचे: बॉटमपैनलपोस,
ऊंचाई: निचला पैनल आकार,
बच्चा: नोटिफिकेशनबार (),
),
// दायां पैनल
स्थित(
शीर्ष: 0,
दाएं: दाएंपैनलपॉस,
बॉटम: बॉटमपैनलपॉस + बॉटमपैनेलसाइज,
चौड़ाई: दायां पैनल आकार,
बच्चा: सेटिंग्समेनू (),
),
// बटन
पंक्ति(
बच्चे: [
बटन ("बाएं", () => सेटस्टेट (() => isLeftMenuOpen =! isLeftMenuOpen)),
बटन ("बीटीएम", () => सेटस्टेट (() => isBtmMenuOpen =! isBtmMenuOpen)),
बटन ("दाएं", () => सेटस्टेट (() => isRightMenuOpen =! isRightMenuOpen)),
],
)
],
);
},
);
},
);
},
);
}
}

वह आखिरी वाला दिलचस्प है ... मैं मूल रूप से सुझाव देने जा रहा था कि बिल्डरों को स्टैक के बजाय स्थिति वाले विजेट के आसपास होना चाहिए (और मैं अभी भी बाएं और दाएं पैनल के लिए सुझाव दूंगा) लेकिन तब मुझे एहसास हुआ कि नीचे वाला प्रभावित करता है तीनों, और मैंने महसूस किया कि बिल्डर आपको केवल एक child तर्क दे रहा है, वास्तव में पर्याप्त नहीं है, क्योंकि आप वास्तव में Container और Row स्थिर रखना चाहते हैं बनाता है। मुझे लगता है कि आप उन्हें पहले बिल्डर के ऊपर बना सकते हैं।

यहाँ मेरा मुख्य बिंदु यह है कि वास्तविक दुनिया के उदाहरणों को खोजना इतना कठिन क्यों है। डेवलपर्स के रूप में हम इन चीजों को अपने कोडबेस में बहुत अधिक मौजूद नहीं होने दे सकते हैं, इसलिए हम उनके आसपास कम-से-आदर्श-लेकिन-प्रभावी वर्कअराउंड के साथ काम करते हैं। फिर जब आप कोडबेस को देखते हैं, तो आप इन वर्कअराउंड को प्रभाव में देखते हैं और सब कुछ ठीक लगता है, लेकिन हो सकता है कि टीम जो बनाना चाहती थी, उसे वहां पहुंचने में उन्हें 20% अधिक समय लगा हो, यह कुल हो सकता है डिबग करने के लिए दर्द, इनमें से कोई भी कोड पर स्पष्ट नज़र नहीं है।

रिकॉर्ड के लिए, यह कोई दुर्घटना नहीं है। यह डिजाइन द्वारा बहुत ज्यादा है। इन विजेट के अपने स्वयं के विजेट होने से प्रदर्शन में सुधार होता है। हम इसके लिए बहुत अधिक इरादा रखते हैं कि लोग फ़्लटर का उपयोग कैसे करते हैं। यह वही है जिसका मैं ऊपर उल्लेख कर रहा था जब मैंने उल्लेख किया था "फ्लटर के डिजाइन दर्शन का एक बड़ा हिस्सा लोगों को सही विकल्प की ओर मार्गदर्शन करना है"।

मैं मूल रूप से यह सुझाव देने जा रहा था कि बिल्डरों को स्टैक के बजाय पोजिशनिंग विजेट्स के आसपास होना चाहिए (और मैं अभी भी सुझाव दूंगा कि बाएं और दाएं पैनल के लिए)

मैंने वास्तव में इसे संक्षिप्तता के लिए छोड़ दिया था, लेकिन आम तौर पर मुझे यहां एक सामग्री कंटेनर चाहिए, और यह अपनी स्थिति को परिभाषित करने के लिए सभी 3 मेनू के आकारों का उपयोग करेगा। मतलब सभी 3 को पेड़ के शीर्ष पर होना चाहिए, और यदि कोई पुनर्निर्माण होता है, तो मुझे पुनर्निर्माण के लिए पूरे दृश्य की आवश्यकता होती है, इसके आसपास नहीं। यह मूल रूप से आपका क्लासिक डेस्कटॉप-शैली का मचान है।

बेशक हम पेड़ को तोड़ना शुरू कर सकते हैं, हमेशा एक विकल्प, हम इसे बड़े विगेट्स के लिए बहुत उपयोग करते हैं, लेकिन मैंने कभी नहीं देखा है कि वास्तव में एक नज़र में ग्रोकेबिलिटी में सुधार होता है, पाठक को उस पर एक अतिरिक्त संज्ञानात्मक कदम की आवश्यकता होती है बिंदु। दूसरी बार जब आप पेड़ को तोड़ते हैं, तो मैं अचानक चर असाइनमेंट के ब्रेड क्रम्ब ट्रेल का अनुसरण कर रहा हूं ताकि यह पता लगाया जा सके कि यहां क्या पारित किया जा रहा है और कैसे पूरी चीज एक साथ फिट हो जाती है। पेड़ को सुपाच्य वृक्ष के रूप में प्रस्तुत करना मेरे अनुभव से तर्क करना हमेशा आसान होता है।

समर्पित RenderObject के लिए शायद एक अच्छा उपयोग केस।

या 3 आसानी से प्रबंधित AnimatorObjects जो स्वयं को विजेट जीवनचक्र में शामिल कर सकते हैं:D

इन विजेट के अपने स्वयं के विजेट होने से प्रदर्शन में सुधार होता है।

चूंकि हम यहां ठोस हो रहे हैं: इस मामले में क्योंकि यह एक मचान है, प्रत्येक उप-दृश्य पहले से ही इसका अपना विजेट है, यह लड़का सिर्फ बच्चों को बिछाने और अनुवाद करने के लिए ज़िम्मेदार है। बच्चे बॉटममेनू (), चैनलमेनू (), सेटिंग्स व्यू (), मेनकंटेंट () आदि होंगे

इस मामले में हम स्व-निहित विगेट्स का एक गुच्छा लपेट रहे हैं, स्व-निहित विगेट्स की एक और परत के साथ, बस उन्हें स्थानांतरित करने के लिए बॉयलरप्लेट का प्रबंधन करने के लिए। मुझे विश्वास नहीं है कि यह एक प्रदर्शन जीत है? इस मामले में हमें उस ढांचे में धकेला जा रहा है जो हम करना चाहते हैं, न कि वह जो हम वास्तव में करना चाहते हैं, जो कि अधिक संक्षिप्त और सुसंगत तरीके से समान रूप से प्रदर्शन करने वाले दृश्य को लिखना है।

[संपादित करें] मैं इस संदर्भ को जोड़ने के लिए उदाहरणों को अपडेट करूंगा

मेरे द्वारा एक समर्पित RenderObject का सुझाव देने का कारण यह है कि यह लेआउट को बेहतर बनाएगा। मैं मानता हूं कि एनीमेशन पहलू एक स्टेटफुल विजेट में होगा, यह केवल तीन 0..1 डबल्स (वैल्यू 1, वैल्यू 2, वैल्यू 3) को स्टैक गणित के बजाय रेंडर ऑब्जेक्ट में पास कर देगा। लेकिन यह ज्यादातर इस चर्चा के लिए एक पक्ष है; उस बिंदु पर जहां आप यह कर रहे हैं, आप अभी भी हुक या उस स्टेटफुल विजेट में कुछ इसी तरह का सरलीकरण करना चाहते हैं।

अधिक प्रासंगिक नोट पर, मुझे @TimWhiting की परियोजना के लिए एक डेमो बनाने में एक दरार थी: https://github.com/TimWhiting/local_widget_state_approaches/pull/1
मैं उत्सुक हूं कि एक हुक संस्करण कैसा दिखेगा। मुझे यकीन नहीं है कि मैं इसे सरल बनाने का एक अच्छा तरीका देख सकता हूं, विशेष रूप से प्रदर्शन विशेषताओं को बनाए रखना (या उन्हें सुधारना; वहां एक ऐसी जगह दिखा रहा है जहां यह वर्तमान में उप-रूपी है)।

(मैं भी बहुत उत्सुक हूं अगर यह ऐसी चीज है जहां हमें इसे सरल बनाने का कोई तरीका मिल गया है, तो हमें यहां किया जाएगा, या यदि इसमें महत्वपूर्ण चीजें गुम हैं जिन्हें हमें पूरा करने से पहले हल करने की आवश्यकता होगी।)

क्या इस उदाहरण के लिए पुनर्स्थापना सामग्री महत्वपूर्ण है? मुझे इसके कारण कठिन समय हो रहा है, और वास्तव में यह नहीं पता कि RestorationMixin क्या करता है। मुझे लगता है कि यह है... मेरे लिए इसे समझने में थोड़ा समय लगेगा। मुझे यकीन है कि रेमी 4 सेकंड के फ्लैट में हुक संस्करण को क्रैंक कर देगा :)

का उपयोग करते हुए बहाली एपीआई का उपयोग कर HookWidget बजाय StatefulHookWidget इस समय समर्थित नहीं है।

आदर्श रूप से हमें बदलने में सक्षम होना चाहिए

final value = useState(42);

में:

final value = useRestorableInt(42);

लेकिन इसके लिए कुछ सोच की जरूरत है, क्योंकि वर्तमान बहाली एपीआई वास्तव में हुक के साथ दिमाग में डिजाइन नहीं किया गया था।

एक साइड नोट के रूप में, रिएक्ट हुक एक "कुंजी" सुविधा के साथ आता है, आमतौर पर इस तरह उपयोग किया जाता है:

int userId;

Future<User> user = useMemo(() => fetchUser(id), [id]);

जहां इस कोड का अर्थ है "कॉलबैक के परिणाम को कैश करें, और जब भी सरणी के अंदर कुछ भी बदलता है तो कॉलबैक का पुनर्मूल्यांकन करें"

Flutter_hooks ने इसका 1to1 पुन: कार्यान्वयन किया है (क्योंकि यह सिर्फ एक बंदरगाह है), लेकिन मुझे नहीं लगता कि हम फ़्लटर अनुकूलित कोड के लिए यही करना चाहते हैं।

हम शायद चाहेंगे:

int userId;

Future<User> user = useMemo1(id, (id) => fetchUser(id));

जो एक ही काम करेगा, लेकिन सूची आवंटन से बचकर और एक फ़ंक्शन टियर-ऑफ का उपयोग करके स्मृति दबाव को हटा दें

इस स्तर पर यह महत्वपूर्ण नहीं है, लेकिन यह ध्यान देने योग्य है कि क्या हम उदाहरण के लिए flutter_hooks का उपयोग करने की योजना बना रहे हैं।

@ हिक्सी मैंने आपके एनीमेशन उदाहरण को हुक में पोर्ट किया है

यह एक दिलचस्प उदाहरण था, इसके बारे में सोचने के लिए यश!
इसमें एक अच्छा उदाहरण है, डिफ़ॉल्ट रूप से, "सक्रिय" और "अवधि" का कार्यान्वयन हर जगह होता है (और उस पर एक दूसरे पर निर्भर करता है)।
इस बिंदु पर कई "अगर (सक्रिय)" / "नियंत्रक.दोहराना" कॉल थे

जबकि हुक के साथ, सभी तर्कों को घोषणात्मक रूप से नियंत्रित किया जाता है और एक ही स्थान पर केंद्रित किया जाता है, जिसमें कोई डुप्लिकेट नहीं होता है।

उदाहरण यह भी दिखाता है कि वस्तुओं को आसानी से कैश करने के लिए हुक का उपयोग कैसे किया जा सकता है - जिसने महंगे विजेट के पुनर्निर्माण के मुद्दे को बहुत बार ठीक किया।
हमें कॉन्स्टेबल कंस्ट्रक्टर्स का लाभ मिलता है, लेकिन यह डायनेमिक मापदंडों के साथ काम करता है।

हमें एक बेहतर हॉट-रीलोड भी मिलता है। हम पृष्ठभूमि रंग के लिए Timer.Periodic अवधि बदल सकते हैं और तुरंत प्रभाव में परिवर्तन देख सकते हैं।

@rrousselGit क्या आपके पास एक लिंक है? मैंने @TimWhiting के भंडार में कुछ भी नया नहीं देखा।

का उपयोग करते हुए बहाली एपीआई का उपयोग कर HookWidget बजाय StatefulHookWidget इस समय समर्थित नहीं है।

हम जो भी समाधान लेकर आते हैं, हमें यह सुनिश्चित करने की आवश्यकता है कि उसे हर अंतिम मिश्रण के बारे में जानने की आवश्यकता नहीं है। अगर कोई हमारे समाधान का उपयोग किसी अन्य पैकेज के साथ संयोजन में करना चाहता है जो TickerProviderStateMixin या RestorationMixin की तरह एक मिश्रण पेश करता है, तो उन्हें ऐसा करने में सक्षम होना चाहिए।

https://github.com/TimWhiting/local_widget_state_approaches/pull/3

सहमत हूं, लेकिन मैं इसके बारे में चिंतित नहीं हूं। useAnimationController को उदाहरण के लिए उपयोगकर्ताओं को SingleTickerProvider की परवाह करने की आवश्यकता नहीं है।

AutomaritKeepAlive उसी उपचार से लाभान्वित हो सकता है।
एक चीज जो मैं सोच रहा था, वह है "useKeepAlive (बूल)" हुक

यह मिक्सिन और "सुपर.बिल्ड (संदर्भ)" दोनों से बचा जाता है (बाद वाला काफी भ्रमित करने वाला)

एक और दिलचस्प बिंदु रिफैक्टरिंग के दौरान आवश्यक परिवर्तन हैं।

उदाहरण के लिए, हम कच्चे दृष्टिकोण बनाम हुक के लिए TickerMode को लागू करने के लिए आवश्यक परिवर्तनों के बीच अंतर की तुलना कर सकते हैं:

• स्टेटफुलविजेट https://github.com/TimWhiting/local_widget_state_approaches/pull/2/commits/0cb7bf60143ead59131b5729044cb51344ffd3fb
• हुक https://github.com/TimWhiting/local_widget_state_approaches/pull/3/commits/b955aab9e5fb02736106732dac9d2398579515ad

कुछ अन्य चीजों को अंतर में मिलाया जाता है, लेकिन हम इससे देख सकते हैं कि:

• तर्क को पूरी तरह से अलग जीवन-चक्र में ले जाने के लिए 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'),
+        );
+      }
    );
  },
);

दूसरे अंतर में यह स्पष्ट नहीं है कि Container अपरिवर्तित है और केवल Text बदल गया है

@rrousselGit क्या आपको लगता है कि कीवर्ड समर्थन के साथ यह कैसा दिख सकता है, इसका प्रतिनिधित्व करने वाले संस्करण को आजमाने और करने के लिए यह समझ में आता है? क्या यह काफी हद तक केवल एक समर्पित 'उपयोग' कीवर्ड के साथ हुक के समान है, या क्या इसका पालन करना और भी आसान हो जाता है? हुक दृष्टिकोण की तुलना एक समान स्तर पर करना मुश्किल है क्योंकि इसमें कई विदेशी अवधारणाएं हैं जैसे उपयोग प्रभाव, उपयोग मेमो इत्यादि जो मुझे लगता है कि इससे अधिक जादुई दिखता है?

एक और ध्यान देने वाली बात यह है कि जहां यह सब वास्तव में घर पर होगा, यदि आपके पास कई विजेट हैं, तो सभी को इस 'रंग-कदम' तर्क को साझा करने की आवश्यकता है, लेकिन परिणामी रंग का उपयोग पूरी तरह से अलग तरीके से किया जाता है। हुक-शैली दृष्टिकोण के साथ, हम जो भी तर्क पुन: उपयोग करने के लिए समझ में आता है, हम बस बंडल करते हैं, और हम बस इसका उपयोग करते हैं। कोई वास्तुशिल्प कोने नहीं हैं जिनमें हमें मजबूर किया जाता है, यह वास्तव में अज्ञेयवादी और लचीला है।

स्टेटफुल दृष्टिकोण में, हमें मजबूर किया जाता है

• तर्क को कॉपी और पेस्ट करना (बहुत ही अनुरक्षणीय)
• एक बिल्डर का उपयोग करना (सुपर पठनीय नहीं, विशेष रूप से घोंसले का उपयोग करते समय)
• मिश्रण (अच्छी तरह से रचना नहीं करता है, विभिन्न मिश्रणों के लिए उनके साझा राज्य में संघर्ष के लिए बहुत आसान है)

मुझे लगता है कि मुख्य बात यह है कि बाद में, आपको तुरंत एक वास्तुशिल्प समस्या है, मुझे इसे अपने पेड़ में कहां रखना चाहिए, मैं इसे सबसे अच्छा कैसे समझा सकता हूं, क्या यह एक निर्माता होना चाहिए, या शायद एक कस्टम विजेट होना चाहिए? पूर्व के साथ एकमात्र निर्णय यह है कि किस फ़ाइल में पुन: उपयोग किए गए तर्क के इस हिस्से को सहेजना है, आपके पेड़ पर कोई प्रभाव नहीं पड़ता है। यह वास्तुकला की दृष्टि से बहुत अच्छा है जब आप इनमें से कुछ लॉजिक एनकैप्सुलेशन का एक साथ उपयोग करना चाहते हैं, उन्हें अपने पदानुक्रम में ऊपर और नीचे ले जाना चाहते हैं या एक सहोदर विजेट में ले जाना चाहते हैं, आदि।

मैं किसी भी तरह से एक विशेषज्ञ डेवलपर नहीं हूं। लेकिन तर्क का

मैंने लंबे समय से Vue.js का उपयोग नहीं किया है, लेकिन उनके पास अपने अगले संस्करण के लिए अपना स्वयं का एपीआई (हुक से प्रेरित) भी है, यह देखने लायक हो सकता है।

• Vue 3 संरचना एपीआई
• रिएक्ट हुक के साथ Vue 3 संरचना API तुलना

और सीएमआईआईडब्ल्यू, मुझे लगता है कि प्रतिक्रिया हुक के नियम (सशर्त का उपयोग न करें), संरचना एपीआई के साथ लागू नहीं होते हैं। इसलिए, आपको नियमों को लागू करने के लिए लिंटर का उपयोग करने की आवश्यकता नहीं है।

फिर से प्रेरणा खंड ओपी को यहाँ दृढ़ता से पुष्ट करता है:

प्रेरणा
जैसे-जैसे समय के साथ सुविधाएँ बढ़ती हैं, जटिल घटकों का कोड तर्क करना कठिन होता जाता है। यह विशेष रूप से तब होता है जब डेवलपर्स कोड पढ़ रहे होते हैं जो उन्होंने स्वयं नहीं लिखा था।
[वहां एक] कई घटकों के बीच तर्क निकालने और पुन: उपयोग करने के लिए एक स्वच्छ और लागत मुक्त तंत्र का अभाव था।

वहां मुख्य शब्द "स्वच्छ" और "लागत मुक्त" हैं। मिक्सिन लागत मुक्त हैं लेकिन वे साफ नहीं हैं। बिल्डर्स साफ-सुथरे हैं, लेकिन वे पठनीयता के अर्थ में लागत-मुक्त नहीं हैं, न ही विजेट आर्किटेक्चरल अर्थ में क्योंकि वे पेड़ के चारों ओर घूमना और पदानुक्रम के संदर्भ में तर्क करना कठिन हैं।

मुझे यह भी लगता है कि पठनीयता चर्चा में नोट करना महत्वपूर्ण है: "_ विशेष रूप से तब होता है जब डेवलपर्स कोड पढ़ रहे हों, उन्होंने नहीं लिखा_"। बेशक _your_ नेस्टेड बिल्डर को पढ़ना आसान हो सकता है, आप जानते हैं कि वहां क्या है और आराम से इसे छोड़ सकते हैं, यह किसी और के कोड को पढ़ रहा है, जैसे आप किसी बड़े प्रोजेक्ट पर करते हैं, या आपका अपना कोड हफ्तों/महीने पहले, जब यह काफी हो जाता है इन चीजों को पार्स और दोबारा करने के लिए परेशान/कठिन।

कुछ अन्य विशेष रूप से प्रासंगिक खंड।

केवल घटकों का होना ही पर्याप्त क्यों नहीं है:

बनाना ... घटक हमें कोड के पुन: प्रयोज्य टुकड़ों में इसकी कार्यक्षमता के साथ युग्मित इंटरफ़ेस के दोहराए जाने योग्य भागों को निकालने की अनुमति देता है। रखरखाव और लचीलेपन के मामले में यह अकेले हमारे आवेदन को बहुत दूर तक ले जा सकता है। हालांकि, हमारे सामूहिक अनुभव ने साबित कर दिया है कि यह अकेले पर्याप्त नहीं हो सकता है, खासकर जब आपका आवेदन वास्तव में बड़ा हो रहा है - कई सैकड़ों घटकों पर विचार करें। इतने बड़े अनुप्रयोगों के साथ काम करते समय, कोड साझा करना और पुन: उपयोग करना विशेष रूप से महत्वपूर्ण हो जाता है।

तार्किक विखंडन को कम करने और चीजों को और अधिक मजबूती से एनकैप्सुलेट करने पर एक जीत क्यों है:

विखंडन वह है जो एक जटिल घटक को समझना और बनाए रखना मुश्किल बनाता है। विकल्पों का पृथक्करण अंतर्निहित तार्किक चिंताओं को अस्पष्ट करता है। इसके अलावा, जब एक तार्किक चिंता पर काम करते हैं, तो हमें प्रासंगिक कोड के लिए विकल्प ब्लॉक के आसपास लगातार "कूदना" पड़ता है। यह बहुत अच्छा होगा यदि हम उसी तार्किक चिंता से संबंधित कोड को जोड़ सकें।

मुझे उत्सुकता है कि क्या प्रामाणिक उदाहरणों के लिए अन्य प्रस्ताव हैं जिन्हें हम मेरे द्वारा सबमिट किए गए प्रस्ताव के अलावा सुधारने का प्रयास कर रहे हैं।
अगर यह शुरुआती बिंदु है जिसका लोग उपयोग करना चाहते हैं तो यह बहुत अच्छा है। हालांकि, मैं कहूंगा कि अभी इसके साथ सबसे बड़ी समस्या वाचालता है; उस उदाहरण में पुन: उपयोग करने के लिए बहुत अधिक कोड नहीं है। तो यह मेरे लिए स्पष्ट नहीं है कि क्या यह ओपी में वर्णित समस्या का अच्छा प्रतिनिधित्व है।

मैं कुछ और सोच रहा हूं कि उन विशेषताओं को कैसे व्यक्त किया जाए जिन्हें मैं व्यक्तिगत रूप से एक समाधान में देखूंगा, और इसने मुझे उन बड़ी समस्याओं में से एक का एहसास कराया जो मैं वर्तमान हुक प्रस्ताव के साथ देखता हूं, जो एक कारण है कि मैं नहीं करूंगा इसे स्पंदन ढांचे में विलय करना चाहते हैं: स्थानीयता और एनकैप्सुलेशन, या यों कहें, इसकी कमी। हुक का डिज़ाइन वैश्विक स्थिति का उपयोग करता है (उदाहरण के लिए स्थिर है कि वर्तमान में कौन सा विजेट बनाया जा रहा है)। IMHO यह एक डिज़ाइन विशेषता है जिससे हमें बचना चाहिए। सामान्य तौर पर हम एपीआई को स्व-निहित बनाने की कोशिश करते हैं, इसलिए यदि आप एक पैरामीटर के साथ एक फ़ंक्शन को कॉल करते हैं, तो आपको विश्वास होना चाहिए कि यह उस पैरामीटर के बाहर के मूल्यों के साथ कुछ भी करने में सक्षम नहीं होगा (यही कारण है कि हम BuildContext को पास करते हैं , के बराबर होने के बजाय useContext )। मैं यह नहीं कह रहा हूं कि यह एक ऐसी विशेषता है जिसे हर कोई अनिवार्य रूप से चाहेगा; और निश्चित रूप से लोग हुक का उपयोग कर सकते हैं यदि यह उनके लिए कोई समस्या नहीं है। बस यही है कि मैं स्पंदन में और अधिक करने से बचना चाहता हूं। हर बार जब हमारे पास वैश्विक स्थिति होती है (उदाहरण के लिए बाइंडिंग में) तो हमें इसका पछतावा होता है।

हुक शायद संदर्भ के तरीके हो सकते हैं (मुझे लगता है कि वे शुरुआती संस्करण में थे), लेकिन ईमानदारी से, मुझे उन्हें विलय करने में ज्यादा मूल्य नहीं दिख रहा है क्योंकि वे वर्तमान में हैं। मर्ज को पैकेज को अलग करने के लिए कुछ रोमांच की आवश्यकता होगी, जैसे बढ़ा हुआ प्रदर्शन या हुक विशिष्ट डिबगिंग टूल। अन्यथा वे केवल भ्रम में जोड़ देंगे, उदाहरण के लिए आपके पास सुनने योग्य सुनने के 3 आधिकारिक तरीके होंगे: एनिमेटेडबिल्डर, स्टेटफुल विजेट और उपयोग योग्य।

तो मेरे लिए, जाने का रास्ता कोड पीढ़ी में सुधार कर रहा है - मैंने कुछ बदलावों का प्रस्ताव दिया है: https://github.com/flutter/flutter/issues/63323

यदि इन सुझावों को वास्तव में लागू किया गया था, तो जो लोग अपने ऐप में जादुई स्विफ्टयूआई-जैसे समाधान चाहते थे, वे सिर्फ एक पैकेज बना सकते थे और किसी और को परेशान नहीं कर सकते थे।

इस स्तर पर हुक की वैधता पर चर्चा करना एक प्रकार का विषय है, क्योंकि हम अभी भी समस्या पर सहमत नहीं हैं जहाँ तक मुझे पता है।

जैसा कि इस मुद्दे में कई बार कहा गया है, कई अन्य समाधान हैं, जिनमें से कई भाषा की विशेषताएं हैं।
हुक किसी अन्य तकनीक से मौजूदा समाधान का एक बंदरगाह है जो अपने सबसे बुनियादी रूप में लागू करने के लिए अपेक्षाकृत सस्ता है।

यह सुविधा हुक से पूरी तरह अलग पथ ले सकती है, जैसे कि स्विफ्टयूआई या जेटपैक कंपोज़ क्या करते हैं; "नामित मिश्रित" प्रस्ताव, या बिल्डर्स प्रस्ताव के लिए वाक्य रचना चीनी।

मैं इस तथ्य पर जोर देता हूं कि यह मुद्दा इसके मूल में StreamBuilder जैसे पैटर्न के सरलीकरण के लिए कह रहा है:

• StreamBuilder की नेस्टिंग के कारण खराब पठनीयता/लेखन क्षमता है
• StreamBuilder के लिए मिक्सिन और फ़ंक्शन एक संभावित विकल्प नहीं हैं
• सभी StatefulWidgets में StreamBuilder के कार्यान्वयन को कॉपी-पेस्ट करना उचित नहीं है

अब तक की सभी टिप्पणियों में StreamBuilder के विकल्पों का उल्लेख किया गया है, दोनों अलग-अलग व्यवहारों के लिए (एक डिस्पोजेबल ऑब्जेक्ट बनाना, HTTP अनुरोध करना, ...) या विभिन्न सिंटैक्स का प्रस्ताव देना।

मुझे यकीन नहीं है कि और क्या कहना है, इसलिए मुझे नहीं लगता कि हम आगे कैसे प्रगति कर सकते हैं।
यह क्या है जिसे आप इस कथन @Hixie में नहीं समझते/असहमत नहीं हैं?

@rrousselGit क्या आप एक डेमो ऐप बना सकते हैं जो इसे दिखाता है? मैंने एक डेमो ऐप बनाने की कोशिश की जो दिखाता है कि मुझे क्या समस्या है, लेकिन जाहिर तौर पर मुझे वह अधिकार नहीं मिला। (मुझे यकीन नहीं है कि "स्ट्रीमबिल्डर जैसे पैटर्न" और मैंने डेमो ऐप में क्या किया है, के बीच क्या अंतर है।)

• StreamBuilder की नेस्टिंग के कारण खराब पठनीयता/लेखन क्षमता है

आपने पहले ही कहा है कि वर्बोसिटी कोई मुद्दा नहीं है। नेस्टिंग वर्बोज़ होने का एक और पहलू है। यदि नेस्टिंग वास्तव में एक मुद्दा है तो हमें पैडिंग, विस्तारित, फ्लेक्सिबल, सेंटर, साइज़बॉक्स और अन्य सभी विजेट्स के बाद जाना चाहिए जो बिना किसी वास्तविक कारण के नेस्टिंग जोड़ते हैं। लेकिन मोनोलिथिक विगेट्स को विभाजित करके नेस्टिंग को आसानी से हल किया जा सकता है।

सभी StatefulWidgets में StreamBuilder के कार्यान्वयन को कॉपी-पेस्ट करना उचित नहीं है

आपका मतलब कोड की पंक्तियों को कॉपी-पेस्ट करना है जो स्टेटफुल विजेट्स को बनाने और निपटाने के लिए आवश्यक धाराओं को बनाते हैं और उनका निपटान करते हैं? हाँ, यह बिल्कुल उचित है।

यदि आपके पास 10 या भगवान ने सैकड़ों _भिन्न_ कस्टम स्टेटफुल विजेट्स को मना किया है, जिन्हें अपनी स्वयं की धाराएं बनाने/निपटान करने की आवश्यकता है - हुक शब्दावली में "उपयोग"-, आपको ""तर्क" पुन: उपयोग या घोंसले के बारे में चिंता करने की बड़ी समस्याएं हैं। मुझे चिंता होगी इस बारे में कि मेरे ऐप को पहली बार में इतनी सारी अलग-अलग धाराएँ क्यों बनानी हैं।

निष्पक्ष होने के लिए, मुझे लगता है कि किसी के लिए यह सोचना ठीक है कि कोई विशेष पैटर्न उनके ऐप में उचित नहीं है। (इसका मतलब यह नहीं है कि ढांचे को मूल रूप से समर्थन करना है, लेकिन कम से कम पैकेज को इसे हल करने की अनुमति देना अच्छा होगा।) अगर कोई stream.listen या StreamBuilder(stream) उपयोग नहीं करना चाहता है।

निष्पक्ष होने के लिए, मुझे लगता है कि किसी के लिए यह सोचना ठीक है कि कोई विशेष पैटर्न उनके ऐप में उचित नहीं है।

मैं आपके समान पृष्ठ पर 100% हूं।
ज़रूर, लोग अपने ऐप्स में जो चाहें कर सकते हैं। मैं जो प्राप्त करने की कोशिश कर रहा हूं वह यह है कि इस धागे में वर्णित सभी समस्याएं और कठिनाइयां खराब प्रोग्रामिंग आदतों का परिणाम हैं, और वास्तव में डार्ट या स्पंदन से बहुत कम लेना-देना है। यह सिर्फ मेरी राय है, लेकिन मैं कहूंगा कि अगर कोई ऐसा ऐप लिख रहा है जो पूरे स्थान पर दर्जनों धाराएं बनाता है तो ढांचे को "सुधार" करने के लिए कहने से पहले अपने ऐप डिज़ाइन की समीक्षा करनी चाहिए।

उदाहरण के लिए, हुक कार्यान्वयन जिसने इसे उदाहरण रेपो में बनाया है।

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

मुझे इसके बारे में बुरा लग रहा है, इसलिए मैंने कुछ आंतरिक जांच की, और क्या हो रहा है यह जांचने के लिए कुछ डीबग प्रिंट जोड़े।
आप नीचे दिए गए आउटपुट से देख सकते हैं कि सुनने योग्य हुक मौसम की जांच करता है, इसे हर एनीमेशन टिक पर अपडेट किया गया है। जैसा कि, वह विजेट था जो सुनने योग्य अद्यतन "उपयोग" करता था? क्या अवधि बदली गई थी? क्या इंस्टेंस को बदल दिया गया था?
मेमोइज्ड हुक, मुझे यह भी नहीं पता कि इससे क्या बात है। यह शायद किसी ऑब्जेक्ट को कैश करने के लिए है, फिर भी हर एक बिल्ड पर विजेट चेक करता है कि क्या ऑब्जेक्ट बदल गया है? क्या? क्यों? बेशक, क्योंकि यह एक स्टेटफुल विजेट के अंदर उपयोग किया जाता है और पेड़ के ऊपर कुछ अन्य विजेट मूल्य बदल सकते हैं, इसलिए हमें परिवर्तनों के लिए मतदान करने की आवश्यकता है। यह शाब्दिक मतदान व्यवहार "प्रतिक्रियाशील" प्रोग्रामिंग के बिल्कुल विपरीत है।

क्या बुरा है, "नया" और "पुराना" हुक दोनों का एक ही उदाहरण प्रकार है, दोनों के समान मान हैं, और फिर भी फ़ंक्शन मानों पर पुनरावृति करता है यह जांचने के लिए कि क्या वे बदल गए हैं। हर एक एनिमेशन पर टिक करें।

यह वह आउटपुट है जो मुझे मिलता है, विज्ञापन infinitum।

/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

यह सारा काम हर एक एनिमेशन टिक पर होता है। अगर मैं एक और हुक जोड़ता हूं जैसे "अंतिम रंग = उपयोगएनीमेशन(एनीमेशन कलर);", रंग को भी चेतन करने के लिए, अब विजेट _two_ बार जांचता है कि क्या इसे अपडेट किया गया था।

मैं यहाँ बैठा हुआ एक पाठ देख रहा हूँ जो ऐप स्थिति या किसी भी विजेट या विजेट ट्री में कोई बदलाव नहीं होने के साथ आगे और पीछे चेतन करता है, और फिर भी हुक लगातार जाँच कर रहे हैं कि क्या ट्री/विजेट अपडेट किए गए थे। प्रत्येक विजेट जो इन विशेष हुकों का "उपयोग" करता है, यह मतदान व्यवहार खराब है।

निर्माण विधि के अंदर राज्य वस्तुओं के प्रारंभिक/अद्यतन/निपटान तर्क को संभालना सिर्फ खराब डिजाइन है। पुन: प्रयोज्यता, हॉटरेलोड या संज्ञानात्मक भार में कोई भी सुधार नहीं हुआ, जो प्रदर्शन पर प्रभाव को सही ठहराता है।
फिर से, मेरी राय में। हुक एक पैकेज होने के कारण, कोई भी उनका उपयोग कर सकता है यदि उन्हें लगता है कि लाभ ओवरहेड को सही ठहराते हैं।

इसके अलावा, मुझे नहीं लगता कि भाषा सुविधाओं, कंपाइलर जादू या अमूर्तता की कोई भी मात्रा ऐसी अनावश्यक जांच को रोक सकती है, अगर हम निर्माण प्रक्रिया के अंदर सब कुछ दूर करने की कोशिश करना शुरू करते हैं। इसलिए हमारे पास StatefulWidget को विस्तारित करने जैसे विकल्पों के साथ छोड़ दिया गया है। कुछ ऐसा जो पहले ही किया जा सकता था, और अनगिनत बार खारिज किया गया था।

@ हिक्सी आपने सवाल का जवाब नहीं दिया है। ऐसा क्या है जिसे आप ऊपर सूचीबद्ध बुलेट सूची में नहीं समझते/सहमत नहीं हैं?

आप मुझे क्या दिखाना चाहते हैं, यह जाने बिना मैं एक उदाहरण नहीं बना सकता।

@Rudiksz निश्चित रूप से किसी भी समाधान पर हम वास्तव में विचार करेंगे, यह सुनिश्चित करने के लिए प्रोफाइल और बेंचमार्क करने की आवश्यकता होगी कि यह चीजों को और खराब नहीं कर रहा है। जिस तरह से मैंने @TimWhiting को सबमिट किए गए डेमो ऐप का निर्माण किया है,

@rrousselGit मैं वास्तव में इस पर मातम नहीं करना चाहता था क्योंकि यह बहुत व्यक्तिपरक है लेकिन जब से आप पूछते हैं:

• सबसे पहले, मैं सामान्य रूप से स्ट्रीम का उपयोग करने से बचूंगा। ValueListenable IMHO कमोबेश समान उपयोग के मामलों के लिए एक बेहतर पैटर्न है।
• मुझे नहीं लगता कि स्ट्रीमबिल्डर को पढ़ना या लिखना विशेष रूप से कठिन है; लेकिन, जैसा कि @satvikpendem ने पहले टिप्पणी की थी , मेरा इतिहास HTML में गहरे घोंसले वाले पेड़ों के साथ है, और मैं अब 4 साल से फ़्लटर पेड़ों को घूर रहा हूं (मैंने पहले कहा है कि फ़्लटर की मुख्य योग्यता यह है कि विशाल पेड़ों को कुशलतापूर्वक कैसे चलाया जाए), इसलिए संभवत: अधिकांश लोगों की तुलना में मेरी सहनशीलता अधिक है, और यहां मेरी राय वास्तव में प्रासंगिक नहीं है।
• इस बारे में कि क्या StreamBuilder के लिए मिश्रण और कार्य एक संभावित विकल्प हो सकते हैं, मुझे लगता है कि हुक बहुत अच्छी तरह से प्रदर्शित करता है कि आप निश्चित रूप से धाराओं को सुनने के लिए कार्यों का उपयोग कर सकते हैं, और मिश्रण स्पष्ट रूप से कुछ भी कर सकते हैं जो कक्षाएं यहां कर सकती हैं, इसलिए मुझे नहीं लगता कि वे क्यों करेंगे समाधान भी नहीं है।
• अंत में, कॉपी-पेस्ट करने के कार्यान्वयन के संबंध में, यह एक व्यक्तिपरक मामला है। मैं व्यक्तिगत रूप से तर्क को initState/didUpdateWidget/निपटान/निर्माण में कॉपी और पेस्ट नहीं करता, मैं इसे हर बार नए सिरे से लिखता हूं, और यह अधिकतर ठीक लगता है। जब यह "नियंत्रण से बाहर" हो जाता है तो मैं इसे StreamBuilder जैसे विजेट में बदल देता हूं। तो फिर मेरी राय शायद यहाँ प्रासंगिक नहीं है।

एक सामान्य नियम के रूप में, मुझे आपके द्वारा देखी जा रही समस्या का अनुभव हो रहा है या नहीं, यह प्रासंगिक नहीं है। आपका अनुभव मेरी राय की परवाह किए बिना मान्य है। मुझे आपके द्वारा अनुभव की जाने वाली समस्याओं के समाधान खोजने पर काम करने में प्रसन्नता हो रही है, भले ही मुझे उन समस्याओं का अनुभव न हो। मेरे द्वारा स्वयं समस्या का अनुभव न करने का एकमात्र प्रभाव यह है कि समस्या को अच्छी तरह से समझना मेरे लिए कठिन है, जैसा कि हमने इस चर्चा में देखा है।

जो मैं आपको दिखाना चाहता हूं वह कोडिंग पैटर्न है जो आपको लगता है कि अस्वीकार्य है, एक डेमो में जो इतना महत्वपूर्ण है कि जब कोई समाधान बनाता है, तो आप इसे यह कहकर खारिज नहीं करेंगे कि एक अलग स्थिति में इसका उपयोग करना मुश्किल हो सकता है (यानी सभी प्रासंगिक स्थितियों को शामिल करें, उदाहरण के लिए, "अपडेट" भागों को शामिल करना सुनिश्चित करें या जो भी अन्य भाग आपको लगता है कि संभालना महत्वपूर्ण है), या यह कहना कि समाधान एक मामले में काम करता है लेकिन सामान्य मामले में नहीं (उदाहरण के लिए लेने के लिए) आपकी पिछली प्रतिक्रिया, यह सुनिश्चित करते हुए कि पैरामीटर कई स्थानों से आ रहे हैं और कई स्थितियों में अपडेट हो रहे हैं ताकि यह स्पष्ट हो कि उपरोक्त संपत्ति जैसा समाधान अन्यथा सामान्य कोड का कारक नहीं होगा)।

मुद्दा यह है कि आप किसी ऐसी चीज के लिए उदाहरण पूछ रहे हैं जो मेरे लिए "स्पष्ट" के क्षेत्र में है।

मुझे कुछ उदाहरण बनाने में कोई आपत्ति नहीं है, लेकिन मुझे नहीं पता कि आप क्या उम्मीद कर रहे हैं, क्योंकि मुझे समझ में नहीं आता कि आप क्या नहीं समझते हैं।

मुझे जो कुछ भी कहना था, मैंने पहले ही कह दिया है।
आप जो नहीं समझते हैं, उसे समझे बिना मैं केवल एक ही काम कर सकता हूं, वह है खुद को दोहराना।

मैं यहां कुछ स्निपेट चला सकता हूं, लेकिन यह खुद को दोहराने के बराबर है।
यदि स्निपेट उपयोगी नहीं था, तो मुझे नहीं लगता कि इसे चलाने में सक्षम होने से कुछ भी बदल जाएगा।

इस बारे में कि क्या StreamBuilder के लिए मिश्रण और कार्य एक संभावित विकल्प हो सकते हैं, मुझे लगता है कि हुक बहुत अच्छी तरह से प्रदर्शित करता है कि आप निश्चित रूप से धाराओं को सुनने के लिए कार्यों का उपयोग कर सकते हैं, और मिश्रण स्पष्ट रूप से कुछ भी कर सकते हैं जो कक्षाएं यहां कर सकती हैं, इसलिए मुझे नहीं लगता कि वे क्यों करेंगे समाधान भी नहीं है।

हुक को कार्यों के रूप में नहीं माना जाना चाहिए।
वे Iterable/Stream के समान एक नई भाषा का निर्माण कर रहे हैं

फ़ंक्शंस वह नहीं कर सकते जो हुक करते हैं - उनके पास कोई राज्य या क्षमता नहीं है जिससे विजेट्स को फिर से बनाया जा सके।

ओपी में मिश्रण के साथ समस्या का प्रदर्शन किया जाता है। टीएल; डीआर: चर पर नाम संघर्ष और एक ही मिश्रण को कई बार पुन: उपयोग करना असंभव है।

@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

मैं इन उदाहरणों में जोड़ने के लिए कुछ भी नहीं सोच सकता।

लेकिन एफडब्ल्यूआईडब्ल्यू मैं रिवरपॉड का उपयोग करके एक ओपन-सोर्स वेदर ऐप पर काम कर रहा हूं। जब यह हो जाएगा तो मैं इसे यहां लिंक कर दूंगा।

मैंने यहां चर्चा की गई समस्याओं से संबंधित बिल्डर्स के बारे में कुछ प्रश्न पूछने के लिए ट्विटर पर एक सर्वेक्षण किया है:

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 के बारे में एक सार है

एफडब्ल्यूआईडब्ल्यू, यह एक विशेष उदाहरण मोबक्स में अधिक आसानी से लागू किया जा सकता है।
यह वास्तव में आपके हुक कार्यान्वयन से छोटा है।

Mobx की वेधशालाएँ स्टेरॉयड पर ValueNotifiers हैं और इसका ऑब्जर्वर विजेट Flutter के ValueListenableBuilder का विकास है - यह एक से अधिक ValueNotifier को सुन सकता है।
ValueNotifier/ValueListenableBuilder कॉम्बो के लिए ड्रॉप-इन प्रतिस्थापन होने का मतलब है कि आप अभी भी मुहावरेदार फ़्लटर कोड लिखते हैं, जो वास्तव में एक महत्वपूर्ण कारक है।

चूंकि यह अभी भी फ़्लटर के ट्वीन बिल्डर में निर्मित का उपयोग करता है, इसलिए यहां नए विजेट/हुक को सीखने/कार्यान्वित करने की कोई आवश्यकता नहीं है (दूसरे शब्दों में इसे किसी नई सुविधाओं की आवश्यकता नहीं है) और इसमें हुक के प्रदर्शन हिट में से कोई भी नहीं है।

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

काउंटर्स.डार्ट जितना सरल है...

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 संस्करण में क्या जोड़ता है।

आपके अंतिम सार के लिए, TickerProvider टूटा हुआ है क्योंकि यह TickerMode समर्थन नहीं करता है - न ही श्रोताओं को हटाया जाता है या नियंत्रकों का निपटान किया जाता है।

और Mobx संभवतः ऑफ-टॉपिक है। हम इस बात पर चर्चा नहीं कर रहे हैं कि परिवेशी स्थिति / ValueListenable बनाम स्टोर बनाम स्ट्रीम को कैसे लागू किया जाए, बल्कि स्थानीय राज्य / नेस्टेड बिल्डर्स से कैसे निपटा जाए - जिसे Mobx किसी भी तरह से हल नहीं करता है

—–––

साथ ही, ध्यान रखें कि हुक उदाहरण में, useAnimatedInt को पैकेज में निकाला जा सकता है/होना चाहिए और व्यक्तिगत टेक्स्ट एनीमेशन और कुल के बीच अवधि/वक्र का कोई डुप्लिकेट नहीं है।

प्रदर्शन के लिए, हुक के साथ हम केवल एक ही तत्व का पुनर्निर्माण कर रहे हैं, जबकि बिल्डर्स के साथ 2-4 बिल्डर्स का पुनर्निर्माण कर रहे हैं।
तो हुक बहुत तेज हो सकता है।

आपके स्निपेट में "कुल" फ़ील्ड का व्यवहार टूटा हुआ है। यह उस उदाहरण से मेल नहीं खाता है, जहां दोनों काउंटर एक साथ चेतन हो सकते हैं लेकिन अलग-अलग समय पर और अलग-अलग वक्रों के साथ एनिमेट करना समाप्त कर सकते हैं।

आपने स्पष्ट रूप से उदाहरण को चलाने की कोशिश भी नहीं की। यह बिल्कुल आपके कोड की तरह व्यवहार करता

आपके अंतिम सार के लिए, टिकरप्रोवाइडर टूट गया है क्योंकि यह टिकरमोड का समर्थन नहीं करता है।

मुझे नहीं पता कि आपका इससे क्या मतलब है। मैंने _your_ उदाहरण को पुन: सक्रिय किया, जो टिकरमोड का उपयोग नहीं करता है। आप फिर से आवश्यकताओं को बदल रहे हैं।

प्रदर्शन के लिए, हुक के साथ हम केवल एक ही तत्व का पुनर्निर्माण कर रहे हैं, जबकि बिल्डर्स के साथ 2-4 बिल्डर्स का पुनर्निर्माण कर रहे हैं। तो हुक बहुत तेज हो सकता है।

नहीं, बस नहीं। आपके हुक विजेट हर एक बिल्ड में बदलाव के लिए लगातार मतदान करते हैं। valuelistenables पर आधारित बिल्डर्स "प्रतिक्रियाशील" हैं।

इसी तरह, मुझे यकीन नहीं है कि यह उदाहरण ValueListenableBuilder संस्करण में क्या जोड़ता है ।

और Mobx संभवतः ऑफ-टॉपिक है। हम इस बात पर चर्चा नहीं कर रहे हैं कि परिवेशी स्थिति / ValueListenable बनाम स्टोर बनाम स्ट्रीम को कैसे लागू किया जाए, बल्कि स्थानीय राज्य / नेस्टेड बिल्डर्स से कैसे निपटा जाए - जिसे Mobx किसी भी तरह से हल नहीं करता है

आप मजाक कर रहे हैं। मैंने आपका उदाहरण लिया और नेस्टेड ValueListenableBuilders * और ट्वीन बिल्डर्स के साथ "निपटाया" ?! एक बिंदु जिसे आपने विशेष रूप से एक मुद्दे के रूप में उठाया है।
लेकिन यहाँ यह वाक्य इस चर्चा के प्रति आपके पूरे रवैये का वर्णन करता है। यदि यह हुक नहीं है तो यह "ऑफ-विषय" है, लेकिन आप कहते हैं कि आपको परवाह नहीं है कि यह हुक है जो समाधान के रूप में उपयोग किया जाएगा।
मुझे एक विराम दें।

आपने स्पष्ट रूप से उदाहरण को चलाने की कोशिश भी नहीं की। यह बिल्कुल आपके कोड की तरह व्यवहार करता है।

यह नहीं है। पहला काउंटर 5 सेकंड से अधिक और दूसरा 2 सेकंड में एनिमेट करता है - और दोनों एक अलग कर्व का भी उपयोग करते हैं।

मेरे द्वारा दिए गए दोनों स्निपेट के साथ, आप एक ही समय में दोनों काउंटरों को बढ़ा सकते हैं, और एनीमेशन के हर एक फ्रेम के दौरान, "कुल" सही होगा। यहां तक ​​​​कि जब दूसरा काउंटर एनिमेट करना बंद कर देता है, जबकि पहला काउंटर अभी भी एनिमेट कर रहा है

दूसरी ओर, आपका कार्यान्वयन इस मामले पर विचार नहीं करता है, क्योंकि इसने 2 TweenAnimationBuilders को एक में मिला दिया है।
इसे ठीक करने के लिए, हमें लिखना होगा:

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 आवश्यक हैं क्योंकि पहला Observer counters.secondCounter पालन ​​नहीं कर सकता है

नहीं, बस नहीं। आपके हुक विजेट हर एक बिल्ड में बदलाव के लिए लगातार मतदान करते हैं। valuelistenables पर आधारित बिल्डर्स "प्रतिक्रियाशील" हैं।

आप अनदेखा कर रहे हैं कि Element क्या करता है, जो हुक की तुलना में वही होता है: रनटाइम टाइप और चाबियों की तुलना करना, और यह तय करना कि एक नया तत्व बनाना है या मौजूदा को अपडेट करना है

मैंने आपका उदाहरण लिया और नेस्टेड 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/

और इस दृष्टिकोण के साथ, हमें हर उस स्थान पर ट्वीन तर्क को फिर से लागू करना होगा जो मूल रूप से एक ट्वीनएनीमेशनबिल्डर चाहते हैं। यह एक महत्वपूर्ण डुप्लिकेट की ओर जाता है, विशेष रूप से तर्क पर विचार करना इतना तुच्छ नहीं है

मेरे द्वारा दिए गए दोनों स्निपेट के साथ, आप एक ही समय में दोनों काउंटरों को बढ़ा सकते हैं, और एनीमेशन के हर एक फ्रेम के दौरान, "कुल" सही होगा। यहां तक ​​​​कि जब दूसरा काउंटर एनिमेट करना बंद कर देता है, जबकि पहला काउंटर अभी भी एनिमेट कर रहा है

दूसरी ओर, आपका कार्यान्वयन इस मामले पर विचार नहीं करता है, क्योंकि इसने 2 TweenAnimationBuilders को एक में मिला दिया है।

हां, यह एक ऐसा ट्रेड-ऑफ है जिसे मैं बनाना चाहता था। मैं आसानी से ऐसे मामले की कल्पना कर सकता हूं जहां परिवर्तन होने के लिए एनीमेशन सिर्फ एक दृश्य प्रतिक्रिया होगी और सटीकता महत्वपूर्ण नहीं है। यह सब आवश्यकताओं पर निर्भर करता है।

मुझे संदेह था कि आप आपत्ति करेंगे, इसलिए दूसरा संस्करण जो इस सटीक समस्या को हल करता है, जबकि कोड को और भी क्लीनर बनाता है।

यदि आप अपने सार का जिक्र कर रहे हैं, तो जैसा कि मैंने पहले उल्लेख किया है, यह दृष्टिकोण टिकरप्रोवाइडर/टिकरमोड को तोड़ता है। Vsync को SingleTickerProviderClientStateMixin का उपयोग करके प्राप्त करने की आवश्यकता है या अन्यथा यह म्यूटिंग लॉजिक का समर्थन नहीं करता है, जो प्रदर्शन समस्याओं का कारण बन सकता है।

तो आप विजेट में टिकरप्रदाता बनाते हैं और उसे काउंटरों पर भेजते हैं। मैंने एनीमेशन नियंत्रकों का निपटान भी नहीं किया। ये विवरण लागू करने के लिए इतने तुच्छ हैं कि मुझे ऐसा नहीं लगा कि वे उदाहरण में कुछ भी जोड़ देंगे। लेकिन यहां हम उन पर ध्यान दे रहे हैं।

मैंने काउंटर() कक्षा को लागू किया है जो आपका उदाहरण करता है और कुछ भी नहीं।

और इस दृष्टिकोण के साथ, हमें हर उस स्थान पर ट्वीन तर्क को फिर से लागू करना होगा जो मूल रूप से एक ट्वीनएनीमेशनबिल्डर चाहते हैं। यह एक महत्वपूर्ण डुप्लिकेट की ओर जाता है, विशेष रूप से तर्क पर विचार करना इतना तुच्छ नहीं है

क्या? क्यों? कृपया समझाएं, मैं काउंटर क्लास के एक से अधिक उदाहरण क्यों नहीं बना सका और विभिन्न विजेट्स में उनका उपयोग क्यों नहीं कर सका?

@Rudiksz मुझे यकीन नहीं है कि आपके समाधान वास्तव में निर्धारित समस्याओं को हल कर रहे हैं। तुम कहो

मैंने काउंटर() कक्षा को लागू किया है जो आपका उदाहरण करता है और कुछ भी नहीं।

और अभी तक

हां, यह एक ऐसा ट्रेड-ऑफ है जिसे मैं बनाना चाहता था। मैं आसानी से ऐसे मामले की कल्पना कर सकता हूं जहां परिवर्तन होने के लिए एनीमेशन सिर्फ एक दृश्य प्रतिक्रिया होगी और सटीकता महत्वपूर्ण नहीं है। यह सब आवश्यकताओं पर निर्भर करता है।

तो आप विजेट में टिकरप्रदाता बनाते हैं और उसे काउंटरों पर भेजते हैं। मैंने एनीमेशन नियंत्रकों का निपटान भी नहीं किया। ये विवरण लागू करने के लिए इतने तुच्छ हैं कि मुझे ऐसा नहीं लगा कि वे उदाहरण में कुछ भी जोड़ देंगे। लेकिन यहां हम उन पर ध्यान दे रहे हैं।

आपने कोड प्रदान किया है जो केवल @rrousselGit के हुक संस्करण के बराबर है, फिर भी यह वास्तव में समकक्ष नहीं है, क्योंकि आप उन हिस्सों को छोड़ देते हैं जिनमें हुक संस्करण शामिल है। उस मामले में, वे वास्तव में तुलनीय नहीं हैं, है ना? यदि आप अपने समाधान की तुलना सुझाए गए समाधान से करना चाहते हैं, तो यह सबसे अच्छा होगा कि आप उन्हें शामिल क्यों नहीं करने के बारे में बात करने के बजाय आवश्यकताओं से बिल्कुल मेल खाते हैं। यह कुछ ऐसा है जो @TimWhiting का भंडार बनाने का कारण है। आप अपना समाधान वहां जमा कर सकते हैं यदि आपको लगता है कि आपने सभी आवश्यकताओं को पूरा कर लिया है।

आपने स्पष्ट रूप से उदाहरण को चलाने की कोशिश भी नहीं की। यह बिल्कुल आपके कोड की तरह व्यवहार करता है।

नहीं, बस नहीं।

आप मजाक कर रहे हैं। मैंने आपका उदाहरण लिया और नेस्टेड ValueListenableBuilders * और ट्वीन बिल्डर्स के साथ "निपटाया"

कृपया इस तरह के आरोपों से बचें, वे केवल अंतर्निहित समस्याओं को हल किए बिना इस धागे को विट्रियल बनाने का काम करते हैं। आप दूसरे पक्ष पर दोषारोपण, अपमानजनक या क्रोधित हुए बिना अपनी बात रख सकते हैं, जो कि इस सूत्र में मेरे द्वारा देखे गए टिप्पणियों का प्रभाव है, मुझे आपके प्रति दूसरों का ऐसा व्यवहार नहीं दिखता। मुझे यह भी पता नहीं है कि आपकी खुद की पोस्ट पर इमोजी-प्रतिक्रिया का क्या प्रभाव पड़ता है।

@rrousselGit

मैं लिंक किए गए स्निपेट के आधार पर उदाहरण बनाने में आपकी सहायता कर सकता हूं, लेकिन मुझे यह जानने की आवश्यकता है कि ये स्निपेट पर्याप्त क्यों नहीं थे
अन्यथा, केवल एक चीज जो मैं कर सकता हूं वह है इन स्निपेट्स को संकलित करना, लेकिन मुझे संदेह है कि आप यही चाहते हैं।

कारण मैं सिर्फ एक स्निपेट की तुलना में अधिक विस्तृत ऐप के लिए पूछ रहा हूं कि जब मैंने एक उदाहरण पोस्ट किया जो आपके एक स्निपेट को संभाला, तो आपने कहा कि यह काफी अच्छा नहीं था क्योंकि यह किसी अन्य मामले को भी संभाल नहीं पाया था आपके स्निपेट में नहीं है (उदाहरण के लिए didUpdateWidget को हैंडल नहीं किया है, या इनमें से दो स्निपेट्स को साथ-साथ नहीं रखा है, या अन्य पूरी तरह से उचित चीजें जिन्हें आप हैंडल करना चाहते हैं)। मैं एक अधिक विस्तृत ऐप के साथ उम्मीद कर रहा हूं कि हम इसे पर्याप्त रूप से विस्तृत कर सकें कि एक बार हमारे पास समाधान हो जाने के बाद, कोई "गॉचा" पल नहीं होता है जहां कुछ नई समस्या सामने आती है जिसे संभालने की भी आवश्यकता होती है। जाहिर है कि यह अभी भी संभव है कि हम सभी को कुछ ऐसा याद आ जाए जिसे संभालने की जरूरत है, लेकिन विचार मौका कम से कम करना है।

हाल ही में कम-से-पूरी तरह से स्वागत करने वाली पोस्ट के बारे में, कृपया दोस्तों, आइए छोटे उदाहरणों के साथ आगे और आगे लड़ने के बजाय @TimWhiting के रेपो पर उदाहरण बनाने पर ध्यान दें। जैसा कि हम पहले ही चर्चा कर चुके हैं, छोटे उदाहरण कभी भी इतने विस्तृत नहीं होंगे कि वे एक विकल्प को साबित करने के लिए पर्याप्त रूप से प्रतिनिधित्व कर सकें जो वास्तव में अच्छी तरह से काम करता है।

आप अपना समाधान वहां जमा कर सकते हैं यदि आपको लगता है कि आपने सभी आवश्यकताओं को पूरा कर लिया है।

इस तथ्य के बाद आवश्यकताओं को बदल दिया गया था। मैंने दो समाधान दिए। एक जो समझौता करता है (एक बहुत ही उचित एक) और एक जो प्रदान किए गए उदाहरण के सटीक व्यवहार को लागू करता है।

आपने कोड प्रदान किया है जो केवल @rrousselGit के हुक संस्करण के बराबर है, फिर भी यह वास्तव में समकक्ष नहीं है,

मैंने "हुक समाधान" को लागू नहीं किया, मैंने ValueListenableBuilder उदाहरण लागू किया, विशेष रूप से "घोंसले के मुद्दे" पर ध्यान केंद्रित किया। यह हर एक काम नहीं करता है जो हुक करता है, मैंने बस यह दिखाया कि कैसे वैकल्पिक समाधान का उपयोग करके शिकायतों की बुलेट सूची में एक आइटम को सरल बनाया जा सकता है।

यदि आपको बाहरी पैकेजों को चर्चा में लाने की अनुमति है, तो मैं भी हूं।

पुन: प्रयोज्य: नीचे रेपो में उदाहरण देखें
https://github.com/Rudiksz/cbl_example

ध्यान दें:

• यह एक शोकेस के रूप में है कि आप विजेट्स के बाहर "तर्क" को कैसे समाहित कर सकते हैं और ऐसे विजेट हैं जो दुबले हैं, लगभग एचटीएमएल दिख रहे हैं
• यह हुक कवर सब कुछ कवर नहीं करता है। वह बात नहीं है। मुझे लगा कि हम स्टॉक फ़्लटर फ्रेमवर्क के विकल्पों पर चर्चा कर रहे हैं, न कि हुक पैकेज पर।
• इसमें _हर_उपयोग के मामले शामिल नहीं हैं, हर मार्केटिंग टीम सामने आ सकती है
• लेकिन, काउंटर ऑब्जेक्ट अपने आप में बहुत लचीला है, इसे एक जटिल विजेट के हिस्से के रूप में स्टैंडअलोन (AppBar शीर्षक देखें) का उपयोग किया जा सकता है, जिसे विभिन्न काउंटरों के योग की गणना करने, प्रतिक्रियाशील बनाने या उपयोगकर्ता इनपुट का जवाब देने की आवश्यकता होती है।
• यह उपभोग करने वाले विजेट्स पर निर्भर करता है कि वे काउंटरों की राशि, प्रारंभिक मूल्य, अवधि, एनीमेशन प्रकार को अनुकूलित करें जिनका वे उपयोग करना चाहते हैं।
• एनिमेशन को संभालने के तरीके के विवरण में गिरावट हो सकती है। यदि फ़्लटर टीम कहती है कि हाँ, विजेट्स के बाहर एनिमेशन नियंत्रकों और ट्वीन्स का उपयोग करके, किसी तरह ढांचे को तोड़ता है, तो मैं पुनर्विचार करूँगा। सुधार करने के लिए निश्चित रूप से चीजें हैं। कस्टम टिकरप्रोवाइडर को बदलना जो मैं उपभोग करने वाले विजेट के मिश्रण द्वारा बनाए गए एक के साथ उपयोग करता हूं वह छोटा है। मैंने नहीं किया है।
• यह "बिल्डर" पैटर्न के लिए सिर्फ एक और वैकल्पिक समाधान है। यदि आप कहते हैं कि आपको बिल्डर्स की आवश्यकता है या उपयोग करना चाहते हैं, तो इनमें से कोई भी लागू नहीं होता है।
• फिर भी, तथ्य यह है कि अतिरिक्त सुविधाओं के बिना, कोड को सरल बनाने के तरीके हैं। अगर आपको यह पसंद नहीं है, तो इसे न खरीदें। मैं इसे ढांचे में शामिल करने के लिए इनमें से किसी की भी वकालत नहीं कर रहा हूं।

संपादित करें: इस उदाहरण में एक बग है, यदि आप परिवर्तन एनिमेटेड होने पर "वृद्धि" शुरू करते हैं, तो काउंटर रीसेट हो जाता है और वर्तमान मान से बढ़ा हुआ होता है। मैंने इसे जानबूझकर ठीक नहीं किया, क्योंकि मुझे नहीं पता कि इन "काउंटरों" के लिए आपकी क्या आवश्यकताएं हो सकती हैं। फिर से इस मुद्दे को ठीक करने के लिए वेतन वृद्धि/कमी के तरीकों को बदलना तुच्छ है।

बस इतना ही।

@Hixie क्या मुझे आपकी टिप्पणी की व्याख्या यह कहने के तरीके के रूप में करनी चाहिए कि मेरा उदाहरण (https://github.com/TimWhiting/local_widget_state_approaches/blob/master/lib/hooks/animated_counter.dart) पर्याप्त नहीं है?

साथ ही, क्या हम जूम/गूगल मीट कॉल कर सकते हैं?

मुझे यह भी पता नहीं है कि आपकी खुद की पोस्ट पर इमोजी-प्रतिक्रिया का क्या प्रभाव पड़ता है।

कुछ नहीं। यह किसी भी चीज के लिए पूरी तरह से अप्रासंगिक है। आप इसे क्यों लाए?

@rrousselGit केवल आप ही जान सकते हैं कि यह काफी अच्छा है या नहीं। अगर हम उस उदाहरण को फिर से तैयार करने का कोई तरीका ढूंढते हैं ताकि वह साफ और छोटा हो और उसका कोई डुप्लिकेट कोड न हो, तो क्या आप संतुष्ट होंगे? या क्या ऐसी चीजें हैं जो आपको लगता है कि हमें समर्थन करना चाहिए जो उस उदाहरण से नियंत्रित नहीं हैं जिसे हमें इस बग को संतुष्ट करने के लिए संभालने की आवश्यकता है?

केवल आप ही जान सकते हैं कि क्या यह काफी अच्छा है

मैं इसका जज नहीं हो सकता। शुरू करने के लिए, मुझे विश्वास नहीं है कि हम अनुप्रयोगों के सीमित सेट का उपयोग करके समस्या को पकड़ सकते हैं।

मुझे उस तरह से काम करने में कोई आपत्ति नहीं है जैसा आप चाहते हैं, लेकिन मुझे मार्गदर्शन की आवश्यकता है क्योंकि मुझे समझ में नहीं आता कि इससे हमें कैसे प्रगति होगी।

मुझे लगता है कि हमने बहुत सारे कोड स्निपेट प्रदान किए हैं जो समस्या को हमारे दृष्टिकोण से दिखाते हैं। मैं वास्तव में नहीं सोचता कि अधिक कोड उदाहरणों के माध्यम से और अधिक स्पष्ट हो जाएगा, अगर दिखाए गए लोग ऐसा नहीं कर रहे हैं।

उदाहरण के लिए, यदि कई नेस्टेड बिल्डरों को पढ़ना भयानक है, या शुद्ध बॉयलरप्लेट की 50 लाइनें जिसमें बग के लिए कई अवसर हैं, तो समस्या को दृढ़ता से प्रदर्शित नहीं करता है, कहीं नहीं जाना है।

यह बहुत अजीब बात है कि मिक्सिन और फ़ंक्शन यहां एक समाधान हैं, जब संपूर्ण आस्क इनकैप्सुलेटेड स्टेट है , जो पुन: उपयोग योग्य है। कार्य राज्य को बनाए नहीं रख सकते। मिक्सिंस एनकैप्सुलेटेड नहीं हैं। यह सुझाव प्रदान किए गए सभी उदाहरणों और औचित्य के पूरे बिंदु को याद करता है और अभी भी पूछने की गहरी गलतफहमी को दर्शाता है।

मेरे लिए, मुझे लगता है कि हमने पृथ्वी में 2 अंक हासिल किए हैं, और मुझे नहीं लगता कि हम दोनों के साथ गंभीरता से बहस कर सकते हैं।

1. नेस्टेड बिल्डरों को पढ़ना स्वाभाविक रूप से कठिन है
2. नेस्टेड बिल्डरों के अलावा विजेट जीवनचक्र हुक वाले राज्य को एनकैप्सुलेट और साझा करने के लिए _no way_ नहीं है।

जैसा कि कई बार कहा गया है, और यहां तक ​​​​कि रेमी के सर्वेक्षण में, सीधे शब्दों में कहें: हम बिल्डर की क्षमताओं को चाहते हैं, बिना वर्बोसिटी और बिल्डर के नेस्टेड क्लोजर के। क्या यह पूरी तरह से इसका सारांश नहीं है? मैं पूरी तरह उलझन में हूं कि यहां आगे बढ़ने के लिए एक और कोड उदाहरण की आवश्यकता क्यों है।

रेमी का सर्वेक्षण हमें दिखाता है कि फ़्लटर देव के ~ 80% जब संभव हो तो अपने कोड में नेस्टेड बिल्डरों से बचने के लिए किसी प्रकार की क्षमता पसंद करेंगे। यह वास्तव में इमो के लिए बोलता है। जब सामुदायिक भावना इतनी स्पष्ट है, तो आपको इसे इस सूत्र में हमसे लेने की आवश्यकता नहीं है।

मेरे दृष्टिकोण से, मुद्दे स्पष्ट हैं, और जब आप प्रतिस्पर्धी ढांचे को देखते हैं तो उन्हें और भी स्पष्ट किया जाता है जो अनुच्छेदों को यहां तर्क का वर्णन करने के लिए समर्पित करते हैं। वू, रिएक्ट, स्पंदन वे सभी चचेरे भाई हैं, वे सभी रिएक्ट से प्राप्त हुए हैं, और वे सभी इस मुद्दे का सामना फिर से उपयोग करने वाले राज्य के साथ करते हैं जिसे विजेट जीवनचक्र में बांधना पड़ता है। वे सभी वर्णन करते हैं कि उन्होंने ऐसा कुछ विस्तार से क्यों लागू किया है। यह वहीं है। यह सब प्रासंगिक है।

@rrousselGit क्या आप कई हुक रखने का उदाहरण बना सकते हैं? उदाहरण के लिए, मैं संभवतः दर्जनों एनिमेशन नियंत्रकों के साथ एक एनीमेशन बना रहा हूं। नियमित स्पंदन के साथ, मैं कर सकता हूँ:

List<AnimationController> controllers = [];
int numAnimationControllers = 50;

<strong i="7">@override</strong>
void initState() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers.add(AnimationController(...));
}

<strong i="8">@override</strong>
void dispose() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers[i].dispose();
}

लेकिन हुक के साथ मैं लूप में useAnimationController को कॉल नहीं कर सकता। मुझे लगता है कि यह एक मामूली उदाहरण है लेकिन मुझे इस प्रकार के उपयोग के मामले में कहीं भी समाधान नहीं मिला।

@satvikpendem

मेरे ऐप्स से कुछ उदाहरण जो उत्पादन में हैं (कुछ हुक जैसे पेजिनेशन के साथ अनुरोध भेजना एक हुक में विलय/रिफैक्टर कर सकता है लेकिन यह यहां अप्रासंगिक है):

पृष्ठ पर अंक लगाना के साथ सरल डेटा प्राप्त करना:

    final selectedTab = useState(SelectedTab.Wallet);
    final isDrawerOpen = useValueNotifier(false);
    final pageNo = useValueNotifier(0);
    final generalData = useValueNotifier(initialData);
    final services = useXApi();
    final isLoading = useValueNotifier(false);
    final waybillData = useValueNotifier<List<WaybillResponseModel>>([]);
    final theme = useTheme();
    final router = useRouter();

    fetchNextPage() async {
      if (isLoading.value || selectedTab.value != SelectedTab.Wallet) return;
      isLoading.value = true;
      final request = WaybillRequestModel()..pageNo = pageNo.value;
      final result = await services.waybillGetList(model: request);
      if (result.isOk && result.data.length > 0) {
        pageNo.value += 1;
        waybillData.value = [...waybillData.value, ...result.data];
      }
      isLoading.value = false;
    }

    // first fetch
    useEffect(() {
      fetchNextPage();
      return () {};
    }, []);

फॉर्म लॉजिक (फोन नंबर सत्यापन के साथ लॉगिन फॉर्म और टाइमर फिर से भेजें):

    final theme = useTheme();
    final loginState = useValueNotifier(LoginState.EnteringNumber);
    final error = useValueNotifier<String>(null);
    final phoneNumberController = useTextEditingController(text: "");
    final phoneNumberFocusNode = useMemoized(() => FocusNode(), []);
    final otpFocusNode = useMemoized(() => FocusNode(), []);
    final otpController = useTextEditingController(text: "");
    final appState = Provider.of<AppStateController>(context);
    final services = useXApi();
    final router = useRouter();
    final resendTimerValue = useValueNotifier(0);
    useEffect(() {
      var timer = Timer.periodic(Duration(seconds: 1), (t) async {
        if (resendTimerValue.value > 0) resendTimerValue.value--;
      });
      return () => timer.cancel();
    }, []);

    final doLogin = () async {
      // login
      loginState.value = LoginState.LoggingIn;
      final loginResult = await services.authLoginOrRegister(
        mobileNumber: phoneNumberController.text,
      );
      if (loginResult.isOk) {
        loginState.value = LoginState.EnteringOtpCode;
        WidgetsBinding.instance.addPostFrameCallback((_) {
          FocusScope.of(context).requestFocus(otpFocusNode);
        });
        resendTimerValue.value = 30;
      } else {
        error.value = loginResult.errorMessage;
        loginState.value = LoginState.EnteringNumber;
        WidgetsBinding.instance.addPostFrameCallback((_) {
          FocusScope.of(context).requestFocus(phoneNumberFocusNode);
        });
      }
    };

एनीमेशन के लिए, मुझे लगता है कि @rrousselGit पहले ही पर्याप्त उदाहरण प्रदान कर चुका है।

मैं इस बारे में बात नहीं करना चाहता कि हुक की रचना योग्य प्रकृति उपरोक्त कोड को अधिक आसान, पुन: प्रयोज्य और क्लीनर कैसे बना सकती है, लेकिन यदि आप चाहें तो मैं रिफैक्टर किए गए संस्करण भी पोस्ट कर सकता हूं।

जैसा कि कई बार कहा गया है, और यहां तक ​​​​कि रेमी के सर्वेक्षण में, सीधे शब्दों में कहें: हम बिल्डर की क्षमताओं को चाहते हैं, बिना वर्बोसिटी और बिल्डर के नेस्टेड क्लोजर के। क्या यह पूरी तरह से इसका सारांश नहीं है? मैं पूरी तरह उलझन में हूं कि यहां आगे बढ़ने के लिए एक और कोड उदाहरण की आवश्यकता क्यों है।

मैंने शाब्दिक रूप से उदाहरण प्रदान किए हैं कि आप कैसे वर्बोसिटी को कम कर सकते हैं और रेमी द्वारा प्रदान किए गए उदाहरण का उपयोग करके बिल्डरों के घोंसले से बच सकते हैं।
मैंने उसका कोड अपने ऐप में चिपका लिया, उसे चलाया और उसे फिर से लिखा। जहां तक ​​कार्यात्मकता का संबंध है अंतिम परिणाम लगभग समान था - जितना मैं केवल कोड चलाने से प्राप्त कर सकता था, क्योंकि कोड आवश्यकताओं के साथ नहीं आया था। निश्चित रूप से हम किनारे के मामलों और संभावित समस्याओं पर चर्चा कर सकते हैं, लेकिन इसके बजाय इसे ऑफ-विषय कहा जाता था।

सरल उपयोग के मामलों के लिए मैं बिल्डर्स का उपयोग करता हूं, जटिल उपयोग के मामलों के लिए मैं बिल्डर्स का उपयोग नहीं करता हूं। यहां तर्क यह है कि बिल्डर्स का उपयोग किए बिना संक्षिप्त, पुन: प्रयोज्य कोड लिखने का कोई आसान तरीका नहीं है। स्पष्ट रूप से, इसका मतलब यह भी है कि बिल्डर्स के पास एक होना चाहिए, और फ़्लटर ऐप्स को विकसित करने का एकमात्र तरीका है। यह स्पष्ट रूप से झूठा है।

मैंने अभी एक कार्यशील, अवधारणा कोड का प्रमाण दिखाया है जो इसे प्रदर्शित करता है। इसने बिल्डर्स या हुक का उपयोग नहीं किया, और इसमें "समस्याओं के अनंत सेट" का 100% शामिल नहीं है कि यह विशेष जीथब मुद्दा हल करना चाहता है। इसे ऑफ-टॉपिक कहा जाता था।
सिडेनोट, यह भी बहुत कुशल है, यहां तक ​​​​कि बिना किसी बेंचमार्क के भी मुझे लगता है कि बिल्डर विजेट्स को भी धड़कता है। गलत साबित होने पर मुझे अपना विचार बदलने में खुशी हो रही है, और अगर मुझे कभी भी Mobx एक प्रदर्शन बाधा बन जाता है, तो मैं Mobx को छोड़ दूंगा और दिल की धड़कन में वेनिला बिल्डरों पर स्विच कर दूंगा।

हिक्सी Google के लिए काम करता है, उसे आपके साथ धैर्य और विनम्र रहना होगा और आपकी सगाई की कमी पर आपको कॉल नहीं कर सकता। सबसे अच्छा वह कर सकता है और अधिक उदाहरणों के लिए धक्का देना।

मैंने किसी का नाम नहीं लिया, या व्यक्तिगत हमले नहीं किए। मैंने केवल यहाँ प्रस्तुत तर्कों पर प्रतिक्रिया व्यक्त की, अपनी राय साझा की
(जो मुझे पता है कि अलोकप्रिय और अल्पमत में है) और यहां तक ​​​​कि कोड के साथ वास्तविक काउंटर उदाहरण पेश करने की कोशिश की। मैं और अधिक कर सकता था, मैं इस बात पर चर्चा करने के लिए तैयार हूं कि मेरे उदाहरण कहां कम हैं और देखें कि हम उन्हें कैसे सुधार सकते हैं, लेकिन हाँ, विषय से हटकर कहा जाना एक तरह से अलग है।

मेरे पास खोने के लिए कुछ भी नहीं है, शायद प्रतिबंधित होने के अलावा, इसलिए मुझे वास्तव में आपको कॉल करने की परवाह नहीं है।
यह स्पष्ट है कि आप दोनों मृत हैं कि हुक ही एकमात्र समाधान है ("क्योंकि रिएक्ट करता है") जो भी समस्याएं आप अनुभव करते हैं और जब तक कि कोई विकल्प "समस्याओं के अनंत सेट" का 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);

हुक नियमों का उल्लंघन किए बिना? क्योंकि मैंने समकक्ष को सामान्य स्पंदन में सूचीबद्ध किया है। मैं स्पंदन में हुक के साथ बहुत अनुभवी नहीं हूं इसलिए वहां मेरे साथ रहें।

मैं बस अपने सभी initState के साथ मांग पर हुक ऑब्जेक्ट्स (उदाहरण के लिए एनीमेशन कंट्रोलर) की एक सरणी बनाना चाहता हूं और पहले से ही तत्काल निपटान करना चाहता हूं, मुझे यकीन नहीं है कि यह हुक में कैसे काम करता है।

@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");

मैं देखता हूं, इसलिए हुक के साथ ऐसा लगता है कि हमें वस्तुओं की एक सरणी के साथ मामलों को संभालने के लिए एक अलग हुक बनाने की जरूरत है, जैसे कि कई एनिमेशन कंट्रोलर।

यह वही है जो मैंने शुरू में किया था जो काम नहीं करता है:

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

क्या इसका मतलब यह है कि अगर हमारे पास हुक का एकवचन संस्करण है, तो हम इसे कई आइटम वाले संस्करण के लिए उपयोग नहीं कर सकते हैं और इसके बजाय तर्क को फिर से लिखना होगा? या ऐसा करने का कोई बेहतर तरीका है?

अगर कोई भी गैर-हुक उदाहरण देना चाहता है तो मैं भी जानना चाहता हूं, मैं पुन: प्रयोज्य पहेली के इस टुकड़े के बारे में सोच रहा हूं। हो सकता है कि इस व्यवहार को कक्षा में समाहित करने का कोई तरीका हो, जिसका अपना एनीमेशन नियंत्रक फ़ील्ड हो, लेकिन यदि वह लूप के अंदर बनाया गया है, तो हुक भी नियमों को तोड़ देगा। शायद हम विचार कर सकते हैं कि 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] तरह संदर्भित करते हैं)

ईमानदारी से मेरे अनुभव में हुक के साथ प्रतिक्रिया और स्पंदन में मुझे शायद ही कभी किसी प्रकार के हुक को लूप में कॉल करने की आवश्यकता होती है। तब भी समाधान सीधे आगे और लागू करने में आसान था। अब मैं इसके बारे में सोचता हूं, इसे निश्चित रूप से बेहतर तरीके से हल किया जा सकता है जैसे कि उनमें से प्रत्येक के लिए एक घटक (विजेट) बनाना जो आईएमओ "क्लीनर" समाधान है।

अपने प्रश्न का उत्तर देने के लिए यदि एकाधिक 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]);

• आप useState का भी उपयोग कर सकते हैं यदि AnimationController s गतिशील हैं।

(टिकर बदलने पर यह फिर से सिंक भी हो जाता है)

@rrousselGit क्या आप कई हुक रखने का उदाहरण बना सकते हैं? उदाहरण के लिए, मैं संभवतः दर्जनों एनिमेशन नियंत्रकों के साथ एक एनीमेशन बना रहा हूं। नियमित स्पंदन के साथ, मैं कर सकता हूँ:

List<AnimationController> controllers = [];
int numAnimationControllers = 50;

<strong i="8">@override</strong>
void initState() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers.add(AnimationController(...));
}

<strong i="9">@override</strong>
void dispose() {
    for (int i = 0; i < numAnimationControllers; i++)
        controllers[i].dispose();
}

लेकिन हुक के साथ मैं लूप में useAnimationController को कॉल नहीं कर सकता। मुझे लगता है कि यह एक मामूली उदाहरण है लेकिन मुझे इस प्रकार के उपयोग के मामले में कहीं भी समाधान नहीं मिला।

हुक इसे अलग तरह से करते हैं।

हम अब नियंत्रकों की सूची नहीं बनाते हैं, बल्कि हम नियंत्रक तर्क को आइटम पर ले जाते हैं:

Widget build(context) {
  return ListView(
    children: [
      for (var i = 0; i < 50; i++)
        HookBuilder(
          builder: (context) {
            final controller = useAnimationController();
          },
        ),
    ],
  );
}

हमने अभी भी अपने 50 एनीमेशन नियंत्रक बनाए हैं, लेकिन वे एक अलग विजेट के स्वामित्व में हैं।

हो सकता है कि आप एक उदाहरण साझा कर सकें कि आपको इसकी आवश्यकता क्यों है, और हम कोशिश कर सकते हैं और हुक में कनवर्ट कर सकते हैं और इसे टिम के रेपो में जोड़ सकते हैं?

हिक्सी Google के लिए काम करता है, उसे आपके साथ धैर्य और विनम्र रहना होगा और आपकी सगाई की कमी पर आपको कॉल नहीं कर सकता। सबसे अच्छा वह कर सकता है और अधिक उदाहरणों के लिए धक्का देना।

@ हिक्सी , अगर आपको ऐसा लगता है, तो कृपया ऐसा कहें (या तो यहां या मुझसे निजी तौर पर संपर्क करें)।

मैंने शाब्दिक रूप से उदाहरण प्रदान किए हैं कि आप कैसे वर्बोसिटी को कम कर सकते हैं और रेमी द्वारा प्रदान किए गए उदाहरण का उपयोग करके बिल्डरों के घोंसले से बच सकते हैं।

धन्यवाद, लेकिन यह मेरे लिए स्पष्ट नहीं है कि आप इस कोड से एक सामान्य पैटर्न कैसे निकालेंगे क्योंकि इस तर्क को विभिन्न उपयोग-मामलों पर लागू करते हैं।

ओपी में, मैंने उल्लेख किया है कि वर्तमान में, हमारे पास 3 विकल्प हैं:

• बिल्डर्स का उपयोग करें और नेस्टेड कोड रखें
• कोड को किसी भी तरह से फ़ैक्टराइज़ न करें, जो अधिक जटिल राज्य तर्क के पैमाने पर नहीं है (मैं तर्क दूंगा कि StreamBuilder और इसका AsyncSnapshot एक जटिल राज्य तर्क है)।
• मिक्सिन्स/ओओपी/... का उपयोग करके कुछ आर्किटेक्चर बनाने की कोशिश करें, लेकिन समस्या के लिए बहुत विशिष्ट समाधान के साथ समाप्त होता है कि यह किसी भी उपयोग-मामले जो कि _tiny_ बिट अलग है, को फिर से लिखने की आवश्यकता होगी।

मुझे ऐसा प्रतीत होता है कि आपने तीसरी पसंद का उपयोग किया है (जो 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 से उदाहरण लें और शुद्ध स्पंदन का उपयोग करके एक ऐप बनाएं जो उन विभिन्न उपयोग मामलों को एक साथ दिखाता है।
2. एक समाधान तैयार करने का प्रयास करें जो उन उदाहरणों के लिए कोड पुन: उपयोग को सक्षम बनाता है जो यहां चर्चा की गई विभिन्न प्रमुख आवश्यकताओं को पूरा करता है और जो हमारे डिजाइन सिद्धांतों के भीतर फिट बैठता है।

अगर कोई इनमें से किसी के साथ मदद करना चाहता है तो मुझे मदद करने में निश्चित रूप से खुशी होगी। मेरे इस तक जल्दी पहुंचने की संभावना नहीं है क्योंकि मैं पहले एनएनबीडी ट्रांजिशन पर काम कर रहा हूं।

@rrousselGit निश्चित रूप से, मैं एक ऐप बना रहा हूं जहां कई विजेट स्क्रीन के चारों ओर घूम सकते हैं (चलिए उन्हें Box es कहते हैं), और वे एक दूसरे से स्वतंत्र रूप से स्थानांतरित करने में सक्षम होना चाहिए (इसलिए कम से कम होना चाहिए प्रत्येक Box लिए एक एनिमेशन CupertinoPicker को लागू करने के लिए, इसके कस्टम स्क्रॉल व्हील प्रभाव के साथ .

एक स्टैक में तीन बॉक्स होते हैं जो फ़्लोटिंगएक्शन बटन पर क्लिक करने पर ऊपर और नीचे जाते हैं।

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 होना चाहिए और यह हर एक को चेतन करने में सक्षम होना चाहिए जैसा कि वह फिट देखता है।

समस्या यह प्रतीत होती है कि एनिमेशन कंट्रोलर और Box es जो अपने आंदोलन को चलाने के लिए उनका उपयोग करते हैं, वे एक ही कक्षा में नहीं हैं, इसलिए किसी को या तो एनीमेशन कंट्रोलर के माध्यम से उपयोग करने के लिए उनमें से एक सरणी रखने की आवश्यकता होगी एक बिल्डर, या प्रत्येक Box अपने स्वयं के एनिमेशन

हुक के साथ, यह देखते हुए कि Box es और मूल विजेट एक ही कक्षा में नहीं हैं, मैं पहले मामले के लिए एनिमेशन नियंत्रकों की सूची कैसे बनाऊंगा जहां प्रत्येक Box को एक एनिमेशन नियंत्रक में पारित किया जाता है? ऐसा लगता है कि हुकबिल्डर के साथ आपके उत्तर के आधार पर इसकी आवश्यकता नहीं है, लेकिन फिर यदि मैं राज्य को बच्चे विजेट में ले जाता हूं, जैसा कि आप कहते हैं, और प्रत्येक Box को useAnimationController माध्यम से अपना स्वयं का एनिमेशन नियंत्रक बनाना चुनते हैं। , मैं एक और समस्या में भाग लेता हूं: मैं प्रत्येक बच्चे के लिए स्वतंत्र एनिमेशन को समन्वयित करने और चलाने के लिए बनाए गए एनिमेशन कंट्रोलर को मूल वर्ग में कैसे उजागर करूं?

Vue में आप emit पैटर्न के माध्यम से माता-पिता को एक घटना वापस भेज सकते हैं, इसलिए फ़्लटर में मुझे रिवरपॉड या आरएक्स जैसे कुछ उच्च राज्य प्रबंधन समाधान की आवश्यकता होती है जहां माता-पिता वैश्विक स्थिति को अपडेट करते हैं और बच्चा वैश्विक सुनता है राज्य? ऐसा लगता है कि मुझे कम से कम इस तरह के एक साधारण उदाहरण के लिए नहीं करना चाहिए। मेरे भ्रम को दूर करने के लिए धन्यवाद।

@satvikpendem क्षमा करें मैं स्पष्ट नहीं था। क्या आप दिखा सकते हैं कि आप इसे बिना हुक के कैसे करेंगे, बजाय इसके कि आप हुक से अवरुद्ध कर रहे हैं?

मैं इस बात की स्पष्ट समझ रखना चाहता हूं कि आप क्या करने की कोशिश कर रहे हैं, बजाय इसके कि आप कहां फंस रहे हैं

लेकिन एक त्वरित अनुमान के रूप में, मुझे लगता है कि आप इसके बजाय अंतराल वक्र की तलाश में हैं, और एक एनीमेशन नियंत्रक है।

@rrousselGit ज़रूर, यहाँ यह है

import 'package:flutter/material.dart';

void main(List<String> args) => runApp(const App());

class Animator {
  Animator({this.controller, this.animation});
  AnimationController controller;
  Animation<double> animation;
}

class App extends StatefulWidget {
  const App({Key key});

  static const Duration duration = Duration(milliseconds: 500);
  static const Curve curve = Curves.easeOutBack;

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

class _AppState extends State<App> with TickerProviderStateMixin {
  List<Animator> animators = [];
  bool isDown = false;
  int numBoxes = 3;

  <strong i="8">@override</strong>
  void initState() {
    for (int i = 0; i < numBoxes; i++) {
      final AnimationController c = AnimationController(
        duration: App.duration,
        vsync: this,
      );
      animators.add(
        Animator(
          controller: c,
          animation: Tween<double>(
            begin: 0,
            end: 300,
          )
              .chain(
                CurveTween(
                  curve: App.curve,
                ),
              )
              .animate(c),
        ),
      );
    }
    super.initState();
  }

  <strong i="9">@override</strong>
  void dispose() {
    for (int i = 0; i < numBoxes; i++) {
      animators[i].controller.dispose();
    }
    super.dispose();
  }

  <strong i="10">@override</strong>
  Widget build(BuildContext context) {
    return MaterialApp(
      home: SafeArea(
        child: Scaffold(
          floatingActionButton: FloatingActionButton(
            onPressed: () {
              if (!isDown) {
                for (final Animator animator in animators) {
                  animator.controller.forward();
                }
                setState(() {
                  isDown = true;
                });
              } else {
                for (final Animator animator in animators) {
                  animator.controller.reverse();
                }
                setState(() {
                  isDown = false;
                });
              }
            },
          ),
          body: Stack(
            children: List<Box>.generate(
              numBoxes,
              (int index) => Box(
                index: index,
                animation: animators[index].animation,
              ),
            ),
          ),
        ),
      ),
    );
  }
}

class Box extends StatelessWidget {
  Box({
    <strong i="11">@required</strong> this.animation,
    <strong i="12">@required</strong> this.index,
  });

  final int index;
  final Animation<double> animation;

  <strong i="13">@override</strong>
  Widget build(BuildContext context) {
    return Positioned(
      top: (animation.value) + (index * (100 + 10)),
      left: (MediaQuery.of(context).size.width - 100) / 2,
      child: Container(
        width: 100,
        height: 100,
        color: Colors.blue,
      ),
    );
  }
}

मैं वास्तव में कई एनीमेशन नियंत्रक चाहता हूं, प्रत्येक विजेट के लिए एक, क्योंकि वे स्वतंत्र रूप से एक दूसरे से स्वतंत्र रूप से स्थानांतरित कर सकते हैं, अपने स्वयं के अवधि, वक्र, आदि के साथ। ध्यान दें कि उपरोक्त कोड में एक बग है जिसे मैं समझ नहीं पाया, जहां इसे सफाई से चेतन करना चाहिए, लेकिन मूल रूप से इसे एक बटन क्लिक पर 3 बक्से ऊपर और नीचे चेतन करना चाहिए। हम एक ऐसे परिदृश्य की कल्पना कर सकते हैं जहां उनमें से प्रत्येक के समान वक्र होने के बजाय, मैं उनमें से प्रत्येक को एक अलग वक्र देता हूं, या मैं 100 बक्से बनाता हूं, जिनमें से प्रत्येक की अवधि पिछले वाले की तुलना में लंबी या छोटी होती है, या मैं सम को ऊपर करता हूं और अजीब नीचे जाते हैं, और इसी तरह।

सामान्य स्पंदन के साथ, initState और dispose दोनों में लूप हो सकते हैं लेकिन ऐसा नहीं है कि यह हुक के साथ लगता है, इसलिए मैं बस सोच रहा हूं कि कोई इसका मुकाबला कैसे कर सकता है। साथ ही, मैं Box वर्ग को मूल विजेट के अंदर नहीं रखना चाहता, क्योंकि मैं उन दोनों को कसकर समाहित नहीं करना चाहता; मुझे मूल तर्क को समान रखने में सक्षम होना चाहिए लेकिन उदाहरण के लिए Box साथ Box2 स्वैप करें।

धन्यवाद!
मैंने आपके उदाहरण को @TimWhiting के रेपो पर एक हुक समकक्ष के साथ धकेल दिया है

टीएल; डीआर, हुक (या बिल्डरों) के साथ, हम अनिवार्य रूप से बजाय घोषणात्मक रूप से सोचते हैं। इसलिए एक विजेट पर नियंत्रकों की सूची रखने के बजाय, उन्हें अनिवार्य रूप से चलाना - जो नियंत्रक को आइटम पर ले जाते हैं और एक निहित एनीमेशन लागू करते हैं।

धन्यवाद @rrousselGit! मैं हुक का उपयोग शुरू करने के बाद थोड़ी देर के लिए इस प्रकार के कार्यान्वयन से जूझ रहा था लेकिन अब मैं समझता हूं कि यह कैसे काम करता है। मैंने प्रत्येक एनीमेशन नियंत्रक के लिए एक अलग लक्ष्य के साथ एक संस्करण के लिए एक पीआर खोला क्योंकि यह समझने के लिए और अधिक आकर्षक हो सकता है कि हुक उपयोगी क्यों हैं जैसा मैंने ऊपर कहा था:

हम एक ऐसे परिदृश्य की कल्पना कर सकते हैं जहां उनमें से प्रत्येक के समान वक्र होने के बजाय, मैं उनमें से प्रत्येक को एक अलग वक्र देता हूं, या मैं 100 बक्से बनाता हूं, जिनमें से प्रत्येक की अवधि पिछले वाले की तुलना में लंबी या छोटी होती है, या मैं सम को ऊपर करता हूं और अजीब नीचे जाते हैं, और इसी तरह।

मैं घोषणात्मक संस्करण बनाने की कोशिश कर रहा था, लेकिन मुझे लगता है कि जो मुझे समझ में नहीं आया वह didUpdateWidget/Hook जीवनचक्र विधि थी, इसलिए मुझे नहीं पता था कि माता-पिता से चाइल्ड प्रोप बदलने पर एनीमेशन कैसे चलाया जाए, लेकिन आपके कोड ने इसे साफ़ कर दिया।

आज मेरे कोड बेस में एक वास्तविक दुनिया का उदाहरण आया, इसलिए सोचा कि मैं इसे साझा भी कर सकता हूं।

तो इस परिदृश्य में, मैं फायरस्टोर के साथ काम कर रहा हूं, और कुछ बॉयलरप्लेट है जो मैं प्रत्येक स्ट्रीमबिल्डर के साथ प्रदर्शन करना चाहता हूं, इसलिए मैंने अपना खुद का कस्टम बिल्डर बनाया। मुझे ValueListenable के साथ भी काम करने की ज़रूरत हैजो उपयोगकर्ता को सूची को फिर से ऑर्डर करने की अनुमति देता है। फायरस्टोर से संबंधित मौद्रिक-लागत कारणों के लिए, इसके लिए एक बहुत ही विशिष्ट कार्यान्वयन की आवश्यकता होती है (प्रत्येक आइटम अपने स्वयं के ऑर्डर को स्टोर नहीं कर सकता है, इसके बजाय सूची को इसे समेकित आईडी के क्षेत्र के रूप में सहेजना चाहिए), ऐसा इसलिए है क्योंकि प्रत्येक लिखने के लिए फायरस्टोर शुल्क, इसलिए आप संभावित रूप से इस तरह से बहुत सारा पैसा बचा सकते हैं। यह कुछ इस तरह पढ़कर समाप्त होता है:

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 नहीं बनाएगा क्योंकि सभी दृश्य तत्व सबसे निचले पत्ती नोड पर हैं, सभी रैपर शुद्ध स्थिति हैं।

कई वास्तविक दुनिया परिदृश्यों के साथ, "बस एक्स का उपयोग न करें" की सलाह यथार्थवादी नहीं है, क्योंकि फायरबेस में कनेक्शन का केवल एक तरीका है जो स्ट्रीम है, और किसी भी समय मुझे यह सॉकेट जैसा व्यवहार चाहिए मेरे पास कोई विकल्प नहीं है एक स्ट्रीम का उपयोग करें। सेस्ट ला विए।

यह दानेदार पुनर्निर्माण के संबंध में अनुकूलन खो देता है, लेकिन यह कोई अलग IRL नहीं बनाएगा क्योंकि सभी दृश्य तत्व सबसे निचले पत्ती नोड पर हैं, सभी रैपर शुद्ध स्थिति हैं।

यह अभी भी फर्क पड़ता है। नोड दृश्य है या नहीं, यह प्रभावित नहीं करता है कि इसे पुनर्निर्माण के लिए कुछ खर्च होता है या नहीं।

मैं शायद उस उदाहरण को अलग-अलग विजेट्स में बदल दूंगा (आईडीई के पास वास्तव में आसान बनाने के लिए एक-क्लिक रिफैक्टरिंग टूल हैं)। _buildItemList शायद एक विजेट होना चाहिए, जैसा कि भाग FamilyStreamBuilder पर निहित होना चाहिए।

हम वास्तव में दानेदार पुनर्निर्माण नहीं खोते हैं।
वास्तव में useMemoized का उपयोग करके विजेट इंस्टेंस को आसानी से कैश करने की अनुमति देकर, हुक उस पहलू को बेहतर बनाते हैं।

टिम के रेपो पर कुछ उदाहरण हैं जो ऐसा करते हैं।

मैं शायद उस उदाहरण को अलग-अलग विजेट्स में बदल दूंगा (आईडीई के पास वास्तव में आसान बनाने के लिए एक-क्लिक रिफैक्टरिंग टूल हैं)। _buildItemList शायद एक विजेट होना चाहिए, जैसा कि भाग FamilyStreamBuilder पर निहित होना चाहिए।

बात यह है कि, मैं वास्तव में ऐसा नहीं करना चाहता, क्योंकि इस दृश्य में मुझे कोई प्रदर्शन संबंधी चिंता नहीं है। इसलिए 100% समय मैं इस तरह के सूक्ष्म अनुकूलन पर कोड इलाके और सुसंगतता का पक्ष लूंगा। यह दृश्य केवल तभी फिर से बनता है जब उपयोगकर्ता कार्रवाई शुरू करता है (~ औसत प्रति 10 सेकंड में एक बार), या जब बैकएंड डेटा बदलता है और वे एक खुली सूची को घूर रहे होते हैं (लगभग कभी नहीं होता)। यह केवल एक साधारण दृश्य होता है जो मुख्य रूप से एक सूची है, और सूची में आंतरिक रूप से चल रहे अपने स्वयं के अनुकूलन का एक टन है। मुझे एहसास है कि बिल्ड() तकनीकी रूप से किसी भी समय आग लग सकता है, लेकिन व्यवहार में कोई भी यादृच्छिक पुनर्निर्माण काफी दुर्लभ है।

आईएमओ इस पर काम करना और इस दृश्य को डीबग करना काफी आसान है यदि यह सब तर्क एक विजेट में समूहीकृत है, मुख्य रूप से भविष्य में वापस आने पर मेरे जीवन को आसान बनाने के प्रयास के रूप में :)

ध्यान देने वाली एक और बात यह है कि घोंसले के शिकार ने मूल रूप से निर्माण विधि के "मुझे बाहर कर दिया", क्योंकि ऐसा कोई रास्ता नहीं था जिससे मैं अपने पेड़ को 3 क्लोजर और छेद में 16 रिक्त स्थान के अंदर बनाना शुरू कर सकूं।

और हाँ, आप कह सकते हैं कि यह समझ में आता है तो बस एक अलग विजेट पर जाएं। लेकिन सिर्फ निर्माण पद्धति में ही क्यों न रहें? अगर हम बायलरप्लेट को कम कर सकते हैं जो वास्तव में _needs_ होना चाहिए, तो 2 फाइलों में चीजों को विभाजित करने की पठनीयता और रखरखाव की परेशानी की कोई आवश्यकता नहीं है। (मान लें कि प्रदर्शन कोई चिंता का विषय नहीं है, जो अक्सर ऐसा नहीं होता है)

इस परिदृश्य में याद रखें कि मैंने अपने स्ट्रीम बिल्डर को संभालने के लिए पहले से ही एक कस्टम विजेट बनाया है। अब मुझे इन बिल्डरों की संरचना को संभालने के लिए एक और बनाने की आवश्यकता होगी ?? ऊपर से थोड़ा सा लगता है।

क्योंकि मुझे इस दृश्य में बिल्कुल भी प्रदर्शन संबंधी कोई चिंता नहीं है

ओह, मैं इसे प्रदर्शन के लिए विजेट्स में दोबारा नहीं डालूंगा, बिल्डरों को पहले से ही इसका ख्याल रखना चाहिए। मैं इसे पठनीयता और पुन: प्रयोज्यता के लिए दोबारा प्रतिक्रिया दूंगा। मैं यह नहीं कह रहा हूं कि ऐसा करने का "सही" तरीका है, बस यह कह रहा हूं कि मैं कोड को कैसे तैयार करूंगा। वैसे भी, यह न इधर है और न उधर।

किसी भी तरह से मैं अपने पेड़ को 3 क्लोजर और छेद में 16 रिक्त स्थान के अंदर बनाना शुरू नहीं कर सकता था

हो सकता है कि मेरे पास आपसे बड़ा मॉनिटर हो...:-/

तो 2 फाइलों में चीजों को विभाजित करने की पठनीयता और रखरखाव की परेशानी की कोई आवश्यकता नहीं है

मैं विजेट्स को उसी फाइल में रखूंगा, FWIW।

वैसे भी, यह एक अच्छा उदाहरण है, और मुझे विश्वास है कि आप अधिक विजेट्स का उपयोग करने के बजाय एक अलग सिंटैक्स वाले एक विजेट का उपयोग करेंगे।

हो सकता है कि मेरे पास आपसे बड़ा मॉनिटर हो...:-/

मेरे पास एक अल्ट्रावाइड है: डी, ​​लेकिन डार्टफएमटी स्पष्ट रूप से हम सभी को 80 तक सीमित करता है। इसलिए 16 खोना महत्वपूर्ण है। मुख्य मुद्दा मेरे बयान का अंत है यह },);});},),),); वास्तव में मजेदार नहीं है जब कुछ गड़बड़ हो जाता है। जब भी मैं इस वंशानुक्रम को संपादित करता हूं तो मुझे बेहद सावधान रहना पड़ता है, और सामान्य आईडीई सहायक जैसे swap with parent काम करना बंद कर देते हैं।

मैं विजेट्स को उसी फाइल में रखूंगा, 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/size_context/score

दिलचस्प - यह निश्चित रूप से पहले ऐसा नहीं था, क्योंकि प्रदाता ने थोड़ी देर के लिए dartfmt का उपयोग नहीं किया था।
मैं सही खडा हूँ।

हाँ, यह निश्चित रूप से नया व्यवहार है, जब मैंने मूल रूप से पिछले वसंत में प्रकाशित किया था तो मैंने सुनिश्चित किया था कि मैं सभी बक्से को टिक रहा था, और डार्टफएमटी की आवश्यकता नहीं थी।

इन सभी चर्चाओं के बाद, मुझे आशा है कि हम स्पंदन में हुक जैसे समाधान के लिए देशी समर्थन देखेंगे। या तो useHook या use Hook या कुछ भी जो स्पंदन करने वाली टीम को उनकी विशेषता महसूस हो सकती है, वह प्रतिक्रिया की तरह नहीं है ‍♂️

हम final controller = useAnimationController(duration: Duration(milliseconds: 800)); जैसे तरीके से हुक का उपयोग करते हैं
क्या डार्ट्स के नए प्रोग्राम फीचर _Extension_ को कोटलिन/स्विफ्ट से कॉपी करके उस सिंटैक्स को खूबसूरती से इस्तेमाल करना बेहतर नहीं है?

कुछ इस तरह: final controller = AnimationController.use(duration: Duration(milliseconds: 800));
इस दृष्टिकोण के साथ, जब स्पंदन/डार्ट टीम वर्तमान में उपलब्ध सिंटैक्स useHook बजाय use Hook जोड़ने का निर्णय लेती है, तो मुझे लगता है कि उस एक्सटेंशन फ़ंक्शन के लिए Annotation ने इसे उपयोग करने के लिए पढ़ा
final controller = use AnimationController(duration: Duration(milliseconds: 800));

use कीवर्ड जैसे const और new उपयोग करना भी समझ में आता है/सार्थक है:
new Something
const Something
use Something

उस सिफारिश के लिए एक बोनस के रूप में, मैं अंत में बात करता हूं कि कंस्ट्रक्टर/जनरेटर फ़ंक्शन भी उस प्रस्तावित Annotation उपयोग/लाभ कर सकते हैं। फिर कुछ अनुकूलन के साथ डार्ट कंपाइलर इसे use कीवर्ड का समर्थन करने के लिए परिवर्तित करता है।

बहुत सुंदर और स्पंदन/डार्ट विशिष्ट विशेषता 😉

क्या मैं यह मानने में सही हूं कि https://github.com/TimWhiting/local_widget_state_approaches/tree/master/lib/stateful में उदाहरण अब उन मुद्दों के प्रतिनिधि हैं जिन्हें लोग हल करना चाहते हैं?

मुझे यकीन नहीं है कि हर कोई कैसा महसूस करता है, लेकिन मुझे लगता है कि समस्याओं का कुछ हद तक प्रतिनिधित्व किया जाता है (जिसका अर्थ है कि मैं निश्चित नहीं हो सकता क्योंकि कोई ऐसा कुछ इंगित कर सकता है जिसका प्रतिनिधित्व नहीं किया जाता है)।

मैंने उस भंडार में एक मध्यम जमीनी समाधान का प्रयास किया है। यह हुक की तरह कंपोज़ेबल है, लेकिन फंक्शन कॉल्स के ऑर्डर करने या लूप्स आदि की अनुमति नहीं देने पर निर्भर नहीं है। यह सीधे स्टेटफुलविजेट्स का उपयोग करता है। इसमें एक मिक्सिन, साथ ही स्टेटफुल गुण शामिल होते हैं जिन्हें विशिष्ट रूप से चाबियों द्वारा पहचाना जाता है। मैं इसे अंतिम समाधान के रूप में बढ़ावा देने की कोशिश नहीं कर रहा हूं, लेकिन दो दृष्टिकोणों के बीच एक मध्य मैदान के रूप में।

मैंने इसे जीवनचक्रमिक्सिन दृष्टिकोण कहा है, यह लेटप्रॉपर्टी दृष्टिकोण के बहुत करीब है जिस पर यहां चर्चा की गई थी, लेकिन मुख्य अंतर यह है कि इसमें अधिक जीवनचक्र लागू हैं, और यह आसानी से रचना कर सकता है। (जीवन चक्र के हिस्से पर, मैंने initState के अलावा विजेट जीवनचक्र का उपयोग नहीं किया है और बहुत अधिक निपटाना है, इसलिए मैं वहां पूरी तरह से गड़बड़ कर सकता हूं)।

मुझे यह दृष्टिकोण पसंद है क्योंकि:

1. इसमें बहुत कम रनटाइम पेनल्टी है।
2. बिल्ड पथ में राज्य बनाने या प्रबंधित करने का कोई तर्क/कार्य नहीं है (बिल्ड शुद्ध हो सकता है - केवल राज्य लाने वाला)।
3. एक बिल्डर के माध्यम से पुनर्निर्माण का अनुकूलन करते समय जीवनचक्र प्रबंधन अधिक स्पष्ट होता है। (लेकिन आप राज्य के छोटे टुकड़ों की पुन: प्रयोज्यता और संरचना पर बलिदान नहीं करते हैं)।
4. चूंकि आप राज्य के बिट्स के निर्माण का पुन: उपयोग कर सकते हैं, एक पुस्तकालय राज्य के सामान्य बिट्स से बना हो सकता है जिसे कुछ तरीकों से बनाया और निपटाया जाना चाहिए, इसलिए आपके अपने कोड में कम बॉयलरप्लेट है।

मुझे निम्नलिखित कारणों से यह दृष्टिकोण (हुक की तुलना में) पसंद नहीं है:

1. मुझे नहीं पता कि इसमें वह सब कुछ शामिल है जो हुक कर सकते हैं।
2. आप विशिष्ट गुण की पहचान करने के लिए कुंजी का उपयोग करने के लिए है। (इसलिए जब कुछ राज्यों का निर्माण करने वाले तर्क के टुकड़ों की रचना करते हैं तो आपको राज्य के प्रत्येक हिस्से की विशिष्ट पहचान करने के लिए कुंजी को जोड़ना होगा - कुंजी को एक आवश्यक स्थितित्मक पैरामीटर बनाने में मदद मिलती है, लेकिन मुझे एक भाषा स्तर समाधान तक पहुंचने में मदद मिलेगी एक चर के लिए अद्वितीय आईडी)।
3. यह राज्य के सामान्य बिट्स बनाने के लिए पुन: प्रयोज्य कार्यों को बनाने के लिए एक्सटेंशन का भारी उपयोग करता है। और एक्सटेंशन आईडीई द्वारा स्वतः आयात नहीं किए जा सकते।
4. यदि आप अलग-अलग विजेट्स के जीवनचक्र को मिलाते हैं/विजेट के बीच उन्हें स्पष्ट रूप से सही ढंग से प्रबंधित किए बिना एक्सेस करते हैं तो आप स्वयं को गड़बड़ कर सकते हैं।
5. बिल्डर सिंटैक्स थोड़ा अजीब है ताकि निर्मित स्थिति बिल्ड फ़ंक्शन के दायरे में हो, लेकिन बिल्ड फ़ंक्शन को शुद्ध छोड़ दे।
6. मैंने अभी तक सभी उदाहरणों को लागू नहीं किया है, इसलिए एक उपयोग-मामला हो सकता है जिसे मैं कवर नहीं कर सकता।

सरल काउंटर उदाहरण।
एनिमेटेड काउंटर उदाहरण

ढांचा
पुन: प्रयोज्य राज्य रचना तर्क के सामान्य बिट्स

मुझे यकीन नहीं है कि मेरे पास कितना समय है, स्नातक अध्ययन हमेशा मुझे व्यस्त रखता है, लेकिन मुझे कुछ प्रतिक्रिया पसंद आएगी। @rrousselGit यह हुक के कितने करीब है, क्या आप पुन: प्रयोज्य या कंपोज़ेबिलिटी में कुछ स्पष्ट छेद देख सकते हैं?

मैं अपने समाधान को बढ़ावा देने की कोशिश नहीं कर रहा हूं, ताकि बीच के मैदान पर सकारात्मक चर्चा को प्रोत्साहित किया जा सके। अगर हम इस बात से सहमत हो सकते हैं कि क्या गुम है या यह समाधान हमें क्या देता है, तो मुझे लगता है कि हम अच्छी प्रगति कर रहे होंगे।

@TimWhiting इस दृष्टिकोण के साथ मेरे पास मुख्य मुद्दा मजबूती की कमी है। यहां एक बड़ा चालक संक्षिप्त रूप में, बिल्डरों की विश्वसनीयता की आवश्यकता है। मैजिक आईडी, और जीवनचक्र पर टकराने की क्षमता, दोनों ही बग के लिए नए वैक्टर बनाते हैं, और मैं अपनी टीम को सिफारिश करना जारी रखूंगा कि वे बिल्डरों का उपयोग करें, क्योंकि पढ़ने में बहुत बुरा होने के बावजूद, कम से कम हम जानते हैं कि वे 100 हैं % बग मुक्त।

उदाहरणों के संबंध में, मुझे अभी भी लगता है कि विजेट से बंधे अवधि मान के साथ, एक आदर्श उदाहरण केवल एनीमेशन नियंत्रक का उपयोग कर रहा है। इसे सरल और परिचित रखता है। इससे अधिक गूढ़ होने की कोई आवश्यकता नहीं है, यह पुन: उपयोग करने योग्य बॉयलरप्लेट के लिए एकदम सही छोटा उपयोग-मामला है, इसे जीवनचक्र हुक की आवश्यकता है, और सभी समाधानों को आसानी से कई एनिमेशन का संक्षिप्त रूप से उपयोग करने की उनकी क्षमता से आंका जा सकता है।

बाकी सब कुछ इसी उपयोग 'स्टेटफुल कंट्रोलर' के उपयोग के मामले का एक रूपांतर है। मैं एक्स इनिटस्टेट में करना चाहता हूं, और वाई को निपटाने की स्थिति में करना चाहता हूं, और जब मेरी निर्भरता बदलती है तो जेड अपडेट करें। इससे कोई फर्क नहीं पड़ता कि एक्स, वाई और जेड क्या हैं।

मुझे आश्चर्य है कि क्या @rrousselGit यहां कुछ अंतर्दृष्टि प्रदान कर सकता है, या कोई डेटा है जिस पर वर्तमान में हुक का सबसे अधिक उपयोग किया जाता है। मुझे लगता है कि यह 80% स्ट्रीम और एनिमेशन है, लेकिन वास्तव में यह जानना अच्छा होगा कि लोग सबसे अधिक क्या उपयोग कर रहे हैं।

पेड़ के हिस्सों के पुनर्निर्माण के संबंध में, बिल्डर्स स्वाभाविक रूप से इस कार्य के लिए उपयुक्त हैं, हमें बस उन्हें ऐसा करने देना चाहिए। एक स्टेटफुल कंट्रोलर को आसानी से स्टेटलेस रेंडरर्स में लगाया जा सकता है, अगर आप यही चाहते हैं (हैलो हर ट्रांजिशन क्लास)।

जैसे हम कर सकते हैं:

var anim = get AnimationController();
return Column(
  _someExpensiveBuildMethod(),
  FadeTransition(opacity: anim, child: ...)
)

हम हमेशा कर सकते थे:

var foo = get ComplicatedThingController();
return Column(
  _someExpensiveBuildMethod(),
  ComplicatedThing(controller: foo, child: ...)
)

@esDotDev मैं सहमत हूं, चाबियां, और बिल्डर सिंटैक्स जीवनचक्रमिक्सिन दृष्टिकोण की मुख्य कमी है। मुझे नहीं पता कि क्या आप इसके संबंधित प्रतिबंधों के साथ एक हुक शैली दृष्टिकोण का उपयोग करके, या जीवन चक्र के साथ राज्य के बिट्स के साथ परिवर्तनीय घोषणाओं को जोड़ने में सक्षम होने में एक भाषा परिवर्तन को छोड़कर इसे प्राप्त कर सकते हैं। यही कारण है कि मैं हुक का उपयोग जारी रखूंगा, और दूसरों को स्टेटफुल विजेट्स का उपयोग करने दूंगा, जब तक कि कोई बेहतर समाधान न हो। हालांकि, मुझे लगता है कि यह उन लोगों के लिए एक दिलचस्प विकल्प है जो हुक के प्रतिबंधों को पसंद नहीं करते हैं, हालांकि यह स्वयं के प्रतिबंधों के साथ आता है।

क्या मैं यह मानने में सही हूं कि https://github.com/TimWhiting/local_widget_state_approaches/tree/master/lib/stateful में उदाहरण अब उन मुद्दों के प्रतिनिधि हैं जिन्हें लोग हल करना चाहते हैं?

मुझे ईमानदारी से यकीन नहीं है।
मैं हाँ कहूँगा_। लेकिन यह वास्तव में इस बात पर निर्भर करता है कि आप इन उदाहरणों की व्याख्या कैसे करेंगे।

इस सूत्र में, हमारा एक-दूसरे को न समझने का इतिहास है, इसलिए मैं गारंटी नहीं दे सकता कि ऐसा दोबारा नहीं होगा।

इसलिए आंशिक रूप से मैं कोड उदाहरणों का उपयोग करना नापसंद करता हूं और इसके बजाय नियमों का एक सेट निकालने का सुझाव देता हूं।
उदाहरण व्यक्तिपरक हैं और उनके कई समाधान हैं, जिनमें से कुछ व्यापक समस्या का समाधान नहीं कर सकते हैं।

मुझे आश्चर्य है कि क्या @rrousselGit यहां कुछ अंतर्दृष्टि प्रदान कर सकता है, या कोई डेटा है जिस पर वर्तमान में हुक का सबसे अधिक उपयोग किया जाता है। मुझे लगता है कि यह 80% स्ट्रीम और एनिमेशन है, लेकिन वास्तव में यह जानना अच्छा होगा कि लोग सबसे अधिक क्या उपयोग कर रहे हैं।

मुझे लगता है कि यह बहुत समरूप है।

हालांकि अगर कुछ भी हो, तो useStream और एनिमेशन का सबसे कम उपयोग होने की संभावना है:

• आपके आर्किटेक्चर के आधार पर यूज़स्ट्रीम का आमतौर पर बेहतर समकक्ष होता है। उपयोग कर सकते हैं context.watch , useBloc , useProvider , ...
• कुछ लोग एनिमेशन बनाने में समय लेते हैं। यह शायद ही कभी प्राथमिकता है, और TweenAnimationBuilder अन्य निहित एनिमेटेड विजेट जरूरत के एक बड़े हिस्से को कवर करते हैं।
  हो सकता है कि अगर मैं अपने useImplicitlyAnimatedInt हुक को flutter_hooks में जोड़ दूं तो यह बदल जाएगा।

@esDotDev ने जीवनचक्रमिक्सिन दृष्टिकोण में कुंजी/आईडी की आवश्यकता को हटा दिया। यह अभी भी बिल्डर सिंटैक्स में थोड़ा अजीब है। लेकिन संभवत: इससे अंततः भी मदद मिल सकती है। जिस एक मुद्दे में मैं चल रहा हूं वह टाइप सिस्टम के साथ है। यह उन चीजों को कुछ खास तरीकों से डालने की कोशिश करता है जो काम नहीं कर रही हैं। लेकिन इसे शायद कुछ सावधानीपूर्वक कास्टिंग या सिस्टम महारत टाइप करने की ज़रूरत है। जहां तक ​​​​जीवनचक्र को मिलाने की बात है, मुझे लगता है कि कुछ उचित अपवादों को फेंककर इसमें सुधार किया जा सकता है, जब आप जिस राज्य के किसी विशेष हिस्से तक पहुंचने का प्रयास करते हैं, वह उस विजेट के जीवनचक्र द्वारा सुलभ नहीं होता है। या एक लिंट कि एक जीवनचक्र निर्माता के भीतर आपको केवल निर्माता के जीवनचक्र का उपयोग करना चाहिए।

धन्यवाद रेमी, जो मुझे आश्चर्यचकित करता है, मुझे लगता है कि लोग कोर में ट्रांजिशन विजेट्स के बड़े संग्रह को चलाने के लिए अक्सर एनीमेशन का उपयोग करेंगे, लेकिन मुझे लगता है कि ज्यादातर लोग विभिन्न इंप्लिकेट का उपयोग करते हैं, क्योंकि वे पढ़ने में काफी अच्छे हैं और घोंसला नहीं है .

फिर भी एनिमेटर कंट्रोलर को इम्प्लिक्ट और एक्सप्लिसिट विजेट्स के सूट के साथ बहुत अच्छी तरह से परोसा जाने के बावजूद, मुझे अभी भी लगता है कि यह एक ऐसी चीज का एक बेहतरीन उदाहरण है जिसे 'स्टेट को बनाए रखने की जरूरत है, और विजेट पैराम्स और लाइफसाइकिल' में बंधे हैं। और हल की जाने वाली समस्या का एक आदर्श छोटा उदाहरण के रूप में कार्य करता है (तथ्य पूरी तरह से फ़्लटर w/जैसे एक दर्जन विजेट्स में हल किया गया है), कि हम सभी चर्चा कर सकते हैं और वास्तुकला पर ध्यान केंद्रित कर सकते हैं, न कि सामग्री पर।

उदाहरण के लिए, विचार करें कि, यदि var anim = AnimationController.use(context, duration: widget.duration ?? _duration); एक प्रथम श्रेणी के नागरिक थे, तो वस्तुतः इनमें से किसी भी निहित या स्पष्ट एनिमेशन का अस्तित्व में होने की आवश्यकता नहीं है। यह उन्हें बेमानी बना देता है क्योंकि वे सभी मुख्य समस्या को प्रबंधित करने के लिए बनाए गए हैं: आसानी से एक विजेट के संदर्भ में एक स्टेटफुल चीज़ (एनीमेशन कंट्रोलर) को कंपोज़िट करना। TAB व्यर्थ के काफी करीब हो जाता है, क्योंकि आप वही काम AnimatedBuilder + AnimatorController.use() साथ कर सकते हैं।

यह वास्तव में सामान्य उपयोग के मामले की आवश्यकता को दर्शाता है यदि आप बड़े पैमाने पर विगेट्स को देखते हैं जो एनिमेशन के आसपास उछले हैं। ठीक है क्योंकि कोर सेटअप/टियरडाउन लॉजिक का पुन: उपयोग करना इतना बोझिल/बग-प्रवण है, हमारे पास 15+ विजेट हैं जो सभी बहुत विशिष्ट चीजों को संभालते हैं, लेकिन उनमें से अधिकांश एक ही एनीमेशन बॉयलरप्लेट को केवल एक मुट्ठी भर के साथ दोहरा रहे हैं कई मामलों में कोड की अनूठी पंक्तियाँ।

यह दिखाने के लिए कार्य करता है, कि हाँ, हम अपने स्वयं के स्टेटफुल लॉजिक का पुन: उपयोग करने के लिए भी ऐसा कर सकते हैं: उपयोग के हर एक क्रमपरिवर्तन के लिए एक विजेट बनाएं। लेकिन क्या परेशानी और रखरखाव सिर दर्द! लाइफसीकल हुक के साथ छोटी स्टेटफुल ऑब्जेक्ट्स को बनाने का एक आसान तरीका इतना अच्छा है, और अगर हम प्रतिपादन के लिए समर्पित विजेट बनाना चाहते हैं, या एक पुन: प्रयोज्य बिल्डर, हम आसानी से उन्हें शीर्ष पर ले जा सकते हैं।

इसके लायक क्या है, मैं सामान्य एनीमेशन विजेट के बजाय अपने ऐप में useAnimation जैसे कुछ का भारी उपयोग करता हूं। ऐसा इसलिए है क्योंकि मैं एक स्प्रिंगएनीमेशन का उपयोग कर रहा हूं जो उदाहरण के लिए एनिमेटेड कंटेनर जैसे विजेट्स के साथ अच्छी तरह से समर्थित नहीं है; वे सभी सिमुलेशन-आधारित एनीमेशन के बजाय curve और duration साथ एक समय-आधारित एनीमेशन मानते हैं, जो Simulation तर्क को स्वीकार करेगा।