• कोडबेस का बड़ा होना = उसे समझना भी कठिन, और उसमें बदलाव करना भी कठिन

  • समाधान क्या है? कोडबेस को छोटा बनाए रखें.

  • डोमेन के आधार पर कोडबेस को अलग करना & micro frontend मदद के लिए!

  • monorepo के भीतर लाइब्रेरी dependency relation सेट करना & dependencies की जाँच जैसी ज़रूरतों को Nx अपनाकर हल किया गया

  • कोड को application और library में अलग करना

  • application की भूमिका dependency और configuration injection की है

  • अधिकांश functionality लाइब्रेरी में implement की जाती है

    • लाइब्रेरी में न सिर्फ सामान्य रूप से उपयोग किए जा सकने वाले design system, internationalization, third-party modules, बल्कि home page का hero banner, product detail page, order history जैसे non-reusable code भी लिखे जाते हैं.

Feature लाइब्रेरी

  • मूल रूप से, किसी एक page में उपयोग होने वाले सभी components उसी नाम की Feature लाइब्रेरी में लिखे जाते हैं

    • उदाहरण) account डोमेन के SignInPage पेज के सभी components account/feature-sign-in लाइब्रेरी में लिखे जाते हैं
  • एक ही डोमेन के दो या अधिक pages में साझा होने वाले components को उसी डोमेन के भीतर अलग feature में विभाजित किया जाता है

    • उदाहरण) अगर account डोमेन के SignInPage और SignUpPage में KakaoLoginButton component कॉमन रूप से उपयोग होता है, तो वह component account/feature-social-login लाइब्रेरी में लिखा जाता है
  • अलग-अलग डोमेनों के pages में साझा होने वाले components को shared डोमेन के भीतर अलग feature में विभाजित किया जाता है

    • उदाहरण) landing डोमेन के HomePage और classroom डोमेन के LecturePage में साझा होने वाला GlobalNavigation component shared/feature-navigation लाइब्रेरी में लिखा जाता है

Shell लाइब्रेरी

  • Feature, UI लाइब्रेरी के components को संयोजित करके pages बनाए जाते हैं

    • उदाहरण) SignInPage component account/shell-kr-web लाइब्रेरी का component है. इसमें SignUpPage, PhoneVerificationPage आदि शामिल हैं.
  • Shell लाइब्रेरी application को दिए जाने वाले किसी विशेष डोमेन का entry point है

  • हर application के लिए अलग entry point दिया जा सकता है

    • उदाहरण के लिए..

    • HomePage component में उपयोग होने वाले components landing/feature-home लाइब्रेरी में लिखे गए हैं.

    • लेकिन वही HomePage भी इस पर निर्भर करते हुए अलग हो सकता है कि वह US site का HomePage है, Japan site का HomePage है, या Korea site का HomePage है.

    • इसलिए landing डोमेन तक पहुँचने वाले हर application के लिए अलग shell लाइब्रेरी बनाई जा सकती है. (shell-us-web, shell-jp-web, shell-kr-web)

Provider लाइब्रेरी

  • ऐसी लाइब्रेरी जो दो या अधिक Feature लाइब्रेरी के बीच साझा state को manage करती है

    • उदाहरण) login state को manage करने वाला shared/provider-auth-state

UI लाइब्रेरी

  • दो या अधिक लाइब्रेरी में साझा होने वाले presentational components का संग्रह.

Utility लाइब्रेरी

  • वे सभी modules जो ऊपर की 4 श्रेणियों में नहीं आते

  • इन्हें CLASS101 के domain model से असंबंधित, और test व deploy किए जा सकने लायक स्वतंत्र functionality देनी चाहिए.

    • उदाहरण) shared/utils-apollo-client, shared/utils-i18n

Application

  • यह केवल configuration और dependency management की भूमिका निभाता है = application का code लगभग नहीं के बराबर होता है

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.