2015-05-27 18 views
17

मैं AngularJS में क्लाइंट-साइड अनुप्रयोगों के विकास से परिचित हूँ, लेकिन अब मैं ReactJS का उपयोग शुरू करना चाहते हैं।"ReactJS में सोच रही थी" अगर मैं एक AngularJS पृष्ठभूमि है?

मैं भी एक आँख पर है ReactNative जो मुझे लगता है कि मोबाइल एप्लिकेशन में क्रांतिकारी बदलाव होगा।

सोच का तरीका क्या है और कैसे एक आवेदन प्रतिक्रिया की संरचना कोणीय से अलग है? क्या सबसे बड़ा अंतर है?

+8

सबसे बड़ा अंतर यह है कि प्रतिक्रिया-आधारित परियोजना के लिए स्पेगेटी में बदलने में अधिक समय लगता है। – zerkms

+1

आपको अंगुलर 1 -> कोणीय 2 माइग्रेशन पोस्ट में दिलचस्पी हो सकती है, क्योंकि कोणीय 2 में घटक होते हैं, और कोणीय में किसी भी चीज़ से प्रतिक्रिया करने के लिए एक बेहतर एनालॉग है 1. [इस पोस्ट] पर एक नज़र डालें (http: // blog.ionic.io/angular-2-series-components/) या [यह वीडियो] (https: // angularu।कॉम/वीडियो/2015 एसएफ/ब्रैड-ग्रीन-वार्ता-निर्देश-नियंत्रक-बनने वाले घटक-इन-कोणीय -2) उदाहरण के लिए –

उत्तर

20

निर्देश

यदि आप कोणीय से परिचित हैं, तो प्रतिक्रिया के बारे में सोचने का तरीका केवल निर्देशों का उपयोग करके कोणीय का उपयोग करके कल्पना करना है। प्रतिक्रिया में नियंत्रकों, सेवाओं, कारखानों या निर्भरता इंजेक्शन की कोई अवधारणा नहीं है। अगर केवल घटकों (कोणीय शर्तों में निर्देश) पर केंद्रित है।

यह भी तरीका है कि कोणीय कोणीय के साथ आगे बढ़ता है 2. कोणीय 2 घटक नामक एक अवधारणा पेश करता है, और निर्देशकों, नियंत्रकों और सेवाओं/कारखानों की धारणा को हटा देता है। कोणीय 2 अभी भी DI का उपयोग करता है, लेकिन आप अपनी कक्षाओं को कोणीय दुनिया में नहीं जोड़ रहे हैं (जो आप कोणीय 1 में करते हैं)।

कार्यक्षेत्र

तो कोणीय का उपयोग करता है बंधन डेटा के लिए scopes, और एक गुंजाइश (या एक माता पिता के दायरे) से संबद्ध किसी भी टेम्पलेट पढ़ सकते हैं और है कि दायरे से डेटा प्रिंट कर सकते हैं, और यहां तक ​​कि गुंजाइश को संशोधित। प्रतिक्रिया में एक दायरे की कोई अवधारणा नहीं है, अधिकांशतः क्योंकि प्रतिक्रिया कोणीय की तरह गंदे-जांच नहीं करती है, बल्कि यह भी कि प्रतिक्रिया नियमित रूप से जावास्क्रिप्ट स्कॉपिंग का उपयोग करती है यह निर्धारित करने के लिए कि कौन से चर/ऑब्जेक्ट दृश्य में उपलब्ध हैं। उस पर और अधिक।

Templating

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

JSX में, आप तत्वों पर या तो <div className="myClass"> की तरह या किसी Javascript- अभिव्यक्ति, इस तरह के साथ तारों के रूप में संपत्ति मूल्यों को निर्धारित कर सकते हैं: <div className={myClassVariable}> जहां myClassVariable एक नियमित रूप से जावास्क्रिप्ट चर रहा है। जेएसएक्स में और } के बीच कुछ भी सिर्फ पुराना जावास्क्रिप्ट है। आप किसी ऑब्जेक्ट, फ़ंक्शन, स्ट्रिंग इत्यादि को पास कर सकते हैं। और जब आप जेएसएक्स में एक अपरिभाषित चर का उपयोग करने का प्रयास करते हैं तो आपका लिंटर आपकी मदद कर सकता है, जो कि जब आप कोणीय टेम्पलेट्स में विशेषताओं का उपयोग करते हैं तो आपका लिटर ऐसा नहीं कर सकता है।

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

डाटा बाध्यकारी/उत्परिवर्तन/राज्य

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

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

फ़ंक्शन में परिभाषित चर को उस फ़ंक्शन में बदला जा सकता है और उन्हें अन्य कार्यों में तर्क के रूप में पारित किया जा सकता है।

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

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

प्रतिक्रिया जानता है कि घटक के राज्य और प्रोप बदलते हैं क्योंकि जब आप किसी घटक की स्थिति को बदलना चाहते हैं तो आपको स्पष्ट रूप से setState पर कॉल करना होगा। यह जानता है कि प्रोप बदलते हैं क्योंकि जब आप मूल घटक प्रस्तुत करते हैं तो आप किसी घटक को प्रोप पास करते हैं।

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

मेरे नियंत्रक कहां हैं !?

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

var TodoItemsComponent = React.createClass({ 
    getInitialState: function() { 
    return { 
     todoItems: null 
    } 
    }, 
    componentDidMount: function() { 
    var self = this; 
    TodoStore.getAll().then(function (todoItems) { 
     self.setState({todoItems: todoItems}); 
    }); 

    TodoStore.onChange(function (todoItems) { 
     self.setState({todoItems: todoItems}); 
    }); 
    }, 
    render: function() { 
    if (this.state.todoItems) { 
     return <TodoListComponent todoItems={this.state.todoItems} />; 
    } else { 
     return <Spinner />; 
    } 
    } 
}); 

var TodoListComponent = React.createClass({ 
    render: function() { 
    return (
     <ul> 
     {this.props.todoItems.map(function (todo) { 
      return <li>{todo.text}</li>; 
     })} 
     </ul> 
    ); 
    } 
}); 

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

डेटा दृश्य मॉडल के साथ दृश्य रखने के लिए सिंक में बाध्यकारी

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

लोगों का एक बहुत की

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

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

यह दीवार की एक पाठ बन गया, इसलिए कृपया मुझे बताएं कि मुझे कुछ स्पष्टीकरण देना चाहिए या विस्तार करना चाहिए।

+0

कोणीय 2 निर्देशों से छुटकारा नहीं मिला। वास्तव में, एक घटक एक टेम्पलेट के साथ सिर्फ एक निर्देश है। [स्रोत] (https://angular.io/docs/ts/latest/guide/attribute-directives.html#!#directives-overview) –

9

ReactJS सब के बारे में (reusable) components है, जो imo कर सकते हैं सर्वोत्तम की तुलना कोणीय के directives से की जा सकती है।

तो मैं कहूंगा कि, केवल निर्देशों :)

मैं कुछ सप्ताह पहले ReactJS में विकास करना शुरू के साथ और पहली बार में यह अजीब था AngularJS में ऐप्स बनाने की कल्पना (अपने जे एस में टेम्पलेट कोड लिखने, WTF?), लेकिन अब मैं इसका इस्तेमाल कर चुका हूं। मैंने हाल ही में प्रतिक्रिया-मूल के साथ खेलना शुरू कर दिया और यह कमाल है!

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

और फिर वहाँ भी ०१२३८५४०६५८३ है, प्रतिक्रिया पुस्तकालयों, संसाधनों, ट्यूटोरियल, लेख का एक संकलन (आप इसे नाम है, यह नहीं है)

आपके प्रश्न से संबंधित, इस खंड शायद आप के लिए सबसे दिलचस्प बात यह है:

More articles on the approach of ReactJS and comparisons with other frameworks

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