रनटाइम में Nuxt.js पर्यावरण चर की स्थापना को कैसे कॉन्फ़िगर करें, या सब कुछ कैसे करें और सभी को पछतावा नहीं है

( चित्रण )

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

हमने एक विशाल तकनीकी ऋण के साथ परियोजना को फिर से लिखना शुरू किया। मासिक दर्शक 6-7 मिलियन अद्वितीय आगंतुक थे, लेकिन मौजूदा मंच ने बहुत अधिक समस्याएं पैदा कीं। इसलिए, उसे सेवानिवृत्ति पर भेजने का फैसला किया गया था। बेशक, प्रदर्शन हमारी सबसे बड़ी चिंता थी, लेकिन मैं एसईओ को बर्बाद नहीं करना चाहता था।

कुछ दौर की चर्चा के बाद, उन्होंने केवल सर्वर-साइड रेंडरिंग के साथ पारंपरिक दृष्टिकोण पर भरोसा नहीं करने का फैसला किया - लेकिन क्लाइंट-साइड रेंडरिंग में खुद को फंसाने के लिए नहीं। परिणामस्वरूप, हमने Nuxt.js. पर आधारित एक समाधान का निर्माण शुरू किया

अच्छे पुराने Nuxt.js

हम सार्वभौमिक ग्राहक-सर्वर अनुप्रयोगों के निर्माण के लिए , पिछले लेख में पहले से ही ज्ञात V..s पर आधारित "फ्रेमवर्क के लिए रूपरेखा" लेते हैं । हमारे मामले में, एप्लिकेशन बल्कि जटिल एपीआई (microservices की पेचीदगियों, लेकिन उस समय के बारे में कुछ और) के साथ संयोजन के रूप में काम करता है, कैशिंग के कई परतों, यह संपादकों द्वारा संपादन योग्य सामग्री प्रदान करता है और बिजली के तेज प्रदर्शन के लिए पहले से ही स्थिर सामग्री देता है। महान, सही?

वास्तव में, यहां कुछ नया नहीं है। लेकिन क्या बनाता है Nuxt.js दिलचस्प है जल्दी से क्लाइंट-सर्वर रेंडरिंग के साथ एक परियोजना शुरू करने की क्षमता। कभी-कभी आपको रूपरेखा के स्थापित ढांचे के खिलाफ जाने की आवश्यकता होती है। यही हमने किया।

समझाने का समय नहीं, एक बार निर्माण करो, कई तैनात करो!

एक दिन एक टेकलीड ने हमसे संपर्क किया और हैरान रह गया: जब भी हम रिपॉजिटरी में बदलावों को आगे बढ़ाते हैं, तो हमें अलग-अलग वातावरण (देव-, मंच- और ठेस-वातावरण) में से प्रत्येक का निर्माण करने की आवश्यकता होती है। यह धीमा था। लेकिन इन बिल्ड्स के बीच अंतर क्या है? हाँ, केवल पर्यावरण चर में! और उन्होंने जो करने के लिए कहा वह तार्किक और उचित है। लेकिन हमारी पहली प्रतिक्रिया थी: O_o

बिल्ड एक बार, कई रणनीति तैनात सॉफ्टवेयर विकास की दुनिया में समझ में आता है। लेकिन जावास्क्रिप्ट दुनिया में ... हमारे पास कंपाइलर, ट्रांसपॉयलर, प्री- और पोस्ट-प्रोसेसर, साथ ही परीक्षण और लिंटर की पूरी बैटरी है। यह सब उन्हें प्रत्येक वातावरण के लिए कॉन्फ़िगर करने में समय लगता है। इसके अलावा, गोपनीय डेटा रिसाव (रहस्य, एपीआई कुंजी, आदि जो कॉन्फ़िगरेशन में संग्रहीत किए जा सकते हैं) की कई संभावित समस्याएं हैं।

और हमने शुरू किया

बेशक, हमने Google पर एक खोज के साथ शुरुआत की। फिर हमने Nuxt.js के रखरखाव के साथ बात की, लेकिन बहुत अधिक सफलता के बिना। क्या करना है - मुझे अपने आप पर एक समाधान के साथ आना था, और इसे स्टैकऑवरफ़्लो से कॉपी नहीं करना चाहिए (यह हमारी गतिविधि का आधार है, ठीक है?)।

चलो यह पता लगाते हैं कि Nuxt.js यह कैसे करता है।

Nuxt.js में अपेक्षित नाम nuxt.config.js के साथ एक कॉन्फ़िगरेशन फ़ाइल है। इसका उपयोग प्रोग्राम में कॉन्फ़िगरेशन को प्रोग्राम में ट्रांसफर करने के लिए किया जाता है:

const config = require('nuxt.config.js') const nuxt = new Nuxt(config) 

पर्यावरण को वैरिएबल के माध्यम से सेट करना संभव है। सामान्य तौर पर, कॉन्फ़िगरेशन फ़ाइल को गतिशील रूप से कनेक्ट करने के लिए एक काफी सामान्य अभ्यास है। तब यह सब डिफाइनप्लगिन वेबपैक में स्थानांतरित हो जाता है और क्लाइंट और सर्वर पर उपयोग किया जा सकता है, कुछ इस तरह से:

process.env.propertyName
// या
context.env.propertyName।

ये चर विधानसभा के दौरान बेक किए जाते हैं, अधिक जानकारी यहां: Nuxt.js env पेज ।
क्या आपने वेबपैक पर गौर किया है? हां, इसका मतलब संकलन है, और यह वह नहीं है जो हम चाहते हैं।

आइए अलग-अलग प्रयास करें

यह समझना कि Nuxt.js हमारे लिए कैसे काम करता है:

• अब हम nuxt.config.js के अंदर env का उपयोग नहीं कर सकते हैं;
• किसी भी अन्य गतिशील चर (उदाहरण के लिए, head.meta के अंदर) को रनटाइम में nuxt.config.js ऑब्जेक्ट को पास करना चाहिए।

सर्वर / index.js में कोड:

 const config = require('../nuxt.config.js') 

इसमें बदलें:

 //    Nuxt.js const config = require('./utils/extendedNuxtConfig.js').default 

जहां बर्तन / विस्तारित

 import config from 'config' import get from 'lodash/get' //   Nuxt.js const defaultConfig = require('../../nuxt.config.js') //   const extendedConfig = {} //   Nuxt.js const nuxtConfig = { ...defaultConfig, ...extendedConfig } //     //       if (get(nuxtConfig, 'head.meta')) { nuxtConfig.head.meta.push({ hid: 'og:url', property: 'og:url', content: config.get('app.canonical_domain') }) } export default nuxtConfig 

हमने हाथी को नोटिस भी नहीं किया

खैर, हमने nuxt.config.js में कॉन्फ़िगरेशन ऑब्जेक्ट की एनवी संपत्ति के बाहर से गतिशील चर प्राप्त करने की समस्या को हल किया। लेकिन मूल समस्या अभी भी हल नहीं हुई है।

एक धारणा थी कि कुछ सार साझा किए गए हैं।

• ग्राहक - एक env.js फ़ाइल बनाएँ जिसे विश्व स्तर पर डाउनलोड किया जाएगा (window.env.envKey),
• सर्वर - मॉड्यूल में आयात किया जाता है, जहां आवश्यक हो,
• समरूप कोड, कुछ इस तरह
  context.isClient? window.env [कुंजी]: Global.saringEnv [कुंजी]।

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

Vuex हमारी मदद करेगा

समस्या की जांच करते समय, हमने देखा कि Vuex स्टोर एक विंडो ऑब्जेक्ट को निर्यात किया जाता है। इस समाधान को न्यूक्स्ट, जेएस के समरूपता का समर्थन करने के लिए मजबूर किया जाता है। Vuex विशेष रूप से Vue.js अनुप्रयोगों के लिए डिज़ाइन किया गया एक फ़्लक्स-प्रेरित डेटा वेयरहाउस है।

ठीक है, हमारे साझा चर के लिए इसका उपयोग क्यों नहीं किया गया? यह एक अधिक कार्बनिक दृष्टिकोण है - एक वैश्विक भंडार में डेटा हमें सूट करता है।

आइए सर्वर / बर्तन / shareEnv.js से शुरू करें:

 import config from 'config' /** *  ,      *  ,     *  ,       * * @type {Object} */ const sharedEnv = { // ... canonicalDomain: config.get('app.canonical_domain'), } export default sharedEnv 

सर्वर स्टार्टअप के दौरान उपरोक्त कोड निष्पादित होगा। फिर इसे Vuex रिपॉजिटरी में जोड़ें:

 /** *   . *        * .   * https://nuxtjs.org/guide/vuex-store/#the-nuxtserverinit-action * * @return {Object} Shared environment variables. */ const getSharedEnv = () => process.server ? require('~/server/utils/sharedEnv').default || {} : {} // ... export const state = () => ({ // ... sharedEnv: {} }) export const mutations = { // ... setSharedEnv (state, content) { state.sharedEnv = content } } export const actions = { nuxtServerInit ({ commit }) { if (process.server) { commit('setSharedEnv', getSharedEnv()) } } } 

हम इस तथ्य पर भरोसा करेंगे कि nuxtServerInit, hmm, server initialization के दौरान लॉन्च किया गया है। कुछ कठिनाई है: getSedenEnv विधि पर ध्यान दें, यहां सर्वर पर बार-बार निष्पादन के लिए जांच को जोड़ा जाता है।

क्या हुआ?

अब हमें आम चर मिल गए हैं जिन्हें इस तरह से घटकों में निकाला जा सकता है:
यह। $ store.state.saredEnv.canonicalDomain

जीत!

अरे नहीं। प्लगइन्स के बारे में क्या?

कुछ प्लगइन्स को कॉन्फ़िगर करने के लिए पर्यावरण चर की आवश्यकता होती है। और जब हम उनका उपयोग करना चाहते हैं:
Vue.use (MyPlugin, {someEnvOption: 'vuexx' की कोई पहुंच नहीं है))

महान, दौड़ की स्थिति, Vue.js Nuxt.js द्वारा साझा किए जाने से पहले खुद को आरंभीकृत करने का प्रयास करता है।

हालाँकि जो फ़ंक्शन प्लगइन्स को पंजीकृत करता है, वह संदर्भ ऑब्जेक्ट को रिपॉजिटरी लिंक तक पहुंच प्रदान करता है, साझा किए गए ईएनवी अभी भी खाली है। यह काफी सरल रूप से हल किया गया है - चलो प्लगइन को एक async फ़ंक्शन करें और निष्पादित करने के लिए nuxtServerInit की प्रतीक्षा करें:

 import Vue from 'vue' import MyPlugin from 'my-plugin' /** *   MyPlugin . */ export default async (context) => { //  ,      sharedEnv await context.store.dispatch('nuxtServerInit', context) const env = { ...context.store.state.sharedEnv } Vue.use(MyPlugin, { option: env.someKey }) } 

अब जीत है।