Kuinka kirjoittaa hyviä, kompostoitavia ja puhtaita komponentteja kulmaan 2+

Suurin osa meistä tietää, mitä Smart- ja Dumb-komponentit ovat. Tiedämme, että meidän tulisi käyttää @Input () ja @Output () niin paljon kuin mahdollista. Mutta kun kylpylämme tulee tarpeeksi isoksi, se alkaa muistuttaa meitä yhä enemmän tyypillisestä spagetista ja näyttää siltä, ​​ettemme voi edes auttaa sitä.

Syynä on hyvin usein se, että tiedämme, mitkä ovat hyvät ja huonot mallit koodinkehityksessä, mutta etenkin käyttöliittymässä olemme usein sekoittuneita siihen, mitä meidän on pitänyt tehdä eikä meidän pitäisi tehdä. Seuraamamme mallit alkavat hämärtyä ja käytämme koodinpikakuvakkeita useammin kuin emme.

Yksi sellaisista malleista on jakaa komponentit “älykäs” ja “tyhmä”. Siinä sanotaan, että meidän tulisi pitää kaikki liiketoimintalogiikka ja sivuvaikutukset Smart-komponenteissa tekemällä kaikista muista komponenteista "tyhmiä" kuin mahdollista.

Tämä toimii hyvin, mutta ellemme ota käyttöön tiukeita sääntöjä projektissamme, unohdamme sen. Koska kun malli ei ole sääntö ja se on vain ”yleinen idea”, joka pidämme mielessä, lopulta ohitamme sen yhä enemmän.

Esimerkiksi, meillä alkaa olla komponentteja tyhmiä, mutta kun tuntuu paisuneelta tarpeesta siirtää ja käsitellä kaikkia tuloja ja lähtöjä kaikkialla, meistä tulee laiskoja ja muutetaan vain tulojen tietoja suoraan.
(Tämän vuoksi on vaikea arvata, mikä komponentti muuttaa mitä tietoja ja milloin.)

Muina aikoina haluamme "optimoida" komponenttiemme suorituskyvyn, ja sen sijaan, että riippuisimme tuloista ja lähdöistä, otamme vain "ng1-lähestymistavan", mikä tarkoittaa, että luomme singleton Controller -palvelun, jonka jokainen komponentti vain injektoi itsensä aina, kun se tarvitsee mitään.
(Tämän vuoksi on vaikea päätellä, mitkä komponentit vastaanottavat mitä tietoja.)

Muutamia muita tapauksia, joissa käytetään samanlaisia ​​pikakuvakkeita, ja alamme huomata, että kummallisesti Kulman muutoksen havaitsemismekanismi ei tee muutoksia komponentteihimme (kun normaalisti sen pitäisi olla). Joten lisäämme muutama this.cdRef.markForCheck () -rivi tänne ja takaisin, jotta se toimisi.

Nopea eteenpäin muutaman kuukauden ajan, ja meillä ei ole vain satunnaisia ​​markForCheck () -linjoja ja injektioita erilaisista singleton-palveluista kaikkialla, mutta emme edes tiedä enää, mikä komponentti riippuu mistä ja mitä tietoja vaihdetaan missä .

Olemme saavuttaneet pisteen, jossa sovelluksessamme on satoja komponentteja ja kymmeniä erilaisia ​​singleton-palveluita, kaikki riippuvaisia ​​toisistaan. Ymmärrämme, että emme enää tiedä, mistä on riippuvainen. Loppujen lopuksi on ratkaisematon etuliittymäkoodin sokkelo.

Projekti kohoaa niin komponenttien välisistä suorista ja epäsuorista riippuvuuksista, että me eksymme ärsyyntyneet , kunnes lopulta luovumme ja siirrymme vain takaisin koodaamaan taustaohjelmia / jQuery / ”kaikkea, mikä oli helppoa kuin etuosa vuonna 2018 "jälleen ...

Näin ei pitäisi käydä.

Vaikka on totta, että kehysten pitäisi auttaa meitä kirjoittamaan sovelluksemme helposti skaalautuvaksi, todellinen totuus on, että kehys oli aina tarkoittanut olevan vain perusteline koodillemme. Emme voi koskaan luottaa pelkästään kehyksiin pitääksemme koodimme hallinnassa. Meidän on tehtävä se itse.

Ratkaisu

Ajattelkaamme uudelleen tätä "älykästä" ja "tyhmä" osien jakoa. Syy eksymme sovellukseemme siksi, ettei tämä malli ole väärä, vaan siksi, että teemme sen usein puutteellisesti.

Suunnittelumallini tämän kuvion määrittelemiseksi on seuraava:

  1. Jaa komponentit älykkäiksi ja tyhmäksi.
  2. Pidä komponentit niin tyhjinä kuin mahdollista.
  3. Päätä, milloin komponentin pitäisi olla älykäs tyhmän sijaan.

Kuvailkaamme kaikki nämä kohdat yksitellen.

Loppusanat Jos haluat selata dioja kuin blogikirjoitusta, voit tutustua esityksen dioihini, jotka annoin ng-poznan -messuilla saman otsikon alla.

1. Jaa komponentit älykkäiksi ja tyhmäksi

Ensin määritetään, mitä Smart- ja Dumb-komponentit todella ovat.

  • Tyhmä komponentti on komponentti, joka toimii kuin puhdas funktio.
    (Puhdas funktio on funktio, joka tuottaa tietyille funktioargumenteille aina saman palautusarvon.)
    Tyhmä komponentti on juuri sellainen. Se on komponentti, joka vastaanotetulle datalle (sisääntulolle) näyttää aina samalla tavalla ja käyttäytyy samalla tavalla, mahdollisesti tuottaa myös muuta dataa (tapahtumia, lähtöjä).
Tyhmä komponentti
  • Älykäs komponentti on komponentti, joka muistuttaa enemmän epäpuhdasta toimintoa.
    (Epäpuhdas funktio on toiminto, joka koskettaa ”ulkomaailmaa”: joko hankkimalla tietoja ulkoisilta palveluilta tai tuottamalla sivuvaikutuksia.)
    Älykäs komponentti on juuri sellainen. Se ei ole riippuvainen pelkästään sen tuloista, vaan myös jonkinlaisesta ulkoisesta tiedosta (”ulkomaailma”), jota ei välitetä suoraan @Input () kautta. Se saattaa myös tuottaa joitain sivuvaikutuksia, joita ei lähetetä @Output () -rajapinnan kautta.
    Esimerkiksi komponentti, joka saa nykyiset käyttäjätiedot muualla toteutetusta erillispalvelusta; ulkoisesta API: sta; tai LocalStorage-palvelusta. Komponentti, joka muuttaa ulkoisen palvelun tilaa; antaa API-puhelun; tai muuttaa tallennettua tietoa LocalStorage-sovelluksessa.
Älykäs komponentti

Tyhmä komponentti kutsutaan joskus myös "puhdas", "Presentational". Älykästä komponenttia kutsutaan joskus ”epäpuhtaaksi”, “kytkettynä”, “säiliöksi”. Internetissä esiintyy erilaisia ​​määritelmiä riippuen siitä, kuinka kirjoittaja kuvaa niitä tai kehykseen, johon hän on keskittynyt, mutta koko käsitys sukeltamalla ne tällä tavalla on yleensä samanlainen.

Pidä mielessä: älykäs vs. tyhmä ei ole tilallinen vs. valtioton!
Ihmiset usein erehtyvät noihin termeihin, mutta minulle ne ovat täysin riippumattomia toisistaan. Katso:

  • Tyhmällä komponentilla ei ole ulkoisia riippuvuuksia ja se ei aiheuta sivuvaikutuksia (mutta sillä voi silti olla paikallinen tila).
  • älykkäällä komponentilla on ulkoisia riippuvuuksia tai se aiheuttaa sivuvaikutuksia (mutta silti voi olla tai olla, että sillä ei ole paikallista tilaa).
  • Valtiottomalla komponentilla ei ole paikallista tilaa (mutta saattaa silti aiheuttaa sivuvaikutuksia).
  • Tilallisella komponentilla on paikallinen tila (mutta hänen ei tarvitse olla riippuvuuksia eikä aiheuttaa sivuvaikutuksia).

Olen laatinut piirustuksen havainnollistamaan sitä selkeämmin, kuinka nämä kaksi jakoa voidaan yhdistää:

Älykäs / tyhmä x tilallinen / kansalaisuudeton matriisi

Mielenkiintoista on, että vain näistä piirustuksista voimme jo saada joitain vakavia johtopäätöksiä:

  • Tyhmä-valtiottoman komponentin käyttäytyminen on helpoin ennustaa ja ymmärtää.
  • Tyhmä-Stateful-komponentti näyttää myös olevan yksinkertainen, koska vaikka sillä on jonkin verran paikallishallintoa, se on läpinäkyvä muille.
    Muiden näkökulmasta kaikki, mitä tämä komponentti tekee, on edelleen vain tulojen vastaanottaminen ja lähtöjen lähettäminen.
  • Älykkäät komponentit näyttävät olevan vaikeimpia käsittää, koska niiden sisääntulojen ja lähtöjen lisäksi ne ovat myös jotenkin yhteydessä ulkomaailmaan hankkimalla siitä tietoa ja / tai aiheuttamalla sivuvaikutuksia.

Nyt minun koko tämän blogikirjoituksen pääkohde on seuraava: Älykkäät komponentit ovat pahin paha. Koska niiden lisäksi, että niillä on selkeästi määritellyt tulot ja lähdöt, ne vaativat myös jonkinlaisia ​​ulkoisia riippuvuuksia ja tuottavat jonkinlaisia ​​sivuvaikutuksia. Valitettavasti tällaista on aina vaikea hallita ohjelmoinnissa.

2. Pidä komponentit mahdollisimman tyhjinä

Sen vuoksi sanon, että meidän pitäisi pitää suurin osa komponenteistamme tyhmiä. Tyhmä, tarkoitan todella tyhmä! Tarkoitan, hyvä tyhmä komponentti:

  • ei saisi olla riippuvainen ulkopuolisista palveluista - jos se vaatii jonkin verran tietoa toimimaan, se tulisi antaa @Input (): n kautta;
  • ei saisi tuottaa sivuvaikutuksia - jos sen on päästävä jotain, se tulisi päästää @Output (): seen;
  • ei pitäisi mutatoida sen tuloja - koska jos se tapahtuu, se todella tuottaa sivuvaikutuksen, joka aiheuttaa muutoksen emokomponentin tiedoissa.
    Lapsen ei tulisi koskaan muokata suoraan vanhempien tietoja. Jos sen on ilmoitettava vanhemmalle, että jotain oli muuttunut, hänen tulisi antaa se tapahtumana, jonka vanhemman tulisi poimia ja sitten toimia asianmukaisesti.

Koodiesimerkki:

3. Päätä, milloin komponentin pitäisi olla älykäs tyhmän sijaan

Tämä kohta on vaikea. Se sai minut kirjoittamaan koko viestin pari kertaa;) Syynä on se, että selkeä ero, minkä pitäisi olla älykäs ja mikä ei pitäisi olla, ei ole niin yksinkertaista. Mutta koska inhoan jättää tietojenkäsittelytieteellisten päätösten tekemisen kehittäjän "henkilökohtaiseen makuun", päädyin lopulta neljään päätelmään:

3a. Jos se voi olla tyhmä, tee siitä tyhmä

Ajattele, mikä on komponentin rooli.

Onko roolia helppo ennustaa ja kuvata paperilla? Jos kyllä, se tarkoittaa, että meidän ei tarvitse tehdä hänestä fiksua. Tulojen ja lähtöjen tulisi olla helppo hallita hänen käyttäytymistään.

esimerkkejä:

  • lomakkeen hallintakomponentti, joka vastaanottaa nykyisen arvon ja lähettää uusia arvoja,
  • lomakekomponentti, joka vastaanottaa alkuperäisen muotoarvon ja lähettää uudet lomakearvot.

Periaatteessa, jos ei ole mitään syytä olla tekemättä komponenttia tyhmäksi, tee siitä vain tyhmä.

3b. Jos useat lapset ovat yhtä älykkäitä, tee niistä tyhmä

Jos sinulla on esimerkiksi hakunäkymä, jossa on useita erilaisia ​​suodattimia, jotka yhdistävät hakusivun tilaan, mutta kaikilla niillä on sama rooli - näyttää nykyisen suodattimen arvo ja mahdollisesti muuttaa sitä - miksi toista sama älykäs logiikka kaikissa heistä?

Sen sijaan meillä voisi olla vain älykäs FiltersListComponent, joka yhdistää hakusivun tilaan ja välittää suodatinarvot sen alapuolella oleville Tyhmille suodatinkomponenteille.

Sitten sen sijaan, että meillä olisi kymmenen älykästä komponenttia, meillä on yksi älykäs ja kymmenen tyhmää.

3 c. Mikä ei voi olla tyhmä, tee siitä älykäs

Lopulta saavutamme pisteen, jossa emme pysty pitämään kaikkia komponenttejamme tyhjinä. Ainakin yhden niistä on oltava älykäs. Meidän on pidettävä sovelluksemme tilaa jossain; meidän on soitettava sovellusliittymille mistä tahansa, eikö niin?

Useimmissa tapauksissa paras valinta on laittaa se yläkuvan komponentteihin.

Huomaa, että tämä ei tarkoita, että meidän täytyy laittaa logiikka suoraan komponentin koodiin. Se voi olla erillisessä palvelussa, kuten SearchPageControllerService. Tai se voi olla Redux-toiminnoissa, tilassa ja reduktorissa, jos käytämme reduxin kaltaista rakennetta.

Tärkeää on, että tämä älykäs komponentti on itse asiassa ainoa, jolla on pääsy tähän ulkoiseen riippuvuuteen, ja se on ainoa, joka emittoi tapahtumia siihen.

Kaikki tämän älykkään komponentin lapset ovat tyhmiä ja reagoivat maailmaan vain tuloillaan ja ulostuloillaan.

Tämän avulla on helpompi päätellä, ketkä muuttavat mitä ja milloin teidän mielestänne ovat ja mistä riippuvat.

Esimerkiksi tyypillisellä hakusivulla vain SearchPageComponentin tulee olla älykäs. Kaikkien muiden sen näkemyksessä olevien osien, kuten SearchPageResultsComponent, SearchPageFiltersComponent, SearchPageResultsItemComponent ja niin edelleen, tulee olla tyhmiä.

Hakusivun esimerkki

3d. Jos älykäs tulee liian isoksi, jaa se erillisiin hajuihin.

”Tee ylhäältä näkyvä komponentti älykkääksi” on erittäin hyvä sääntö, mutta joissakin näkymissä se ei ehkä riitä.

Esimerkiksi Gmail-postilaatikon pääsivulla on seuraavat ominaisuudet:

  • luetteloida ja hallita viimeisimpiä sähköpostilankoja
  • luettele ja hallinnoi käytettävissä olevia kansioita
  • näyttää online-ihmisiä Hangoutista
  • anna nopeasti kirjoittaa uuden viestin

Jos Gmail-sivulla olisi vain yksi Smart-komponentti, sen olisi otettava kaikki vastuunsa. Melko paljon. On erittäin todennäköistä, että se lopultakin tulee valtavaksi osaksi erittäin monimutkaista koodia.

Joten sen sijaan voimme jakaa sen muutamiin älykkäisiin komponentteihin, joilla on omat vastuunsa:

  • ThreadsListView
  • FoldersListView
  • HangoutPeopleListView
  • NewMessageModalView

Jokaisella näistä näkemyksistä olisi vain tyhmiä lapsia sen alla. Joten, se on silti hallittavissa.

Usein Kysytyt Kysymykset

1. Kuinka ja milloin saan antaa ulkoisia palveluita / riippuvuuksia? Voinko luottaa heihin ja miten voin kommunikoida heidän kanssaan?

Yleensä et koskaan saa kommunikoida ulkomaailman kanssa, ellet ole älykäs komponentti.

Älykkäänä komponenttina olet välimies sovellusliittymien ja sovelluksesi liiketoimintalogiikan ja muiden Tyhmä-komponenttien välillä.

Vain älykkään komponentin tulisi pystyä kommunikoimaan ulkoisten sovellusliittymien kanssa kutsumalla niiden toiminnot ja tilaamalla palautusarvot / lupaukset / havaittavissa olevat kohteet.

Aina, kun sovellusliittymästä tulee jotain uutta, päivität älykkään komponentin tila, joka aiheuttaa muutoksen leviämisen sen tyhmäksi lapseksi.

Sama pätee toiseen suuntaan. Aina kun tyhmä lapsesi haluaa ”muuttaa” mitä tahansa, esimerkiksi se haluaa päivittää hakutulokset, se lähettää vain tapahtuman. Älykäs komponentti poimii sen, soittaa uudelleen ulkoiselle sovellusliittymälle ja levittää muutoksen vain tyhmälle lapselleen päivittämällä heidän tulonsa.

Käytännössä se tarkoittaa, että vain komponenttipuun yläosassa sijaitsevat älykkäät komponentit ovat yhteydessä ulkoisiin palveluihin. Kaikki muut, jotka sijaitsevat syvällä puussa, ovat lopulta tyhmiä ja kommunikoivat muiden kanssa vain tulojen ja lähtöjen kautta.

Kuitenkin voi silti olla tapauksia, joissa saattaa olla syytä kytkeä tyhmä komponentti suoraan ulkomaailmaan. Esimerkiksi:

  • Napsauttamalla painiketta ProductItemComponentissa, voit siirtyä sovelluksessa heti toiseen URL-osoitteeseen tarvitsematta lähettää ja tarttua @Output () productItemClick -tapahtumaan.
  • Kun renderoit DateTimePickerComponent -kuvaketta, saatat saada nykyisen käyttäjän aikavyöhykkeen suoraan jostain globaalista muuttujasta.
  • Kun listaat mahdollisia käyttäjiä UserSelectComponent-ohjelmassa, saatat saada luettelon kaikista online-käyttäjistä suoraan sovelluksesi globaalisti saatavasta API-palvelusta.

Nämä kolme yllä olevaa esimerkkiä ovat mielestäni okei, koska vaikka heillä olisi yhteys “ulkomaailmaan”, se tapahtuu vain hankkimalla globaalisti saatavilla olevat ja harvoin muutettavat tiedot sovellukseesi. Mutta muista, että se rikkoo edelleen sääntöjä. Jos syntyy tilanne, jossa haluamme olla erilainen käyttäytyminen tuotteessa ProductItemComponent # productItemClick, haluamme käyttää eri aikavyöhykettä tiettyyn DateTimePickerComponent-esiintymään tai käyttää erilaista käyttäjävalintaa UserSelectComponent-sovelluksessa, sitten IMO: n pitäisi palata luonnolliseen luontoon. @Input () - ja @Output () -rajapintojen käyttö.

2. Kuinka voin soveltaa muutosta vanhempani? Periaatteessa kuinka käsittelen sovellukseni muuttaaksesi jotain?

Päästät tapahtuman ja vanhempi tarttuu siihen ja käsittelee muutoksen sisäisesti. Itse asiassa komponenttien tulot ja lähdöt muodostavat eräänlaisen syklin:

  1. Lapsi B lähettää @Output () -tapahtuman;
  2. Vanhempi A tarttuu @Output () -tapahtumaan ja käsittelee sen joko:
    a) tapahtuman lähettäminen ylöspäin - lähettämällä toinen @Output () tai
    b) hoitaa muutoksen sisäisesti - päivittämällä sen 'paikallinen tila' (ja valinnaisesti käskemällä kulmaa tarkistamaan omat ja lastensa sidokset ChangeDetectorRef # deteChanges ());
  3. Lapsi B vastaanottaa uudet tiedot @Input () -sovelluksen kautta, sen 'ngOnChanges () -soittopyyntö soitetaan ja' -näkymä ja lasten sidokset tarkistetaan Kulmilla automaattisesti.

Loppusanat Lue lisää kulmanmuutoksen havaitsemismekanismista edellisestä artikkelissani: Kulmasuorituksen hallitseminen, osa 1 - pudottamalla muutostunnistimen taikuus.)

3. Voinko koskaan mutatoida syötteitäni?

Ei. Syötesi mutaatio on loukkaavaa puhdasta toimintoa - se tosiasiallisesti tuottaa sivuvaikutuksen, joka aiheuttaa vanhempien komponenttien tietojen vaihtamisen kysymättä ketään.

Jos haluat, että vanhempi komponentti vaihdetaan, sinun tulisi vain lähettää tapahtuma, jonka kohdalla on @Output (), ja käsitellä vanhemman komponentin muutos.

4. Minun on saatava nykyinen kaupungin sää CityListItemComponent -sivustolleni. Voinko vain pistää pienen WeatherService -sovellukseni siihen ja käyttää sitä suoraan kuten this.cityWeather = WeatherService.getWeatherForCity (this.city)?

Ei, mielestäni sinun ei pitäisi. CityListItemComponent kuulostaa komponentilta, joka on sijoitettu syvälle ja jonka pitäisi olla tyhmä. Jos teet sen riippuvaiseksi ulkoisesta palvelusta, kuten WeatherService, se ei ole enää tyhmä. Sen käyttäytymistä on vaikea ennustaa, koska epäpuhdas funktio on aina vaikeampi ymmärtää kuin puhdas.

Sen sijaan voit saada esimerkiksi kaikkien komponenttien nykyiset säätiedot komponentista, joka tosiasiallisesti saa kaupungit, ja välittää sen sitten alaspäin käyttämällä @Input ().

5. Minun on päivitettävä tietyn kaupungin nykyinen sää päivityspainikkeella, joka sijaitsee CityListItemComponent-sovelluksessa. Voinko vain pistää pienen WeatherService -sivustoni sinne ja soittaa WeatherService.refreshWeatherForCity (this.city) -sivulle?

Ei, mielestäni sinun ei pitäisi. Jos CityListItemComponent on tyhmä komponentti, sen ei pitäisi tuottaa sivuvaikutuksia.

Sen sijaan, lähetä @Output () weatherRefresh -tapahtuma ja käsittele sitä älykkäässä esivanhemmassa, joka tosiasiallisesti käsittelee koko luettelon säätietoja.
Tämä johtuu siitä, että haluat pitää komponenttien koodin yksinkertaisena. Tyhmä CityListItemComponent tulee pitää huolta vain kaupungin yksityiskohtien näyttämisestä ja käyttöliittymätapahtumien lähettämisestä. Sillä ei pitäisi olla mitään logiikkaa nykyisen kaupungin säähaun hakemiseksi jollain sovellusliittymällä.

Koko erottelu tarkoittaa komponenttien pitämistä kiinteinä. Kaupunkien luettelossivun kaupunkien sää saamisen ja virkistämisen pitäisi olla vain yhdessä paikassa. Luultavasti luettelon tai luettelosivun koodi (tai sen redux-tila ja toiminnot).

Plussaa ja miinusta Smart / Dumb -jaon seuraamisesta

Plussat

  1. Voit helposti ennustaa tyhmäkomponentin käyttäytymisen.
    Se on niin yksinkertainen kuin sen julkiset tulo- ja lähtöliittymät.
    (Mikä muuten toimii yhdessä TypeScriptin tyyppimuotojen kanssa mahtava dokumentaatio koodisi kanssa.)
  2. Voit helposti testata tyhmäkomponentin käyttäytymisen.
    Tyhmän komponentin testaaminen on niin yksinkertaista kuin:
    1. Määritä tuloarvot
    2. Välitön komponentti
    3. Laki komponentista (napsauta sitä)
    4. Väitä, että tietty "@Output ()" oli lähetetty.
    Älykkään komponentin testaaminen vaatii yleensä paljon enemmän: ulkoisten riippuvuuksien tarttumisen, sivuvaikutusten tarkistamisen jne.
  3. Voit (melko) helposti muuttaa tyhmäkomponentin käyttäytymistä rikkomatta asioita.
    Aina kun muutat tyhmä komponenttia:
    - Varmista, että vanha käyttöliittymä toimii edelleen (tai etsi ja korvaa tämän komponentin vanhat käyttötavat, jotka voit helposti tehdä TypeScriptin avulla)
    - Komponentin pääkäyttäytyminen toimii edelleen suunnitellulla tavalla.
    Sinun ei tarvitse varmistaa, että mahdolliset ulkoiset riippuvuudet rikkovat tämän komponentin tai jos se aiheuttaa joitain muita haittavaikutuksia kuin ennen. Se ei koskaan tehnyt niin eikä koskaan tule.
  4. Vain älykkäät komponentit hallitsevat sovelluksesi päälogiikkaa.
    Sinun ei enää tarvitse lukea koko koodisäilöäsi, vaan vain nähdä, kuka hakee mitä missä ja mikä on muuttunut mitä ja missä.
    Nyt voit nähdä suurimman osan siitä lähinnä tarkastelemalla älykkäiden komponenttiesi HTML-mallia.
  5. Se on esiintyvämpi.
    Koska nyt tiedät, mistä tarkalleen riippuu, sinun ei tarvitse enää NgZonea eikä maagista muutosten havaitsemismekanismia, joka tarkistaa muutokset kaikessa kaikkialla. Voit ohittaa NgZonen ja käyttää ChangeDetectionStrategy.OnPush -sovellusta kaikissa tyhmäissä komponenteissasi.
  6. Se auttaa sinua välttämään virheitä.
    Vähemmän koodin kytkemistä;
    Jakamalla se pienempiin, SOLID-kaltaisimpiin ja puhtaisiin bitteihin;
    Sivuvaikutusten välttäminen;
    Kirjoitettujen tulojen ja lähtöjen käyttäminen tietojen siirtämiseen suurimmassa osassa sovellustasi;
    - kaikki tämä vähentää koodisi monimutkaisuutta ja vähentää samalla mahdollisuutta, että virheitä tapahtuu koodissa.
  7. Bonus: Voit ohittaa käyttämällä muutosta ChangeDetectorRef # markForCheck () kokonaan.
    Sitä ei vain tarvitse käyttää ollenkaan.
    Meidän ei tarvitse ilmoittaa kulmalle, että jotain oli muutettu vanhemmassa komponentissa, koska koska se on lapsikomponentti, emme enää koskaan muuta sitä suoraan.
    (Jos teemme niin, teemme sen `@Output ()`: n kautta, ja vanhempi hoitaa muutoksen itse.)

Haittoja

  1. Et voi pistää riippuvuuksia missä haluat.
    Sinun on aina mietittävä etukäteen, mitä tietoja komponentit vaativat ja miten ne siirretään heille.
  2. Et voi mutatoida tulon / lähdön kautta kulkevia tietoja.
    Sen sijaan käytät paikallista osavaltiota tai jätät tietojen ylläpidon älykkäille vanhemmille.

TL; DR:

  • Jaa selkeästi komponentit Smart- ja Dumb-komponentteihin.
  • Toteuta tyhmä komponentit hyvin.
    Älä koskaan mutatoi @Input () -arvoja.
    Vältä riippuen ulkoisista palveluista - käytä sen sijaan @Input ().
    Vältä aiheuttamasta sivuvaikutuksia - käytä sen sijaan @Output ().
  • Vältä hakkeroiden käyttämistä koodissa. Pitkällä aikavälillä ne pakottavat sinut viettämään enemmän aikaa koodiin eikä ole pikanäppäimiä ollenkaan. Ne myös vaikeuttavat koko sovelluksen ymmärtämistä, muuttamista ja laajentamista.

Aloimme kaikkien näiden sääntöjen soveltamisen valtavassa Rekrytoituneen yhden sivun kulmahakemuksessamme muutama kuukausi sitten ja näemme siitä jo valtavia etuja.

Mitä mieltä olet kaikista näistä säännöistä? Asennatko samanlaisia ​​ryhmissäsi ja projekteissasi? Ehkä olet eri mieltä jostakin? Kerro meille kommenteissa.

Voit myös nähdä vapaasti esitykseni, jonka äskettäin piti samasta aiheesta. Ehkä diat toimivat sinulle paremmin kuin blogiteksti.

-

Loppusanat Rekrytoidun palkkaaminen! Jos etsit työtä Angular + TypeScript- tai Elixir + Phoenix Framework -taustalla, mieluiten Poznańissa, Puolassa, tutustu uramahdollisuuksiin. Saatamme olla täydellinen ottelu sinulle.