React: बग़ल में डेटा लोड करना लागू करें

को निर्मित 13 मार्च 2015 · 136टिप्पणियाँ · स्रोत: facebook/react

यह एक वैश्विक स्टोर/नेटवर्क/संसाधन से स्टेटलेस (हालांकि संभावित रूप से याद किए गए) डेटा के बग़ल में डेटा लोडिंग के लिए एक प्रथम श्रेणी एपीआई है, संभावित रूप से इनपुट के रूप में प्रॉप्स/स्टेट का उपयोग कर रहा है।

type RecordOfObservables = { [key:string]: Observable<mixed> };

class Foo {

  observe(): RecordOfObservables {
    return {
      myContent: xhr(this.props.url)
    };
  }

  render() {
    var myContent : ?string = this.data.myContent;
    return <div>{myContent}</div>;
  }

}

निरीक्षण () कंपोनेंटविलमाउंट / कंपोनेंटविलअपडेट के बाद निष्पादित होता है लेकिन रेंडर करने से पहले।

रिकॉर्ड में प्रत्येक कुंजी/मान के लिए। मूल्य में नमूदार की सदस्यता लें।

subscription = observable.subscribe({ onNext: handleNext });

हम ऑननेक्स्ट को सब्सक्राइब से सिंक्रोनाइज़ करने की अनुमति देते हैं। यदि ऐसा है, तो हम सेट करते हैं:

this.data[key] = nextValue;

अन्यथा हम इसे प्रारंभिक रेंडर के लिए अपरिभाषित के रूप में छोड़ देते हैं। (हो सकता है कि हम इसे शून्य पर सेट करें?)

फिर हमेशा की तरह आय प्रस्तुत करें।

हर बार ऑननेक्स्ट का आह्वान किया जाता है, हम एक नया "यह। डेटा [कुंजी]" शेड्यूल करते हैं जो प्रभावी रूप से इस घटक पर एक मजबूर अद्यतन को ट्रिगर करता है। यदि यह एकमात्र परिवर्तन है, तो निरीक्षण को पुन: निष्पादित नहीं किया जाता है (घटकविलअपडेट -> रेंडर -> कॉम्पोनेंटडिडअपडेट)।

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

इस बिंदु पर हम नए रिकॉर्ड पर लूप करते हैं, और सभी नए वेधशालाओं की सदस्यता लेते हैं।

उसके बाद, पिछले वेधशालाओं की सदस्यता समाप्त करें।

subscription.dispose();

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

जब कोई घटक अनमाउंट किया जाता है, तो हम स्वचालित रूप से सभी सक्रिय सदस्यताओं से सदस्यता समाप्त कर देते हैं।

यदि नई सदस्यता तुरंत onNext कॉल नहीं करती है, तो हम पिछले मान का उपयोग करना जारी रखेंगे।

इसलिए यदि मेरे उदाहरण से मेरा this.props.url बदलता है, और मैं एक नए URL की सदस्यता ले रहा हूं, तो myContent पिछले url की सामग्री को तब तक दिखाता रहेगा जब तक कि अगला url पूरी तरह से लोड न हो जाए।

इसमें <img /> टैग के समान शब्दार्थ है। हमने देखा है कि, जबकि यह भ्रमित करने वाला हो सकता है और विसंगतियों को जन्म दे सकता है, यह एक काफी समझदार डिफ़ॉल्ट है, और इसके विपरीत डिफ़ॉल्ट होने की तुलना में इसे स्पिनर दिखाना आसान है।

यदि आपके पास डेटा कैश नहीं है तो तुरंत "शून्य" मान भेजना सर्वोत्तम अभ्यास हो सकता है। एक ऑब्जर्वेबल के लिए एक अन्य विकल्प यूआरएल (या आईडी) और परिणाम में सामग्री दोनों प्रदान करने के लिए है।

class Foo {

  observe() {
    return {
      user: loadUser(this.props.userID)
    };
  }

  render() {
    if (this.data.user.id !== this.props.userID) {
      // Ensure that we never show inconsistent userID / user.name combinations.
      return <Spinner />;
    }
    return <div>Hello, {this.data.user.name} [{this.props.userID}]!</div>;
  }

}

हमें ऑब्जर्वेबल के आरएक्सजेएस अनुबंध का उपयोग करना चाहिए क्योंकि यह आम उपयोग में अधिक है और सिंक्रोनस निष्पादन की अनुमति देता है, लेकिन एक बार @jhusain का प्रस्ताव अधिक सामान्य उपयोग में है, तो हम इसके बजाय उस अनुबंध पर स्विच करेंगे।

var subscription = observable.subscribe({ onNext, onError, onCompleted });
subscription.dispose();

यदि आवश्यक हो तो हम इन घटनाओं का जवाब देने वाले अधिक जीवन-चक्र हुक जोड़ सकते हैं।

नोट: यह अवधारणा बग़ल में डेटा को "व्यवहार" की तरह व्यवहार करने की अनुमति देती है - ठीक प्रॉप्स की तरह। इसका मतलब है कि हमें इन चीजों के लिए धारणा की स्थिति को अधिभारित नहीं करना है। यह अनुकूलन के लिए अनुमति देता है जैसे डेटा को केवल बाद में पुनः सदस्यता लेने के लिए फेंक देना। यह आराम करने योग्य है।

Component API Big Picture

स्रोत

sebmarkbage

👍3

सबसे उपयोगी टिप्पणी

अगर कोई इस तरह के एपीआई के साथ खेलना चाहता है, तो मैंने उच्च ऑर्डर घटक के रूप में observe के लिए वास्तव में गूंगा पॉलीफिल बनाया है:

import React, { Component } from 'react';

export default function polyfillObserve(ComposedComponent, observe) {
  const Enhancer = class extends Component {
    constructor(props, context) {
      super(props, context);

      this.subscriptions = {};
      this.state = { data: {} };

      this.resubscribe(props, context);
    }

    componentWillReceiveProps(props, context) {
      this.resubscribe(props, context);
    }

    componentWillUnmount() {
      this.unsubscribe();
    }

    resubscribe(props, context) {
      const newObservables = observe(props, context);
      const newSubscriptions = {};

      for (let key in newObservables) {
        newSubscriptions[key] = newObservables[key].subscribe({
          onNext: (value) => {
            this.state.data[key] = value;
            this.setState({ data: this.state.data });
          },
          onError: () => {},
          onCompleted: () => {}
        });
      }

      this.unsubscribe();
      this.subscriptions = newSubscriptions;
    }

    unsubscribe() {
      for (let key in this.subscriptions) {
        if (this.subscriptions.hasOwnProperty(key)) {
          this.subscriptions[key].dispose();
        }
      }

      this.subscriptions = {};
    }

    render() {
      return <ComposedComponent {...this.props} data={this.state.data} />;
    }
  };

  Enhancer.propTypes = ComposedComponent.propTypes;
  Enhancer.contextTypes = ComposedComponent.contextTypes;

  return Enhancer;
}

उपयोग:

// can't put this on component but this is good enough for playing
function observe(props, context) {
  return {
    yourStuff: observeYourStuff(props)
  };
}

class YourComponent extends Component {
  render() {
    // Note: this.props.data, not this.data
    return <div>{this.props.data.yourStuff}</div>;
  }
}

export default polyfillObserve(YourComponent, observe);

gaearon 15 मार्च 2015

👍3 🎉1 😄1

सभी 136 टिप्पणियाँ

undefined संभवतः data को असाइन करने के लिए सबसे सुरक्षित मान है जब तक कि देखने योग्य onNext के माध्यम से अपना पहला मान प्रदान नहीं करता है। उदाहरण के लिए रिले में हम null (डेटा मौजूद नहीं है) और undefined (अभी तक प्राप्त नहीं हुआ) के लिए अलग-अलग अर्थ निर्दिष्ट करते हैं, इसलिए हमारा आदर्श डिफ़ॉल्ट डेटा मान undefined होगा। विकल्प एक नई विधि प्रदान करना है, उदाहरण के लिए getInitialData , लेकिन मुझे संदेह है कि यह अनावश्यक/ओवरकिल है।

josephsavona 13 मार्च 2015

यह बहुत दिलचस्प है हालांकि स्थिर टाइपिंग के दृष्टिकोण से मैं कुंजी/मूल्य प्रणाली से इतना खुश नहीं हूं, उनके प्रकार को व्यक्त करना बहुत असंभव है।
क्यों नहीं observe एक अवलोकन योग्य लौटाएं और this.data के लिए हल किए गए मान को सेट/मर्ज करें:

class Foo {

  observe() {
    return (
      loadUser(this.props.userID)
        .map(user => { user })
  }

  render() {
    if (this.data.user.id !== this.props.userID) {
      // Ensure that we never show inconsistent userID / user.name combinations.
      return <Spinner />;
    }
    return <div>Hello, {this.data.user.name} [{this.props.userID}]!</div>;
  }

}

और एकाधिक लाने के मामले में कुछ ऐसा:

class Foo {

  observe() {
    return (
     combineLatest(
      loadUser(this.props.userID),
      loadSomethingElse(this.props.somethingElseId),
      (user, somethingElse) => ({ user, somethingElse})
     )
  }

  render() {
    ..
  }

}

यह शायद थोड़ा अधिक वर्बोज़ है, लेकिन यह अच्छा स्थिर प्रकार रखने की अनुमति देता है:

interface Comp<T> {
  observe(): Observable<T>;
  data: T;
}

fdecampredon 13 मार्च 2015

इसके अलावा observe को फिर से निष्पादित करने के बजाय जब प्रॉप्स/स्टेट चेंज होता है तो हम 'प्रॉप्स' 'स्टेट' को एक अवलोकन योग्य के रूप में एक्सेस कर सकते हैं:

class Foo {

  observe(propsStream) {
    return (
      propsStream
        .flatMap(({ userID }) => loadUser(userId))
        .map(user => { user })
    );
  }

  render() {
    if (this.data.user.id !== this.props.userID) {
      // Ensure that we never show inconsistent userID / user.name combinations.
      return <Spinner />;
    }
    return <div>Hello, {this.data.user.name} [{this.props.userID}]!</div>;
  }
}

fdecampredon 13 मार्च 2015

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

हालांकि, एक साधारण फ्लक्स स्टोर की सदस्यता लेने के लिए, आपको इसकी आवश्यकता नहीं होनी चाहिए।

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

class Foo extends React.Component {
  data : { user : User, content : string };
  observe() /* implied as { user : Observable<User>, content : Observable<string> } */ {
  }
}

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

sebmarkbage 13 मार्च 2015

❤1

cc @ericvicenti

vjeux 13 मार्च 2015

कम से कम टाइपस्क्रिप्ट के मामले में, observe के प्रकार के आधार पर $ data observe के रिटर्न प्रकार को बाधित करने का कोई तरीका नहीं होगा, कम से कम जब तक https://github.com/ जैसा कुछ नहीं होगा।

fdecampredon 13 मार्च 2015

मैं इसे रिएक्ट डीएनडी के अगले संस्करण के लिए उपयोग करना पसंद करूंगा, लेकिन जाहिर है कि इसके लिए रिएक्ट 0.14 की प्रतीक्षा करनी होगी।
मुझे आश्चर्य है कि क्या मैं उस समय के लिए एक उच्च-आदेश घटक के साथ "पॉलीफिल" कर सकता हूं जो ref उदाहरण पर this.data सेट करता है .. हालांकि बहुत पागल हो सकता है।

gaearon 14 मार्च 2015

क्या वादों का पालन करना संभव होगा? फिर पहले रेंडर करने से पहले पूरे कंपोनेंट ट्री के डेटा को हल करने के लिए एक प्रॉमिस ट्री का उपयोग किया जा सकता है! यह सर्वर-साइड रिएक्ट के लिए बहुत उपयोगी होगा।

RickWong 14 मार्च 2015

इसे प्रथम श्रेणी API बनाने के क्या लाभ हैं? यह अनिवार्य रूप से "उच्च-क्रम घटक" का उपयोग करके पूरा किया जा सकता है।

aaronshaf 14 मार्च 2015

इसे प्रथम श्रेणी API बनाने के क्या लाभ हैं? यह अनिवार्य रूप से "उच्च-क्रम घटक" का उपयोग करके पूरा किया जा सकता है।

5 सब्सक्रिप्शन प्राप्त करने के लिए 5 एचओसी में लपेटना शुरुआती लोगों के लिए थोड़ा बोझिल और समझने में कठिन है। componentWillReceiveProps को समझना भी गैर-तुच्छ है। यह दोनों को ठीक करता है।

मैं, एक के लिए, हमारे नए अवलोकन योग्य अधिपति का स्वागत करता हूं।

gaearon 14 मार्च 2015

😄3

मुझे आश्चर्य है कि क्या यह https://github.com/chenglou/react-state-stream को रिएक्ट के वेनिला एपीआई के करीब लाने में मदद कर सकता है

gaearon 14 मार्च 2015

क्या यह सिर्फ एक एचओसी नहीं लेगा? आपके माध्यम पोस्ट में उदाहरण में, आप stores से अधिक पुनरावृति करते हैं और प्रत्येक की सदस्यता लेते हैं।

stores.forEach(store =>
  store.addChangeListener(this.handleStoresChanged)
);

aaronshaf 14 मार्च 2015

@aaronshaf निश्चित रूप से उपयोग के मामले पर निर्भर करता है। कभी-कभी यह विभिन्न प्रकार के राज्य स्रोत होते हैं, न कि केवल "कई स्टोर"। लेकिन मैं रिएक्ट टीम की ओर से कुछ नहीं कह सकता, आइए सुनते हैं @sebmarkbage क्या कहते हैं।

gaearon 14 मार्च 2015

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

nmn 14 मार्च 2015

( @vjeux ने मुझसे कहा था कि मुझे झंकार करना चाहिए! इसलिए मैं यहां हूं।)

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

एपीआई की तरह दिखता है:

class UserDetails {
  getNexusBindings(props) {
    return {
      // binding to data in the datacenter
      posts: [this.getNexus().remote, `users/${this.props.userId}/posts`],
      // binding to data in the local flux
      mySession: [this.getNexus().local, `session`],
    }
  }
}

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

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

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

elierotenberg 14 मार्च 2015

@aaronshaf @gaearon इसे प्रथम श्रेणी बनाने का लाभ यह है:

1) यह प्रॉप्स नेमस्पेस पर नहीं खाता है। उदाहरण के लिए, उच्च-क्रम वाले घटक को आपके प्रॉप्स ऑब्जेक्ट से data जैसे नाम का दावा करने की आवश्यकता नहीं है जो किसी अन्य चीज़ के लिए उपयोग नहीं कर सकता है। कई उच्च क्रम के घटकों की श्रृंखला अधिक नाम खा रही है और अब आपको उन नामों को अद्वितीय रखने का एक तरीका खोजना होगा। क्या होगा यदि आप कुछ ऐसी रचना कर रहे हैं जो पहले से ही बनाई जा सकती है और अब आपके पास नाम का विरोध है?

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

2) हमें अंतिम मूल्य को स्टोर करने के लिए state का उपयोग करने की आवश्यकता नहीं है। data अवधारणा इस अर्थ में props के समान है कि यह विशुद्ध रूप से एक संस्मरण है। यदि हमें स्मृति को पुनः प्राप्त करने की आवश्यकता है तो हम इसे किसी भी समय बाहर फेंकने के लिए स्वतंत्र हैं। उदाहरण के लिए, एक अनंत स्क्रॉल में हम अदृश्य सबट्री को स्वचालित रूप से साफ कर सकते हैं।

sebmarkbage 14 मार्च 2015

@RickWong हां, वादों का समर्थन करना काफी तुच्छ होगा क्योंकि वे

ए) उन्हें ढांचे द्वारा स्वचालित रूप से रद्द नहीं किया जा सकता है। सबसे अच्छा हम यह कर सकते हैं कि देर से किए गए समाधान को नज़रअंदाज करें। इस बीच, वादा संभावित रूप से महंगे संसाधनों पर कायम है। लंबे समय तक चलने वाले टाइमर/नेटवर्क अनुरोधों की सदस्यता/रद्द/सदस्यता/रद्द करने की कठिन स्थिति में आना आसान है और यदि आप वादे का उपयोग करते हैं, तो वे रूट पर रद्द नहीं होंगे और इसलिए आपको बस इंतजार करना होगा पूरा करने या समय समाप्त करने के लिए संसाधन। यह बड़े डेस्कटॉप पेजों (जैसे facebook.com) या स्मृति बाधित वातावरण (जैसे प्रतिक्रिया-मूल) में विलंबता महत्वपूर्ण ऐप्स में प्रदर्शन के लिए हानिकारक हो सकता है।

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

इसलिए मुझे लगता है कि ऑब्जर्वेबल बनाने के लिए बेहतर एपीआई है क्योंकि यह आपको जरूरत पड़ने पर इन मुद्दों को ठीक करने के लिए लॉक नहीं करता है।

sebmarkbage 14 मार्च 2015

@elierotenberg में चिंराट करने के लिए धन्यवाद! यह वास्तव में बहुत समान लगता है। एक ही तरह के लाभ। क्या आप मेरे प्रस्ताव के साथ कोई सीमाएँ देखते हैं? यानी वहाँ कुछ याद आ रही है, कि रिएक्ट नेक्सस है, जिसे आप इसके ऊपर नहीं बना सकते हैं? अच्छा होगा यदि हम स्वयं को महत्वपूर्ण उपयोग के मामलों से बाहर न निकालें। :)

sebmarkbage 14 मार्च 2015

सर्वर-रेंडरिंग दृष्टिकोण से, यह महत्वपूर्ण है कि हम अंतिम रेंडरटॉस्ट्रिंग को तब तक स्थगित कर सकते हैं जब तक कि ऑब्जर्वेबल/वादा डेटा के साथ हल नहीं हो जाता है जिसे एसिंक्रोनस रूप से प्राप्त किया जा सकता है। अन्यथा, हम अभी भी रिएक्ट के बाहर सभी एसिंक्रोनस डेटा लाने की स्थिति में हैं, यह जाने बिना कि कौन से घटक पृष्ठ पर होंगे।

मेरा मानना है कि रिएक्ट-नेक्सस रेंडर ट्री को जारी रखने से पहले एक घटक के भीतर अतुल्यकालिक लोडिंग की अनुमति देता है।

mridgway 14 मार्च 2015

हां, प्रतिक्रिया-गठबंधन स्पष्ट रूप से अलग करता है:
1) getNexusBindings के रूप में बाध्यकारी घोषणा (जो एक तुल्यकालिक, साइड-इफेक्ट मुक्त जीवनचक्र विधि है, रेंडर के समान - वास्तव में इसका नाम रेंडरडिपेंडेंसी हुआ करता था लेकिन मुझे लगा कि यह भ्रमित करने वाला है),
2) बाध्यकारी सदस्यता/अद्यतन applyNexusBindings के रूप में (जो तुल्यकालिक है और यह निर्धारित करने के लिए पिछले नेक्सस बाइंडिंग को अलग करता है कि कौन सी नई बाइंडिंग को सब्सक्राइब किया जाना चाहिए और किन लोगों को अनसब्सक्राइब किया जाना चाहिए)
3) प्रीफ़ेचिंग को prefetchNexusBindings के रूप में बाध्य करना (जो अतुल्यकालिक है और "प्रारंभिक" (इसका जो भी अर्थ हो) मान तैयार होने पर हल हो जाता है)

ReactNexus.prefetchApp(ReactElement) एक Promise(String html, Object serializableData) $ लौटाता है। यह हुक रिएक्ट ट्री के निर्माण की नकल करता है ( instantiateReactComponent का उपयोग करके) और पुनरावर्ती रूप से घटकों का निर्माण/प्रीफ़ेच/रेंडर करता है। जब पूरा घटक पेड़ 'तैयार' होता है, तो अंत में यह React.renderToString को कॉल करता है, यह जानकर कि सभी डेटा तैयार है (मॉड्यूलो त्रुटियां)। एक बार हल हो जाने पर, इस वादे का मूल्य सर्वर प्रतिक्रिया में इंजेक्ट किया जा सकता है। क्लाइंट पर, नियमित React.render() जीवनचक्र हमेशा की तरह काम करता है।

elierotenberg 14 मार्च 2015

import React, { Component } from 'react';

export default function polyfillObserve(ComposedComponent, observe) {
  const Enhancer = class extends Component {
    constructor(props, context) {
      super(props, context);

      this.subscriptions = {};
      this.state = { data: {} };

      this.resubscribe(props, context);
    }

    componentWillReceiveProps(props, context) {
      this.resubscribe(props, context);
    }

    componentWillUnmount() {
      this.unsubscribe();
    }

    resubscribe(props, context) {
      const newObservables = observe(props, context);
      const newSubscriptions = {};

      for (let key in newObservables) {
        newSubscriptions[key] = newObservables[key].subscribe({
          onNext: (value) => {
            this.state.data[key] = value;
            this.setState({ data: this.state.data });
          },
          onError: () => {},
          onCompleted: () => {}
        });
      }

      this.unsubscribe();
      this.subscriptions = newSubscriptions;
    }

    unsubscribe() {
      for (let key in this.subscriptions) {
        if (this.subscriptions.hasOwnProperty(key)) {
          this.subscriptions[key].dispose();
        }
      }

      this.subscriptions = {};
    }

    render() {
      return <ComposedComponent {...this.props} data={this.state.data} />;
    }
  };

  Enhancer.propTypes = ComposedComponent.propTypes;
  Enhancer.contextTypes = ComposedComponent.contextTypes;

  return Enhancer;
}

उपयोग:

// can't put this on component but this is good enough for playing
function observe(props, context) {
  return {
    yourStuff: observeYourStuff(props)
  };
}

class YourComponent extends Component {
  render() {
    // Note: this.props.data, not this.data
    return <div>{this.props.data.yourStuff}</div>;
  }
}

export default polyfillObserve(YourComponent, observe);

gaearon 15 मार्च 2015

👍3 🎉1 😄1

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

एक तरफ के रूप में धाराएं क्यों नहीं? मेरे पास दौड़ में कोई घोड़ा नहीं है, लेकिन मैं ईमानदारी से सोच रहा हूं; वेब स्ट्रीम पर पहले से ही काम किया जा चुका है, और निश्चित रूप से नोड है

jquense 15 मार्च 2015

विचार करने के लिए एक और दो: https://github.com/cujojs/most और https://github.com/caolan/highland

aaronshaf 15 मार्च 2015

@jquense ईसीएमएस्क्रिप्ट 7 (+) में अवलोकन योग्य जोड़ने के प्रस्ताव पर सक्रिय काम है, इसलिए आदर्श रूप से यह सादा जेएस बन जाएगा। https://github.com/jhusain/asyncgenerator (वर्तमान में पुराना है।)

हम RxJS पर निर्भरता नहीं लेंगे। एपीआई आरएक्सजेएस का उपयोग किए बिना स्वयं को लागू करने के लिए छोटा है। RxJS सक्रिय ECMAScript प्रस्ताव के सबसे करीब है।

अधिकांश.जेएस भी करने योग्य लगता है।

बेकन पर निर्भरता के बिना बेकन.जेएस एपीआई का उपभोग करना मुश्किल लगता है क्योंकि मूल्यों को अलग करने के लिए Bacon.Event प्रकारों का उपयोग किया जाता है।

स्ट्रीम एपीआई बहुत उच्च-स्तरीय हैं और इस उपयोग के मामले से बहुत दूर हैं।

sebmarkbage 15 मार्च 2015

क्या किसी प्रकार का "रेंडर करने से पहले प्रतीक्षा करें" विकल्प है? मेरा मतलब है कि क्लाइंट पर रेंडरिंग से पहले सभी ऑब्जर्वेबल्स की प्रतीक्षा करना आवश्यक नहीं है, लेकिन सर्वर पर आप उन्हें हल करने के लिए इंतजार करना चाहेंगे ताकि प्रत्येक कंपोनेंट का रेंडर () हो पूर्ण , आंशिक नहीं।

[parent] await observe(). full render(). -> [foreach child] await observe(). full render().

अपने सभी अन्वेषणों में मैंने पाया कि यह सर्वर-साइड रिएक्ट में गायब होने वाला सबसे महत्वपूर्ण जीवनचक्र हुक है।

RickWong 15 मार्च 2015

इस चर्चा के बाद, मैंने यह बताने की कोशिश की है कि रिएक्ट नेक्सस निम्नलिखित पोस्ट में क्या करता है:

इस्मोर्फिक ऐप्स ने रिएक्ट नेक्सस के साथ सही किया

कोर प्रीफ़ेचिंग रूटीन का आरेख यहां दिया गया है:

React Nexus

elierotenberg 15 मार्च 2015

हम RxJS पर निर्भरता नहीं लेंगे। एपीआई आरएक्सजेएस का उपयोग किए बिना स्वयं को लागू करने के लिए छोटा है। RxJS सक्रिय ECMAScript प्रस्ताव के सबसे करीब है।

:+1: यह मेरे लिए बड़ी चिंता का विषय है, कहने के बारे में सोचकर, वादों को लागू करना जहां अपने आप को लागू करना बेहद कठिन है, जब तक कि आप यह नहीं जानते कि आप क्या कर रहे हैं। मुझे लगता है कि अन्यथा आप पारिस्थितिक तंत्र में एक विशिष्ट lib पर एक अंतर्निहित आवश्यकता के साथ समाप्त हो जाते हैं। मूर्त रूप से ... वादे की दुनिया से अच्छी चीजों में से एक ए + टेस्ट सूट है, इसलिए पुस्तकालयों में भी कम से कम .then की एक सामान्य कार्यक्षमता का आश्वासन था, जो वादा इंटरऑप के लिए सहायक था इससे पहले कि वे थे मानकीकृत।

jquense 15 मार्च 2015

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

पूरी तरह से सहमत। शुक्र है कि वेधशालाओं का वास्तव में सरल अनुबंध है, और यहां तक कि then जैसी अंतर्निहित विधियां भी नहीं हैं,

gaearon 15 मार्च 2015

वे और अधिक जटिल (और धीमे) हो सकते हैं यदि समिति जोर देकर कहती है कि next को कॉल करने से वादे जैसे सूक्ष्म कार्य को शेड्यूल किया जाता है।

sebmarkbage 15 मार्च 2015

यह कुछ बहुत परेशान करेगा पैटर्न इस तथ्य पर आधारित है कि अगला आरएक्सजेएस में सिंक्रोनस है: /

fdecampredon 15 मार्च 2015

👍1

मुझे लगता है कि एक सामान्य फ्लक्स स्टोर पैटर्न प्रति-कुंजी आधार पर वेधशालाओं का नक्शा रखना हो सकता है ताकि उनका पुन: उपयोग किया जा सके। फिर जब सभी की सदस्यता समाप्त हो जाए तो उन्हें साफ करें।

इस तरह आप इस तरह की चीजें कर सकते हैं: MyStore.get(this.props.someID) और हमेशा वही ऑब्जर्वेबल वापस पाएं।

sebmarkbage 16 मार्च 2015

इस तरह आप चीजें कर सकते हैं जैसे: MyStore.get(this.props.someID) और हमेशा वही ऑब्जर्वेबल वापस पाएं।

this.props.key (मुझे पता चला गया) का उपयोग करना समझ में आता है? ज्यादातर मामलों में आप पहले से ही ऐसे विशिष्ट पहचानकर्ता को <... key={child.id} .. /> साथ पास कर चुके हैं।

RickWong 16 मार्च 2015

इस तरह आप चीजें कर सकते हैं जैसे: MyStore.get(this.props.someID) और हमेशा वही ऑब्जर्वेबल वापस पाएं।

यही वह पैटर्न है जिसका उपयोग मैं रिएक्ट नेक्सस के लिए भी करता हूं। स्टोर#ऑब्जर्व एक मेमोइज्ड, अपरिवर्तनीय ऑब्जर्वर लौटाता है; जब सभी सब्सक्राइबर कम से कम एक टिक के लिए चले जाते हैं तो यह साफ हो जाता है (प्रासंगिक बैकएंड-विशिष्ट सफाई तंत्र सहित, जैसे वास्तविक "सदस्यता समाप्त करें" संदेश या जो कुछ भी भेजना)।

elierotenberg 16 मार्च 2015

@sebmarkbage @gaearon v0.14 में सर्वर पर काम कैसे देखेंगे?
क्या यह प्रतिक्रिया-नेक्सस (लेकिन प्रतिक्रिया करने के लिए बनाया गया) के समान स्ट्रिंग को प्रस्तुत करने से पहले सभी पर्यवेक्षकों को हल करने के लिए ठीक से प्रतीक्षा करने में सक्षम होगा?

jeffbski 20 मार्च 2015

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

gaearon 20 मार्च 2015

@gaearon : आईएमओ यह बहुत अच्छा होगा यदि घटक सर्वर पर प्रतिपादन के लिए "तैयार" होने से पहले पहले देखे गए मूल्य की प्रतीक्षा कर रहे हों।

हाँ, :+1: अतुल्यकालिक प्रतिपादन के लिए। इस बीच @andreypopp द्वारा react-async एक विकल्प है, लेकिन इसके लिए प्रतिक्रिया को "हैक" करने के लिए fibers आवश्यकता होती है। यह बहुत अच्छा होगा यदि रिएक्ट आउट-ऑफ-द-बॉक्स एसिंक्रोनस रेंडरिंग का समर्थन कर सके।

RickWong 20 मार्च 2015

Async रेंडरिंग एक ऐसी चीज़ है जिसका हम समर्थन करना चाहेंगे लेकिन यह इस समस्या का हिस्सा नहीं है। ली

दुर्भाग्य से इसे 0.14 में नहीं बना पाएंगे। विचार करने और रिफ्लेक्टर की जरूरत के लिए कई अलग-अलग डिजाइन।

ऐसा करने के लिए आवश्यक आंतरिक में वास्तुशिल्प परिवर्तनों का वर्णन करने और जारी करने के लिए स्वतंत्र महसूस करें।

sebmarkbage 20 मार्च 2015

मेरे पास @gaearon re: React -streaming-state जैसा ही विचार था। साइड लोडिंग के अलावा अन्य सभी संभावित अनुप्रयोगों को देखते हुए, क्या data से बेहतर नाम हो सकता है? उदाहरण के लिए, observed इसे विधि से अधिक स्पष्ट रूप से संबद्ध करेगा।

बाइक शेडिंग के साथ पटरी से उतरने का मतलब नहीं है, लेकिन इसे वहीं फेंकना चाहता हूं।

matthewwithanm 25 मार्च 2015

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

chicoxyzzy 30 मार्च 2015

👍2

react-async को फिर से लिखते समय मैं इसी तरह के विचार के साथ प्रयोग कर रहा हूं, README देखें।

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

जब नामित प्रक्रिया का id बदलता है तो React Async पुराने प्रोसेस इंस्टेंस को रोक देता है और एक नया प्रारंभ करता है।

एपीआई की तरह दिखता है:

import React from 'react';
import Async from 'react-async';

function defineFetchProcess(url) {
  return {
    id: url,
    start() {
      return fetch(url)
    }
  }
}

function MyComponentProcesses(props) {
  return {
    user: defineFetchProcess(`/api/user?user${props.userID}`)
  }
}

@Async(MyComponentProcesses)
class MyComponent extends React.Component {

  render() {
    let {user} = this.props
    ...
  }
}

प्रक्रिया API अब ES6 Promise API का वाक्य-रचना और नाम-वार अनुसरण करता है, लेकिन शब्दार्थ की दृष्टि से यह process.then(onNext, onError) के लिए प्रति प्रक्रिया लाइव केवल एक बार कॉल किए जाने की उम्मीद नहीं है। यह वादों के माध्यम से डेटा लाने के सबसे लोकप्रिय (?) उपयोग के मामले को समायोजित करने के लिए बनाया गया है। लेकिन ईमानदार होने के लिए, अब मुझे लगता है कि भ्रम को रोकने के लिए मुझे इसे बदलने की जरूरत है।

andreypopp 6 अप्रैल 2015

मैं शायद गलत हूं, लेकिन मुझे लगता है कि केवल एक चीज जो प्रस्तावित (इस मुद्दे में) एपीआई को यूजरलैंड में लागू करने से रोकती है, वह जीवनचक्र हुक की कमी है जो componentWillUpdate तरह प्रस्तुत करने से ठीक पहले निष्पादित होता है लेकिन नए props और state पहले से ही इंस्टेंस पर स्थापित है।

andreypopp 6 अप्रैल 2015

एक बात जिस पर अभी तक चर्चा नहीं हुई है वह है onError कॉलबैक का प्रबंधन। यदि कोई अवलोकन योग्य त्रुटि उत्पन्न करता है, तो वह जानकारी घटक को किसी भी तरह उपलब्ध होनी चाहिए। चूंकि रिएक्ट वास्तविक subscribe(callbacks) कॉल को संभालता है, इसलिए हमें उस कॉलबैक ऑब्जेक्ट में इंजेक्ट करने के लिए एक मानकीकृत विधि की आवश्यकता होगी।

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

onObserveError(key, error) {
  // do something with the error
  this.state.errors[key] = error;
  this.setState({ errors: this.state.errors });
}

यह वैसा ही है जैसा हमने Parse+React के आगामी पुनरावृत्ति में किया है। हमने अपनी इच्छित एपीआई का उत्पादन करने के लिए अपनी स्वयं की त्रुटि प्रबंधन बनाई। त्रुटियों को एक निजी {नाम => त्रुटि} मानचित्र में जोड़ा जाता है, और घटकों में एक शीर्ष-स्तरीय सार्वजनिक विधि होती है, queryErrors() , जो मानचित्र का एक क्लोन लौटाती है यदि वह खाली नहीं है, और null अन्यथा (एक साधारण if (this.queryErrors()) के लिए अनुमति देना।

बेशक, नए आरक्षित तरीकों को परिभाषित करना भी एक मुश्किल काम है; मैं दिखावा नहीं करूंगा कि ऐसा नहीं है। लेकिन हमें प्रतिपादन करते समय घटक के लिए त्रुटियों को स्पष्ट रूप से या स्पष्ट रूप से उपलब्ध कराने का एक तरीका चाहिए।

andrewimm 7 अप्रैल 2015

@andrewimm विचार यह है कि इसे एक सामान्य त्रुटि प्रसार प्रणाली में फीड करना है जो पदानुक्रम को त्रुटि देता है जब तक कि इसे त्रुटि सीमा द्वारा नियंत्रित नहीं किया जाता है। https://github.com/facebook/react/issues/2928

इसे फेंकने और इनायत से पुनर्प्राप्त करने के तरीकों में त्रुटियों को भी संभालना चाहिए। जैसे अगर render() विधि फेंकता है। यह काफी अधिक काम है और इसे ठीक से लागू करने में कुछ समय लगेगा लेकिन विचार इस तरह से त्रुटि प्रबंधन को एकीकृत करना था।

sebmarkbage 7 अप्रैल 2015

मैं तर्क दूंगा कि इसे उचित प्रतिक्रिया के बाहर छोड़ दिया जाना चाहिए, और 1 या 2 प्रमुख एकीकरण बिंदुओं को प्रतिक्रिया-एसिंक और प्रतिक्रिया-नेक्सस जैसी परियोजनाओं के साथ समन्वयित किया जाना चाहिए ताकि यह प्रतिक्रिया के शीर्ष पर सफाई से किया जा सके ....

kryptt 22 अप्रैल 2015

मैं सहमत हूं, ऐसा लगता है कि ऐसा करने के लिए सुझाए गए तरीके से बेहतर है
इसे ढांचे में ही पकाना

मंगलवार को, अप्रैल 21, 2015, रात 11:38 अपराह्न रोडोल्फो हैनसेन सूचनाएं @github.com
लिखा था:

मैं तर्क दूंगा कि इसे उचित प्रतिक्रिया के बाहर छोड़ दिया जाना चाहिए, और 1 या 2 कुंजी
एकीकरण बिंदुओं को प्रतिक्रिया-एसिंक जैसी परियोजनाओं के साथ समन्वयित किया जाना चाहिए और
प्रतिक्रिया-गठबंधन तो यह उचित रूप से प्रतिक्रिया के शीर्ष पर सफाई से किया जा सकता है ....
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें
https://github.com/facebook/react/issues/3398#issuecomment -95048028।

pspeter3 22 अप्रैल 2015

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

इसलिए, मैं कहूंगा कि वास्तविक वेधशालाओं के साथ एपीआई बनाना काफी आसान है।

उस ने कहा, कोड को कठोरता से न आंकें, यह एक सप्ताह के अंत में किया गया था:

मज़ा
सहमति
जेएस-सीएसपी का उपयोग करना
अवलोकन एपीआई का उपयोग करना

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

nmn 23 अप्रैल 2015

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

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

हम कौन से हुक याद कर रहे हैं?

sebmarkbage 23 अप्रैल 2015

अरे,

ईमानदार होने के लिए, जबकि नए हुक ने कार्यान्वयन को आसान बना दिया होगा, हम निश्चित रूप से उनके बिना बग़ल में डेटा लोडिंग प्राप्त कर सकते हैं, जैसा कि हमने react-async और react-nexus ।

यदि कुछ भी हो, तो रिएक्ट घटकों को बनाए रखने और समर्थन करने से एक माउंटेड रिएक्ट पदानुक्रम के बाहर जीवनचक्र को मदद मिलेगी। react-nexus मैं आंतरिक instanciateReactComponent उपयोग करता हूं और componentWillMount , componentWillUnmount , आदि को स्वयं कॉल करता हूं, और मैं इस दृष्टिकोण को भंगुर मानता हूं (क्या होगा यदि instanciateReactComponents उन आंतरिक इनवेरिएंट पर निर्भर करता है जो रिएक्ट के अगले संस्करण में बदलते हैं?)

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

elierotenberg 23 अप्रैल 2015

आप किन अन्य एकीकरण बिंदुओं का सुझाव देंगे?

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

jquense 23 अप्रैल 2015

मैं यहां बड़ी चर्चा में नहीं पड़ रहा हूं।
लेकिन @sebmarkbage का जवाब देने के लिए मुझे लगता है कि सबसे महत्वपूर्ण हुक में से एक मुझे कुछ ऐसा चाहिए जो वास्तविक वेधशालाओं का उपयोग न करने पर ही आवश्यक हो।

एक हुक जो फ़ंक्शन प्रदान कर सकता है जो देखने योग्य _before_ द्वारा धक्का दिए गए मानों से निपट सकता है, वे डेटा पर सेट होते हैं। वास्तविक वेधशालाओं के साथ, यह केवल एक .map . होगा

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

nmn 23 अप्रैल 2015

ऐसा लगता है कि पिछली कुछ टिप्पणियां कह रही हैं कि सबसे छोटा विस्तार बिंदु वास्तव में "कनेक्ट" और "डिस्कनेक्ट" जीवनचक्र हुक है - जो एक घटक को एसिंक डेटा संलग्न करना और उन सदस्यताओं को प्रबंधित करना आसान बनाता है?

तब वेधशालाओं को उस (अंदर या बाहर कोर) पर काफी तुच्छ रूप से बनाया जा सकता था - लेकिन उन जीवनचक्र बिंदुओं को उजागर करने से व्यापक अपील होती है?

क्या यह एक उचित सारांश है?

glenjamin 23 अप्रैल 2015

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

लेकिन एक पल के लिए, मान लें कि हम observe() के साथ जा रहे हैं। कुछ विचार:

हमारे पास this.props , this.state , this.context और अब this.data , सभी render() में नए डेटा के संभावित स्रोत हैं। यह मुझे अत्यधिक लगता है। क्या एप्लिकेशन स्टेट को कंपोनेंट स्टेट से अलग करने का विचार है? यह राज्य के आसपास के कुछ मुद्दों को स्पष्ट और अलग कर सकता है, लेकिन मुझे लगता है कि एक नया इनपुट पेश करने की लागत लाभ से अधिक नहीं हो सकती है। यदि हम चाहते हैं कि this.state पूरी तरह से घटक स्थिति पर केंद्रित हो, तो क्यों न this.data में फ़ील्ड को this.props या this.context $ में जोड़ने दिया जाए?

this.data नाम बहुत सामान्य है। सहारा डेटा है, राज्य डेटा है, और कोई भी स्थानीय चर डेटा है। नाम कोई अर्थ नहीं जोड़ता है और मौजूदा अर्थों को उलझाता है। मैं this.observed या किसी अन्य नाम को पसंद करूंगा जिसका वास्तव में कुछ मतलब होगा। तो +1 से @matthewwithanm की टिप्पणी:

data से बेहतर कोई नाम हो सकता है? उदाहरण के लिए, observed इसे विधि से अधिक स्पष्ट रूप से संबद्ध करेगा।

अगर हम सर्वर पर observe() निष्पादित करते हैं, तो हमें किसी प्रकार के हुक की आवश्यकता होती है जो किसी भी मेमोरी लीक को साफ कर देगा, क्योंकि अनमाउंटिंग कभी नहीं होगी।

यदि हम observe() को हर बार props या state परिवर्तन (और context observe ) गलती से महंगा नहीं बनाया जा सकता। यह गर्म रास्ते का हिस्सा बन जाता है। मुझे रिएक्ट नेक्सस से यह पसंद है:

अगले बाइंडिंग पिछले बाइंडिंग से भिन्न हैं; हटाए गए बाइंडिंग को अनसब्सक्राइब किया जाता है, जोड़े गए बाइंडिंग को सब्सक्राइब किया जाता है।

fisherwebdev 27 अप्रैल 2015

👍1

मुझे विश्वास हो गया है कि राज्य घटकों को जटिल बनाता है और मैं इसे अपने घटकों में कम उपयोग करने और इसके बजाय इसे ऊपर उठाने की कोशिश कर रहा हूं। यही कारण है कि, @fisherwebdev द्वारा उठाई गई चिंताओं के अलावा (जिससे मैं अभी सहमत हूं), मुझे विश्वास नहीं है कि observe को state पर निर्भर रहने देना एक अच्छा विचार है। राज्य सहारा पर निर्भर करता है, मनाया राज्य _और_ सहारा पर निर्भर करता है.. क्या यह बहुत जटिल नहीं है? मेरे पास इसके बजाय observe(props) होगा।

gaearon 27 अप्रैल 2015

मुझे यह भी पता चल रहा है कि निरीक्षण state पर निर्भर नहीं होना चाहिए, ज्यादातर इसलिए क्योंकि इसकी आवश्यकता नहीं है। जैसा कि @gaearon बताते हैं, राज्य को एक स्तर से ऊपर उठाना काफी आसान है, जो चिंताओं को अलग करने के बाद साफ महसूस करता है। जब observe संभावित रूप से state पर निर्भर हो सकता है, तो घटक के भीतर अद्यतनों को संभालने का तर्क काफी अधिक जटिल हो जाता है; जब यह केवल props पर निर्भर करता है, तो आपके पास componentDidMount / componentWillReceiveProps में कांटा रहित हैंडलर हो सकते हैं। महत्वपूर्ण पथ में कम कोड एक सरल रेंडरिंग चक्र में बदल जाता है, और यह अनपेक्षित अपडेट की संख्या को भी कम करता है जो सदस्यता को फिर से ट्रिगर करते हैं।

andrewimm 27 अप्रैल 2015

अवलोकन के लिए +1 (प्रॉप्स)

हम राज्य के साथ जितना कम व्यवहार करेंगे, IMO उतना ही बेहतर होगा।

jeffbski 27 अप्रैल 2015

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

nmn 27 अप्रैल 2015

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

nbostrom 28 अप्रैल 2015

संपादित करें: क्षमा करें, बस एहसास हुआ कि मैं flatMap ढूंढ रहा था। मैंने खुद को भ्रमित किया क्योंकि मैं सोच रहा था कि यह संदेशों की सरणी को समतल कर देगा, लेकिन यह उच्च स्तर पर काम कर रहा है (संदेश देखने योग्य)।

क्या प्रस्तावित एपीआई उस मामले को संभालेगा जहां एक डेटा फ़ील्ड का परिणाम दूसरे के परिणाम पर निर्भर है? यानी आप पहले परिणाम को मैप करते हैं और एक नमूदार लौटाते हैं:

observe(props, context) {
  if (!props.params.threadID) {
    return {};
  }

  const observeThread = ThreadStore.observeGetByID(
    {id: props.params.threadID}
  );
  return {
    thread: observeThread,
    messages: observeThread.map(thread => {
      return MessageStore.observeGetByIDs({ids: thread.messageIDs});
    })
  };
}

मैं सामान्य रूप से वेधशालाओं के लिए काफी नया हूं, इसलिए मैं इस बारे में पूरी तरह से गलत हो सकता हूं। वादा-भूमि में यह बेहद सरल है, क्योंकि then से एक वादा वापस करने से बाद में then एस उस वादे पर आधारित होगा।

ianobermiller 3 मई 2015

मैं टिप्पणियों को समझ नहीं पा रहा हूं कि इसे this.state पर निर्भर नहीं होना चाहिए। एनकैप्सुलेटेड स्टेट निश्चित रूप से रिएक्ट को और अधिक जटिल बना देता है लेकिन वह भी बस इतना ही है। यदि एनकैप्सुलेटेड अवस्था नहीं होती, तो हमें केवल एक मेमोइज्ड तत्काल मोड लाइब्रेरी की आवश्यकता होती। यदि आप सभी "स्टोर" पर जाते हैं, तो हाँ, आपको राज्य की आवश्यकता नहीं है, लेकिन यह वह नहीं है जो रिएक्ट निर्धारित करता है कि आप करते हैं।

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

observe() {
  return { items: Items.getPagedItems({ pageIndex: this.state.currentPage }) };
}

भले ही observe state पर निर्भर न हो, फिर भी यह props और context पर निर्भर करेगा। यहां तक कि अगर यह context पर निर्भर नहीं था, तब भी आपके पास एक संकेत होगा जो context का उपयोग एक घटक के प्रोप को प्रस्तुत करने के लिए करता है जो इसे observe में उपयोग करता है।

observe को हर बार एक रेंडर पास के नीचे आने पर पुनर्मूल्यांकन करने की आवश्यकता होगी क्योंकि प्रॉप्स बदल सकते थे। हालांकि, हम निश्चित रूप से परिणामी वेधशालाओं को अलग करेंगे और यदि वही अवलोकन योग्य वापस किया जाता है तो हम सदस्यता समाप्त/पुनः सदस्यता नहीं लेंगे। हालांकि, हम अलग-अलग गुणों (चाहिए कॉम्पोनेंटअपडेट के अलावा) पर अंतर नहीं कर सकते हैं, इसलिए आदर्श है कि आपको पावर फीचर के रूप में Map का उपयोग करके अपना खुद का कैश लागू करना चाहिए। इस तरह आप पेड़ में कई घटकों के लिए एक ही अवलोकन योग्य वापस कर सकते हैं। उदाहरण के लिए एक ही उपयोगकर्ता को लोड करने वाले एकाधिक घटक। यहां तक कि अगर आप नहीं करते हैं, तो आप केवल ऑब्जर्वेबल को फिर से बनाते हैं और अंत में नीचे के कैश को हिट करते हैं। वैसे भी रिएक्ट सुलह कैसे काम करता है। यह इतना धीमा नहीं है।

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

जो मुझे मेरे अंतिम बिंदु पर लाता है ...

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

रिएक्ट का प्राथमिक उद्देश्य घटकों के बीच एक अनुबंध बनाना है ताकि पारिस्थितिकी तंत्र में विभिन्न अमूर्त सह-अस्तित्व में रह सकें। उस भूमिका का एक महत्वपूर्ण हिस्सा सामान्य अवधारणाओं के लिए अमूर्तता के स्तर को ऊपर उठाना है ताकि हम नई क्रॉस-घटक सुविधाओं को सक्षम कर सकें। उदाहरण के लिए एक सबट्री की सभी स्थिति को सहेजना, फिर सबट्री को पुनर्जीवित करना। या संभवतः सर्वर पर स्वचालित अनमाउंटिंग या सर्वर पर सामंजस्य के समय पहलुओं को बदलना शामिल है।

यह सब स्वादिष्ट और समान बनाने के लिए शामिल कुछ बैटरी प्रदान करना भी महत्वपूर्ण है।

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

sebmarkbage 4 मई 2015

👍2 ❤1

काश ऐसा कुछ डॉक्स में "दर्शन / डिजाइन लक्ष्य / गैर-लक्ष्य" के रूप में होता।

gaearon 5 मई 2015

👍3

रिएक्ट का प्राथमिक उद्देश्य घटकों के बीच एक अनुबंध बनाना है ताकि पारिस्थितिकी तंत्र में विभिन्न अमूर्त सह-अस्तित्व में रह सकें। उस भूमिका का एक महत्वपूर्ण हिस्सा सामान्य अवधारणाओं के लिए अमूर्तता के स्तर को ऊपर उठाना है ताकि हम नई क्रॉस-घटक सुविधाओं को सक्षम कर सकें।

इसे प्रेम करें। मैं @gaearon से सहमत हूं कि यह अच्छा होगा यदि यह किसी प्रकार के दस्तावेज़ में होता।

acdlite 5 मई 2015

👍1

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

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

jquense 5 मई 2015

@jquense मैं पूरी तरह से सहमत हूँ। मैं इस हुक को बहुत पहले जोड़ना चाहता था। (मूल प्रयोग: https://github.com/reactjs/react-page/commit/082a049d2a13b14199a13394dfb1cb8362c0768a)

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

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

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

sebmarkbage 5 मई 2015

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

आम तौर पर मुझे ज़ाल्गो को वेधशालाओं के साथ कोई समस्या नहीं लगती क्योंकि उपभोक्ता हमेशा नियंत्रण में होता है और observeOn जैसी किसी चीज़ के साथ हमेशा-एसिंक का विकल्प चुन सकता है।

gaearon 5 मई 2015

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

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

nmn 5 मई 2015

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

jeffbski 5 मई 2015

@sebmarkbage मुझे लगता है कि आपने मेरी अधिकांश चिंताओं को दूर कर दिया है और अब मैं इसे ढांचे में जोड़ने का लाभ देखता हूं। हालाँकि, क्या आप this.data पर टिप्पणी कर सकते हैं - (1) क्या हम उन क्षेत्रों को प्रॉप्स/संदर्भ/राज्य में मोड़ सकते हैं या (2) क्या हम इसका नाम बदल सकते हैं?

fisherwebdev 5 मई 2015

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

... जहां कोई वादा पुस्तकालय (यहां तक कि विशिष्ट शिकायत वाले भी) एक दूसरे पर भरोसा नहीं कर सकते हैं, जो यह सुनिश्चित करने के लिए अनावश्यक लपेटने और रक्षात्मक कार्य की ओर जाता है कि वे सही ढंग से हल करते हैं

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

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

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

jquense 5 मई 2015

"हमें ऑब्जर्वेबल के आरएक्सजेएस अनुबंध का उपयोग करना चाहिए क्योंकि यह अधिक सामान्य उपयोग में है और समकालिक निष्पादन की अनुमति देता है, लेकिन एक बार @झुसैन का प्रस्ताव अधिक सामान्य उपयोग में होने के बाद, हम इसके बजाय उस अनुबंध पर स्विच करेंगे।"

बस थोड़ा और संदर्भ जोड़ने के लिए। गैर-अवरुद्ध बैक प्रेशर के साथ एसिंक्रोनस स्ट्रीम प्रोसेसिंग के लिए मानक प्रदान करने के लिए एक प्रतिक्रियाशील स्ट्रीम पहल (http://www.reactive-streams.org/) है। इसमें रनटाइम वातावरण (JVM और JavaScript) के साथ-साथ नेटवर्क प्रोटोकॉल के उद्देश्य से किए गए प्रयास शामिल हैं।

वर्तमान प्रमुख कार्यान्वयन fe Akka Streams या RxJava हैं। मुझे नहीं पता कि क्या RxJ पहले से ही अब उसी इंटरफ़ेस का अनुपालन करते हैं, सब्सक्राइबर के लिए वर्तमान इंटरफ़ेसऑनसब्सक्राइब (सदस्यता एस), ऑननेक्स्ट (टी टी), पूर्ण (), ऑनरर (थ्रोबल टी) पर है।

क्या आप @jhusain के प्रस्ताव पर अधिक प्रकाश डाल सकते हैं?

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

क्या इस पहल के संबंध में कोई स्थिति या लक्ष्य है?

vladap 6 मई 2015

@vladap मेरा मानना है कि यह @jhusain . का उल्लिखित प्रस्ताव है

Shenlok 6 मई 2015

मैंने @jhusain के माध्यम से पढ़ा है और मैं भविष्य में संभवतः इस युक्ति पर आगे बढ़ने की प्रेरणा के बारे में निश्चित नहीं हूं। क्या कोई विशेष लाभ है?

रिएक्टिव-स्ट्रीम स्पेक का बड़ा समर्थन है और पहले से ही संस्करण 1.0 पर है। क्योंकि RxJava पहले से ही इस युक्ति को लागू करता है, मुझे लगता है कि RxJs अनुसरण करेंगे (लेकिन जाँच नहीं की है)।

यह ब्लॉग अक्का धाराओं का उपयोग करते हुए कुछ उदाहरणों के साथ इंटरफेस को सारांशित करता है।

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

मुझे अभी www.reactive-streams.org पर कार्यान्वयनकर्ताओं की सूची नहीं मिल रही है, लेकिन पिछली बार जब मैंने इसकी जाँच की थी:

ब्योर्न एंटोन्सन - टाइपसेफ इंक।
गेविन बीरमैन - ओरेकल इंक।
जॉन ब्रिस्बिन - निर्णायक सॉफ्टवेयर इंक।
जॉर्ज कैंपबेल - नेटफ्लिक्स, इंक
बेन क्रिस्टेंसेन - नेटफ्लिक्स, इंक
माथियास डोनिट्ज़ - स्प्रे.आईओ
मारियस एरिक्सन - ट्विटर इंक।
टिम फॉक्स - रेड हैट इंक।
विक्टर क्लैंग - टाइपसेफ इंक।
डॉ. रोलैंड कुह्न - टाइपसेफ इंक।
डौग ली - SUNY Oswego
स्टीफन मालदिनी - निर्णायक सॉफ्टवेयर इंक।
नॉर्मन मौरर - रेड हैट इंक।
एरिक मीजर - एप्लाइड ड्यूएलिटी इंक।
टॉड मोंटगोमरी - काज़िंग कॉर्प।
पैट्रिक नॉर्डवॉल - टाइपसेफ इंक।
जोहान्स रूडोल्फ - Spray.io
एंड्रे वर्गा - टाइपसेफ इंक।

हो सकता है कि मैं यहां बहुत दूर जाऊं लेकिन मेरा मानना है कि बड़ा संदर्भ भविष्य के फैसलों में मदद कर सकता है।

vladap 7 मई 2015

@vladap जो मैं समझता हूं और जो मैं जीथब मुद्दों पर देखता हूं
एक इंटरफेस के नजरिए से, जो मैं अलग-अलग जीथब मुद्दों और अन्य विशिष्ट दस्तावेजों में भी समझ सकता हूं, पर्यवेक्षक निश्चित रूप से जनरेटर इंटरफ़ेस का सम्मान करेगा, इसलिए कुछ इस तरह है:

{
  next(value),
  throw(e),
  return(v)
}

बस एक 'सब्सक्राइब' विधि के साथ एक बहुत ही बुनियादी अवलोकन योग्य लागू करना जो उस इंटरफ़ेस का सम्मान करता है जो प्रतिक्रिया के लिए सुरक्षित होना चाहिए।

fdecampredon 7 मई 2015

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

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

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

vladap 7 मई 2015

भविष्य के ईसीएमएस्क्रिप्ट के लिए मुझे प्रस्तावित अवलोकन योग्य इंटरफेस कहां मिल सकता है? अगर कोई पहले से ही है।

vladap 7 मई 2015

वर्तमान प्रस्ताव यहां पाया जा सकता है:

https://github.com/jhusain/asyncgenerator

जेएच

7 मई, 2015, पर 2:32 AM पर, vladap [email protected] लिखा है:
भविष्य के ईसीएमएस्क्रिप्ट के लिए मुझे प्रस्तावित अवलोकन योग्य इंटरफेस कहां मिल सकता है? अगर कोई पहले से ही है।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

jhusain 7 मई 2015

रिएक्टिव स्ट्रीम प्रस्ताव (आरएसपी) टीसी-39 प्रस्ताव से आगे जाता है क्योंकि यह एक अवलोकन योग्य पेश करता है जो बैक प्रेशर को संभालता है। आरएसपी ऑब्जर्वेबल को बैकप्रेशर का सम्मान करते हुए पूरे नेटवर्क में कुशलतापूर्वक स्ट्रीम भेजने के लिए अनुकूलित किया गया है। यह आंशिक रूप से RxJava में किए गए कार्य पर आधारित है, जो इंजीनियरिंग का एक बहुत ही प्रभावशाली नमूना है (पूर्ण प्रकटीकरण: इसे नेटफ्लिक्स के सहयोगी बेन क्रिस्टेंसन द्वारा डिज़ाइन किया गया था)।

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

FYI करें RxJS की वर्तमान में RSP ऑब्जर्वेबल को लागू करने की कोई योजना नहीं है।

जेएच

7 मई, 2015 को दोपहर 2:30 बजे, vladap [email protected] ने लिखा:
यह एक ही कार्यक्षमता के साथ एक अलग नामकरण जैसा दिखता है, इस मायने में यह ठीक है। मैं शायद उसी नामकरण को पसंद करूंगा जैसा कि कल्पना में है लेकिन अंत में मुझे इसकी परवाह नहीं है जहां तक ये विधियां समान हैं।
मैं ऑनसब्सक्राइब() के बराबर लापता का मूल्यांकन नहीं कर सकता। ब्लॉग में मैंने उल्लेख किया है कि लेखक कहते हैं कि यह पीठ के दबाव को नियंत्रित करने की कुंजी है। मुझे नहीं पता कि इसके अन्य उपयोग के मामले हैं। इससे मुझे लगता है कि रिएक्ट बैक-प्रेशर को नियंत्रित करने की परवाह नहीं करता है या इसके लिए कोई और रणनीति है। यह एक जटिल चीज है इसलिए मैं समझता हूं कि यह प्रतिक्रिया की चिंता नहीं है।
क्या मैं सही ढंग से समझता हूं कि रणनीति लाइनों के साथ कुछ है - या तो ऐप जटिल है और बैक-प्रेशर की समस्याएं पैदा हो सकती हैं, फिर इसे हल करने के लिए बीच में कुछ का उपयोग करें, जैसे कि आरएक्सजेएस, या आप रिएक्ट घटक को सीधे वेबसोकेट से कनेक्ट करते हैं और आप डॉन बैक-प्रेशर की समस्या नहीं है क्योंकि ऐप सरल है और इसमें धीमे अपडेट हैं।
-
इस ईमेल का सीधे उत्तर दें या इसे GitHub पर देखें।

jhusain 7 मई 2015

👍1

बहुमूल्य विवरण के लिए बहुत धन्यवाद। इससे बहुत कुछ बोध होता है।

vladap 7 मई 2015

@gaearon मैंने आपको कॉपी किया है। मैं ES6 कक्षाओं के साथ ParseReact का उपयोग करना चाहता था, इसलिए मुझे उच्च-क्रम वाले घटक के रूप में मिक्सिन के अवलोकन एपीआई को फिर से लागू करने की आवश्यकता थी।

https://gist.github.com/amccloud/d60aa92797b932f72649 (नीचे उपयोग)

मैं निरीक्षण को घटक पर परिभाषित करने या सजावटी में पारित करने की अनुमति देता हूं। (मैं दोनों को मिला सकता हूं)
मैं वेधशालाओं में प्रॉप्स के रूप में विलय करता हूं (नहीं यह। डेटा, या यह। प्रॉप्स। डेटा)

amccloud 11 मई 2015

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

HOC के बजाय, यह एक नियमित घटक हो सकता है:

import Observe from 'react/addons/Observe';

class Foo {
  render() {
    return (
      <Observe
        render={this.renderData}
        resources={{
          myContent: xhr(this.props.url)
        }} />
    );
  }

  renderData({ myContent }) {
    if (myContent === null) return <div>Loading...</div>;
    return <div>{myContent}</div>;
  }
}

क्योंकि आप render प्रोप के रूप में पारित फ़ंक्शन को नियंत्रित करते हैं, नामों के टकराने का कोई तरीका नहीं है। दूसरी ओर, यह मालिक की स्थिति को प्रदूषित नहीं करता है।

मुझे यहां क्या समझ नहीं आ रहा है?

gaearon 22 मई 2015

यह कम वर्बोज़ भी हो सकता है यदि Observe घटक ने अपने प्रॉप्स से वेधशालाओं को पकड़ लिया:

render() {
  return (
    <Observe myContent={Observable.fetch(this.props.url)}
             render={this.renderData} />
  );
}

renderData({ myContent }) {
  if (myContent === null) return <div>Loading...</div>;
  return <div>{myContent}</div>;
}

इसके बारे में भी अच्छी बात यह है कि यदि shouldComponentUpdate झूठी वापसी करता है तो यह पुन: सदस्यता से बच जाएगा क्योंकि हम render में बिल्कुल भी नहीं पहुंचेंगे।

gaearon 22 मई 2015

अंत में, कोई render के लिए एक डेकोरेटर लिख सकता है जो इसे Observe घटक में लपेटता है:

@observe(function (props, state, context) {
  myContent: Observable.fetch(props.url)
})
render({ myContent }) {
  if (myContent === null) return <div>Loading...</div>;
  return <div>{myContent}</div>;
}

gaearon 22 मई 2015

मैं डेटा-फ़ेचिंग लॉजिक को इंजेक्ट करने के बजाय render को शुद्ध रेंडरिंग फ़ंक्शन के रूप में रखना पसंद करूंगा।
मेरी राय में प्रारंभिक प्रस्ताव अच्छा लगता है। यह बहुत करीब है कि राज्य rx-react के साथ कैसे काम करता है और यह राज्य प्रबंधन को डेटा-फ़ेचिंग तर्क से अलग करने की अनुमति देगा जो बहुत सुसंगत लगता है।

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

fdecampredon 22 मई 2015

यह वास्तव में तर्क लाने वाले डेटा को इंजेक्ट नहीं कर रहा है, बस कुछ टाइपिंग बचाता है। यह ऊपर के संस्करण के लिए desugar होगा, जो सिर्फ <Observe /> घटक प्रस्तुत करता है। स्टेटफुल घटकों को प्रस्तुत करना असामान्य नहीं है, इसलिए मुझे नहीं लगता कि यह render को अब की तुलना में कम शुद्ध बनाता है।

मैंने #3858 और इस प्रस्ताव से सर्वश्रेष्ठ को संयोजित करने का प्रयास किया।

किसी भी एचओसी दृष्टिकोण में, लाभ खोजकर्ता है , लेकिन डाउनसाइड्स का

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

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

मेरे प्रस्ताव में, मैं स्थान और खोजकर्ता रख रहा हूँ, लेकिन:

<Observe /> (या observe() डेकोरेटर जो रेंडर को <Observe /> साथ लपेटता है) सिर्फ एक ऐड-ऑन है, मैं रिएक्ट कोर में _any_ परिवर्तन का प्रस्ताव नहीं कर रहा हूं।
हर कोई अपने उपयोग के मामलों के लिए अपने स्वयं के अवलोकन तर्क को लागू कर सकता है। आपके पास अपना स्वयं का <Observe /> जो केवल एक अवलोकन योग्य का उपयोग करता है, यदि आप इसे पसंद करते हैं। आप डेकोरेटर का उपयोग कर सकते हैं या नहीं भी कर सकते हैं।
घटक जीवनचक्र वही रहता है।
कोई प्रोप विरोध नहीं है क्योंकि डेटा को एक पैरामीटर के रूप में पारित किया जाता है।
हम अपने पास मौजूद टूल्स से समस्याओं का समाधान करके डॉगफूडिंग कर रहे हैं।
बॉयलरप्लेट को कम करने के लिए, हम नई मूल अवधारणाओं को पेश करने के बजाय बॉयलरप्लेट कमी उपकरण (सज्जाकार) का उपयोग करते हैं।

gaearon 22 मई 2015

शानदार चर्चा और यहां चारों ओर काम करते हैं, बहुत सम्मान। :)

मैं मानता हूं कि यह इसे मूल में बनाने के लायक नहीं है। शायद एक ऐड-ऑन इस प्रस्ताव को पर्याप्त कर्षण देता है कि लोग अधिक पूरी तरह से करने से पहले इसे अभिसरण और मानकीकृत करने का प्रयास कर सकते हैं। कहा जा रहा है, मुझे यह प्रस्ताव https://github.com/facebook/react/issues/3858 और https://github.com/facebook/react/pull/3920 से बेहतर लगता है।

यह कुछ ऐसा है जिसका मैं साइड प्रोजेक्ट्स (इसलिए नमक के दाने) पर उपयोग कर रहा हूं - यह @elierotenberg के भयानक काम के समान है, लेकिन जीवनचक्र पर कब्जा नहीं करता है, क्योंकि यह ऐप रिएक्ट में 100% नहीं है और इसे इंटरऑप करना है।

कॉफ़ीस्क्रिप्ट और मिक्सिन्स के लिए खुद को तैयार करें, या जब तक आप चाहें तो ES6 जैसा दिखने तक स्क्विंट करते रहें। :)

_ = require 'lodash'

module.exports = DeclareNeedsMixin = 
  componentDidMount: ->
    <strong i="12">@needsConsumerId</strong> = _.uniqueId @constructor.displayName
    <strong i="13">@sinkNeeds</strong> <strong i="14">@props</strong>, <strong i="15">@state</strong>

  componentWillUpdate: (nextProps, nextState) ->
    <strong i="16">@sinkNeeds</strong> nextProps, nextState

  componentWillUnmount: ->
    @props.flux.declareNeeds <strong i="17">@needsConsumerId</strong>, []

  sinkNeeds: (props, state) ->
    if not @declareNeeds?
      return console.warn 'Missing method required for DeclareNeedsMixin: `declareNeeds`', @

    needs = <strong i="18">@declareNeeds</strong> props, state
    props.flux.declareNeeds <strong i="19">@needsConsumerId</strong>, needs

  # Intended to be overridden by the host class.
  # Returns a set of facts, stored as an array.
  # Yes, immutable data is awesome, that's not the point here though. :)
  # Facts are serializable data, just values.
  # declareNeeds: (props, state) ->
  #   []

और इस तरह इस्तेमाल किया:

module.exports = EmailThreads = React.createClass
  displayName: 'EmailThreads'
  mixins: [DeclareNeedsMixin]

  propTypes:
    flux: PropTypes.flux.isRequired

  declareNeeds: (props, state) ->
    [Needs.GmailData.myThreads({ messages: 20 })]

  ...

तो declareNeeds इस घटक की आवश्यकता के विवरण के लिए प्रोप और राज्य का एकतरफा कार्य है। यहां वास्तविक कार्यान्वयन में, @props.flux.declareNeeds का प्राप्त अंत, जो एक शीर्ष-स्तरीय घटक पर स्थापित है, इन जरूरतों को ProcessSink ऑब्जेक्ट में डुबो देता है। यह अपनी पसंद के अनुसार बैच करता है, समान flux साझा करने वाले घटकों में needs डी-डुप्लिकेट करता है, और फिर उन जरूरतों को पूरा करने के लिए साइड-इफेक्ट करता है (जैसे सॉकेट से कनेक्ट करना या HTTP अनुरोध करना)। यह सॉकेट कनेक्शन जैसी स्टेटफुल चीजों को साफ करने के लिए रेफरेंस काउंटिंग का उपयोग करता है, जब कोई घटक नहीं होते हैं जिन्हें अब उनकी आवश्यकता होती है।

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

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

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

kevinrobinson 23 मई 2015

स्टेटलेस दृष्टिकोण के लिए, मुझे ऐसा लगता है कि एसिंक डेटा प्राप्त करना स्टेटफुल है, और इस प्रकार कुछ घटकों की स्थिति में लंबित/पूर्ण/विफल स्थिति को संग्रहीत करना प्रासंगिक है।

@elierotenberg और @andrewimm प्रथम श्रेणी त्रुटि प्रबंधन के बारे में एक उत्कृष्ट बिंदु बनाते हैं। @sebmarkbage मुझे लगता है कि न्यूनतम इंटरऑप बिंदु की ओर आपकी वृत्ति सही है, लेकिन मुझे यकीन नहीं है कि घटक पेड़ को बुलबुला करने के लिए त्रुटियों के लिए अर्थशास्त्र जोड़ना उस आवश्यकता को पूरा करता है। onError और onCompleted से मूल्यों का उपयोग कैसे करें, इसके लिए यहां एक समान रूप से सरल कहानी होने की आवश्यकता है, भले ही यह सिर्फ this.observed में स्लॉट हो या तो next/error/completed का अंतिम मान रखता हो { next: "foo" } । प्रथम श्रेणी की विशेषता के रूप में देखने योग्य अनुबंध का समर्थन किए बिना, मुझे इस प्रस्ताव में कटौती करने के बारे में थोड़ा संदेह है।

और चूंकि यह इंटरनेट है, और यहां मेरी पहली बार झंकार हो रही है: रिएक्ट इश्यू फीड कुछ बेहतरीन पढ़ने और महान काम और विचारों के लिए एक ऑल-अराउंड स्रोत है। :+1:

kevinrobinson 23 मई 2015

मेरे लिए बाइंडिंग की तरह खुशबू आ रही है।

StoneCypher 9 जून 2015

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

निम्नलिखित उदाहरण को react-nexus@^3.4.0 :

// the result from this query...
@component({
  users: ['remote://users', {}]
})
// is injected here...
@component(({ users }) =>
  users.mapEntries(([userId, user]) =>
    [`user:${userId}`, [`remote://users/${userId}/profile`, {}]]
  ).toObject()
))
class Users extends React.Component {
  // ... this component will receive all the users,
  // and their updates.
}

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

हालाँकि, जैसा कि @sebmarkbage ने उल्लेख किया है, इसके बजाय प्रॉप्स नेमस्पेस में प्रदूषण का खतरा है। अभी के लिए, मैं प्रॉप्स ट्रांसफॉर्मर डेकोरेटर ( react-transform-props ) का उपयोग कर रहा हूं ताकि प्रॉप्स को आंतरिक घटक में पास करने से पहले उन्हें साफ / नाम बदला जा सके, लेकिन मैं स्वीकार करता हूं कि यह भविष्य में समस्याग्रस्त हो सकता है यदि उच्च-क्रम-घटक बन जाते हैं अधिक सामान्य है और नाम टकराने का जोखिम बढ़ जाता है।
क्या इसे संपत्ति कुंजियों के प्रतीकों का उपयोग करके हल किया जा सकता है? क्या propTypes चेकिंग Symbol -कीड प्रॉप्स को सपोर्ट करता है? क्या JSX कंप्यूटेड इनलाइन प्रॉप्स कीज़ को सपोर्ट करेगा (हालाँकि कोई हमेशा कंप्यूटेड प्रॉपर्टीज़ + ऑब्जेक्ट स्प्रेड का उपयोग कर सकता है)?

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

elierotenberg 9 जून 2015

मेरा 2¢

समय के साथ बदलते मूल्यों के लिए 'बच्चों को एक समारोह के रूप में' पैटर्न के साथ मुझे बहुत मज़ा आ रहा है। मेरा मानना है कि @elierotenberg पहले इसके साथ आए थे? मेरा वर्तमान उपयोग प्रतिक्रिया-स्प्रिंग्स पर स्प्रिंग्स (रिबाउंड के माध्यम से) मॉडल करना है। उदाहरण -

<Springs to={{x: 20, y: 30}} tension={30}>
  {val => <div style={{left: val.x, top: val.y}}>moving pictures</div>}
</Springs>

कोई सहारा टकराव नहीं, और मालिक की स्थिति का कोई उपयोग नहीं। मैं कई स्प्रिंग्स को घोंसला भी बना सकता हूं, और प्रतिक्रिया सभी कठिन बिट्स का प्रबंधन करती है। ये 'अवलोकन' (हे!) onError , onComplete और अन्य प्रॉप्स (ग्राफक्ल क्वेरीज़?) को भी स्वीकार कर सकते हैं।

इसे 'फ्लक्स' के लिए स्केच करने का एक मोटा प्रयास

<Store 
  initial={0}
  reduce={(state, action) => action.type === 'click'? state+1 : state} 
  action={{/* assume this comes as a prop from a 'Dispatcher' up somewhere */}}> 
    {state => <div onClick={() => dispatch({type: 'click'})}> clicked {state} times</div>}
</Store>

threepointone 10 जून 2015

हमने आसन में इस पैटर्न का उपयोग किया, जिसे हम _render कॉलबैक_ कहते हैं, लेकिन अंततः इससे दूर जा रहे हैं।

पेशेवरों

प्रॉप्स के टकराने की कोई संभावना नहीं है।
StoreComponent के लेखक और $#$1 StoreComponent #$ . के उपयोगकर्ता के रूप में दोनों को लागू करना आसान है

दोष

shouldComponentUpdate को लागू करना बेहद मुश्किल है क्योंकि रेंडर कॉलबैक पूरे राज्य में बंद हो सकता है। कल्पना कीजिए कि हमारे पास A -> Store -> B का एक घटक पेड़ था। A के पास अपने राज्य में एक काउंटर है जिसे रेंडर कॉलबैक के दौरान B के लिए सहारा के रूप में एक्सेस किया जाता है। यदि काउंटर के कारण A अपडेट होता है और Store अपडेट नहीं होता है, तो B में काउंटर का पुराना संस्करण होगा। नतीजतन, हमें हमेशा स्टोर को अपडेट करने के लिए मजबूर होना पड़ा।
अलगाव में घटकों का परीक्षण करना बहुत कठिन हो गया। अनिवार्य रूप से, डेवलपर्स रेंडर कॉलबैक में जटिल तर्क डालते हैं जिसके लिए घटक को प्रस्तुत करना है और तर्क का परीक्षण करना चाहते हैं। ऐसा करने का प्राकृतिक तरीका पूरे पेड़ को प्रस्तुत करना और _थ्रू_ स्टोर घटक का परीक्षण करना था। इससे उथले रेंडरर का उपयोग करना असंभव हो गया।

अब हम एक ऐसे मॉडल की ओर बढ़ रहे हैं जहां StoreComponent ReactElement #$ लेता है और जब स्टोर को नया डेटा प्राप्त होता है, तो स्टोर एक विशिष्ट प्रोप को ओवरराइड करते हुए ReactElement को क्लोन करता है। इस पैटर्न को करने के कई तरीके हैं जैसे कि कंपोनेंट कंस्ट्रक्टर और प्रॉप्स लेना। हम इस दृष्टिकोण के साथ गए क्योंकि टाइपस्क्रिप्ट में यह मॉडल करना सबसे आसान था।

pspeter3 10 जून 2015

👍1

बहुत बढ़िया बिंदु, 'बग़ल में' आवश्यकता को तोड़े बिना किसी भी तरह के बारे में नहीं सोच सकते।

threepointone 10 जून 2015

@threepointone सत्ता के लिए कार्यान्वयन प्रस्तावों में से एक की तरह लगता है https://github.com/reactjs/react-future/pull/28

jimfb 10 जून 2015

@ pspeter3 आपके उदाहरण में, स्टोर को हमेशा अपडेट / shouldComponentUpdate: ()=> true बनाने में कोई गंभीर कमी है? मैं सोच रहा हूँ कि इसके 'बच्चों' को किसी भी तरह श्रृंखला में Store बिना प्रस्तुत किया गया होगा। आपके समय के लिए धन्यवाद!

threepointone 11 जून 2015

@threepointone ठीक यही हमने अपनी सीमाओं के लिए किया। यह स्पष्ट नहीं था कि वास्तव में प्रभाव क्या था, लेकिन टीम के सदस्यों की ओर से पूर्ण चिंताएँ थीं। कठिनाई परीक्षण के साथ संयुक्त चिंताओं ने स्विच को React.cloneElement(this.props.child, {data: this.state.data}) . का उपयोग करने के लिए मजबूर किया

pspeter3 11 जून 2015

@ pspeter3 परीक्षण कोण निश्चित रूप से एक समस्या है। क्या होगा अगर उथले रेंडरर ने 'रेंडर कॉलबैक' को मान्यता दी? क्या इससे मदद मिलेगी?

Ps- 'रेंडर कॉलबैक' :thumbs_up:

threepointone 11 जून 2015

@sebmarkbage es- अवलोकन योग्य पर वर्तमान चर्चा यह है कि subscribe को async की गारंटी दी जाएगी, [Symbol.observer] विधि के साथ शॉर्टकट और समकालिक रूप से सदस्यता प्रदान की जाएगी, हालांकि सिंक/एसिंक एपिस दोनों होने की वैधता है वर्तमान में बहस हो रही है।

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

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

इसके अलावा @gaearon मैंने आपके HOC बिट को ऊपर सरल बनाया, एक स्थिर - ComposedComponent.observe का उपयोग करके और this.state.data के बजाय this.state.data this.state का उपयोग करके - https://gist.github.com/tgriesser/d5d80ade6f895c28e659

यह प्रस्तावित es7 डेकोरेटर्स के साथ वास्तव में अच्छा लगता है:

<strong i="20">@observing</strong>
class Foo extends Component {
  static observe(props, context) {
    return {
      myContent: xhr(props.url)
    };
  }
  render() {
    var myContent = this.props.data.myContent;
    return <div>{myContent}</div>;
  }
}

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

tgriesser 17 जून 2015

सिंक्रोनस सब्सक्रिप्शन की कमी एक बड़ी समस्या हो सकती है।

nmn 17 जून 2015

मुझे लगता है कि मुझे यह मिल गया है कि "राज्य की समस्या" और "बग़ल में डेटा लोड हो रहा है" (व्युत्पन्न डेटा) को लगातार तरीके से कैसे हल किया जाए। यह इसे एक स्टेटलेस "रिएक्शन-वे" में बनाता है। मुझे किसी भी समय राज्य की स्थिरता बनाए रखने का एक तरीका मिल गया है और यह पैटर्न UI = React(state) में फिट बैठता है। संभावना नहीं है कि मैं इसे पूरी तरह से बुलेट-प्रूफ बनाने, और उदाहरण जोड़ने और अच्छी प्रस्तुति देने के लिए हाथ से बाहर हूं। https://github.com/AlexeyFrolov/slt । दूसरी ओर यह अच्छी तरह से परीक्षण किया गया है और मैं इसे अपने उत्पादन परियोजनाओं में पुनरावृत्त रूप से उपयोग कर रहा हूं। योगदान करने के लिए चतुर दिमाग का स्वागत है।

chain-police 3 जुल॰ 2015

नमस्ते,

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

जैसा कि हमें कुछ भी उपलब्ध नहीं मिला जो उपयोग के लिए तैयार था, हमने नॉकआउट वेधशालाओं (विशेष रूप से: स्वचालित सदस्यता) के सिद्धांतों के आधार पर अपने स्वयं के वेधशालाओं का निर्माण किया।
यह वास्तव में रिएक्ट घटकों के वर्तमान जीवनचक्र में बहुत अच्छी तरह से फिट बैठता है, और हमें अजीब हैक या यहां तक कि चाइल्ड रेंडरिंग कॉलबैक की आवश्यकता नहीं थी (नीचे इस्तेमाल किया गया ऑब्जर्वरमिक्स लगभग 10 लोकेशन है)।
इसने हमारे DX में बहुत सुधार किया और हमारी टीम के लिए इतना अच्छा काम किया कि हमने इसे ओपन सोर्स के रूप में प्रकाशित करने का निर्णय लिया। इस बीच यह काफी युद्ध सिद्ध है (यह उदाहरण के लिए एक ES7 अवलोकन योग्य सरणी पॉलीफिल प्रदान करता है) और अत्यधिक अनुकूलित।
यहां एक छोटा टाइमर उदाहरण है, ( जेएसएफडल के रूप में भी उपलब्ध है),

var store = {};
// add observable properties to the store
mobservable.props(store, {
    timer: 0
});

// of course, this could be put flux-style in dispatchable actions, but this is just to demo Model -> View
function resetTimer() {
    store.timer = 0;
}

setInterval(function() {
    store.timer += 1;
}, 1000);

var TimerView = React.createClass({
    // This component is actually an observer of all store properties that are accessed during the last rendering
    // so there is no need to declare any data use, nor is there (seemingly) any state in this component
    // the combination of mobservable.props and ObserverMixin does all the magic for us.
    // UI updates are nowhere forced, but all views (un)subscribe to their data automatically
    mixins: [mobservable.ObserverMixin],

    render: function() {
        return (<span>Seconds passed: {this.props.store.timer}</span>);
    }
});

var TimerApp = React.createClass({
    render: function() {
        var now = new Date(); // just to demonstrate that TimerView updates independently of TimerApp
        return (<div>
            <div>Started rendering at: {now.toString()}</div>
            <TimerView {...this.props} />
            <br/><button onClick={resetTimer}>Reset timer</button>
        </div>);
    }
});

// pass in the store to the component tree (you could also access it directly through global vars, whatever suits your style)
React.render(<TimerApp store={store} />, document.body);

इस दृष्टिकोण के बारे में अधिक जानकारी के लिए यह ब्लॉग देखें। BTW, मैं यह सुनिश्चित करूँगा कि ES6 कक्षाओं का उपयोग करने वालों के लिए एक डेकोरेटर और/या कंटेनर को lib में जोड़ा जाएगा।

अफसोस की बात है कि मैंने प्रतिक्रिया-यूरोप से पहले यह धागा नहीं देखा था, अन्यथा हमारे पास प्रतिक्रिया और अवलोकनों पर चर्चा करने का एक अच्छा अवसर होता। लेकिन प्रेरक वार्ता के लिए बहुत-बहुत धन्यवाद! : +1: मुझे विशेष रूप से ग्राफक्यूएल के सार और रेडक्स के पीछे विचार कार्य पसंद आया :)

mweststrate 4 जुल॰ 2015

@mweststrate मुझे लगता है कि समुदाय अंततः "अवलोकन" और "अपरिवर्तनीय डेटा" समाधानों के बीच चयन करने की आवश्यकता के साथ समाप्त हो जाएगा। हो सकता है कि हमें एक समाधान (https://github.com/AlexeyFrolov/slt/issues/4) में दोनों दृष्टिकोणों की ताकत रखने के लिए किसी तरह से मिश्रण करने की आवश्यकता हो। मेरे समाधान में मैंने किसी भी समय राज्य की स्थिरता पर ध्यान देने के साथ "अपरिवर्तनीय डेटा" दृष्टिकोण लागू किया है। मैं ऑब्जर्वेबल और जेनरेटर को भी सपोर्ट करने की योजना बना रहा हूं। यह "व्युत्पन्न" या "पूरक" डेटा (जैसे पृष्ठ निकाय, संपत्ति, अनुशंसाएं, टिप्पणियां, पसंद) लाने और ऐप स्थिति की स्थिरता बनाए रखने के लिए उपयोग किए जाने वाले नियमों का एक उदाहरण है।

https://github.com/AlexeyFrolov/slt#rules -example

यह एक जटिल वास्तविक दुनिया (मेरा उत्पादन कोड) उदाहरण है जो दिखाता है कि स्थान शीर्षलेख के साथ एपीआई रीडायरेक्ट को कैसे संभालना है।

import r from "superagent-bluebird-promise";
import router from "./router";

export default {
    "request": function (req)  {
        let route = router.match(req.url);
        let session = req.session;
        route.url = req.url;
        return this
            .set("route", route)
            .set("session", req.session);
    },
    "route": {
        deps: ["request"],
        set: function (route, request) {
            let {name, params: { id }} = route;
            if (name === "login") {
                return this;
            }
            let url = router.url({name, params: {id}});
            let method = request.method ? request.method.toLowerCase() : "get";
            let req = r[method]("http://example.com/api/" + url);
            if (~["post", "put"].indexOf(method)) {
                req.send(request.body);
            }
            return req.then((resp) => {
                let ctx = this.ctx;
                let path = url.substr(1).replace("/", ".");
                if (!resp.body) {
                    let location = resp.headers.location;
                    if (location) {
                        ctx.set("request", {
                            method: "GET",
                            url: location.replace('/api', '')
                        });
                    }
                } else {
                    ctx.set(path, resp.body);
                }
                return ctx.commit();
            });
        }
    }
}

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

chain-police 4 जुल॰ 2015

मुझे लगता है कि यह एक बुरा विचार है क्योंकि ऐसे कई किनारे-मामले होंगे जिन पर विचार करना मुश्किल है।

उपरोक्त टिप्पणियों से मैं संभावित क्षेत्रों को सूचीबद्ध कर सकता हूं जिन्हें अंतिम उपयोगकर्ता द्वारा हर बार "डेटाफुल" घटक बनाना चाहता है:

सर्वर-साइड प्रतिपादन
.state और .data . की शुरुआत
.context , .props , .state और .observe उलझाव
अतुल्यकालिक प्रतिपादन

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

मैं @glenjamin द्वारा प्रस्तावित connect और disconnect जीवनचक्र हुक से सहमत हूं।

YChebotaev 4 जुल॰ 2015

क्षमा करें अगर यह ऑफ-विषय है (मैं काफी नहीं बता सकता)। लेकिन यहां एक उदाहरण है कि मुझे क्यों लगता है कि घटक पेड़ के साथ बातचीत करने के लिए एपीआई को उजागर करना इस समस्या से संपर्क करने का एक दिलचस्प तरीका होगा: https://github.com/kevinrobinson/redux/blob/feature/loggit-todomvc/examples/loggit -todomvc/loggit/renderers/precompute_react_renderer.js#L72

यह तरीका पेड़ पर चलने के लिए मेरी हैकरी है, और इसलिए मेरा सवाल यह है कि इस तरह की चीज करने के लिए सार्वजनिक एपीआई कैसे "बग़ल में डेटा-लोडिंग" में नवाचार को सक्षम करेगा, जो मुझे लगता है कि "एक रेंडरर जो करता है" टी वर्क टॉप-डाउन": https://github.com/kevinrobinson/redux/blob/feature/loggit-todomvc/examples/loggit-todomvc/loggit/react_interpreter.js#L8

kevinrobinson 6 जुल॰ 2015

लेकिन यहां एक उदाहरण है कि मुझे क्यों लगता है कि घटक पेड़ के साथ बातचीत करने के लिए एपीआई को उजागर करना इस समस्या से संपर्क करने का एक दिलचस्प तरीका होगा।

मेरा मानना है कि @swannodette ने इस बारे में

gaearon 6 जुल॰ 2015

हां, उन्होंने पहले ReactConf में इसी तरह का सुझाव दिया था। मैंने नवीनतम Om.next नहीं देखा है या यूरोक्लोजर बात नहीं सुनी है, लेकिन पहले ओम अपनी संरचना का उपयोग करता था जिसे ऐसा करने के लिए उपयोगकर्ताओं को बनाना पड़ता था।

kevinrobinson 6 जुल॰ 2015

यह तरीका पेड़ पर चलने के लिए मेरी हैकरी है, और इसलिए मेरा सवाल यह है कि इस तरह की चीज करने के लिए सार्वजनिक एपीआई कैसे "बग़ल में डेटा-लोडिंग" में नवाचार को सक्षम करेगा, जो मुझे लगता है कि "एक रेंडरर जो करता है" टी काम ऊपर से नीचे"

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

प्रारंभिक प्रतिक्रिया यह है कि यह थोड़ा निम्न स्तर का हो सकता है - लेकिन एक्स्टेंसिबल वेब सामग्री के समान ही मुझे लगता है कि इससे उपयोगकर्ता स्थान में प्रयोग करना आसान हो जाएगा।

glenjamin 6 जुल॰ 2015

मैं सहमत हूं, अगर हमारे पास पेड़ पाने के लिए प्रस्तुत करने का कोई तरीका है तो हम इसे चला सकते हैं और सभी डेटा की जरूरतों को ढूंढ सकते हैं और उन्हें पास कर सकते हैं।

jeffbski 6 जुल॰ 2015

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

nmn 6 जुल॰ 2015

वेधशालाओं की जटिलता को देखते हुए, मैं विनम्रतापूर्वक इस सूत्र में अच्छे सज्जनों को उल्का के प्रतिक्रियाशील डेटा के कार्यान्वयन को देखने का सुझाव देता हूं: https://github.com/meteor/meteor/wiki/Tracker-Manual। रिएक्ट के साथ इसे समेटने के लिए componentWillMount विधि में कोड की 3-5 लाइनें शाब्दिक रूप से लगती हैं, कुछ इस तरह:

  componentWillMount() {
    if (typeof this.getState === 'function') {
      Tracker.autorun(() => {
        // Assuming this.getState() calls some functions that return
        // reactive data sources
        this.setState(this.getState());
      });
    }
  }

मुझे नहीं पता कि ट्रैकर (जिसे आसानी से एक अलग पुस्तकालय के रूप में निकाला जाता है) प्रतिक्रिया में अवलोकन योग्य समर्थन की आवश्यकता को रोकता है, लेकिन यह निश्चित रूप से ऐसा लगता है।

mitranim 12 जुल॰ 2015

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

    componentWillMount: function() {
        var baseRender = this.render;
        this.render = function() {
            if (this._watchDisposer)
                this._watchDisposer();
            var[rendering, disposer] = mobservableStatic.watch(() => baseRender.call(this), () => {
                    this.forceUpdate();
            });
            this._watchDisposer = disposer;
            return rendering;
        }
    },

mweststrate 12 जुल॰ 2015

@Mitranim मैं सहमत हूं, यह वास्तव में एक अच्छा पठन है, इसे खोजने के लिए धन्यवाद! यह प्रभावी रूप से https://github.com/facebook/react/pull/3920 सुझाव दे रहा है।

हम तय नहीं कर पा रहे हैं कि कौन सा प्रस्ताव बेहतर है। दोनों के साथ खेलने के बाद, मैं ज्यादातर आश्वस्त हूं कि प्रतिक्रियाशील प्रोग्रामिंग (जैसा कि आपने लिंक किया है; https://github.com/meteor/meteor/wiki/Tracker-Manual) जाने का रास्ता है, लेकिन हम आम सहमति तक नहीं पहुंचे हैं और हम अभी भी यह पता लगाने की कोशिश कर रहे हैं कि सबसे अधिक समझ में क्या आता है, इसलिए प्रतिक्रिया का स्वागत है।

jimfb 12 जुल॰ 2015

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

https://github.com/ccorcos/meteor-track/blob/master/client/main.js

और मैंने ट्रैकर के साथ एक नमूदार स्ट्रीम लाइब्रेरी भी बनाई:

https://github.com/ccorcos/meteor-tracker-streams

लेकिन जैसा कि मैंने ब्लेज़ के बजाय रिएक्ट का उपयोग करने के लिए पूरी तरह से संक्रमण किया है, मुझे पता चला है कि ट्रैकर बहुत जटिल है और कभी-कभी एक साधारण प्रकाशन/सब्सक्राइब/ऑन चेंज विधियां सिर्फ 100x आसान होती हैं।

इसके अलावा, सभी कार्यात्मक प्रोग्रामिंग प्रशंसकों के लिए, ट्रैकर कुछ साइड-इफेक्ट्स के साथ आता है जो 99% मामलों में समझ में आता है, लेकिन कभी-कभी वे आपको प्राप्त करते हैं। यहां बताया गया है कि यह एक प्रतिक्रिया घटक में कैसा दिखेगा

componentWillMount: ->
  <strong i="15">@c</strong> = Tracker.autorun =>
    @setState({loading: true})
    Meteor.subscribe 'users', => @setState({loading: false})
    Tracker.autorun =>
      @setState({users: Users.find({}, {sort:{name:-1}}).fetch()})
componentWillUnmount: ->
  @c.stop()

साइड-इफेक्ट्स के बारे में मेरा कहना है कि c.stop() सब्सक्रिप्शन और आंतरिक ऑटोरन को भी बंद कर देगा।

ccorcos 12 अक्तू॰ 2015

@ccorcos हां, https://github.com/facebook/react/pull/3920 में सभी दुष्प्रभाव प्रतिक्रिया के लिए पूरी तरह से आंतरिक होंगे। वास्तव में, रिएक्ट कोर उन्हें पूरी तरह से अपरिवर्तनीय/कार्यात्मक तरीके से लागू कर सकता है जो कोई उत्परिवर्तन नहीं करेगा। लेकिन यह एक कार्यान्वयन विवरण है, क्योंकि साइड इफेक्ट वैसे भी बाहरी रूप से दिखाई नहीं देंगे।

jimfb 12 अक्तू॰ 2015

दिलचस्प... तो क्यों न सिर्फ चेंज कॉलबैक का उपयोग करें? मैंने उन्हें सबसे अधिक संगत पाया है। चाहे आप उल्का (ट्रैकर), RxJS, Highland.js, आदि का उपयोग कर रहे हों, आप किसी ईवेंट कॉलबैक के साथ हमेशा उनके साथ एकीकृत कर सकते हैं। और रिएक्ट हाई-ऑर्डर कंपोनेंट के साथ भी ऐसा ही है।

Redux के बारे में मुझे जो पसंद है वह यह है कि यह इस तर्क को ढांचे से बाहर रखता है और रिएक्ट घटकों को शुद्ध कार्यों के रूप में रखता है।

ccorcos 13 अक्तू॰ 2015

@ccorcos मुख्य समस्या यह है कि जब कोई घटक उदाहरण नष्ट हो जाता है, तो सभी "सदस्यता" को साफ़ करने की आवश्यकता होती है। घटक लेखक अक्सर इस सफाई के बारे में भूल जाते हैं, इस प्रकार स्मृति रिसाव बनाते हैं। हम चाहते हैं कि यह स्वचालित हो, जिससे लिखना आसान हो (कम बॉयलरप्लेट) और कम त्रुटि-प्रवण (क्लीनअप स्वचालित है)।

jimfb 13 अक्तू॰ 2015

@jimfb बिल्कुल सही। स्वचालित सदस्यता समाप्त करना ट्रैकर के दृष्टिकोण के बारे में वास्तव में साफ-सुथरी चीजों में से एक है। प्रतिक्रियाशील डेटा स्रोत के लिए प्रत्येक कॉल सदस्यता को फिर से स्थापित करता है, और एक बार घटक डेटा के लिए कॉल करना बंद कर देता है, तो सफाई के लिए कुछ भी नहीं है!

mitranim 13 अक्तू॰ 2015

हाँ, लेकिन यह वास्तव में "स्वचालित रूप से" सदस्यता समाप्त नहीं हुई है। आपको कॉल करना होगा c.stop() में घटक अनमाउंट हो जाएगा। यद्यपि आप इसे एक मिश्रण के साथ दूर कर सकते हैं।

componentWillMount: ->
  <strong i="7">@autorun</strong> =>
    @setState({loading: true})
    Meteor.subscribe 'users', => @setState({loading: false})
    Tracker.autorun =>
      @setState({users: Users.find({}, {sort:{name:-1}}).fetch()})

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

ccorcos 13 अक्तू॰ 2015

@ccorcos हम विभिन्न तंत्रों के बारे में बात कर रहे होंगे। पिछली बार मैंने जाँच की थी, ट्रैकर के पास स्थायी सदस्यता नहीं थी; प्रत्येक फ़ंक्शन जो एक प्रतिक्रियाशील डेटा स्रोत (इसे एक्सेस करके) पर निर्भरता स्थापित करता है, जब यह बदलता है तो _once_ फिर से चला जाता है, और यह सदस्यता का अंत है। यदि यह डेटा स्रोत को फिर से एक्सेस करता है, तो यह एक और बदलाव के लिए "सदस्यता" को फिर से स्थापित करता है। और इसी तरह।

mitranim 13 अक्तू॰ 2015

@Mitranim सही है, # 3920 के शब्दार्थ उल्का की तुलना में अधिक "स्वचालित" हैं (सदस्यता वास्तव में स्वचालित है), और कहीं अधिक सरल है क्योंकि सामान्य उपयोग के मामले में शाब्दिक रूप से शून्य एपीआई सतह क्षेत्र है।

jimfb 13 अक्तू॰ 2015

@ccorcos @Mitranim उपयोग के लिए तैयार ट्रैकर / Vue.js प्रेरित लाइब्रेरी के लिए आप Mobservable आज़मा सकते हैं, यह _render_ के दौरान एक्सेस किए गए सभी डेटा का निरीक्षण करता है, और अनमाउंट पर सभी सब्सक्रिप्शन का निपटान करता है (तब तक सब्सक्रिप्शन को जीवित रखा जाता है)। हमने इसे मेंडिक्स में अब तक बहुत बड़ी परियोजनाओं में सफलतापूर्वक लागू किया है। यह आपके डेटा के लिए बहुत विनीत है और साथ ही यह अपने स्वयं के मॉडल ऑब्जेक्ट प्रदान करने के बजाय मौजूदा वस्तुओं को सजाता है।

mweststrate 13 अक्तू॰ 2015

पिछली बार मैंने जाँच की थी, ट्रैकर के पास स्थायी सदस्यता नहीं थी

@Mitranim सदस्यता स्थायी हो सकती है। इसकी जांच करें।

sub = Meteor.subscribe('chatrooms')
# this subscription lasts until...
sub.stop()

अब ट्रैकर के साथ कुछ दिलचस्प चीजें हैं। इसकी जांच करें।

comp = Tracker.autorun ->
  Meteor.subscribe('chatrooms')
# this subscription lasts until...
comp.stop()

हालांकि अंतिम उदाहरण बहुत उपयोगी नहीं है। जब तक हम ऐसा कुछ नहीं करते।

roomId = new ReactiveVar(1)
comp = Tracker.autorun ->
  Meteor.subscribe('messages', roomId.get())
# when I change the roomId, the autorun will re-run
roomId.set(2)
# the subscription to room 1 was stopped and now the subscription to room 2 has started
# the subscription is stopped when I call stop...
comp.stop()

प्रत्येक फ़ंक्शन जो एक प्रतिक्रियाशील डेटा स्रोत पर निर्भरता स्थापित करता है (इसे एक्सेस करके) एक बार फिर से चला जाता है जब यह बदलता है, और यह सदस्यता का अंत है।

सदस्यता तब तक चलती है जब तक ऑटोरन फिर से चालू नहीं हो जाता (एक प्रतिक्रियाशील निर्भरता बदल जाती है) या गणना यह रुक जाती है। जिनमें से दोनों कंप्यूटेशन को कॉल करते हैं। इनवैलिडेट हुक।

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

comp = Tracker.autorun ->
  Meteor.subscribe('chatrooms')

# is the same as

comp = Tracker.autorun (c) ->
  sub = null
  Tracker.nonreactive ->
    # dont let comp.stop() stop the subscription using Tracker.nonreactive
    sub = Meteor.subscribe('chatrooms')
  c.onInvalidate ->
    # stop the subscription when the computation is invalidated (re-run)
    sub.stop()
# invalidate and stop the computation
comp.stop()

ccorcos 13 अक्तू॰ 2015

@ccorcos मैं अब भ्रम का स्रोत देखता हूं; यह मेरी शब्दावली थी। सब्सक्रिप्शन के बारे में बात करते समय, मेरा मतलब _Meteor सब्सक्रिप्शन_ नहीं था। वे निर्धारित करते हैं कि सर्वर से क्लाइंट को कौन सा डेटा पुश किया जाता है, लेकिन वे व्यू लेयर अपडेट के लिए प्रासंगिक नहीं हैं, जो इस चर्चा का विषय है। _सदस्यता_ कहते समय, मैं पारंपरिक ईवेंट श्रोताओं और एक प्रतिक्रियाशील डेटा स्रोत पर निर्भरता वाले फ़ंक्शन को फिर से चलाने की ट्रैकर की क्षमता के बीच एक समानांतर चित्रण कर रहा था। रिएक्ट घटकों के मामले में, यह एक घटक विधि होगी जो डेटा प्राप्त करती है और फिर कॉल करती है setState या forceUpdate ।

@mweststrate उदाहरण के लिए धन्यवाद, यह दिलचस्प लग रहा है।

mitranim 14 अक्तू॰ 2015

आह हाँ। तो उनके पास ऐसा करने का एक चतुर तरीका है।

componentWillMount: function() {
  this.comp = Tracker.autorun(() => {
    let sub = Meteor.subscribe('messages')
    return {
      loading: !sub.ready(),
      messages: Messages.find().fetch()
    }
  })
componentWillUnmount: function() {
  this.comp.stop()
}

सदस्यता हर बार बिना किसी समस्या के फिर से सदस्यता लेगी। sub.ready और Messages.find.fetch दोनों "प्रतिक्रियाशील" हैं और जब भी वे बदलते हैं तो ऑटोरन को फिर से चलाने के लिए ट्रिगर करेंगे। ट्रैकर के बारे में सबसे अच्छी बात यह है कि जब आप ऑटोरन को छिपाना शुरू करते हैं और केवल दस्तावेज़ीकरण में होते हैं कि एक निश्चित फ़ंक्शन "प्रतिक्रियाशील संदर्भ" के भीतर होता है

आप इसे मिक्सी में फेंक सकते हैं

componentWillMount: function() {
  this.comp = Tracker.autorun(() => {
    return this.getReactiveData()
  })
componentWillUnmount: function() {
  this.comp.stop()
}

और फिर आप इस जादुई प्रतिक्रियाशील कार्य के साथ रह गए हैं जो बस काम करता है!

getReactiveData: function() {
  let sub = Meteor.subscribe('messages')
  return {
    loading: !sub.ready(),
    messages: Messages.find().fetch()
  }
}

ट्रैकर इस तरह बहुत अच्छा है...

ccorcos 14 अक्तू॰ 2015

@ccorcos पता चला है कि ट्रैकर-शैली की घटना का उपयोग करते समय मैं स्वचालित सदस्यता समाप्त करने के बारे में कुछ गलत था। आपको अभी भी श्रोता को componentWillUnmount में रोकने की आवश्यकता है, अन्यथा यह डेटा स्रोतों तक पहुंचता रहेगा और setState कॉल करता रहेगा (जब तक कि आप isMounted() जो अब बहिष्कृत है)।

एक तरफ ध्यान दें, आप घटक विधियों को प्रतिक्रियाशील बनाने के लिए सुरुचिपूर्ण सज्जाकार बना सकते हैं। यहां कुछ उदाहरण दिए गए हैं: [1] , [2] । इस तरह दिखता है:

export class Chat extends React.Component {
  <strong i="13">@reactive</strong>
  updateState () {
    this.setState({
      auth: auth.read(),
      messages: messages.read()
    })
  }

  /* ... */
}

mitranim 24 अक्तू॰ 2015

@ मित्रानिम बहुत साफ-सुथरा है - हालांकि मैं उच्च-क्रम के कार्यों को पसंद करता हूं। ;)

ccorcos 26 अक्तू॰ 2015

@sebmarkbage @jimfb मैं कुछ महीनों से इस थ्रेड और ऑल्ट थ्रेड (#3858) का अनुसरण कर रहा हूं, और मैं उत्सुक हूं कि क्या कोर टीम इस समस्या के बारे में किसी आम सहमति पर पहुंच गई है, या कम से कम एक सामान्य दिशा।

oztune 16 नव॰ 2015

@oztune कोई अपडेट नहीं; हमने अन्य प्राथमिकताओं पर ध्यान केंद्रित किया है। इस विषय पर कोई अपडेट होने पर हम किसी एक थ्रेड पर पोस्ट करेंगे।

jimfb 16 नव॰ 2015

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

import { compose } from `react-komposer`;

// Create a component to display Time
const Time = ({time}) => (<div>{time}</div>);

// Create the composer function and tell how to fetch data
const composerFunction = (props, onData) => {
    const handler = setInterval(() => {
    const time = new Date().toString();
    onData(null, {time});
  }, 1000);

  const cleanup = () => clearInterval(handler);
  return cleanup;
};

// Compose the container
const Clock = compose(composerFunction)(Time);

// Render the container
ReactDOM.render(<Clock />, document.getElementById('react-root'));

यहाँ लाइव संस्करण है: https://jsfiddle.net/arunoda/jxse2yw8/

हमारे पास वादों, Rx.js वेधशालाओं और उल्का के ट्रैकर के साथ कंटेनर बनाने के कुछ आसान तरीके भी हैं।

इस पर मेरा लेख भी देखें: आइए कुछ रिएक्ट कंटेनरों की रचना करें

arunoda 3 जन॰ 2016

@arunoda हम कुछ ऐसा ही कर रहे हैं। एक बात जो मैं सोच रहा हूं, वह यह है कि आप कंपोजर फंक्शन को हर प्रोप चेंज पर कॉल करने से कैसे रोकते हैं?

oztune 3 जन॰ 2016

@oztune वास्तव में अब यह फिर से चलेगा। हम इस लोकका और उल्का का उपयोग करते हैं। उन दोनों के पास स्थानीय कैश हैं और जब हम कंपोजरफंक्शन को कई बार कॉल करते हैं तब भी सर्वर हिट नहीं होता है।

लेकिन मुझे लगता है कि हम ऐसा कुछ कर सकते हैं:

const options =  {propsToWatch: ["postId"]};
const Clock = compose(composerFunction, options)(Time);

कोई विचार?

arunoda 3 जन॰ 2016

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

oztune 3 जन॰ 2016

@oztune मैंने एक नया GH मुद्दा बनाया है और चलिए वहां अपनी चैट जारी रखते हैं। मुझे लगता है कि ट्विटर से काफी बेहतर है।

arunoda 4 जन॰ 2016

क्यों न सिर्फ JSX को ऑब्जर्वेबल्स को सीधे समझने और रेंडर करने दें, ताकि मैं ऑब्जर्वेबल को प्रॉप्स में पास कर सकूं, जैसे कि this.props.todo$ और उन्हें JSX में एम्बेड करें। तब मुझे किसी एपीआई की आवश्यकता नहीं होगी, बाकी को रिएक्ट के बाहर प्रबंधित किया जाता है और एचओसी का उपयोग वेधशालाओं को भरने के लिए किया जाता है। इससे कोई फर्क नहीं पड़ता कि प्रॉप्स में सादा डेटा है या एक अवलोकन योग्य है, इसलिए कोई विशेष this.data की आवश्यकता नहीं है।

{this.props.todo$

इसके अतिरिक्त रिएक्ट रेंडर ऑसर्वेबल [JSX] को रेंडर करने में सक्षम हो सकता है जो अतिरिक्त लाइब्रेरी के बिना लिंक में वर्णित डिज़ाइन की अनुमति देगा।

https://medium.com/@milankinen/containers -are-dead-long-live-observable-combinators-2cb0c1f06c96#.yxns1dqin

https://github.com/milankinen/react-combinators

vladap 17 जन॰ 2016

नमस्ते,
अभी के लिए हम आसानी से rxjs स्ट्रीम के साथ स्टेटलेस घटकों का उपयोग कर सकते हैं।
मैं किसी अन्य एपीआई की आवश्यकता को नहीं समझता।
मैंने एक उदाहरण लिखा - एक बोर्ड जिस पर आप माउस ले जा सकते हैं और जब यह 26 हो जाता है तो यह पुनः आरंभ करने के लिए बदल जाता है।
मुझे यह सुनना अच्छा लगेगा कि आप इस बारे में क्या सोचते हैं।
यहाँ कोड है:
https://jsfiddle.net/a6ehwonv/74/

giltig 1 मार्च 2016

👍1

@giltig : मैं हाल ही में इस तरह से सीख रहा हूं और इसे पसंद कर रहा हूं। साथ में Cycle.js.

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

इसके अलावा RxJs कंबाइनलेस्ट में ऑब्जेक्ट का समर्थन कर सकते हैं ताकि हम बड़े घटकों को बनाने के लिए सीधे रिएक्ट कार्यात्मक घटकों का उपयोग कर सकें।

const myFancyReactComponent = ({surface, number, gameover}) => (
        <div> 
          {gameover ? gameover : surface}
          {number}
        </div>
)

const LiveApp = Rx.Observable.combineLatest(
    LiveSurface, DynamicNumberView, DynamicGameOver,
    myFancyReactComponent
)

vladap 2 मार्च 2016

नमस्ते,
साइकिल या किसी अन्य ढांचे का उपयोग नहीं करने का कारण यह है कि मैं फ्रेमवर्क (डेवलपर के लिए अधिक नियंत्रण) पर पुस्तकालयों को पसंद करता हूं और साथ ही मैं उस सामुदायिक शक्ति का आनंद लेना चाहता हूं जो रिएक्ट के पास है।
इतने सारे रेंडर इंजन अब रिएक्ट के लिए विकसित किए गए हैं और इसका उपयोग न करना अफ़सोस की बात है (ReactNative, ReactDom, ReactThree आदि ..)। केवल Rxjs का उपयोग करना और ऊपर दिखाए गए उदाहरण के रूप में प्रतिक्रिया करना बहुत आसान है।

अगर प्रतिक्रिया घटक पोजोस को तब तक स्वीकार कर सकते हैं जब तक वे प्रोप के रूप में अवलोकन योग्य हों। अभी के लिए यह संभव नहीं है इसलिए मैंने ऊपर जो दिखाया है वह वही तरीका है जिसे हमने चुना है।

बीटीडब्ल्यू आपने MyFancyReactComponent के साथ जो किया वह संभव है और हमने वास्तव में कुछ मामलों में भी ऐसा किया है, हालांकि आप सीधे जेएसएक्स भी लिख सकते हैं।

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

giltig 2 मार्च 2016

👍1

अगर प्रतिक्रिया घटक पोजोस को तब तक स्वीकार कर सकते हैं जब तक वे प्रोप के रूप में अवलोकन योग्य हों। अभी के लिए यह संभव नहीं है इसलिए मैंने ऊपर जो दिखाया है वह वही तरीका है जिसे हमने चुना है।

देखने योग्य प्रॉप्स का लंबे समय में कोई मतलब नहीं है। उस संदर्भ में इसका कोई मतलब नहीं है, वास्तव में..

chain-police 20 नव॰ 2016

यह मुझे ऐसा लगता है जैसे हमने सस्पेंस (कैश + संदर्भ) के साथ एक अलग मॉडल के साथ समाप्त किया। कैश को ही सब्सक्रिप्शन के लिए सपोर्ट मिल सकता है। आप सस्पेंस के शेष कार्य को https://github.com/facebook/react/issues/13206 में ट्रैक कर सकते हैं।

हम अधिक पृथक मामलों के लिए एक सदस्यता पैकेज भी प्रदान करते हैं।

gaearon 15 अग॰ 2018

क्या यह पृष्ठ उपयोगी था?

0 / 5 - 0 रेटिंग्स

React: बग़ल में डेटा लोड करना लागू करें

सबसे उपयोगी टिप्पणी

सभी 136 टिप्पणियाँ

संबंधित मुद्दों