Frontend Academy · पाठ

फ़ीचर-आधारित फ़ोल्डर संरचना

कोड को प्रकार के बजाय फ़ीचर डोमेन के अनुसार व्यवस्थित करें, टेस्ट, स्टाइल और कंपोनेंट को साथ रखें, और eslint-plugin-boundaries से सीमाएँ लागू करें।

पाठ 4, कुल 4 में से14 चरण

फ़ीचर-आधारित फ़ोल्डर संरचना, CoddyKit पर Frontend Academy का एक निःशुल्क पाठ है। यह 4 में से 4वाँ पाठ है। आप नीचे पूरा पाठ निःशुल्क पढ़ सकते हैं—फिर अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर के साथ ब्राउज़र में इसका व्यावहारिक अभ्यास कर सकते हैं। यह Frontend Academy सीखने के मार्ग का हिस्सा है और आपकी प्रगति वेब तथा CoddyKit ऐप पर सिंक होती रहती है। Frontend Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

कोड व्यवस्थित करने के दो तरीके

आप कोड को प्रकार के आधार पर (components/, hooks/, services/, types/) या फ़ीचर के आधार पर (auth/, checkout/, dashboard/ — जिनमें अपने components, hooks आदि होते हैं) समूहित कर सकते हैं। मध्यम से बड़े ऐप्स के लिए फ़ीचर-आधारित संरचना बेहतर है।

प्रकार-आधारित संरचना — डिफ़ॉल्ट जाल

क्लासिक React ट्यूटोरियल संरचना हर चीज़ को प्रकार के आधार पर समूहित करती है। यह बड़े स्तर पर ठीक से काम नहीं करती: हर फ़ाइल में बदलाव से कई असंबंधित फ़ोल्डर प्रभावित होते हैं, और ‘सारा चेकआउट कोड खोजें’ का अर्थ है पूरे ट्री में खोज करना।

// Type-based (avoid for large apps):
src/
  components/
    Button.tsx
    LoginForm.tsx
    CartItem.tsx
  hooks/
    useAuth.ts
    useCart.ts
  services/
    auth.ts
    cart.ts
  types/
    User.ts
    CartItem.ts

फ़ीचर-आधारित संरचना

किसी फ़ीचर से संबंधित हर चीज़ को एक ही फ़ोल्डर में रखें। इसे ढूँढना, हटाना और समझना आसान होता है।

src/
  features/
    auth/
      LoginForm.tsx
      SignupForm.tsx
      useAuth.ts
      auth.service.ts
      auth.types.ts
      auth.test.tsx
    cart/
      CartItem.tsx
      CartSummary.tsx
      useCart.ts
      cart.service.ts
      cart.types.ts
  shared/
    components/
      Button.tsx
    hooks/
      useDebounce.ts

फ़ीचर के भीतर सह-स्थान

एक फ़ीचर फ़ोल्डर में components, hooks, services, types और tests होते हैं — उस डोमेन के लिए आवश्यक पूरा कोड। कोई नया डेवलपर auth को समझना चाहता है? auth/ खोलें। auth हटाना चाहते हैं? फ़ोल्डर हटा दें।

साझा बनाम फ़ीचर कोड

2 या अधिक फ़ीचर्स द्वारा उपयोग किया जाने वाला कोड shared/ (या lib/) में ले जाएँ। केवल एक फ़ीचर द्वारा उपयोग किया जाने वाला कोड उसी के भीतर रखें। ‘बाद में शायद पुनः उपयोग हो’ जैसी सोच से बचें — निकालने से पहले दूसरे उपयोग की प्रतीक्षा करें।

फ़ीचर सीमा के नियम

फ़ीचर्स को एक-दूसरे से सीधे इम्पोर्ट नहीं करना चाहिए। यदि दो फ़ीचर्स को कोड साझा करना हो, तो साझा भाग को shared/ में ले जाएँ। यदि उन्हें समन्वय करना हो, तो ऐप स्तर पर इवेंट्स या साझा स्टोर का उपयोग करें।

ESLint से सीमाएँ लागू करना

यह लागू करने के लिए eslint-plugin-boundaries या eslint-plugin-import का उपयोग करें कि फ़ीचर्स shared से इम्पोर्ट कर सकते हैं, लेकिन एक-दूसरे से नहीं।

// .eslintrc.json
{
  "plugins": ["boundaries"],
  "settings": {
    "boundaries/elements": [
      { "type": "feature", "pattern": "src/features/*" },
      { "type": "shared",  "pattern": "src/shared/*" }
    ]
  },
  "rules": {
    "boundaries/element-types": ["error", {
      "default": "disallow",
      "rules": [
        { "from": "feature", "allow": ["shared"] },
        { "from": "shared",  "allow": ["shared"] }
      ]
    }]
  }
}

हर फ़ीचर का सार्वजनिक API

हर फ़ीचर features/auth/index.ts के माध्यम से सार्वजनिक API एक्सपोर्ट करता है। अन्य कोड गहरे पाथ के बजाय '@/features/auth' से इम्पोर्ट करता है। इससे उपभोक्ताओं को तोड़े बिना आंतरिक संरचना को पुनर्गठित किया जा सकता है।

// features/auth/index.ts
export { LoginForm } from './LoginForm';
export { useAuth } from './useAuth';
export type { User, AuthState } from './auth.types';

// Consumers:
import { LoginForm, useAuth } from '@/features/auth';
// NOT: import { LoginForm } from '@/features/auth/LoginForm';

उप-फ़ीचर्स को नेस्ट करना

बड़े फ़ीचर्स में उप-फ़ोल्डर हो सकते हैं: dashboard/widgets/, dashboard/charts/। 2–3 स्तर से अधिक गहराई तक नेस्ट करने से बचें — खोज करना बहुत कठिन हो जाता है।

रूट कहाँ रहते हैं

पेज या रूट शीर्ष-स्तरीय pages/ या routes/ फ़ोल्डर में रह सकते हैं। ये पतले होते हैं — फ़ीचर्स से components और hooks लेते हैं और उन्हें संयोजित करते हैं।

src/
  pages/
    Dashboard.page.tsx   // composes Dashboard widgets from features/dashboard/
    Cart.page.tsx        // composes from features/cart/
  features/
  shared/

मौजूदा ऐप को स्थानांतरित करना

केवल नए फ़ीचर्स से शुरुआत करें — नया कोड features/ में रखें। सब कुछ एक साथ पुनर्गठित न करें। पुराने फ़ाइलों पर काम करते समय उन्हें धीरे-धीरे स्थानांतरित करें। ESLint की सीमा संबंधी नियम नई संरचना में दोबारा आने वाली समस्याओं को रोकते हैं।

प्रकार-आधारित संरचना कब काम करती है

बहुत छोटे ऐप्स (30 से कम components) या लाइब्रेरी के लिए प्रकार-आधारित संरचना ठीक है। जैसे ही आपके पास अलग-अलग व्यावसायिक डोमेन (auth, checkout, billing, settings) हों, फ़ीचर-आधारित संरचना अपनाएँ।

त्वरित जाँच

फ़ाइल प्रकार के बजाय फ़ीचर के आधार पर कोड समूहित करने का मुख्य संगठनात्मक लाभ क्या है?

इंटरैक्टिव पाठ में इसका उत्तर दें

पुनरावलोकन: फ़ीचर-आधारित संरचना

features/ में डोमेन-विशिष्ट कोड होता है; shared/ में फ़ीचर्स के बीच उपयोग होने वाली उपयोगिताएँ होती हैं। हर फ़ीचर एक सार्वजनिक index.ts एक्सपोर्ट करता है। फ़ीचर्स एक-दूसरे से इम्पोर्ट नहीं करते — केवल shared से करते हैं। इसे eslint-plugin-boundaries से लागू करें। पेज और रूट फ़ीचर्स को संयोजित करते हैं। धीरे-धीरे स्थानांतरण करें। छोटे ऐप्स के लिए प्रकार-आधारित संरचना ठीक है।

शुरुआत निःशुल्क

एआई शिक्षक के साथ HTML सीखें — निःशुल्क

अपने ब्राउज़र में वास्तविक कोड लिखें और चलाएँ, चौबीसों घंटे एआई शिक्षक से तुरंत सहायता पाएँ, और वेब या ऐप पर वहीं से शुरू करें जहाँ आपने छोड़ा था।

पाठ्यक्रम: 41
पाठ: 163

निःशुल्क सीखना शुरू करें पूरा पाठ्यक्रम देखें

अक्सर पूछे जाने वाले प्रश्न

क्या “फ़ीचर-आधारित फ़ोल्डर संरचना” पाठ निःशुल्क है?

हाँ—“फ़ीचर-आधारित फ़ोल्डर संरचना” का पूरा पाठ यहाँ वेब पर निःशुल्क पढ़ा जा सकता है। इंटरैक्टिव अभ्यास (अंतर्निहित कोड संपादक और 24/7 एआई ट्यूटर) करने और Frontend Academy पाठ्यक्रम का बाकी हिस्सा अनलॉक करने के लिए CoddyKit PRO लें। Frontend Academy पाठ्यक्रम में कुल 4 पाठ शामिल हैं।

“फ़ीचर-आधारित फ़ोल्डर संरचना” में मैं क्या सीखूँगा?

कोड को प्रकार के बजाय फ़ीचर डोमेन के अनुसार व्यवस्थित करें, टेस्ट, स्टाइल और कंपोनेंट को साथ रखें, और eslint-plugin-boundaries से सीमाएँ लागू करें। आप ब्राउज़र में सीधे चलाए जाने वाले व्यावहारिक कोड के साथ Frontend Academy का अभ्यास करते हैं, और पाठ पूरा करते समय 24/7 एआई ट्यूटर आपके प्रश्नों के उत्तर देता है।

क्या Frontend Academy शुरू करने के लिए मुझे किसी अनुभव की आवश्यकता है?

पहले के अनुभव की आवश्यकता नहीं है। CoddyKit पर Frontend Academy शुरुआती से लेकर उन्नत शिक्षार्थियों तक सभी के लिए व्यवस्थित किया गया है, इसलिए आप यहीं से या शुरुआत से सीखना शुरू कर सकते हैं और अपनी गति से आगे बढ़ सकते हैं। यह 4 में से 4वाँ पाठ है।

“फ़ीचर-आधारित फ़ोल्डर संरचना” पाठ पूरा करने में कितना समय लगता है?

CoddyKit का अधिकांश पाठ लगभग 5–10 मिनट में पूरा हो जाता है। हर पाठ छोटा और संवादात्मक है, इसलिए आप लगातार प्रगति करते हैं और वेब या ऐप पर वहीं से सीखना जारी रख सकते हैं जहाँ आपने छोड़ा था।

क्या मैं इस Frontend Academy पाठ में कोड लिख और चला सकता हूँ?

हाँ। हर Frontend Academy पाठ में एक अंतर्निर्मित कोड संपादक शामिल है, जिससे आप सीधे अपने ब्राउज़र में वास्तविक कोड लिख और चला सकते हैं और तुरंत एआई प्रतिक्रिया पा सकते हैं—स्थानीय सेटअप की आवश्यकता नहीं है।

इस पाठ्यक्रम के सभी पाठ

एटॉमिक डिज़ाइन: एटम, मॉलिक्यूल, ऑर्गैनिज़्म
Turborepo के साथ मोनोरेपो सेटअप
माइक्रो-फ्रंटएंड: मॉड्यूल फ़ेडरेशन
फ़ीचर-आधारित फ़ोल्डर संरचना

← Frontend Academy पर वापस जाएँ