छोटे घटक: क्या गलत हो सकता है? हम एकमात्र जिम्मेदारी के सिद्धांत का उपयोग करते हैं

हम आपका ध्यान स्कॉट डोमेस के एक लेख का अनुवाद प्रस्तुत करते हैं, जो blog.bitsrc.io पर प्रकाशित हुआ था। कैट के तहत पता करें कि घटकों को यथासंभव छोटा क्यों होना चाहिए और एकमात्र जिम्मेदारी का सिद्धांत अनुप्रयोगों की गुणवत्ता को कैसे प्रभावित करता है।


फोटो ऑस्टिन कर्क अनस्प्लैश के साथ

रिएक्ट घटक प्रणाली (और इसी तरह के पुस्तकालयों) का लाभ यह है कि आपके यूआई को छोटे भागों में विभाजित किया जाता है जो पढ़ने में आसान और पुन: प्रयोज्य हैं।

ये घटक कॉम्पैक्ट (100-200 लाइनें) हैं, जो अन्य डेवलपर्स को आसानी से समझने और उन्हें संशोधित करने की अनुमति देता है।

यद्यपि घटक, एक नियम के रूप में, छोटे होने की कोशिश करते हैं, उनकी लंबाई पर कोई स्पष्ट, सख्त प्रतिबंध नहीं है। यदि आप अपने आवेदन को एक विशाल विशाल घटक में फिट करने का निर्णय लेते हैं, तो 3,000 लाइनों से मिलकर कोई प्रतिक्रिया नहीं होगी।

... लेकिन यह इसके लायक नहीं है। आपके अधिकांश घटक, सबसे अधिक संभावना है, पहले से ही बहुत अधिक चमकदार हैं - या बल्कि, वे बहुत अधिक कार्य करते हैं।

इस लेख में मैं यह साबित करूंगा कि अधिकांश घटकों (यहां तक ​​कि सामान्य 200-लाइन लंबाई के साथ) को अधिक संकीर्ण रूप से लक्षित किया जाना चाहिए। उन्हें केवल एक ही कार्य करना चाहिए, और इसे अच्छा प्रदर्शन करना चाहिए। यह वही है जो एडी उस्मानी यहाँ महान कहते हैं ।

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

आइए दिखाते हैं कि कैसे, घटक बनाते समय , कुछ गलत हो सकता है ।

हमारा ऐप

कल्पना करें कि हमारे पास ब्लॉगर्स के लिए एक मानक एप्लिकेशन है। और यहाँ मुख्य स्क्रीन पर क्या है:

class Main extends React.Component { render() { return ( <div> <header> // Header JSX </header> <aside id="header"> // Sidebar JSX </aside> <div id="post-container"> {this.state.posts.map(post => { return ( <div className="post"> // Post JSX </div> ); })} </div> </div> ); } } 

(यह उदाहरण, बाद के कई लोगों की तरह, छद्म कोड माना जाना चाहिए।)

यह शीर्ष पैनल, साइडबार और पदों की सूची प्रदर्शित करता है। सब कुछ सरल है।

चूंकि हमें पोस्ट डाउनलोड करने की भी आवश्यकता है, हम घटक के माउंट होने के दौरान यह कर सकते हैं:

 class Main extends React.Component { state = { posts: [] }; componentDidMount() { this.loadPosts(); } loadPosts() { // Load posts and save to state } render() { // Render code } } 

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

 class Main extends React.Component { state = { posts: [], isSidebarOpen: false }; componentDidMount() { this.loadPosts(); } loadPosts() { // Load posts and save to state } handleOpenSidebar() { // Open sidebar by changing state } handleCloseSidebar() { // Close sidebar by changing state } render() { // Render code } } 

हमारा घटक थोड़ा अधिक जटिल हो गया है, लेकिन अभी भी पढ़ने में आसान है।

यह तर्क दिया जा सकता है कि इसके सभी भाग एक उद्देश्य की पूर्ति करते हैं: आवेदन के मुख्य पृष्ठ को प्रदर्शित करना। इसलिए हम एकमात्र जिम्मेदारी के सिद्धांत का पालन करते हैं।

एकमात्र जिम्मेदारी का सिद्धांत कहता है कि एक घटक को केवल एक फ़ंक्शन को पूरा करना चाहिए। यदि हम wikipedia.org से ली गई परिभाषा में सुधार करते हैं, तो यह पता चलता है कि प्रत्येक घटक कार्यक्षमता के केवल एक भाग [आवेदन] के लिए जिम्मेदार होना चाहिए।

हमारा मुख्य घटक इस आवश्यकता को पूरा करता है। क्या समस्या है?

यहां सिद्धांत का एक अलग सूत्रीकरण है: किसी भी [घटक] में परिवर्तन का केवल एक कारण होना चाहिए ।

यह परिभाषा रॉबर्ट मार्टिन की पुस्तक रैपिड सॉफ्टवेयर डेवलपमेंट से ली गई है। सिद्धांत, उदाहरण, अभ्यास, ” और इसका बहुत महत्व है।

अपने घटकों को बदलने के लिए एक कारण पर ध्यान केंद्रित करके, हम बेहतर एप्लिकेशन बना सकते हैं जो कि इसके अलावा, कॉन्फ़िगर करना आसान होगा।

स्पष्टता के लिए, आइए हमारे घटक को जटिल करें।

उलझन

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

यह करना मुश्किल नहीं है!

 class Main extends React.Component { state = { posts: [], isSidebarOpen: false, postsToHide: [] }; // older methods get filteredPosts() { // Return posts in state, without the postsToHide } render() { return ( <div> <header> // Header JSX </header> <aside id="header"> // Sidebar JSX </aside> <div id="post-container"> {this.filteredPosts.map(post => { return ( <div className="post"> // Post JSX </div> ); })} </div> </div> ); } } 

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

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

 class Main extends React.Component { state = { posts: [], isSidebarOpen: false, postsToHide: [], isMobileSidebarOpen: false }; // older methods handleOpenSidebar() { if (this.isMobile()) { this.openMobileSidebar(); } else { this.openSidebar(); } } openSidebar() { // Open regular sidebar } openMobileSidebar() { // Open mobile sidebar } isMobile() { // Check if mobile device } render() { // Render method } } 

एक और छोटा सा बदलाव। नए नाम वाले तरीकों और नई संपत्ति का एक जोड़ा।

और यहाँ हम एक समस्या है। Main अभी भी केवल एक ही कार्य करता है (मुख्य स्क्रीन को प्रस्तुत करना), लेकिन आप इन सभी तरीकों को देखते हैं जो अब हम काम कर रहे हैं:

 class Main extends React.Component { state = { posts: [], isSidebarOpen: false, postsToHide: [], isMobileSidebarOpen: false }; componentDidMount() { this.loadPosts(); } loadPosts() { // Load posts and save to state } handleOpenSidebar() { // Check if mobile then open relevant sidebar } handleCloseSidebar() { // Close both sidebars } openSidebar() { // Open regular sidebar } openMobileSidebar() { // Open mobile sidebar } isMobile() { // Check if mobile device } get filteredPosts() { // Return posts in state, without the postsToHide } render() { // Render method } } 

हमारा घटक बड़ा और भारी हो जाता है, यह समझना मुश्किल है। और कार्यक्षमता के विस्तार के साथ, स्थिति केवल खराब हो जाएगी।

क्या गलत हुआ?

केवल कारण

आइए एकमात्र जिम्मेदारी के सिद्धांत की परिभाषा पर वापस जाएं: किसी भी घटक को परिवर्तन का केवल एक कारण होना चाहिए ।

पहले, हमने पोस्ट प्रदर्शित करने के तरीके को बदल दिया था, इसलिए हमें अपना मुख्य घटक बदलना पड़ा। अगला, हमने साइडबार को खोलने के तरीके को बदल दिया - और फिर से हमने मुख्य घटक को बदल दिया।

इस घटक में परिवर्तन के कई असंबंधित कारण हैं। इसका मतलब है कि यह बहुत सारे कार्य करता है ।

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

अधिक कुशल जुदाई

समाधान सरल है: आपको मुख्य घटक को कई भागों में विभाजित करने की आवश्यकता है। यह कैसे करना है?

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

 class Main extends React.Component { render() { return ( <Layout> <PostList /> </Layout> ); } } 

अद्भुत।

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

Layout पर चलते हैं:

 class Layout extends React.Component { render() { return ( <SidebarDisplay> {(isSidebarOpen, toggleSidebar) => ( <div> <Header openSidebar={toggleSidebar} /> <Sidebar isOpen={isSidebarOpen} close={toggleSidebar} /> </div> )} </SidebarDisplay> ); } } 

यह थोड़ा और जटिल है। Layout घटकों (साइड पैनल / टॉप पैनल) के प्रतिपादन के लिए लेआउट जिम्मेदार है। लेकिन हम प्रलोभन के आगे नहीं झुकेंगे और Layout को यह निर्धारित करने Layout जिम्मेदारी देंगे कि साइडबार खुला है या नहीं।

हम इस फ़ंक्शन को SidebarDisplay घटक में असाइन करते हैं, जो Header और Sidebar घटकों के लिए आवश्यक तरीकों या राज्य को पारित करता है।

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

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

 class Sidebar extends React.Component { isMobile() { // Check if mobile } render() { if (this.isMobile()) { return <MobileSidebar />; } else { return <DesktopSidebar />; } } } 

फिर, हम इस घटक में सीधे कंप्यूटर / मोबाइल उपकरणों के लिए JSX सम्मिलित करने के प्रलोभन का विरोध करते हैं, क्योंकि इस मामले में परिवर्तन के दो कारण होंगे।

आइए एक और घटक देखें:

 class PostList extends React.Component { state = { postsToHide: [] } filterPosts(posts) { // Show posts, minus hidden ones } hidePost(post) { // Save hidden post to state } render() { return ( <PostLoader> { posts => this.filterPosts(posts).map(post => <Post />) } </PostLoader> ) } } 

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

यदि हम पोस्ट लोड करने के तरीके को बदलते हैं, तो PostLoader ही बदल जाता है। और अंत में, Post तभी बदलता है जब हम पोस्ट को प्रस्तुत करने के तरीके को बदलते हैं।

निष्कर्ष

ये सभी घटक छोटे हैं और एक छोटा कार्य करते हैं। उनमें परिवर्तन के कारणों की पहचान करना आसान है, और घटकों को स्वयं परीक्षण किया जाता है और ठीक किया जाता है।

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

हम जानते हैं कि हमारे घटक समय के साथ बदलेंगे और बढ़ेंगे, लेकिन इस सार्वभौमिक नियम को लागू करने से आपको तकनीकी ऋण से बचने और टीम की गति बढ़ाने में मदद मिलेगी। घटकों को कैसे वितरित किया जाए यह आपके ऊपर है, लेकिन याद रखें - घटक को बदलने का केवल एक कारण होना चाहिए ।

आपका ध्यान के लिए धन्यवाद और आपकी टिप्पणियों के लिए तत्पर हैं!