Unlimited Plugins, WordPress themes, videos & courses! Unlimited asset downloads! From $16.50/m
Advertisement
  1. Code
  2. Vue
Code

Дизајн шеми за комуникација помеѓу Vue.js компонента

by
Difficulty:AdvancedLength:LongLanguages:

Macedonian (Македонски јазик) translation by Andrijana Mitevska (you can also view the original English article)

Како програмери, ние сакаме да произведеме податлив и одржувачки код, кој исто така е полесен за дебагирање и тестирање. За да го направите ова, ние ги донесуваме најдобрите практики познати како модели. Шаблони се докажани алгоритми и архитектури, кои ни помагаат да се направат конкретни задачи на ефикасен и предвидлив начин.

Во овој туторијал, ќе ги разгледаме најчестите Vue.js компонентни комуникациски модели, заедно со некои стапици што треба да ги избегнуваме. Сите знаеме дека, во реалниот живот, не постои единствено решение за сите проблеми. На ист начин, во развојот на апликација Vue.js, не постои универзален модел за сите програмски сценарија. Секоја шема има свои предности и недостатоци, и е погодна за конкретни случаи на употреба. Најважното нешто за програмерите на Vue.js е да ги знае сите најчести обрасци, за да можеме да го избереме вистинскиот за даден проект. Ова ќе доведе до правилна и ефикасна комуникација на компонентите.

Зошто е важна комуникацијата со соодветна компонента?

Кога ќе изградиме апликација со рамка базирана на компоненти како Vue.js, сакаме да ги направиме компонентите на нашата апликација изолирани како што можат. Ова ги прави еднократно, одржливо и тестирано. За да направите компонента еднократно, ние треба да ја обликуваме во апстрактна и раздвоена (или лабаво заедно) форма, и како таква, можеме да ја додадеме во нашата апликација или да ја отстраниме без да ја нарушиме функционалноста на апликацијата.

Сепак, не можеме да постигнеме целосна изолација и независност во компонентите на нашата апликација. Во одреден момент, тие треба да комуницираат едни со други: да разменуваат некои податоци, да ја менуваат состојбата на апликацијата итн. Значи, важно е да научиме како правилно да ја реализираме оваа комуникација додека сеуште го одржуваме апликацијата да работи, да биде флексибилна и да може да се приспособи.

Vue.js Преглед на компонентни комуникации

Во Vue.js, постојат два главни типа на комуникација помеѓу компонентите:

  1. Директна комуникација помеѓу родителот и детето, базирана на строги односи родител-дете и дете-до-родител.
  2. Меѓукомпонентна комуникација, во која една компонента може да "разговара" со кој било друг независно од нивната врска.

Во следните делови, ќе ги истражиме двата типа, заедно со соодветни примери.

Директно известување за родител-дете

Стандардниот модел на коммуникациска компонента, кој Vue.js го поддржува надвор од кутијата, е моделот родител-дете реализиран преку реквизити и сопствени настани. Во дијаграмот подолу, можете да видите визуелна претстава за тоа како овој модел изгледа во акција.

Како што можете да видите, родителот може да комуницира само со неговите директни деца, а децата само можат да комуницираат директно со нивниот родител. Во овој модел не е можна ниту една братска или меѓукомпонентна комуникација.

Во следните делови, ќе ги земеме компонентите од дијаграмот погоре и ќе ги имплементираме во низа практични примери.

Порака родител-дете

Да претпоставиме дека компонентите што ги имаме се дел од играта. Повеќето игри ја прикажуваат играта некаде во нивниот интерфејс. Замислете дека имаме променлива на резултат пријавена во компонентата Родител А, а ние сакаме да ја прикажеме во компонентата Child A. Значи, како можеме да го направиме тоа?

За да испраќа податоци од родител на своите деца, Vue.js користи реквизити. Постојат три неопходни чекори за да се пренесе сопственост:

  1. Регистрирање на имотот во детето, вака: реквизити: ["резултат"]
  2. Користејќи го регистрираниот имот во шаблонот на детето, вака: Резултат: {{резултат}}
  3. Врзување на имотот со променливата на резултат (во шаблонот на родителот), вака: <дете-а: резултат = "резултат" />

Ајде да истражиме целосен пример за подобро да разбереме што навистина се случува:

Пример за CodePen

Потврдување на реквизитите

За краткост и јасност, ги регистрирав реквизитите со користење на нивната стенографска варијанта. Но, во вистински развој, се препорачува да се проверат реквизитите. Ова ќе осигури дека реквизитите ќе добијат точен тип на вредност. На пример, нашата оценка на имотот може да биде валидирана вака:

Кога користите реквизити, бидете сигурни дека ја разбирате разликата помеѓу нивните буквални и динамички варијанти. Реквилитот е динамичен кога го поврзуваме со променлива (на пример, v-bind: score = "score" или нејзино стенографија: резултат = "резултат"), а со тоа вредноста на реквизитот ќе варира во зависност од вредноста на променливата. Ако само ставиме вредност без обврзувачка, тогаш таа вредност ќе се толкува буквално, а резултатот ќе биде статичен. Во нашиот случај, ако го напишеме резултатот = "резултат", тој ќе прикаже резултат наместо 100. Ова е буквален реквизит. Треба да внимавате на таа суптилна разлика.

Ажурирање на детето пропрат

Досега успешно го прикажавме резултатот од играта, но во одреден момент ќе треба да го ажурираме. Ајде да пробаме ова.

Создадовме метод changeScore (), кој треба да го ажурира резултатот откако ќе го притиснете копчето Change Score. Кога го правиме тоа, се чини дека резултатот е ажуриран правилно, но ние го добиваме следното предупредување за Vue во конзолата:

[Vue warn]: Избегнувајте мутирање на реквизит директно, бидејќи вредноста ќе се пребрише секогаш кога родителската компонента повторно ќе се појави. Наместо тоа, користете податоци или пресметана сопственост врз основа на вредноста на реквизитот. Пропуштање мутира: "резултат"

Како што можете да видите, Vue ни кажува дека реквизитот ќе биде препишан ако родителот повторно го рендерира. Ајде да го тестираме ова со симулирање на таквото однесување со вградениот метод $ forceUpdate ():

Пример за CodePen

Сега, кога ќе го смените резултатот и потоа притиснете го копчето Rerender Parent, можеме да видиме дека резултатот се враќа на неговата почетна вредност од родителот. Значи, Ву ја кажува вистината!

Сепак, имајте на ум дека низите и предметите ќе влијаат врз нивните родители, бидејќи тие не се копирани, туку се пренесуваат со референца.

Значи, кога треба да мутираме на реквизит кај детето, постојат два начини да се работи околу овој редефиниран несакан ефект.

Мутирајќи прост со локална податочна сопственост

Првиот метод е да го свртиме реквизитот на резултат во локален податочен простор (localScore), кој може да го користиме во методот changeScore () и во шаблонот:

Пример за CodePen

Сега, ако повторно го притиснеме копчето Пренасочување на родители, откако ќе го смениме резултатот, ќе видиме дека овој пат резултатот останува ист.

Мутирајќи прост со пресметана сопственост

Вториот метод е да се користи реквизитот на резултат во пресметаниот имот, каде што ќе се трансформира во нова вредност:

Пример за CodePen

Еве, создадовме пресметана doubleScore (), која го умножува резултатот на родителот за два, а потоа резултатот се прикажува во дефиниција. Очигледно, притискањето на копчето Пренасочување на родителите нема да има несакан ефект.

Комуникација од дете-до-родител

Сега, да видиме како компонентите можат да комуницираат спротивно.

Само што видовме како да мутираме реквизит кај детето, но што ако треба да го користиме овој реквизит во повеќе од една детска компонента? Во тој случај, ние ќе треба да мутираме на реквизитот од неговиот извор во родителот, така што сите компоненти кои го користат реквизитот ќе бидат ажурирани правилно. За да се задоволи ова барање, Vue воведува сопствени настани.

Принципот овде е тоа што ние го известуваме родителот за промената што сакаме да ја направиме, родителот не се менува и таа промена се рефлектира преку усвоениот поттик. Еве неопходни чекори за оваа операција:

  1. Во детето, ние емитираме настан кој ја опишува промената што сакаме да ја извршиме, како што е ова: ова. $ Emit ('updatingScore', 200)
  2. Во родителот, ние регистрираме слушател на настани за емитуваниот настан, на пример: @ updatingScore = "updateScore"
  3. Кога емитува настан, доделениот метод ќе го ажурира реквизитот, како што е ова: this.score = newValue

Да разгледаме целосен пример за подобро да разбереме како се случува ова:

Пример за CodePen

Го користиме вградениот метод $ emit () за емитување настан. Методот трае два аргументи. Првиот аргумент е настан што сакаме да го емитираат, а вториот е новата вредност.

Модификатор .sync

Vue нуди .sync модификатор кој работи слично, и ние можеби ќе сакаме да го користиме како кратенка во некои случаи. Во таков случај, ние го користиме методот $ emit () на малку поинаков начин. Како аргумент за настанот, го ставаме ажурирањето: резултат како ова: ова. $ Emit ('update: score', 200). Потоа, кога ќе го поврземе рејтинг на резултат, додаваме .sync модификатор вака: . Во компонентата "Родител А" го отстрануваме методот updateScore () и регистрацијата на настанот (@ updatingScore = "updateScore"), бидејќи повеќе не се потребни.

Пример за CodePen

Зошто да не го користите овој. $ Родител и оваа $ $ деца за директна родител-дете комуникација?

Vue нуди две API методи кои ни даваат директен пристап до родителските и детските компоненти: овој. $ Родител и оваа $ $ деца. Најпрво можеби е примамливо да ги искористиме како побрза и полесна алтернатива на реквизитите и настаните, но не треба. Ова се смета за лоша практика или анти-шема, бидејќи таа претставува тесна врска помеѓу родителите и децата компоненти. Вториот води кон нефлексибилни и лесно разбивачки компоненти, за кои тешко може да се дебагира и да се размислуваат. Овие API методи ретко се користат, и како правило, треба да ги избегнуваме или да ги користиме со претпазливост.

Двонасочна компонентна комуникација

Реквизитите и настаните се еднонасочни. Реквизитите одат надолу, настаните одат нагоре. Но, со користење на реквизитите и настаните заедно, можеме ефикасно да комуницираме нагоре и надолу на компонентото дрво, што резултира со двонасочна податоци обврзувачки. Ова е всушност она што директивата V-модел го прави внатрешно.

Меѓукомпонентни комуникации

Шаблонот за комуникација помеѓу родителите и децата брзо станува незгодно и непрактично, бидејќи комплексноста на нашиот стан расте. Проблемот со системот за реквизити е дека работи директно, и е цврсто поврзан со компонентото дрво. Вју настани не меур, за разлика од мајчин, и затоа ние треба да се повтори емитуваат нив додека не стигне до целта. Како резултат на тоа, нашиот код станува надуен со премногу слушатели на настани и емитери. Значи, во посложени апликации, треба да размислиме за користење на модел за комуникација меѓу компоненти.

Да го разгледаме дијаграмот подолу:

Како што можете да видите, во овој било кој тип на комуникација, секоја компонента може да испраќа и / или прима податоци од која било друга компонента без потреба од посредни чекори и посреднички компоненти.

Во следните делови, ќе ги испитаме најчестите имплементации на меѓукомпонентни комуникации.

Глобален автобус за настани

Глобален настан автобус е Vue пример, кој ние ги користиме за емитување и слушање на настани. Ајде да го видиме во пракса.

Пример за CodePen

Еве чекори за креирање и користење на автобус на настани:

  1. Објавувајќи го автобусот како нов Vue пример, на пример: const eventBus = new Vue ()
  2. Емитување на настанот од изворната компонента, на пример: eventBus. $ Emit ('updatingScore', 200)
  3. Слушањето на емитираниот настан во целните компоненти, како овој настанBus. $ On ('updatingScore', this.updateScore)

Во горенаведениот пример за код, ние го избришаме @ updatingScore = "updateScore" од детето, а наместо тоа го користиме куката за креирање на животниот циклус, за да го слушнете настанот updatingScore. Кога емитува настан, ќе се изврши методот updateScore (). Ние исто така можеме да го поминеме методот за ажурирање како анонимна функција:

Глобалниот модел на автобус за настани може да го реши проблемот со некаков напад до одреден степен, но воведува и други прашања. Податоците на апликацијата можат да се променат од кој било дел од апликацијата без да остават траги. Ова ја прави апликацијата потешко да се дебагира и тестира.За покомплексни апликации, каде што работите можат брзо да излезат од контрола, треба да размислиме за посветен модел на државен менаџмент, како што е Vuex, кој ќе ни даде повеќе фини зрачна контрола, подобра структура и организација на кодот и корисни функции за следење и дебагирање на промени .

Vuex

Vuex е државна библиотека за управување скроена за изградба на комплексни и скалабилни Vue.js апликации. Кодот напишан со Vuex е повеќе глагол, но ова може да се исплати долгорочно. Таа користи централизирана продавница за сите компоненти во апликацијата, со што нашите апликации се поорганизирани, транспарентни и лесни за следење и дебагирање. Продавницата е целосно реактивна, така што промените што ги правиме се рефлектираат веднаш.

Еве, ќе ви дадам кратко објаснување за тоа што е Vuex, плус контекстуален пример. Ако сакате да се нурнете подлабоко во Vuex, ви предлагам да ги погледнете моите посветени упатства за изградба на комплексни апликации со Vuex.

Да го разгледаме следниов дијаграм:

Како што можете да видите, апликацијата Vuex е направена од четири различни делови:

  • Државата е местото каде што ги држиме податоците од апликацијата.
  • Getters се методи за пристап до состојбата на продавницата и ја прикажуваат на компонентите.
  • Мутациите се вистински и единствени методи за мутирање на државата.
  • Акциите се методи за извршување на асинхронизирани кодови и активирање на мутации.

Ајде да создадеме едноставна продавница и да видиме како сето ова функционира во акција.

Пример за CodePen

Во продавницата имаме:

  • А променлива резултат во државниот објект.
  • Инкрементација () мутација (мутација), која ќе го зголеми резултатот со дадена вредност.
  • А резултат () getter, кој ќе пристапи до резултат променлива од државата и ќе го направи тоа во компоненти.
  • ИнкрементScoreAsync () акција, која ќе ја користи мутација на incrementScore () за да го зголеми резултатот по одреден временски период.

Во Vue пример, наместо реквизити, ние користиме пресметани својства за да ја добиеме вредноста на резултатот преку getters. Потоа, за да го смените резултатот, во компонентата Child A ние ја користиме мутацијата store.commit ('incrementScore', 100). Во компонентата Матичен Б, ние ја користиме акцијата store.dispatch ('incrementScoreAsync', 3000).

Зависност за ингеренција

Пред да завршиме, ајде да истражиме уште еден модел. Неговите случаи на употреба се главно за споделени компонентни библиотеки и приклучоци, но вреди да се спомене за комплетноста.

Инекцијата за зависност ни овозможува да дефинираме услуга преку обезбедување на својство, кое треба да биде објект или функција која враќа објект и да биде достапна за сите потомци на компонентата, а не само неговите директни деца. Потоа, можеме да ја консумираме таа услуга преку инјектирање на имотот.

Ајде да видиме ова во акција:

Пример за CodePen

Со користење на опцијата за обезбедување во компонентата Гранд родител, ние направивме променлива на резултатите достапни за сите нејзини потомци. Секој од нив може да добие пристап до него со прогласување на инјектирање: ['score'] сопственост. И, како што можете да видите, резултатот се прикажува во сите компоненти.

Забелешка: Ограничувањата што инјектирањето на зависност создава не се реактивни. Значи, ако сакаме промените направени во компонентата на услуги да се рефлектираат во неговите потомци, треба да му доделиме објект на својство на податоци и да го користиме тој објект во дадената услуга.

Зошто да не го користите овој. $ Root за крос-компонентни комуникации?

Причините поради кои не треба да го користиме овој корен. $ Root се слични на оние за овој. Родител и оваа. $ Деца опишани претходно - тоа создава премногу зависности. Потпирајќи се на било кој од овие методи за комуникација на компонентите мора да се избегнува.

Како да го изберете вистинскиот модел

Значи веќе ги знаете сите заеднички методи на комуникација на компонентите. Но, како можеш да одлучиш кој најдобро одговара на твоето сценарио?

Изборот на правилна шема зависи од проектот во кој сте вклучени или од апликацијата што сакате да ја изградите. Тоа зависи од сложеноста и видот на вашата апликација. Да ги испитаме најчестите сценарија:

  • Во едноставни апликации, реквизитите и настаните ќе бидат сите што ви требаат.
  • Апликациите од среден опсег ќе бараат пофлексибилни начини на комуникација, како на пример автобус на настани и инјекција на зависност.
  • За комплексни апликации од големи размери, дефинитивно ќе ви треба моќта на Vuex како целосно опремен државен систем за управување.

И последно нешто. Од вас не се бара да користите било кој од истражуваните обрасци само затоа што некој друг ви кажува да го сторите тоа. Слободно можете да изберете и да користите каква било шема што сакате, сѐ додека успеете да ја задржите апликацијата да работи и да ја одржувате и обемувате лесно.

Заклучок

Во ова упатство, ги научивме најчестите Vue.js компонентни комуникациски модели. Видовме како да ги имплементираме во пракса и како да го избереме вистинскиот, кој најдобро се вклопува во нашиот проект. Ова ќе осигури дека апликацијата што ја имаме изградена користи правилен тип на комуникација на компонентите што го прави целосно работен, одржува, тестира и може да се приспособи.

Advertisement
Advertisement
Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.