Cara mengkonfigurasi instalasi variabel lingkungan Nuxt.js di runtime, atau Cara melakukan semuanya tidak seperti semua orang dan tidak menyesalinya

( Ilustrasi )

Pengembang web senior, Anton dan Alexei, melanjutkan kisah perjuangan yang sulit dengan Nuxt. Di babak sebelumnya pertempuran dengan kerangka kerja ini, mereka menunjukkan cara meluncurkan proyek di Nuxt sehingga semua orang senang. Dalam artikel baru kita akan berbicara tentang aplikasi nyata dari framework.

Kami mulai menulis ulang proyek dengan hutang teknis yang besar. Audiens bulanan adalah 6-7 juta pengunjung unik, tetapi platform yang ada menyebabkan terlalu banyak masalah. Karena itu, diputuskan untuk mengirimnya ke masa pensiun. Tentu saja, kinerja adalah perhatian terbesar kami, tetapi saya juga tidak ingin menyia-nyiakan SEO.

Setelah beberapa putaran diskusi, mereka memutuskan untuk tidak bergantung pada pendekatan tradisional dengan hanya rendering sisi server - tetapi tidak untuk menjebak diri mereka dalam rendering sisi klien. Sebagai hasilnya, kami mulai membangun solusi berdasarkan Nuxt.js.

Nuxt.js tua yang bagus

Kami mengambil "framework for framework" berdasarkan Vue.js, yang sudah kami kenal di artikel terakhir, untuk membangun aplikasi universal client-server. Dalam kasus kami, aplikasi ini bekerja bersama dengan API yang agak rumit (seluk-beluk layanan microser, tetapi tentang beberapa waktu lainnya) dan beberapa lapisan caching, ia membuat konten yang dapat diedit oleh editor dan mengembalikan konten yang sudah statis untuk menghasilkan kinerja yang cepat. Bagus kan?

Padahal, tidak ada yang baru di sini. Tetapi yang membuat Nuxt.js menarik adalah kemampuan untuk memulai proyek dengan cepat dengan rendering client-server. Terkadang Anda perlu menentang kerangka kerja kerangka kerja yang sudah ada. Itu yang kami lakukan.

Tidak ada waktu untuk menjelaskan, membangun sekali, mengerahkan banyak!

Suatu hari suatu techlide mendekati kami dan bingung: setiap kali kami mendorong perubahan ke repositori, kami perlu membangun masing-masing lingkungan (dev, stage, dan prod-environment) secara terpisah. Itu lambat. Tapi apa perbedaan antara bangunan ini? Ya, hanya dalam variabel lingkungan! Dan apa yang dia minta terdengar logis dan masuk akal. Tetapi reaksi pertama kami adalah: O_o

Build sekali, gunakan banyak strategi masuk akal di dunia pengembangan perangkat lunak. Tetapi di dunia Javascript ... Kami memiliki banyak kompiler, transpiler, pra dan pasca prosesor, serta tes dan linter. Semua ini membutuhkan waktu untuk mengkonfigurasinya untuk masing-masing lingkungan. Selain itu, ada banyak potensi masalah kebocoran data rahasia (rahasia, kunci API, dll. Yang dapat disimpan dalam konfigurasi).

Dan kami mulai

Tentu saja, kami mulai dengan pencarian di Google. Kemudian kami berbicara dengan pengelola Nuxt.js, tetapi tidak berhasil. Apa yang harus dilakukan - saya harus menemukan solusi sendiri, dan tidak menyalinnya dari StackOverflow (ini adalah dasar dari kegiatan kami, kan?).

Mari kita cari tahu bagaimana Nuxt.js melakukannya.

Nuxt.js memiliki file konfigurasi dengan nama yang diharapkan nuxt.config.js. Ini digunakan untuk secara terprogram mentransfer konfigurasi ke aplikasi:

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

Dimungkinkan untuk mengatur lingkungan melalui variabel env. Secara umum, praktik yang cukup umum adalah menyambungkan file konfigurasi secara dinamis. Kemudian semua ini ditransfer ke webpack definePlugin dan dapat digunakan pada klien dan server, seperti ini:

process.env.propertyName
// atau
context.env.propertyName.

Variabel-variabel ini dipanggang selama perakitan, informasi lebih lanjut di sini: Halaman Nuxt.js env .
Pernahkah Anda memperhatikan webpack? Ya, itu berarti kompilasi, dan bukan itu yang kita inginkan.

Mari kita coba secara berbeda

Memahami cara kerja Nuxt.js berarti bagi kami:

• kita tidak bisa lagi menggunakan env di dalam nuxt.config.js;
• variabel dinamis lainnya (misalnya, di dalam head.meta) harus diteruskan ke objek nuxt.config.js di runtime.

Kode di server / index.js:

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

Ubah ke:

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

Di mana utils / extendedNuxtConfig.js:

 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 

Kami bahkan tidak memperhatikan gajah

Yah, kami memecahkan masalah mendapatkan variabel dinamis dari luar properti env dari objek konfigurasi di nuxt.config.js. Namun masalah aslinya masih belum terselesaikan.

Ada asumsi bahwa beberapa sharedEnv.js abstrak akan digunakan untuk:

• client - buat file env.js yang akan diunduh secara global (window.env.envKey),
• server - diimpor ke dalam modul, jika perlu,
• kode isomorfik, sesuatu seperti
  klien konteks? window.env [key]: global.shareEnv [key].

Entah bagaimana tidak hebat. Abstraksi ini akan memecahkan masalah yang paling serius - kebocoran data rahasia ke dalam aplikasi klien, karena akan perlu untuk menambahkan nilai secara sadar.

Vuex akan membantu kami

Saat menyelidiki masalah, kami perhatikan bahwa toko Vuex diekspor ke objek jendela. Solusi ini dipaksa untuk mendukung isomorfisme Nuxt, js. Vuex adalah gudang data yang terinspirasi oleh Flux yang dirancang khusus untuk aplikasi Vue.js.

Nah, mengapa tidak menggunakannya untuk variabel bersama kami? Ini adalah pendekatan yang lebih organik - data dalam repositori global cocok untuk kita.

Mari kita mulai dengan server / utils / sharedEnv.js:

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

Kode di atas akan dijalankan saat startup server. Kemudian tambahkan ke repositori 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()) } } } 

Kami akan mengandalkan fakta bahwa nuxtServerInit diluncurkan selama, hmm, inisialisasi server. Ada beberapa kesulitan: perhatikan metode getSharedEnv, di sini periksa untuk eksekusi berulang di server ditambahkan.

Apa yang terjadi

Sekarang kita sudah mendapatkan variabel umum yang dapat diekstraksi dalam komponen seperti ini:
ini. $ store.state.sharedEnv.canonicalDomain

Kemenangan!

Oh tidak Bagaimana dengan plugin?

Beberapa plugin memerlukan variabel lingkungan untuk dikonfigurasikan. Dan ketika kita ingin menggunakannya:
Vue.use (MyPlugin, {someEnvOption: 'Tidak ada akses ke toko vuex'})

Hebat, kondisi balapan, Vue.js mencoba menginisialisasi sendiri sebelum Nuxt.js mendaftar sharedEnvobject di repositori Vuex.

Meskipun fungsi yang mendaftarkan plugin menyediakan akses ke objek Konteks yang berisi tautan repositori, sharedEnv masih kosong. Ini dipecahkan dengan cukup sederhana - mari kita buat plugin sebagai fungsi async dan tunggu eksekusi 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 }) } 

Sekarang adalah kemenangan.