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

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



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

भाग 1: बड़े पैमाने पर प्रतिक्रिया अनुप्रयोगों को विकसित करने के लिए व्यावहारिक दिशानिर्देश। योजना, कार्य, डेटा स्रोत और एपीआई

भाग 2: बड़े पैमाने पर प्रतिक्रिया अनुप्रयोगों को विकसित करने के लिए व्यावहारिक दिशानिर्देश। भाग 2: राज्य प्रबंधन, मार्ग

आयोजन

अक्सर, डेवलपर्स एप्लिकेशन पर काम के इस चरण को छोड़ देते हैं। यह इस तथ्य के कारण है कि नियोजन प्रक्रिया के दौरान कोड लिखने पर कोई काम नहीं किया जाता है। लेकिन इस कदम के महत्व को कम करके नहीं आंका जा सकता। आप जल्द ही सीखेंगे कि ऐसा क्यों है।

Applications अनुप्रयोगों को विकसित करते समय आप क्यों योजना बनाते हैं?

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

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

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

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

EpStep 1: पृष्ठ और घटक

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


पृष्ठ लेआउट ( यहां से लिया गया )

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

EpStep 2: कार्यों और घटनाओं

आपके द्वारा आवेदन के घटकों पर निर्णय लेने के बाद, इस बारे में सोचें कि उनमें से प्रत्येक में क्या कार्य किए जाएंगे। बाद में, इन घटकों से, इन कार्यों को भेजा जाएगा।

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


ऑनलाइन स्टोर होमपेज का उदाहरण ( यहां से लिया गया )

इस एप्लिकेशन में, Product अनुभाग में घटक जो कार्रवाई करता है उसे getItems कहा जाता है। इस पृष्ठ पर शामिल की जा सकने वाली कुछ अन्य गतिविधियाँ getUserDetails , getSearchResults और इसी तरह शामिल हो सकती हैं।

EpStep 3: डेटा और मॉडल

आवेदन के प्रत्येक घटक के साथ कुछ डेटा जुड़ा हुआ है। यदि एक ही डेटा का उपयोग कई एप्लिकेशन घटकों द्वारा किया जाता है, तो वे एक केंद्रीकृत राज्य वृक्ष का हिस्सा होंगे। राज्य के पेड़ को Redux का उपयोग करके प्रबंधित किया जाता है।

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

अपने एप्लिकेशन के समान डेटा की एक सूची बनाएं। यह एक मॉडल आरेख बन जाएगा। इस सूची के आधार पर, रिड्यूसर बनाना संभव होगा।

 products: {  productId: {productId, productName, category, image, price},  productId: {productId, productName, category, image, price},  productId: {productId, productName, category, image, price}, } 

आइए एक ऑनलाइन स्टोर के साथ उपरोक्त उदाहरण पर लौटते हैं। अनुशंसित उत्पाद और नए उत्पाद अनुभाग व्यक्तिगत उत्पादों ( product जैसे कुछ) का प्रतिनिधित्व करने के लिए उपयोग किए जाने वाले समान डेटा प्रकार का उपयोग करते हैं। यह प्रकार एक अनुप्रयोग रिड्यूसर बनाने के लिए आधार के रूप में काम करेगा।

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

क्रियाएँ, डेटा स्रोत और API

जैसे-जैसे आपका एप्लिकेशन बढ़ता है, अक्सर ऐसा होता है कि अत्यधिक संख्या में तरीके Redux रिपॉजिटरी से जुड़े होते हैं। ऐसा होता है कि निर्देशिका संरचना बिगड़ती है, आवेदन की वास्तविक आवश्यकताओं से प्रस्थान करती है। यह सब बनाए रखना मुश्किल हो जाता है, एप्लिकेशन में नई सुविधाओं को जोड़ना अधिक जटिल हो जाता है।

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

▍ एपीआई डिजाइन और ग्राहक अनुप्रयोग

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

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

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

 export function formatTweet (tweet, author, authedUser, parentTweet) {  const { id, likes, replies, text, timestamp } = tweet  const { name, avatarURL } = author  return {    name,    id,    timestamp,    text,    avatar: avatarURL,    likes: likes.length,    replies: replies.length,    hasLiked: likes.includes(authedUser),    parent: !parentTweet ? null : {      author: parentTweet.author,      id: parentTweet.id,    } 

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

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

अब आइए उन एप्लिकेशन के उन हिस्सों के बारे में बात करते हैं जो एपीआई में कॉल करने के लिए जिम्मेदार हैं।

। डेटा स्रोतों के साथ काम का संगठन

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

• एक एजेंट (कूरियर) के उपयोग के बिना।
• एजेंट का उपयोग करना।

एक एजेंट का उपयोग किए बिना एक रिपॉजिटरी डिजाइन करना

इस दृष्टिकोण के साथ, भंडारण के विन्यास के दौरान, प्रत्येक मॉडल के लिए GET , POST और PUT अनुरोधों को निष्पादित करने के लिए तंत्र अलग-अलग बनाए जाते हैं।


घटक एक एजेंट का उपयोग किए बिना एपीआई के साथ बातचीत करते हैं

पिछले आरेख से पता चलता है कि प्रत्येक घटक विभिन्न डेटा स्टोर से तरीकों को लागू करने वाले कार्यों को भेजता है। यहां बताया गया है कि, इस दृष्टिकोण के साथ, BlogApi फ़ाइल से updateBlog विधि दिखाई देगी:

 function updateBlog(blog){   let blog_object = new BlogModel(blog)   axios.put('/blog', { ...blog_object })  .then(function (response) {    console.log(response);  })  .catch(function (error) {    console.log(error);  }); } 

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

Rep अभिकर्ता का उपयोग कर भंडार का डिजाइन तैयार करना

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


घटक एक एजेंट का उपयोग करके एपीआई के साथ बातचीत करते हैं

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

 export default function courier(query, payload) {   let path = `${SITE_URL}`;   path += `/${query.model}`;   if (query.id) path += `/${query.id}`;   if (query.url) path += `/${query.url}`;   if (query.var) path += `?${QueryString.stringify(query.var)}`;     return axios({ url: path, ...payload })     .then(response => response)     .catch(error => ({ error })); } 

आधार courier विधि के लिए कोड courier । सभी एपीआई हैंडलर इसे कॉल कर सकते हैं, इसे निम्नलिखित डेटा पास कर सकते हैं:

• URL से संबंधित जानकारी वाली ऑब्जेक्ट का अनुरोध करें। उदाहरण के लिए, मॉडल का नाम, क्वेरी स्ट्रिंग, और इसी तरह।
• पेलोड जिसमें अनुरोध हेडर और उसका शरीर है।

▍ एपीआई कॉल और आंतरिक कार्यों को अनुप्रयोग

Redux के साथ काम करते समय, पूर्वनिर्धारित क्रियाओं के उपयोग पर विशेष ध्यान दिया जाता है। यह एप्लिकेशन में होने वाले डेटा परिवर्तनों को पूर्वानुमेय बनाता है।

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

 export const BOOK_ACTIONS = {   GET:'GET_BOOK',   LIST:'GET_BOOKS',   POST:'POST_BOOK',   UPDATE:'UPDATE_BOOK',   DELETE:'DELETE_BOOK', } export function createBook(book) {   return {      type: BOOK_ACTIONS.POST,   book  } export function handleCreateBook (book) {   return (dispatch) => {      return createBookAPI(book)         .then(() => {            dispatch(createBook(book))         })         .catch((e) => {            console.warn('error in creating book', e);            alert('Error Creating book')         })  } export default {   handleCreateBook, } 

ऊपर कोड स्निपेट Redux कार्यों के साथ createBookApi डेटा स्रोत विधियों का उपयोग करने का एक सरल तरीका दिखाता है। createBook विधि को आसानी से Redux dispatch विधि में पारित किया जा सकता है।

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

परिणाम

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

प्रिय पाठकों! आप रिएक्ट एप्लिकेशन कहां से विकसित करना शुरू करते हैं?