सिर्फ इसलिए React Components जोड़ना बंद करें क्योंकि आपको वे पसंद हैं

वह Heading जिसने यह सब शुरू किया

अभी हर जगह codebases में एक बातचीत चल रही है। कोई एक नया React component प्रस्तावित करता है। यह नुकसानरहित लगता है। लेकिन फिर कोई और पूछता है: क्या हमें सच में इसकी ज़रूरत है? जवाब अक्सर लोगों को चौंका देता है।

14 जुलाई, 2026 को पोस्ट किए गए एक लेख में, DEV Community के एक डेवलपर ने अपने codebase की एक architectural चर्चा का वर्णन किया। कुछ सहकर्मी एक नया Heading component पेश करना चाहते थे। कोड कुछ ऐसा दिखेगा:

<Heading level={3}>Profile Settings</Heading>

यह साफ है। यह semantic है। यह व्यवस्थित लगता है। लेकिन एक समस्या थी।

हमारे पास पहले से ही तीन समाधान हैं

टीम पहले से ही लिख सकती थी:

<h3>Profile Settings</h3>

और वे बिल्कुल इसी तरह की flexibility के लिए बनाए गए मौजूदा Text component का भी उपयोग कर सकते थे:

<Text as="h3">Profile Settings</Text>

तो चौथा तरीका क्यों जोड़ें? पूछने पर, जवाब ईमानदार था: "मुझे पसंद है कि हमारे पास एक अलग heading component हो।"

यह एक मानवीय कारण है। यह कोई बुरा कारण नहीं है। लेकिन यह एक engineering कारण नहीं है।

व्यक्तिगत पसंद (Personal Preference) कोई Design Principle नहीं है

Frontend टीमों को abstractions बहुत पसंद हैं। कभी-कभी थोड़ा बहुत ज़्यादा। Wrappers के ऊपर wrappers लगाए जाते हैं। उनके चारों ओर के wrappers को फिर से wrap किया जाता है। मूल HTML पहचानने लायक नहीं रह जाता है।

तर्क जाने-पहचाने लगते हैं: "यह अधिक साफ दिखता है।" "अधिक consistent लगता है।" "मुझे यह पसंद है।"

ये समझने योग्य हैं। इनसे जुड़ाव महसूस होता है। लेकिन ये कमज़ोर engineering तर्क हैं। यहाँ बताया गया है कि क्यों: हर नए component की कुछ कीमत होती है।

• लिखने के लिए Documentation
• Maintain करने के लिए Code
• Current रखने के लिए Tests
• Train करने के लिए नए developers
• चीज़ें बदलने पर Migration paths
• API overlap जो टीम को भ्रमित करता है

एक साझा codebase किसी का व्यक्तिगत sandbox नहीं है। हर abstraction आपकी टीम के दीर्घकालिक बोझ का हिस्सा बन जाता है। वह बोझ पसंद से अधिक मजबूत औचित्य का हकदार है।

HTML पहले से ही एक सावधानीपूर्वक डिज़ाइन किया गया API है

हम कभी-कभी इसे भूल जाते हैं। HTML primitive नहीं है। यह crude नहीं है। यह सोच-समझकर तैयार किया गया एक abstraction है जिसके ऊपर आप निर्माण कर सकते हैं—लेकिन हमेशा इसे बदल नहीं सकते।

headings को ही ले लीजिए। मूल hierarchy पहले से ही आपको देती है:

• Semantic अर्थ (h1, h3 से अधिक महत्वपूर्ण है)
• Accessibility सपोर्ट अंतर्निहित है
• Screen reader अनुकूलता
• SEO संदर्भ
• Document outline संरचना

इनमें से कोई भी side effect नहीं है। इसे standard में इंजीनियर किया गया है।

जब आप इसे इस तरह एक custom component में wrap करते हैं:

<Heading level={1}>Dashboard</Heading>
<Heading level={2}>Analytics</Heading>
<Heading level={3}>Revenue</Heading>

ज़्यादातर मामलों में आप आउटपुट में सुधार नहीं कर रहे होते हैं। आप बस syntax बदल रहे होते हैं। और बिना behavior बदले syntax बदलना शायद ही कभी कीमत के लायक होता है।

एक नियम जो सब कुछ बदल देता है

यहाँ वह सिद्धांत है जो इन निर्णयों का मार्गदर्शन करना चाहिए: syntax को abstract न करें। behavior को abstract करें।

बस इतना ही। यह एक अंतर अधिकांश अनावश्यक बहसों को समाप्त कर देता है।

एक बुरा abstraction मूल HTML की बहुत करीब से नकल करता है:

<Heading level={3}>Title</Heading>

यह बुरा क्यों है? क्योंकि यह ज्यादातर h3 की नकल करता है। यह कुछ भी नया नहीं जोड़ता है।

एक अच्छा abstraction वास्तविक behavior जोड़ता है:

<Text variant="muted" size="small" truncate>
  Description
</Text>

यह केंद्रीकृत (centralizes) करता है:

• Design token mapping
• Text truncation logic
• Theme consistency
• Responsive behavior

यही मूल्य (value) है। यह abstraction की कीमत के लायक है।

एक Concept के पास एक API होना चाहिए

codebases में भ्रम तेज़ी से फैलता है। यहाँ एक आदर्श प्रजनन स्थल (breeding ground) है:

<Heading level={3}>Profile</Heading>
<Text as="h3">Profile</Text>
<h3>Profile</h3>

एक ही चीज़ को लिखने के तीन तरीके। अब हर pull request एक style की बहस बन जाता है। "क्या हमें Heading या Text या मूल h3 का उपयोग करना चाहिए?" कोई वास्तव में नहीं जानता।

अच्छे सिस्टम विकल्प कम करते हैं। एक उपयोगी सिद्धांत: एक concept, एक API। यदि HTML पहले से ही semantics को संभालता है, तो उसे semantics का स्वामित्व रखने दें। यदि आपका Text component typography का स्वामित्व रखता है, तो उसे typography का स्वामित्व रखने दें। स्पष्ट अलगाव (separation)। स्पष्ट स्वामित्व (ownership)।

Composition, Abstraction को पछाड़ता है

सुविधाओं के हर संयोजन (combination) के लिए एक wrapper बनाने के बजाय, composition को प्राथमिकता दें।

इससे बचें:

<Heading level={2}>Billing Settings</Heading>

इसे प्राथमिकता दें:

<h2>
  <Text variant="secondary">
    Billing Settings
  </Text>
</h2>

आपको मिलता है:

• मूल HTML semantics (h2 का अभी भी वही अर्थ है जो h2 का है)
• पुन: प्रयोज्य (Reusable) typography tokens (Text संस्करण styling संभालता है)
• स्पष्ट जिम्मेदारी (h2 संरचना के लिए, Text दिखावट के लिए)
• कोई overlapping APIs नहीं
• कोई अस्पष्टता (ambiguity) नहीं

Composition abstraction की एक और परत की तुलना में अधिक लचीला (flexible) है और कम भ्रम पैदा करता है।

बनाने से पहले पाँच प्रश्न

एक नया component प्रस्तावित करने से पहले, खुद से पूछें:

1. यह वास्तव में किस समस्या का समाधान करता है? "अधिक साफ दिखता है" या "मुझे यह इस तरह पसंद है" नहीं। कुछ मापने योग्य (measurable), जैसे "accessible hierarchy लागू करता है" या "font size की असंगति (inconsistency) को रोकता है।"

2. क्या HTML पहले ही इसे हल कर देता है? यदि हाँ: आप इसे क्यों बदलेंगे? उस बोझ को गंभीर औचित्य की आवश्यकता है।

3. क्या यह जटिलता (complexity) को कम करता है? या क्या यह सिर्फ जटिलता को इधर-उधर ले जाता है और इसे एक component के अंदर छिपा देता है?

4. क्या यह API overlap लाता है? एक ही काम को करने के Overlapping तरीके असंगत (inconsistent) codebases बनाते हैं। यह एक कीमत है, सुविधा (feature) नहीं।

5. क्या यह behavior जोड़ता है? यदि component बिना behavior जोड़े सिर्फ syntax बदलता है, तो यह शायद मौजूद नहीं होना चाहिए।

निष्कर्ष (Conclusion)

हर दोहराया जाने वाला पैटर्न (repeated pattern) एक component के लायक नहीं होता। हर HTML तत्व को React wrapper की आवश्यकता नहीं होती। और हर पसंद एक साझा abstraction बनने के लायक नहीं होती। जो प्रश्न मायने रखता है वह यह है: क्या यह abstraction नई क्षमता बना रहा है, या सिर्फ नया syntax? इसका ईमानदारी से उत्तर दें, और आप अपने codebase को वर्षों की उस जटिलता से बचा लेंगे जिसकी वास्तव में किसी को आवश्यकता नहीं है।

गुण (Merits)

• यह तय करने के लिए मापने योग्य मानदंड (measurable criteria) प्रदान करता है कि components कब वास्तविक समस्याओं को हल करते हैं
• मूल HTML तत्वों की accessibility और semantic मूल्य को सुरक्षित रखता है
• एक ही कार्य को पूरा करने के कई तरीकों के कारण होने वाले टीम के भ्रम को कम करता है
• सिर्फ syntax बदलने के बजाय नया behavior जोड़ने पर component निर्माण को केंद्रित करता है
• Composition को प्रोत्साहित करता है, जो wrapper abstractions से अधिक लचीला है
• Codebases को अनावश्यक components की परतों के नीचे दबने से रोकने में मदद करता है

दोष (Demerits)

• जो Developers custom abstractions बनाना पसंद करते हैं, उन्हें यह दृष्टिकोण सीमित लग सकता है
• जिन Codebases में पहले से ही कई custom components हैं, उन्हें महत्वपूर्ण refactoring काम का सामना करना पड़ता है
• "behavior" बनाम "syntax" के रूप में क्या गिना जाता है, यह निर्धारित करने के लिए निरंतर टीम चर्चा और सहमति की आवश्यकता होती है
• Composition पैटर्न कभी-कभी hierarchical component संरचनाओं की तुलना में कम व्यवस्थित लगते हैं

सावधानी (Caution)

यह लेख एक प्रकाशित स्रोत से architectural सिद्धांतों की व्याख्या करता है। कोड उदाहरण उदाहरणात्मक हैं और placeholder JSX syntax का उपयोग करते हैं। इन सिद्धांतों को अपने स्वयं के codebase में लागू करने से पहले, मूल स्रोत के खिलाफ दावों को सत्यापित करें और मार्गदर्शन को अपनी टीम के विशिष्ट संदर्भ और मौजूदा पैटर्न के अनुकूल बनाएं। हर टीम की स्थिति अलग होती है; जो एक के लिए काम करता है उसे दूसरे के लिए समायोजन की आवश्यकता हो सकती है। नियमों को एकतरफा लागू करने के बजाय हमेशा अपनी टीम के साथ architectural निर्णयों पर चर्चा करें।

अक्सर पूछे जाने वाले प्रश्न (Frequently asked questions)

मुझे HTML का उपयोग करने के बजाय custom component कब बनाना चाहिए? — Components तब बनाएं जब वे design tokens, responsive logic, या केंद्रीकृत styling (centralized styling) जैसा behavior जोड़ते हैं। यदि component बिना लॉजिक जोड़े केवल syntax बदलता है, तो मूल HTML या composition आमतौर पर बेहतर काम करता है।

मैं अच्छे और बुरे abstractions के बीच का अंतर कैसे बताऊँ? — पूछें: क्या यह component किसी ऐसी समस्या को हल करता है जिसे HTML पहले से हल नहीं करता है? क्या यह behavior या लॉजिक को केंद्रीकृत करता है? यदि हाँ, तो यह शायद अच्छा है। यदि यह केवल क्षमता जोड़े बिना HTML को wrap करता है, तो यह शायद अनावश्यक है।

क्या होगा यदि मेरी टीम के पास पहले से ही बहुत सारे custom components हैं? — यह पहचान कर शुरू करें कि कौन से components वास्तविक behavior जोड़ते हैं और कौन से केवल HTML syntax को wrap करते हैं। उन लोगों को रखें जो वास्तविक समस्याओं को हल कर रहे हैं। केवल syntax वाले wrappers के लिए, धीरे-धीरे मूल HTML या composition में migrate करें।

Composition, wrapper components से बेहतर क्यों है? — Composition मूल HTML semantics को संरक्षित करता है, design tokens का स्पष्ट रूप से पुन: उपयोग करता है, और separation of concerns बनाए रखता है। यह अधिक लचीला भी है क्योंकि आप एक wrapper जो अनुमति देता है उसमें लॉक होने के बजाय छोटे केंद्रित टुकड़ों को जोड़ते हैं।

Design system consistency के बारे में क्या? — Design systems को wrappers बनाने के बजाय behavior और design tokens (colors, fonts, spacing) को परिभाषित करना चाहिए। Developers को उन tokens को मूल तत्वों या न्यूनतम abstractions के साथ compose करने दें।

मैं अपनी टीम को यह दृष्टिकोण कैसे समझाऊँ? — इसे भविष्य के components के लिए एक निर्णय ढांचे (decision framework) के रूप में प्रस्तुत करें, न कि मौजूदा की आलोचना के रूप में। हर component की लागत पर ध्यान दें: documentation, testing, और maintenance। इस बात पर सहमत हों कि किस तरह का behavior एक नया component जोड़ने को सही ठहराता है।

Tags

#react #frontend #architecture #components #webdev #designsystems #abstraction #codemaintenance