Angular UI -reititys ja komponentit

Angular UI Router on hiljalleen integroinut tuen reititykselle Angular-komponentteihin. Tässä postauksessa käsitellään, miksi se on hyödyllistä ja miten se tehdään käyttäen sekä Angular UI Router 0.x.x- että 1.0.0-beta.x-versioita.

Tausta

Kun Angular-komponentit otettiin käyttöön versiossa 1.5, erillisen, uudelleenkäytettävän käyttäytymis- ja näkymäkokonaisuuden käsite tuli helpommin määriteltäväksi kuin mitä aiemmin on tehty direktiiveissä. Näihin muutoksiin kuuluvat: laajuuden abstrahointi, ohjaimiin sitominen eksplisiittisesti, elinkaarikoukkujen tarjoaminen ohjaimeen sekä muutama muu asia.

Tämä mahdollisti kokonaisten näkymien ja sovellusten paremman komponentoinnin. Tämän myötä tuli oivallus, että verkkosivu on komponentti, joka koostuu komponenteista.

Tämän sanottuaan reititys komponenttiin tuli halutuksi käytökseksi.

Älykkäät vs. tyhmät komponentit

Ennen kuin syvennytään UI Routerin käyttöön komponentteihin reitittämiseen, on syytä keskustella älykkäiden ja tyhmien komponenttien käsitteestä.

Älykäs komponentti on komponentti, joka tuntee API:n ja datan, joka ohjaa näkymää. Tämä tarkoittaa, että sen kontrollerissa tehdään tyypillisesti palvelukutsu komponentin alustuksen yhteydessä. Se tietää, mitä kutsun tekeminen vaatii ja mitä vastausta sen pitäisi odottaa API:lta.

Toisaalta on olemassa tyhmiä komponentteja, jotka tietävät, mitä tehdä välitetylle objektille tai arvolle ja mistä vuorovaikutuksista se on vastuussa. Se ei tyypillisesti ole vuorovaikutuksessa minkään palvelun kanssa. Useimmat vuorovaikutukset johtavat takaisinkutsuun vanhemmalle komponentille, joka välittää tietoa takaisin ylöspäin käytettäväksi
älykkäällä komponentilla, tai ne liittyvät puhtaasti näyttömuutoksiin.

Uudelleenkäytettävyyden vuoksi tyhmät komponentit ovat tyypillisesti kaikkein uudelleenkäytettävimpiä (ajattele kontteja, joissa on otsikoita, navigointipalkkeja, valintaruutuja jne.). Älykkäät komponentit ovat loistavia kokonaisten sovellusten rakentamiseen korkealta tasolta, mutta ne eivät ole kovinkaan muokattavissa.

Paras tapa tehdä komponentista tyhmä on poistaa API-kutsut kontrollereista ja keksiä keino tarjota tiedot jonkinlaisen sidonnan kautta. Tämä on hyödyllistä, jos sinulla on jo samat tiedot, joita älykäs komponentti tarvitsee, mutta et halua tehdä kahta hakua palvelimelle niitä varten.

Sovelluksen kirjoittaminen komponenttina

Kun siirryttiin komponenttisovelluksiin, tapahtui mielenmuutos, joka liittyi siihen, miten katsomme sovelluksia. Kokonaisia sovelluksia voidaan tarkastella komponenttina. Tällä on itse asiassa käytännön käyttötapauksia. Jos esimerkiksi kirjoitamme sovelluksemme komponenttina, voimme ottaa erillisen web-sovelluksen ja mahdollisesti laittaa sen hybridi-web-säiliöön ja tehdä siitä mobiilisovelluksen.

Paras tapa kirjoittaa sovellus komponenttina on hyödyntää sisäkkäisiä näkymiä UI Routerissa. Tämä voi olla ajoittain haastavaa, mutta se mahdollistaa suuren joustavuuden komponenttien vaihtamisessa
sovelluksen tilan perusteella.

Komponenttien käyttö tilamäärittelyssä mallin avulla

Ensimmäinen integraatio reititettäviin komponentteihin oli käyttää tilamäärittelyn templateUrl-ominaisuuden sijasta template-ominaisuutta. Esimerkki tästä olisi
seuraava:

Tämä ilmeisesti toimii, mutta kun jokainen tila määritellään HTML-elementillä, joka on yksinkertaisesti vain yksi HTML-elementti ilman attribuutteja, siitä alkaa tulla työlästä.

Todennäköisesti kaikki kyseiseen komponenttiin liittyvä logiikka ja näyttö on eristetty ja uudelleenkäytettävissä. Jos esimerkiksi päätät kietoa myComponent navigointimallin sisään, voit nyt tehdä sen ilman, että sinun tarvitsee luoda uutta komponenttia mallista, jos olisit määrittänyt saman tilan sellaiseksi:

Sitoutuminen komponentteihin

Miten kirjoitamme kokonaisen sovelluksen tyhmänä komponenttina, kun monien reittiemme täytyy tehdä palvelukutsuja näyttääksemme tietoa, jota käyttäjä haluaa tarkastella?

Yksi mahdollinen vastaus tähän on ratkaista komponentin toiminnan kannalta tarpeelliset tiedot reitistä ja sitoa ne sitten komponenttiin komponentin sidontojen kautta. Tähän on kaksi lähestymistapaa:

1. Luo älykäs komponentti, joka kietoo tyhmän komponentin. Älykkään komponentin ainoa tarkoitus on tehdä palvelukutsu ja sitoutua asianmukaisesti tyhmään komponenttiin.
2. Käytä UI-reitittimen tarjoamaa resoluutiotoiminnallisuutta ratkaistaksesi tietoja suoraan tyhmään komponenttiin.

Kummassakin vaihtoehdossa on joitakin ilmeisiä kompromisseja. Älykkään komponentin kääreellä saat ylimääräisen komponentin ylläpidettäväksi. Ratkaistessasi komponentin UI Routerin avulla sitoudut reitittimen kykyyn, ja poikkeuskäsittelyn hallitseminen on myös vaikeampaa.

Sitä huolimatta reititettävien komponenttien luominen UI Routerin sidontojen avulla on äärimmäisen yksinkertaista, ja UI Router on tarpeeksi tehokas ja tarjoaa loistavaa toiminnallisuutta siinä määrin, että jos se on projektissasi, se todennäköisesti pysyy siellä sovelluksen täydelliseen uudelleenkirjoittamiseen asti.

Sitoutuaksemme komponenttiin UI Routerin stabiilissa versiossa (0.x.x) UI Router luo $resolve-olion kontekstissa, jota se käytti ui-view:n sisällön kääntämiseen.

Tämän avulla voidaan sitoa komponenttideklaraatio tilamäärittelyn template-ominaisuuteen.

Tämän avulla voimme poistaa UserService-riippuvuuden user-komponentista. Niille älykkäille komponenteille, jotka vain tekevät palvelukutsun ja näyttävät sitten tiedot, voimme itse asiassa poistaa myös kokonaisen ohjaimen.

Komponentteihin sitominen – 1.0.0-beta.x

Julkaisun [email protected] myötä tilamäärittelyn objektiin lisättiin component-ominaisuus. Tämä antaa kehittäjälle mahdollisuuden sitoutua suoraan angular-moduulissa määriteltyyn komponenttiin. Se poistaa tarpeen yhden elementin sisältävälle mallille, kuten aiemmin olimme nähneet.