दिलचस्प पोस्ट
क्या जावा में कंस्ट्रक्टर कोड चलाने से पहले खेले जाने वाले फ़ील्ड शुरू होते हैं? जावास्क्रिप्ट: प्रयोक्ता को स्क्रॉल करने के बाद कार्रवाई करें क्या मैं एक उपयोगकर्ता-विशिष्ट gitignore फ़ाइल बना सकता हूँ? क्यों स्विच मॉड्यूल पर्ल में पदावनत है? रूबी में स्ट्रिंग्स के बजाय प्रतीकों का उपयोग कब करना है? आयात लाइब्रेरी कैसे काम करती है? विवरण? विंडोज बैच फाइलें: कमांड के परिणाम के साथ एक वैरिएबल कैसे सेट करें? अजगर के साथ एक ध्वनि का पता लगाओ और रिकॉर्ड करें सी ++ द्वारा कॉल करने के लिए मैं पायथन में सी ++ क्लास कैसे लागू कर सकता हूं? मैं स्क्रीन रोटेशन का कैसे पता लगा सकता हूं कैसे। एसक्यूएल फ़ाइल को MySQL डेटाबेस में php का उपयोग कर एक पिक्सेल संपादक के लिए ग्रिड का एक प्रकार चाहते हैं सी का उपयोग करते हुए बाइनरी प्रस्तुति में एक int मुद्रित करें Java8 के साथ इंट आवृत्तियों को गणना करें एक संरचना को दूसरे में कॉपी करना

ReactJS आवेदन – लचीलाता वीएस तेजी से विफल

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

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

कौन सा दृष्टिकोण सही है और पेशेवर और विपक्ष क्या हैं?

विचार के लिए भोजन के रूप में मेरे कुछ विचार ..

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

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

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

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

विचार?

एक सरल उदाहरण का पालन करता है:

प्रतिक्रिया घटक

import React from 'react'; import PropTypes from 'prop-types'; import styles from './styles.css'; export const App = ({ person : { name, surname, address, subscription } = {} }) => ( <div style={styles.person}> <p> {person.name} </p> <p> {person.surname} </p> <p> {person.address} </p> <div> { person.subscription && <Subscription details={person.subscription} /> } </div> </div> ); // PS. this is incorrect in this example (as pointed out in an answer). Real code used inline initialization. // App.defaultProps = { // person: { subscription: undefined }, // }; App.propTypes = { person: PropTypes.shape({ name: PropTypes.string.isRequired, surname: PropTypes.string.isRequired, address: PropTypes.string, subscription: PropTypes.object, }).isRequired, }; 

परीक्षा

 import React from 'react'; import { shallow } from 'enzyme'; import { mockOut } from 'testUtils/mockOut'; import { App } from '../index.js'; describe('<App>', () => { mockout(App, 'Subscription'); it('renders correctly', () => { const testData = { name: 'a name', surname: 'a surname', address: '1232 Boulevard Street, NY', subscription: { some: 'data' }, } const tree = shallow(<App person={testData} />); expect(tree.html()).toMatchSnapshot(); }); it('is resilient in case of bad data - still generates PropTypes validation logs', () => { const tree = shallow(<App person={undefined} />); expect(tree.html()).toMatchSnapshot(); }); }); 

अद्यतन करें:

प्रश्न का मुख्य फोकस यह है कि क्या यह सही है या नहीं करने के लिए डिफ़ॉल्ट मूल्यों को असाइन करने के लिए है जो isRequired (उनकी अनुपस्थिति को घटक को तोड़ने के बजाय) के साथ चिह्नित किया गया है

Solutions Collecting From Web of "ReactJS आवेदन – लचीलाता वीएस तेजी से विफल"

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

वास्तव में, यदि घटक में कोई सहारा वैकल्पिक है, घटक (जो वास्तविक दृश्य देता है) को वहन करना चाहिए, मूल घटक नहीं

हालांकि, आप ऐसी स्थिति बना सकते हैं, जहां माता-पिता को तोड़ना चाहिए, यदि कोई भी बच्चा घटकों का अनुबंध टूट रहा हो मैं इस स्थिति को संभालने के दो संभावित तरीकों के बारे में सोच सकता हूं-

  1. बाल घटकों को त्रुटि नोटिफिकेशन पास करना, जहां कुछ गलत हो जाता है, मूल घटक को त्रुटि रिपोर्ट कर सकता है लेकिन यह साफ समाधान नहीं है क्योंकि अगर कोई बच्चा है और यदि एक से अधिक माता पिता को टूट जाएगा (या रिपोर्ट की गई त्रुटि), तो आपको कोई सुराग नहीं होगा और इसे प्रबंधित करना कठिन होगा। [यह बिल्कुल भी प्रभावी नहीं है, लेकिन यहां लिखा है क्योंकि मैं इसका पालन करता था जब मैं रिएक्ट सीख रहा था: पी]

  2. माता पिता के घटक में try/catch और किसी भी बच्चे के घटक पर विश्वास न करें और कुछ गलत होने पर त्रुटि संदेश दिखाएं। जब आप अपने सभी घटक में try/catch का उपयोग कर रहे हैं, तो किसी भी अनुबंध को पूरा नहीं होने पर आप घटकों से सुरक्षित रूप से त्रुटि फेंक सकते हैं।

कौन सा दृष्टिकोण सही है और पेशेवर और विपक्ष क्या हैं?

आईएमओ, दूसरा दृष्टिकोण (घटकों में try/catch और आवश्यकताओं को पूरा नहीं करने पर त्रुटि फेंकना) मान्य है और सभी मुद्दों को हल करेगा। घटक के लिए परीक्षण लेखन करते समय जब सहारा नहीं पारित हो जाते हैं, तो घटक लोड करते समय त्रुटि की उम्मीद कर सकते हैं।

अद्यतन करें

यदि आप प्रतिक्रिया> 16 का उपयोग कर रहे हैं, तो यह त्रुटियों को संभालने का तरीका है

घटक defaultProps माध्यम से .isRequred को डिफ़ॉल्ट मान असाइन करने के लिए सही नहीं है। आधिकारिक दस्तावेजों के अनुसार:

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

यदि आप Component.defaultProps में डिफ़ॉल्ट प्रॉपर्टी वैल्यू सेट करते हैं, तो आपको कभी भी एक चेतावनी प्राप्त नहीं होगी, अगर यह प्रोप पैरेंट घटक द्वारा प्रदान नहीं किया गया है।

मेरी राय में, मैं अपने आवेदन को तोड़ने के लिए एक या दो लापता गुणों को नहीं दूँगा। प्रतिक्रिया मेरे ऐप में प्रस्तुति स्तर के रूप में काम करती है और मुझे लगता है कि यह एक दूर तक रास्ता है कि "ओह! कुछ गड़बड़ है" दिखा रहा है जब मुझे एक ऑब्जेक्ट में कोई कुंजी नहीं मिलती। यह 500 स्टेटस के साथ बुरी तरह से टूटने वाले सर्वर से संदेश की तरह लगता है, लेकिन हमें पता है कि निश्चित रूप से यह गलत नहीं है।

मेरे लिए, मैं रेंडर फ़ंक्शन और डिफ़ॉल्ट पॉप्स के बीच संचार को संभालने के लिए कुछ नियम बना देता हूं:

मान लें कि हमारे पास माता-पिता से एक उपयोगकर्ता ऑब्जेक्ट पास है:

 defaultProps: { user: { avatar: { small: '' } } } 

रेंडर फ़ंक्शन में

 render() { const { user } = this.props; // if user.avatar is not defined or user.avatar.small is empty string or undefined then we render another component we have prepared for this situation. if (!user.avatar || !user.avatar.small) { return ( // components ... ); } // normal situation return ( // components ... ); } 

उपरोक्त उदाहरण स्ट्रिंग के लिए है और हमें अन्य डेटा प्रकारों के लिए अलग-अलग कार्यान्वयन की आवश्यकता है।

सौभाग्य।