Žiniatinklio komponentų projektavimo modeliai: kuriame pakartotinai naudojamą komponentų architektūrą

Žiniatinklio komponentai yra galingas žiniatinklio standartų rinkinys, leidžiantis kūrėjams kurti pakartotinai naudojamus, inkapsuliuotus HTML elementus, skirtus naudoti žiniatinklio programose ir žiniatinklio puslapiuose. Tai skatina kodo pakartotinį naudojimą, prižiūrimumą ir nuoseklumą įvairiuose projektuose ir platformose. Tačiau vien tik naudojant žiniatinklio komponentus automatiškai negarantuojama gerai struktūruota ar lengvai prižiūrima programa. Štai čia atsiranda projektavimo modeliai. Taikydami nusistovėjusius projektavimo principus, galime kurti patikimas ir keičiamo dydžio komponentų architektūras.

Kodėl verta naudoti žiniatinklio komponentus?

Prieš pasinerdami į projektavimo modelius, trumpai apžvelkime pagrindinius žiniatinklio komponentų privalumus:

• Pakartotinis naudojimas: Sukurkite pasirinktinius elementus vieną kartą ir naudokite juos bet kur.
• Inkapuliavimas: Shadow DOM suteikia stiliaus ir scenarijų izoliaciją, apsaugančią nuo konfliktų su kitomis puslapio dalimis.
• Sąveikumas: Žiniatinklio komponentai sklandžiai veikia su bet kuriuo JavaScript karkasu ar biblioteka arba net be karkaso.
• Prižiūrimumas: Gerai apibrėžtus komponentus lengviau suprasti, išbandyti ir atnaujinti.

Pagrindinės žiniatinklio komponentų technologijos

Žiniatinklio komponentai yra sukurti remiantis trimis pagrindinėmis technologijomis:

• Pasirinktiniai elementai: JavaScript API, leidžiantys apibrėžti savo HTML elementus ir jų elgesį.
• Shadow DOM: Suteikia inkapsuliavimą sukuriant atskirą komponento DOM medį, apsaugantį jį nuo visuotinio DOM ir jo stilių.
• HTML šablonai: <template> ir <slot> elementai leidžia apibrėžti pakartotinai naudojamas HTML struktūras ir vietos rezervavimo ženklo turinį.

Esminiai žiniatinklio komponentų projektavimo modeliai

Šie projektavimo modeliai gali padėti jums sukurti efektyvesnes ir lengviau prižiūrimas žiniatinklio komponentų architektūras:

1. Kompozicija, o ne paveldėjimas

Aprašymas: Geriau kurkite komponentus iš mažesnių, specializuotų komponentų, nei pasikliaukite paveldėjimo hierarchijomis. Paveldėjimas gali sukelti glaudžiai susietus komponentus ir trapios bazinės klasės problemą. Kompozicija skatina laisvą susiejimą ir didesnį lankstumą.

Pavyzdys: Vietoj to, kad kurtumėte <special-button>, kuris paveldi iš <base-button>, sukurkite <special-button>, kuris turi <base-button> ir prideda specifinį stilių ar funkcionalumą.

Įgyvendinimas: Naudokite lizdus, kad projektuotumėte turinį ir vidinius komponentus į savo žiniatinklio komponentą. Tai leidžia jums pritaikyti komponento struktūrą ir turinį nekeičiant jo vidinės logikos.

<my-composite-component>
  <p slot="header">Antraštės turinys</p>
  <p>Pagrindinis turinys</p>
</my-composite-component>

2. Stebėtojo modelis

Aprašymas: Apibrėžkite priklausomybę nuo vieno prie daugelio tarp objektų, kad, pasikeitus vieno objekto būsenai, visi jo priklausomi objektai būtų automatiškai informuojami ir atnaujinami. Tai labai svarbu tvarkant duomenų susiejimą ir ryšį tarp komponentų.

Pavyzdys: <data-source> komponentas galėtų pranešti <data-display> komponentui, kai tik pasikeičia pagrindiniai duomenys.

Įgyvendinimas: Naudokite pasirinktinius įvykius, kad suaktyvintumėte atnaujinimus tarp laisvai susietų komponentų. <data-source> išsiunčia pasirinktinį įvykį, kai duomenys pasikeičia, o <data-display> klauso šio įvykio, kad atnaujintų savo rodinį. Apsvarstykite galimybę naudoti centralizuotą įvykių magistralę sudėtingiems ryšio scenarijams.

// data-source komponentas
this.dispatchEvent(new CustomEvent('data-changed', { detail: this.data }));

// data-display komponentas
connectedCallback() {
  window.addEventListener('data-changed', (event) => {
    this.data = event.detail;
    this.render();
  });
}

3. Būsenos valdymas

Aprašymas: Įgyvendinkite strategiją, skirtą komponentų ir visos programos būsenai valdyti. Tinkamas būsenos valdymas yra labai svarbus kuriant sudėtingas ir duomenimis pagrįstas žiniatinklio programas. Apsvarstykite galimybę naudoti reaktyvias bibliotekas arba centralizuotas būsenos saugyklas sudėtingoms programoms. Mažesnėms programoms gali pakakti komponento lygio būsenos.

Pavyzdys: Pirkinių krepšelio programai reikia valdyti prekes krepšelyje, vartotojo prisijungimo būseną ir pristatymo adresą. Šie duomenys turi būti prieinami ir nuoseklūs keliuose komponentuose.

Įgyvendinimas: Galimi keli būdai:

• Komponento vietinė būsena: Naudokite savybes ir atributus komponentui būdingai būsenai saugoti.
• Centralizuota būsenos saugykla: Naudokite biblioteką, tokią kaip Redux arba Vuex (arba panašią), kad valdytumėte visos programos būseną. Tai naudinga didesnėms programoms su sudėtingomis būsenos priklausomybėmis.
• Reaktyvios bibliotekos: Integruokite tokias bibliotekas kaip LitElement arba Svelte, kurios teikia įmontuotą reaktyvumą, palengvindamos būsenos valdymą.

// Naudojant LitElement
import { LitElement, html, property } from 'lit-element';

class MyComponent extends LitElement {
  @property({ type: String }) message = 'Hello, world!';

  render() {
    return html`<p>${this.message}</p>`;
  }
}

customElements.define('my-component', MyComponent);

4. Fasado modelis

Aprašymas: Pateikite supaprastintą sąsają su sudėtinga posisteme. Tai apsaugo kliento kodą nuo pagrindinio įgyvendinimo sudėtingumo ir palengvina komponento naudojimą.

Pavyzdys: <data-grid> komponentas gali viduje tvarkyti sudėtingą duomenų gavimą, filtravimą ir rūšiavimą. Fasado modelis pateiktų paprastą API klientams, kad jie galėtų konfigūruoti šias funkcijas per atributus ar savybes, nesigilindami į pagrindinio įgyvendinimo detales.

Įgyvendinimas: Atskleiskite gerai apibrėžtų savybių ir metodų rinkinį, kuris apima pagrindinį sudėtingumą. Pavyzdžiui, užuot reikalavus, kad vartotojai tiesiogiai manipuliuotų duomenų tinklelio vidinėmis duomenų struktūromis, pateikite tokius metodus kaip setData(), filterData() ir sortData().

// data-grid komponentas
<data-grid data-url="/api/data" filter="active" sort-by="name"></data-grid>

// Vidinėje sistemoje komponentas tvarko gavimą, filtravimą ir rūšiavimą pagal atributus.

5. Adapterio modelis

Aprašymas: Konvertuokite klasės sąsają į kitą sąsają, kurios tikisi klientai. Šis modelis naudingas integruojant žiniatinklio komponentus su esamomis JavaScript bibliotekomis ar karkasais, kurie turi skirtingas API.

Pavyzdys: Galbūt turite seną diagramų sudarymo biblioteką, kuri tikisi duomenų konkrečiu formatu. Galite sukurti adapterio komponentą, kuris transformuoja duomenis iš bendrojo duomenų šaltinio į formatą, kurio tikisi diagramų sudarymo biblioteka.

Įgyvendinimas: Sukurkite apvyniojimo komponentą, kuris gauna duomenis bendru formatu ir transformuoja juos į formatą, kurio reikalauja senoji biblioteka. Tada šis adapterio komponentas naudoja senąją biblioteką diagramai atvaizduoti.

// Adapterio komponentas
class ChartAdapter extends HTMLElement {
  connectedCallback() {
    const data = this.getData(); // Gaukite duomenis iš duomenų šaltinio
    const adaptedData = this.adaptData(data); // Transformuokite duomenis į reikiamą formatą
    this.renderChart(adaptedData); // Naudokite senąją diagramų sudarymo biblioteką diagramai atvaizduoti
  }

  adaptData(data) {
    // Transformavimo logika čia
    return transformedData;
  }
}

6. Strategijos modelis

Aprašymas: Apibrėžkite algoritmų šeimą, inkapsuliuokite kiekvieną iš jų ir padarykite juos keičiamus. Strategija leidžia algoritmui skirtis nepriklausomai nuo klientų, kurie jį naudoja. Tai naudinga, kai komponentui reikia atlikti tą pačią užduotį skirtingais būdais, atsižvelgiant į išorinius veiksnius ar vartotojo nuostatas.

Pavyzdys: <data-formatter> komponentui gali reikėti formatuoti duomenis skirtingais būdais, atsižvelgiant į lokalę (pvz., datos formatus, valiutos simbolius). Strategijos modelis leidžia apibrėžti atskiras formatavimo strategijas ir dinamiškai perjungti jas.

Įgyvendinimas: Apibrėžkite formatavimo strategijų sąsają. Sukurkite konkrečius šios sąsajos įgyvendinimus kiekvienai formatavimo strategijai (pvz., DateFormattingStrategy, CurrencyFormattingStrategy). <data-formatter> komponentas priima strategiją kaip įvestį ir naudoja ją duomenims formatuoti.

// Strategijos sąsaja
class FormattingStrategy {
  format(data) {
    throw new Error('Metodas neįgyvendintas');
  }
}

// Konkreti strategija
class CurrencyFormattingStrategy extends FormattingStrategy {
  format(data) {
    return new Intl.NumberFormat(this.locale, { style: 'currency', currency: this.currency }).format(data);
  }
}

// data-formatter komponentas
class DataFormatter extends HTMLElement {
  set strategy(strategy) {
    this._strategy = strategy;
    this.render();
  }

  render() {
    const formattedData = this._strategy.format(this.data);
    // ...
  }
}

7. Publikavimo-prenumeratos (PubSub) modelis

Aprašymas: Apibrėžia priklausomybę nuo vieno prie daugelio tarp objektų, panašią į Stebėtojo modelį, bet su laisvesniu susiejimu. Leidėjams (komponentams, kurie skleidžia įvykius) nereikia žinoti apie prenumeratorius (komponentus, kurie klauso įvykių). Tai skatina moduliškumą ir sumažina priklausomybes tarp komponentų.

Pavyzdys: <user-login> komponentas galėtų paskelbti "user-logged-in" įvykį, kai vartotojas sėkmingai prisijungia. Keli kiti komponentai, tokie kaip <profile-display> komponentas arba <notification-center> komponentas, galėtų prenumeruoti šį įvykį ir atitinkamai atnaujinti savo vartotojo sąsają.

Įgyvendinimas: Naudokite centralizuotą įvykių magistralę arba pranešimų eilę, kad valdytumėte įvykių publikavimą ir prenumeratą. Žiniatinklio komponentai gali išsiųsti pasirinktinius įvykius į įvykių magistralę, o kiti komponentai gali prenumeruoti šiuos įvykius, kad gautų pranešimus.

// Įvykių magistralė (supaprastinta)
const eventBus = {
  events: {},
  subscribe: function(event, callback) {
    if (!this.events[event]) {
      this.events[event] = [];
    }
    this.events[event].push(callback);
  },
  publish: function(event, data) {
    if (this.events[event]) {
      this.events[event].forEach(callback => callback(data));
    }
  }
};

// user-login komponentas
this.login().then(() => {
  eventBus.publish('user-logged-in', { username: this.username });
});

// profile-display komponentas
connectedCallback() {
  eventBus.subscribe('user-logged-in', (userData) => {
    this.displayProfile(userData);
  });
}

8. Šablono metodo modelis

Aprašymas: Apibrėžkite algoritmo skeletą operacijoje, atidėdami kai kuriuos žingsnius potipių klasėms. Šablono metodas leidžia potipių klasėms iš naujo apibrėžti tam tikrus algoritmo žingsnius nekeičiant algoritmo struktūros. Šis modelis yra veiksmingas, kai turite kelis komponentus, kurie atlieka panašias operacijas su nedideliais skirtumais.

Pavyzdys: Tarkime, kad turite kelis duomenų rodymo komponentus (pvz., <user-list>, <product-list>), kuriems visiems reikia gauti duomenis, juos formatuoti ir tada atvaizduoti. Galite sukurti abstrakčią bazinę komponentą, kuri apibrėžia pagrindinius šio proceso žingsnius (gavimas, formatavimas, atvaizdavimas), bet palieka kiekvieno žingsnio konkretų įgyvendinimą konkrečioms potipių klasėms.

Įgyvendinimas: Apibrėžkite abstrakčią bazinę klasę (arba komponentą su abstrakčiais metodais), kuri įgyvendina pagrindinį algoritmą. Abstraktūs metodai atspindi žingsnius, kuriuos reikia pritaikyti potipių klasėms. Potipių klasės įgyvendina šiuos abstrakčius metodus, kad pateiktų savo specifinį elgesį.

// Abstrakti bazinė komponentas
class AbstractDataList extends HTMLElement {
  connectedCallback() {
    this.data = this.fetchData();
    this.formattedData = this.formatData(this.data);
    this.renderData(this.formattedData);
  }

  fetchData() {
    throw new Error('Metodas neįgyvendintas');
  }

  formatData(data) {
    throw new Error('Metodas neįgyvendintas');
  }

  renderData(formattedData) {
    throw new Error('Metodas neįgyvendintas');
  }
}

// Konkreti potipių klasė
class UserList extends AbstractDataList {
  fetchData() {
    // Gaukite vartotojo duomenis iš API
    return fetch('/api/users').then(response => response.json());
  }

  formatData(data) {
    // Formatuokite vartotojo duomenis
    return data.map(user => `${user.name} (${user.email})`);
  }

  renderData(formattedData) {
    // Atvaizduokite formatuotus vartotojo duomenis
    this.innerHTML = `<ul>${formattedData.map(item => `<li>${item}</li>`).join('')}</ul>`;
  }
}

Papildomi žiniatinklio komponentų projektavimo aspektai

• Prieinamumas (A11y): Užtikrinkite, kad jūsų komponentai būtų prieinami vartotojams su negalia. Naudokite semantinį HTML, ARIA atributus ir pateikite naršymą klaviatūra.
• Testavimas: Rašykite vienetinius ir integracinius testus, kad patikrintumėte savo komponentų funkcionalumą ir elgesį.
• Dokumentacija: Aiškiai dokumentuokite savo komponentus, įskaitant jų savybes, įvykius ir naudojimo pavyzdžius. Tokie įrankiai kaip Storybook puikiai tinka komponentų dokumentacijai.
• Našumas: Optimizuokite savo komponentų našumą sumažindami DOM manipuliacijas, naudodami efektyvius atvaizdavimo būdus ir tingiai įkeldami išteklius.
• Internacionalizacija (i18n) ir lokalizacija (l10n): Sukurkite savo komponentus taip, kad jie palaikytų kelias kalbas ir regionus. Naudokite internacionalizacijos API (pvz., Intl), kad datos, skaičiai ir valiutos būtų formatuojamos teisingai skirtingoms lokalėms.

Žiniatinklio komponentų architektūra: Mikro priekinės sąsajos

Žiniatinklio komponentai vaidina pagrindinį vaidmenį mikro priekinės sąsajos architektūrose. Mikro priekinės sąsajos yra architektūrinis stilius, kai priekinės sąsajos programa yra suskaidoma į mažesnius, nepriklausomai įdiegiamus vienetus. Žiniatinklio komponentai gali būti naudojami kiekvienos mikro priekinės sąsajos funkcionalumui apgaubti ir atskleisti, leidžiant juos sklandžiai integruoti į didesnę programą. Tai palengvina nepriklausomą skirtingų priekinės sąsajos dalių kūrimą, diegimą ir mastelio keitimą.

Išvada

Taikydami šiuos projektavimo modelius ir geriausią praktiką, galite sukurti žiniatinklio komponentus, kurie yra pakartotinai naudojami, prižiūrimi ir keičiamo dydžio. Tai lemia patikimesnes ir efektyvesnes žiniatinklio programas, nepriklausomai nuo pasirinkto JavaScript karkaso. Laikydamiesi šių principų, galite pagerinti bendradarbiavimą, pagerinti kodo kokybę ir galiausiai pagerinti vartotojo patirtį savo pasaulinei auditorijai. Nepamirškite atsižvelgti į prieinamumą, internacionalizaciją ir našumą viso projektavimo proceso metu.