JavaScript рамки / библиотеки като Vue могат да предложат фантастично потребителско изживяване при сърфиране в сайта ви. Повечето предлагат начин за динамична промяна на съдържанието на страницата, без да се налага да изпращате заявка до сървъра всеки път.
Има обаче проблем с този подход. При първоначалното зареждане на уебсайта ви браузърът не получава пълна страница за показване. Вместо това му се изпращат куп парчета за конструиране на страницата (HTML, CSS, други файлове) и инструкции за това как да ги съберете всички (рамка / библиотека на JavaScript) Отнема измеримо време, за да събере цялата тази информация заедно преди браузърът ви всъщност да има какво да покаже. Това е като да ви изпратят куп книги заедно с библиотека с плосък пакет. Първо ще трябва да построите библиотеката и след това да я напълните с книгите.
Решението за това е умно: Имайте версия на рамката / библиотеката на сървър които могат да създадат готова за показване страница. След това изпратете тази пълна страница до браузъра, заедно с възможността да правите допълнителни промени и все още да имате динамично съдържание на страницата (рамката / библиотеката), точно както изпращате готова библиотека заедно с някои книги. Разбира се, все още трябва да поставите книгите в библиотеката, но веднага имате нещо, което може да се използва.
Отвъд глупавата аналогия има и куп други предимства. Например страница, която рядко се променя, като страница „За нас“, не трябва да се пресъздава всеки път, когато потребителят я поиска. Така сървърът може да го създаде веднъж и след това да го кешира или да го съхрани някъде за бъдеща употреба. Този вид подобрения на скоростта може да изглеждат малки, но в среда, в която времето до отзивчивост се измерва в милисекунди (или по-малко), всяко малко малко е от значение.
е финансов директор на фирма
Ако искате повече информация за предимствата на SSR в среда на Vue, трябва да проверите Собствена статия на Vue за SSR . Има разнообразни възможности за постигане на тези резултати, но най-популярната, която също е препоръчани от екипа на Vue , Nuxt.
Защо Nuxt.js
Nuxt.js се основава на внедряване на SSR за популярната библиотека на React, наречена Next. След като видяха предимствата на този дизайн, подобно изпълнение беше проектирано за Vue, наречено Nuxt. Запознатите с комбинацията React + Next ще открият куп прилики в дизайна и оформлението на приложението. Nuxt обаче предлага специфични за Vue функции, за да създаде мощно, но гъвкаво SSR решение за Vue.
Nuxt беше актуализиран до готова за производство версия 1.0 през Януари 2018г и е част от активна и добре подкрепяна общност. Едно от чудесните неща е, че изграждането на проект с помощта на Nuxt не е толкова различно от изграждането на който и да е друг Vue проект. Всъщност той предоставя куп функции, които ви позволяват да създавате добре структурирани кодови бази за намалено време.
Друго важно нещо, което трябва да се отбележи, е Nuxt не трябва да се използва за SSR . Той се популяризира като рамка за създаване на универсални Vue.js приложения и включва команда (nuxt generate) за създаване на статично генерирани Vue приложения, използващи същата кодова база. Така че, ако се притеснявате да се потопите дълбоко в SSR, не се паникьосвайте. Винаги можете винаги да създадете статичен сайт, като същевременно се възползвате от функциите на Nuxt.
За да разберем потенциала на Nuxt, нека създадем прост проект. Крайният изходен код за този проект е хостван на GitHub ако искате да го видите, или можете вижте версия на живо създаден с помощта на nuxt generate и се хоства в Netlify.
Създаване на Nuxt проект
За да започнем, нека използваме генератор на проекти на Vue, наречен vue-cli за бързо създаване на примерен проект:
# install vue-cli globally npm install -g vue-cli # create a project using a nuxt template vue init nuxt-community/starter-template my-nuxt-project След като преминете през няколко опции, това ще създаде проект в папката my-nuxt-project или каквото сте посочили. Тогава просто трябва да инсталираме зависимости и да стартираме сървъра:
cd my-nuxt-project npm install # Or yarn npm run dev Ето. Отворете браузъра си за localhost:3000 и вашият проект трябва да работи. Не се различава много от създаването на проект на Vue Webpack. Когато обаче погледнем действителната структура на приложението, там няма много, особено в сравнение с нещо като шаблона Vue Webpack.
Търси в package.json също показва, че имаме само една зависимост, самият Nuxt. Това е така, защото всяка версия на Nuxt е пригодена да работи със специфични версии на Vue, Vue-router и Vuex и ги обединява за вас.
Има и nuxt.config.js файл в корена на проекта. Това ви позволява да персонализирате куп функции, които Nuxt предоставя. По подразбиране той задава заглавните маркери, цвета на лентата за зареждане и правилата на ESLint за вас. Ако искате да видите какво можете да конфигурирате, ето документацията ; ще разгледаме някои опции в тази статия.
как да направя игра в обработка
И така, какво е толкова специално в тези директории?
Оформление на проекта
Ако разглеждате създадените директории, всички те имат придружаващ Readme, в който се посочва кратко резюме на това, което влиза в тази директория, и често връзка към документите.
Това е едно предимство от използването на Nuxt: структура по подразбиране за вашето приложение. Всякакви добър разработчик отпред ще структурира приложение, подобно на това, но има много различни идеи за структурите и когато работите в екип, неизбежно ще влезе известно време в обсъждането или избора на тази структура. Nuxt предоставя такъв за вас.
Nuxt ще търси определени директории и ще изгради вашето приложение вместо вас в зависимост от това, което намери. Нека разгледаме тези директории един по един.
Страници
Това е единственото задължително директория. Всички Vue компоненти в тази директория се добавят автоматично към vue-router въз основа на техните имена на файлове и структурата на директориите. Това е изключително удобно. Обикновено така или иначе щях да имам отделна директория Pages и трябва ръчно да регистрирам всеки от тези компоненти в друг файл на рутера. Този файл на рутера може да стане сложен за по-големи проекти и може да се наложи разделяне, за да се запази четливостта. Вместо това Nuxt ще се справи с цялата тази логика вместо вас.
За демонстрация можем да създадем Vue компонент, наречен about.vue вътре в директорията Pages. Нека просто добавим прост шаблон като:
export default { layout: 'admin-layout' } Това е всичко. Компонентите на страницата ще използват default оформление, освен ако не е посочено, но когато навигирате до /admin, сега използва admin-layout.vue оформление. Разбира се, това оформление може да бъде споделено на няколко администраторски екрана, ако желаете. Важното нещо, което трябва да запомните, е оформленията трябва да съдържат елемент .
Има едно последно нещо, което трябва да се отбележи относно оформленията. Може да сте забелязали, докато експериментирате, че ако въведете невалиден URL адрес, ще ви се покаже страница за грешка. Тази страница за грешка всъщност е друго оформление. Nuxt има собствено оформление за грешка ( изходен код тук ), но ако искате да го редактирате, просто създайте error.vue оформление и това ще бъде използвано вместо това. Тук е предупреждението оформлението на грешката не трябва да има елемент . Също така ще имате достъп до error обект върху компонента с някаква основна информация за показване. (Това се отпечатва в терминала, изпълняващ Nuxt, ако искате да го разгледате.)
Middleware
Middleware са функции, които могат да бъдат изпълнени преди изобразяване на страница или оформление. Има различни причини, поради които може да искате да го направите. Охраната на маршрути е популярна употреба, при която можете да проверите хранилището на Vuex за валиден вход или да проверите някои параметри (вместо да използвате метода validate на самия компонент). Един проект, по който работих наскоро, използваше междинен софтуер за генериране на динамични галета въз основа на маршрута и параметрите.
Тези функции могат да бъдат асинхронни; само бъдете внимателни, тъй като нищо няма да се показва на потребителя, докато междинният софтуер не бъде разрешен. Те също имат достъп до Nuxt’s Context, което ще обясня по-късно.
Приставки
Тази директория ви позволява да регистрирате Vue плъгини преди създаването на приложението. Това позволява на приставката да бъде споделяна в цялото ви приложение на екземпляра на Vue и да бъде достъпна във всеки компонент.
Повечето основни приставки имат версия Nuxt, която може лесно да бъде регистрирана в екземпляра на Vue, като следвате техните документи. Все пак ще има обстоятелства, когато ще разработвате плъгин или трябва да адаптирате съществуващ плъгин за тази цел. Пример, който заемам от документите, показва как да направя това за vue-notifications. Първо, трябва да инсталираме пакета:
npm install vue-notifications --save След това създайте файл в директорията на приставките, наречен vue-notifications.js и включват следното:
import Vue from 'vue' import VueNotifications from 'vue-notifications' Vue.use(VueNotifications) Много подобно на това как бихте регистрирали приставка в нормална среда на Vue. След това редактирайте nuxt.config.js файл в корен на вашия проект и добавете следния запис към обекта module.exports:
plugins: ['~/plugins/vue-notifications'] Това е. Сега можете да използвате vue-notifications в цялото ви приложение. Пример за това е /plugin в примерния проект.
Така че завършва преглед на структурата на директориите. Може да изглежда много за научаване, но ако разработвате приложение Vue, вече настройвате същия вид логика. Nuxt помага да се абстрахира настройката и да ви помогне да се съсредоточите върху изграждането.
Nuxt обаче помага повече от развитието. То наддувки вашите компоненти, като предоставите допълнителна функционалност.
Nuxt’s Supercharged Components
Когато за първи път започнах да изследвам Nuxt, продължих да чета как са компонентите на Page компресор . Звучеше страхотно, но не беше веднага очевидно какво точно означава това и какви ползи носи.
заглавен файл c++ пример
Това означава, че всички компоненти на Page имат допълнителни методи, прикрепени към тях, които Nuxt може да използва за предоставяне на допълнителна функционалност. Всъщност вече видяхме едно от тях по-рано, когато използвахме validate метод за проверка на параметри и пренасочване на потребител, ако те са невалидни.
Двете основни, използвани в Nuxt проект, ще бъдат asyncData и fetch методи. И двете са много сходни по концепция, те се управляват асинхронно преди компонентът да бъде генериран и те могат да се използват за попълване на данните на компонент и хранилището. Те също така позволяват страницата да бъде изцяло изобразена на сървъра, преди да я изпрати на клиента, дори когато трябва да изчакаме някакво извикване на база данни или API.
Каква е разликата между asyncData и fetch?
asyncDataсе използва за попълване на данните на компонента Page. Когато върнете обект, той се обединява с изхода наdataпреди рендиране.fetchсе използва за попълване на Vuex Store. Ако върнете обещание, Nuxt ще изчака, докато бъде разрешено, преди да го направи.
Така че нека да ги използваме добре. Не забравяйте по-рано на /products/view страница имахме проблем, при който първоначалното състояние на магазина се показваше за кратко, докато беше направено нашето фалшиво API извикване? Един от начините да се коригира това е да има булево значение, съхранено на компонента или в Store, например loading = true и след това показване на компонент за зареждане, докато призоваването на API приключи. След това щяхме да зададем loading = false и покажете данните.
Вместо това нека използваме fetch за попълване на магазина преди рендиране. В нова страница, наречена /products/view-async, нека променим created метод за fetch; това трябва да работи, нали?
export default { fetch () { // Unfortunately the below line throws an error // because 'this.$store' is undefined... this.$store.dispatch('product/load') }, computed: {...} } Ето и уловката: Тези методи с „наддуване“ се изпълняват преди компонентът е създаден, така че this не сочи към компонента и нищо на него не може да бъде достъпно. И така, как да влезем в магазина тук?
API за контекст
Разбира се, има решение. Във всички методи на Nuxt ви се предоставя аргумент (обикновено първият), съдържащ изключително полезен обект, наречен Context. В това е всичко, за което ще ви е необходима препратка в приложението, което означава, че не е нужно първо да чакаме Vue да създаде тези препратки в компонента.
Силно препоръчвам да разгледате Контекстни документи за да видите какво е на разположение. Някои удобни са app, където можете да получите достъп до всичките си приставки, redirect, които могат да се използват за промяна на маршрути, error за показване на страницата за грешка и някои обясняващи се като route, query и store.
Така че, за достъп до Магазина, можем да деструктурираме Контекста и да извлечем Магазина от него. Също така трябва да се уверим, че връщаме обещание, така че Nuxt да може да изчака да се разреши, преди да изобрази компонента, така че трябва да направим и малка корекция на действието ни Store.
// Component export default { fetch ({ store }) { return store.dispatch('product/load') }, computed: {...} } // Store Action load ({ commit }) { return new Promise(resolve => { setTimeout(() => { commit('update', { _id: 1, title: 'Product', price: 99.99 }) resolve() }, 1000) }) } Можете да използвате async / await или други методи в зависимост от вашия стил на кодиране, но концепцията е същата - казваме на Nuxt да се увери, че извикването на API завършва и Store се актуализира с резултата преди опитвайки да изобразите компонента. Ако се опитате да навигирате до /products/view-async, няма да видите светкавицата на съдържание, където продуктът е в първоначалното си състояние.
Можете да си представите колко полезно може да бъде във всяко приложение на Vue дори без SSR. Контекстът също е достъпен за всички посредници както и към други Nuxt методи като NuxtServerInit което е специално действие на магазина, което се изпълнява преди инициализирането на Store (пример за това е в следващия раздел)
Съображения при използване на SSR
Сигурен съм, че мнозина (включително и аз), които започват да използват технология като Nuxt, докато я третират като всеки друг проект на Vue, в крайна сметка удрят стена, където нещо, което знаем, че обикновено работи, изглежда невъзможно в Nuxt. Тъй като повече от тези предупреждения са документирани, ще бъде по-лесно да се преодолеят, но основното нещо, което трябва да се има предвид при започване на отстраняване на грешки, е, че клиентът и сървърът са две отделни единици.
Когато първоначално отворите страница, се изпраща заявка до Nuxt, сървърът изгражда колкото е възможно повече от тази страница и останалата част от приложението и след това сървърът ви я изпраща. Тогава отговорността е на клиента да продължи с навигацията и да зарежда парчета, когато има нужда от тях.
Искаме сървърът първо да направи възможно най-много, но понякога няма достъп до информацията, от която се нуждае, което в резултат на това работата се извършва от страна на клиента. Или по-лошо, когато крайното съдържание, представено от клиента, се различава от това, което сървърът е очаквал, на клиента се казва да го възстанови от нулата. Това е голяма индикация, че нещо не е наред с логиката на приложението. За щастие в конзолата на браузъра ви ще се генерира грешка (в режим на разработка), ако това започне да се случва.
Нека вземем пример за това как да решим общ проблем, управление на сесии. Представете си, че имате приложение Vue, където можете да влезете в акаунт и сесията ви се съхранява с помощта на маркер (JWT, например), който решите да запазите localStorage Когато първоначално влезете в сайта, искате да удостоверите този маркер срещу API, който връща някаква основна потребителска информация, ако е валидна, и поставя тази информация в магазина.
за какво се използва scala
След като прочетете документите на Nuxt, виждате, че има удобен метод, наречен NuxtServerInit което ви позволява да асинхронно попълвате Store веднъж при първоначално зареждане. Това звучи перфектно! Така че създавате своя потребителски модул в магазина и добавяте подходящото действие в index.js файл в директорията Store:
export const actions = { nuxtServerInit ({ dispatch }) { // localStorage should work, right? const token = localStorage.getItem('token') if (token) return dispatch('user/load', token) } } Когато опресните страницата, получавате грешка, localStorage is not defined. Мислейки къде се случва това, има смисъл. Този метод се изпълнява на сървъра, той няма представа какво се съхранява в localStorage на клиента; всъщност дори не знае какво е „localStorage“! Така че това не е опция.
И така, какво е решението? Всъщност има няколко. Вместо това можете да накарате клиента да инициализира Store, но в крайна сметка да загуби предимствата на SSR, защото клиентът свършва цялата работа. Можете да настроите сесии на сървъра и след това да използвате това за удостоверяване на потребителя, но това е друг слой за настройка. Какво е най-подобно на localStorage метод вместо това използва бисквитки.
Nuxt има достъп до бисквитки, защото те се изпращат със заявката от клиента до сървъра. Както при другите методи на Nuxt, nuxtServerInit има достъп до контекста, този път като втори аргумент, защото първият е запазен за магазина. В контекста имаме достъп до req обект, който съхранява всички заглавки и друга информация от заявката на клиента. (Това ще бъде особено познато, ако сте използвали Node.js.)
Така че, след като вместо това съхраним маркера в бисквитка (в този случай наречен „токен“), нека да го осъществим на сървъра.
import Cookie from 'cookie' export const actions = { nuxtServerInit ({ dispatch }, { req }) '' if (token) return dispatch('user/load', token) } Просто решение, но такова, което може да не е веднага очевидно. Да се научим да мислим къде се случват определени действия (клиент, сървър или и двете) и до какво имат достъп отнема известно време, но ползите си заслужават.
Разгръщане
Внедряването с Nuxt е изключително просто. Използвайки една и съща кодова база, можете да създадете SSR приложение, приложение на една страница или статична страница.
Рендерирано приложение от страна на сървъра (SSR приложение)
Вероятно към това сте се стремили, когато сте използвали Nuxt. Основната концепция за разполагане тук е да стартирате build обработвайте на каквато и платформа да изберете и задайте няколко конфигурации. Ще използвам примера Heroku от документи :
Първо, настройте скриптове за Heroku в package.json:
'scripts': { 'dev': 'nuxt', 'build': 'nuxt build', 'start': 'nuxt start', 'heroku-postbuild': 'npm run build' } След това настройте средата Heroku, използвайки heroku-cli ( инструкции за настройка тук :
# set Heroku variables heroku config:set NPM_CONFIG_PRODUCTION=false heroku config:set HOST=0.0.0.0 heroku config:set NODE_ENV=production # deploy git push heroku master Това е. Сега вашето приложение SSR Vue е готово на живо, за да го види светът. Други платформи имат различни настройки, но процесът е подобен. Понастоящем изброените официални методи за разполагане са:
Приложение за една страница (SPA)
Ако искате да се възползвате от някои от допълнителните функции, които Nuxt предоставя, но избягвате сървъра да се опитва да изобразява страници, можете вместо това да разположите като SPA.
Първо, най-добре е да тествате приложението си без SSR, както по подразбиране npm run dev работи с включен SSR. За да промените това, редактирайте nuxt.config.js файл и добавете следната опция:
mode: 'spa', Сега, когато стартирате npm run dev, SSR ще бъде изключен и приложението ще работи като SPA за тестване. Тази настройка също така гарантира, че бъдещите компилации няма да включват SSR.
angular 5 урок за начинаещи стъпка по стъпка
Ако всичко изглежда добре, разполагането е точно същото като за приложението SSR. Само не забравяйте, че трябва да зададете mode: 'spa' първо да уведомите процеса на изграждане, че искате SPA.
Статични страници
Ако изобщо не искате да се занимавате със сървър и вместо това искате да генерирате страници за използване със статични хостинг услуги като Surge или Netlify, тогава това е опцията за избор. Само имайте предвид, че без сървър няма да имате достъп до req и res в контекста, така че ако вашият код разчита на това, не забравяйте да го приспособите. Например, когато се генерира примерният проект, nuxtServerInit функция извежда грешка, защото се опитва да извлече маркер от бисквитките в заглавките на заявката. В този проект няма значение, тъй като тези данни не се използват никъде, но в реално приложение ще трябва да има алтернативен начин за достъп до тези данни.
След като това е подредено, внедряването е лесно. Едно нещо, което вероятно ще трябва да промените първо, е да добавите опция, така че nuxt generate команда също ще създаде резервен файл. Този файл ще подкани хостинг услугата да позволи на Nuxt да се справи с маршрутизацията, а не с хостинг услугата, като изведе грешка 404. За целта добавете следния ред към nuxt.config.js:
generate: { fallback: true }, Ето пример за използване на Netlify, който в момента не е в документите Nuxt. Само имайте предвид, че ако за първи път използвате netlify-cli, ще бъдете подканени да удостоверите:
# install netlify-cli globally npm install netlify-cli -g # generate the application (outputs to dist/ folder) npm run generate # deploy netlify deploy dist Толкова е просто! Както бе споменато в началото на статията, има версия на този проект тук . Има и официална документация за внедряване на следните услуги по-долу:
Научете повече
Nuxt се актуализира бързо и това е само малка селекция от функциите, които предлага. Надявам се тази статия да ви насърчи да я изпробвате и да видите дали тя може да помогне за подобряване на възможностите на вашите Vue приложения, позволявайки ви да се развивате по-бързо и да се възползвате от мощните му функции.
Ако търсите повече информация, не търсете повече от официалните връзки на Nuxt:
Търсите ли вашата игра на JavaScript? Опитайте да прочетете Изчерпателното ръководство за модели за дизайн на JavaScript от колегата ApeeScapeer Марко Мишура.
Разбиране на основите
Какво е Vue.js?
Vue.js (или просто Vue) е JavaScript рамка, създадена да бъде лека и лесна за научаване, но достатъчно мощна за работа с големи приложения. Тя ви позволява да разработвате богато интерактивни уеб приложения, които могат да осигурят превъзходно потребителско изживяване.
Какво е Nuxt?
Nuxt е рамка за създаване на универсални Vue приложения. Това означава, че той осигурява структура за вашия проект, обработва по-сложната конфигурация на сървъра за вас и позволява същата кодова база да бъде внедрена в различни среди.
Vue и Nuxt отворени ли са?
Да, и двете им кодови бази са публично видими в GitHub и са в непрекъснато развитие. И двамата имат основни екипи и са подкрепяни от техните общности. Проблемите се проследяват там и всеки е добре дошъл да предложи подобрения или да подаде заявка за изтегляне.
Какво означава клиентска и сървърна страна?
Клиентската страна се отнася до устройството, което се използва за заявяване и в крайна сметка показване на уеб страницата, например браузъра на вашия компютър / таблет / телефон, когато преглеждате уебсайт. Сървърната страна се отнася до сървъра, който получава заявката за уеб страница и изпраща съответните файлове, за да я покаже.
Какви са предимствата на изобразяването от страна на сървъра?
SSR осигурява по-добра SEO, по-бързо първоначално зареждане и възможност за кеширане на страници, но като цяло означава повече заявки на сървъра и пълно презареждане на страници. Комбинирането на SSR с предимствата на рамка от страна на клиента (като Vue) предлага богато взаимодействие с потребителите и актуализации на DOM на място, което прави Nuxt чудесно решение.
Какво се разбира под виртуален DOM?
Рамки като Vue.js позволяват частични актуализации на обектния модел на документ на уеб страница (DOM). Директните актуализации на DOM обаче са скъпи във времето, така че вместо Vue.js 2.0 виртуално копие на DOM се съхранява в паметта, там първо се правят промени и ефективната актуализация периодично добавя тези промени към реалния DOM.
