Reactin viisi kuoleman sormea. Hallitse nämä viisi käsitettä ja hallitse sitten React.

Muutama vuosi sitten ystäväni Sean alkoi kertoa minulle, kuinka tämä uusi React-niminen käyttöliittymäkirjasto aikoo ottaa verkon haltuunsa. Aluksi hylkäsin sen vain yhtenä kehyshulluna. Mutta sitten aloin kuulla Reactista yhä enemmän, siihen pisteeseen, jossa tunsin, että sen sivuuttaminen ei enää ollut vaihtoehto.

Ehkä olet samassa asennossa kuin minä: olet kuullut Reactista vasemmalle ja oikealle, mutta itse asiassa istumalla ja oppimalla se tuntuu sellaiselta työläältä.

Hyvä uutinen on, että voit keittää kaiken mitä sinun tarvitsee tietää React viiteen keskeiseen käsitteeseen .

Älä nyt ymmärrä minua väärin, tämä ei tarkoita, että voin tehdä sinusta hetkeksi React-mestarin. Mutta ainakin ymmärrät kaikki tärkeimmät käsitteet, jos päätät hypätä sisään.

Viisi avainkäsitettä ovat:

  1. Komponentit
  2. JSX
  3. Rekvisiitta ja osavaltio
  4. Komponentti-sovellusliittymä
  5. Komponenttityypit

Ennen kuin aloitamme, huomaa, että olen alun perin oppinut Reactin Wes Bosin kurssien kautta, ja olen sisällyttänyt niihin muutaman tytäryhtiölinkin. Aina kun mahdollista, olen myös sisällyttänyt linkkejä ilmaisiin resursseihin.

Voi, ja ystäväni Sean? Sittemmin hän on siirtynyt paljon enemmän huippuluokan asioihin. React on loppujen lopuksi niin vuosi 2015.

Käsite # 1: Kuinka React-komponentit toimivat

Ensimmäinen asia, joka sinun on tiedettävä Reactista, on se, että kyse on komponenteista . React-koodikanta on pohjimmiltaan vain yksi iso kasa isoja komponentteja, jotka kutsuvat pienempiä komponentteja.

Mutta mikä on komponentti, kysyt? Täydellinen esimerkki komponentista on yhteinen ct> HTML element. Not only does it come with its own visual output (the grey box, text label, and downward arrow that make up the element itself) — it also handles its own opening and closing logic.

Now imagine being able to build your own self-contained custom ct>, with its own style and behavior:

Well, that’s exactly what React lets you do. A React component is a single object that not only outputs HTML like a traditional template would, but also includes all the code needed to control that output.

In practice, the most common way to write React components is as an ES6 class containing a render method that returns HTML. (There’s also a super-secret functional way, but you’ll have to wait until concept #4 to learn about it):

class MyComponent extends React.Component {
 render() { return 

Hello World!

; }

}

Käsite # 2: Kuinka JSX toimii

Kuten näette, komponenttimenetelmä tarkoittaa, että sekä HTML- että JavaScript-koodi elävät samassa tiedostossa. Reactin salainen ase tämän epäpyhän liittoutuman saavuttamiseksi on JSX-kieli (jossa ”X” tarkoittaa ”XML”).

JSX saattaa tuntua aluksi hankalalta, mutta totut siihen melko nopeasti.

Kyllä tiedän. Meitä kaikkia on opetettu pitämään vahva ero HTML: n ja JavaScriptin välillä. Mutta käy ilmi, että näiden sääntöjen hieman rentouttaminen voi todella tehdä ihmeitä käyttöliittymän tuottavuudelle.

Esimerkiksi, koska sinulla on nyt käytettävissäsi kaikki JavaScript-ominaisuudet, voit näyttää nykyisen päivämäärän lisäämällä HTML-koodinpätkän HTML-koodiin seuraavalla tavalla {...}:

class MyComponent extends React.Component {
 render() { return 

Today is: {new Date()}

; }
}

Tämä tarkoittaa myös sitä, että käytät tavallista JavaScriptiä iflauseissa tai silmukoissa jonkinlaisen mallikohtaisen syntaksin sijaan. Javascriptin kolmikantainen operaattori on erityisen kätevä tässä:

class MyComponent extends React.Component {
 render() { return 

Hello {this.props.someVar ? 'World' : 'Kitty'}

; }
}

Ja muuten, jos haluat päivittää JavaScriptin syntaksin uusimmat kohdat, suosittelen Wes Bosin ES6 for Everyone (jos pidät videoista) tai Nicolas Bevacqua Practical ES6 (jos haluat lukea).

Käsite # 3: Kuinka rekvisiitta ja osavaltio toimivat

Ehkä olet miettinyt, mistä yllä oleva this.props.someVarmuuttuja tulee.

Jos olet koskaan kirjoittanut HTML-rivin, olet todennäköisesti perehtynyt HTML-määritteisiin, kuten <; a> tag’s href. Reactissa attribuutit ovat kno wn rekvisiitta (lyhenne sanoista "ominaisuudet"). Rekvisiitta on kuinka komponentit puhuvat keskenään.

class ParentComponent extends React.Component {
 render() { return ; }
}
class ChildComponent extends React.Component {
 render() { return 

And then I said, “{this.props.message}”

; }
}

Tästä syystä Reactin tietovirta on yksisuuntainen : data voi siirtyä vain vanhempien osista lapsilleen, ei päinvastoin.

Joskus komponentin on kuitenkin reagoitava dataan, joka ei tule vanhemmasta komponentista (kuten esimerkiksi käyttäjän syötteestä). Ja tässä valtio tulee.

Hyvä metafora rekvisiitta ja tila-eron ymmärtämiseksi olisi Etch-A-Sketch. Toisin kuin Etch-A-Sketch-tabletin ( rekvisiitta ) rungon väri ja valintaasento , itse piirustus ( tila ) ei ole Etch-A-Sketchin luonnollinen ominaisuus. Se on vain käyttäjän syötteen väliaikainen tulos.

Huomaa, että komponentin tila voidaan välittää myös sen omille lapsille rekvisiittaa . Voit ajatella tätä suurena alamäkeen virtaavana jokena, jossa reititin, tietokerros ja erilaiset komponentit lisäävät kumpikin oman pienen tietovirransa sovelluksen päätilan muodostamiseksi.

Komponentin sisällä tilaa hallitaan setStatetoiminnolla, jota kutsutaan usein tapahtumakäsittelijän sisällä:

class MyComponent extends React.Component {
 handleClick = (e) => { this.setState({clicked: true}); }
 render() { return Click me; }
}

Käytännössä valtaosa datan Reagoi sovellus tulee potkuri . Vain silloin, kun sinun on hyväksyttävä käyttäjän syöttämä tieto, käytät tilaa muutoksen käsittelemiseen.

Huomaa, että käytämme tässä rasvaa nuolta huolehtimaksemme käsittelijän sitomisesta handleClick. Voit oppia lisää tästä tekniikasta täältä.

Käsite # 4: Kuinka komponentti-sovellusliittymä toimii

Olemme jo maininneet renderja setState, jotka ovat molemmat osa pientä komponentti-API-menetelmien joukkoa. Toinen hyödyllinen on constructor, jota voit käyttää alustamaan tilasi ja sidontamenetelmät.

Näiden kolmen toiminnon lisäksi React tarjoaa myös joukon takaisinkutsuja, jotka käynnistetään komponentin elinkaaren eri vaiheissa (ennen lataamista, lataamisen jälkeen, irrottamisen jälkeen ja niin edelleen). Ellet tee edistynyttä React voodoodia, sinun ei todennäköisesti tarvitse koskaan huolehtia näistä.

Jos tämä osa näyttää lyhyeltä, se johtuu siitä, että Reactin oppiminen on itse asiassa paljon enemmän ohjelmoinnin ja arkkitehtonisten käsitteiden hallitsemisesta kuin tylsän API-menetelmän oppimisesta. Tämä tekee siitä niin virkistävän!

Käsite # 5: Kuinka komponenttityypit toimivat

Olemme oppineet käyttämään luokkia komponentin määrittelemiseen:

class MyComponent extends React.Component {
 render() { return 

Hello World!

; }

}

Ja olemme puhuneet myös näiden luokkien tukemista komponenttimenetelmistä. Unohda nyt kaikki niistä! Yhä useammat ihmiset kirjoittavat React-komponentteja toiminnallisiksi komponenteiksi .

Toiminnallinen komponentti on funktio, joka ottaa propsobjektin argumentiksi ja palauttaa joukon HTML-koodeja. Melkein kuin perinteinen malli, tärkein ero, että voit silti käyttää mitä tahansa tarvitsemasi JavaScript-koodia kyseisen toiminnon sisällä:

const myComponent = props => {
 return 

Hello {props.name}! Today is {new Date()}.

}

Toiminnallisen komponentin syntaksin käytön seurauksena menetät pääsyn juuri puhuihimme komponenttimenetelmiin. Mutta käy ilmi, että käytännössä se on täysin hieno, koska suurin osa komponentteistasi ei todennäköisesti tarvitse niitä.

Muuten, yksi näistä menetelmistä on setState, ja tämä tarkoittaa, että toiminnallisilla komponenteilla ei voi olla tilaa. Tästä syystä heitä kutsutaan usein kansalaisuudettomiksi toiminnallisiksi komponenteiksi.

Koska toiminnalliset komponentit vaativat paljon vähemmän kattilakoodia, on järkevää käyttää niitä aina kun mahdollista. Tästä syystä useimmat React-sovellukset sisältävät terveellisen sekoituksen molemmista syntakseista.

Huomaa, että toiminnon avulla on myös kolmas, vanha perinteet createClass. Mutta kenenkään sitä käyttävän tulisi häpeä ja kutsua nimeksi, koska hän uskaltaa käyttää edelleen 18 kuukauden takaisia ​​koodausmalleja:

var Greeting = React.createClass({ render: function() { return 

Hello, {this.props.name}

; }
});

Käsite # 6: Kuinka komponenttiroolit toimivat

OK, valehtelin. Tosiasiassa on kuusi asiaa, ei viisi. Mutta mitä voin sanoa, elokuva ei ole nimeltään "Six Fingers Of Death". Vaikka nyt kun ajattelen sitä, se kuulostaa siltä, ​​että se olisi melko siisti elokuva, johon todennäköisesti sisältyisi jonkinlainen kosto-kung-kung-fu-mestari.

Mutta palataan käsillä olevaan aiheeseen. Nyt tulevat tylsät arkkitehtoniset käsitteet, joista puhuin. Joten jos mikään tästä ei ole järkevää, palaa takaisin, kun sinulla on ollut mahdollisuus pelata Reactin kanssa vielä.

Käytettyään Reactia jonkin aikaa ihmiset alkoivat nähdä kaksi erillistä koodin "makua" sisältyvän komponentteihinsa: yksi maku koski käyttöliittymälogiikkaa , kuten esityksen näyttäminen ja piilottaminen. Ja toinen oli kyse tietojen logiikan, kuten lastaus tietoja palvelimelle.

Tämä johti eroon kontti- ja esityskomponenttien välillä (tunnetaan myös joskus nimellä " älykkäät " ja " tyhmät " komponentit). Konttiosien tulisi käsitellä tietojasi, mutta - ja tämä on tärkeä osa - ei käyttöliittymääsi. Esityskomponentit ovat päinvastoin.

Toisin sanoen klassisessa tehtäväluettelon esimerkissä yksi komponentti lataa tiedot ja välittää ne sitten toiselle komponentille, joka vastaa todellisen HTML-merkinnän tuottamisesta ja paikallisten tilamuutosten käsittelemisestä.

Tämä on hyvin samanlainen kuin näkymän / ohjaimen malli, jonka saatat tuntea taustakehittäjäsi päiviltä. ( 'jäsen Rails?' jäsen Django? )

Kontti- / esittelyerot suositteli tässä blogikirjoituksessa Dan Abramov (Reduxin luoja), ja suosittelen tarkistamaan se, jos haluat kaivaa syvemmälle.

Korkeamman tilauksen komponentit

Ennen kuin käärimme asioita, meidän tulisi puhua vähän eräänlaisista konttiosista , jotka tunnetaan korkeamman asteen komponenteina (usein lyhennettynä HoC: ksi).

HoC on komponentti, jonka voit kiertää toisen komponentin ympärille erityisten rekvisiitojen välittämiseksi, ja se luodaan tyypillisesti korkeamman asteen komponenttitehdasfunktiolla . Huomaa, että ihmiset kutsuvat itse toimintoa "HoC: ksi", joka ei ehkä ole teknisesti 100-prosenttisesti oikea, mutta ei käytännössä kovin iso asia.

Esimerkiksi React Routerin withRoutertehdastoiminnon kutsuminen päälle nt>will wrap it in a new ponent)/> component that passes the Router prop to the afor e-mentioned &lt;MyComponent>.

You can think of a HoC function as a golf caddie that follows their golfer around and hands them the club they need it. By themselves, the caddie can’t actually do anything with the golf clubs. They’re just there to give the golfer access to more tools.

HoCs are a very powerful concept. For example, the Recompose library even lets you handle state changes through HoCs. In other words, you can now manage state without having to involve any ES6 class-based components.

With HoC composition becoming so common, it seems like React might be moving away from the ES6 class syntax and more towards a purely functional approach. Interesting times!

Recap

So let’s recap what we’ve just learned:

  • A React codebase is made up of components.
  • These components are written using JSX.
  • Data flows from parent to children, except when it comes to state, which originates inside a component.
  • Components possess a small set of lifecycle and utility methods.
  • Components can also be written as pure functions.
  • You should keep data logic and UI logic in separate components.
  • Higher-order components are a common pattern for giving a component access to new tools.

Believe it or not, we’ve just covered 90% of the knowledge used by a React developer on a daily basis. No matter how abstract or obscure the pattern, everything in React can always be boiled down to functions and props.

Once you truly understand this, React will stop being scary. You’ll be able to see patterns in the code, understand new codebases at a glance, and only then will you be able to proudly proclaim:

“Pfff! React is so 2015!”

Going Further

If I’ve managed to convince you that React isn’t so bad, you might want to take a stab at learning it properly. If so, I can’t recommend the React for Beginners video course enough. It’s how I learned React myself, and it’s actually just been updated to cover all the cool new stuff like functional stateless components:

If you don’t want your hard-earned dollars to finance the nefarious React lobby (I heard Dan Abramov is onto his third yacht), you can also learn for free by checking out this huge list of React resources.

And if you need to put all this newly-acquired knowledge in practice by contributing to a cool React open-source project, check out Telescope Nova. It’s the easiest way to quickly create a full-stack React + GraphQL app, complete with user accounts, forms, and data loading out of the box. And did I mention we’re looking for contributors?

Finally, if you’ve enjoyed this article, please share it and recommend it (that little green heart just below). And please let me know on Twitter what you’d like me to write about next!