React's Five Fingers of Death. Mestre disse fem koncepter, og mestre derefter React.

For et par år siden begyndte min ven Sean at fortælle mig, hvordan dette helt nye frontend-bibliotek kaldet React skulle overtage internettet. Først afviste jeg det som bare endnu en rammefad. Men så begyndte jeg at høre om Reager mere og mere, til det punkt, hvor jeg havde lyst til at ignorere det bare ikke var en mulighed længere.

Måske er du i den samme position som jeg var i: du har hørt om Reager til venstre og højre, men faktisk sidder du ned og lærer det føles som sådan en opgave.

Den gode nyhed er, at du kan koge alt hvad du behøver at vide om Reager ned til fem nøglekoncepter .

Gør mig ikke forkert, det betyder ikke, at jeg kan forvandle dig til en React-mester med det samme. Men i det mindste forstår du alle de store koncepter, hvis du beslutter dig for at springe ind.

De fem nøglebegreber er:

  1. Komponenter
  2. JSX
  3. Rekvisitter og stat
  4. Component API
  5. Komponenttyper

Før vi kommer i gang, skal du bemærke, at jeg oprindeligt lærte React gennem Wes Bos kurser og har inkluderet et par tilknyttede links til dem. Når det er muligt, har jeg også inkluderet links til gratis ressourcer.

Åh, og min ven Sean? Han er siden gået videre til meget mere banebrydende ting. Når alt kommer til alt er React 2015.

Koncept nr. 1: Hvordan reaktionskomponenter fungerer

Den første ting du skal vide om React er, at det hele handler om komponenter . Din React-kodebase er stort set kun en stor bunke med store komponenter, der kalder mindre komponenter.

Men hvad er en komponent, spørger du? Et perfekt eksempel på en komponent er det fælles 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!

; }

}

Koncept nr. 2: Hvordan JSX fungerer

Som du kan se, betyder komponenttilgangen, at både HTML- og JavaScript-kode lever i den samme fil. React's hemmelige våben for at opnå denne uhellige alliance er JSX-sproget (hvor "X" står for "XML").

JSX kan synes akavet i starten, men du vænner dig til det ret hurtigt.

Ja, det ved jeg. Vi har alle lært at opretholde en stærk adskillelse mellem HTML og JavaScript. Men det viser sig, at det at slappe af disse regler faktisk kan gøre underværker for din front-end produktivitet.

For eksempel, da du nu har den fulde kraft af JavaScript til din rådighed, kan du her se, hvordan du kan vise den aktuelle dato ved at indsætte et JavaScript-uddrag i din HTML ved hjælp af {...}:

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

Today is: {new Date()}

; }
}

Dette betyder også, at du bruger almindelig JavaScript til ifudsagn eller sløjfer, snarere end en slags skabelonspecifik syntaks. JavaScript's ternære operatør kommer især til nytte her:

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

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

; }
}

Og forresten, hvis du har brug for at pusse op på de nyeste punkter i JavaScript-syntaks, anbefaler jeg ES6 for alle af Wes Bos (hvis du kan lide videoer) eller Praktisk ES6 af Nicolas Bevacqua (hvis du foretrækker at læse).

Koncept # 3: Hvordan rekvisitter og stat fungerer

Måske har du spekuleret på, hvor this.props.someVarvariablen ovenfor kommer fra.

Hvis du nogensinde har skrevet en linje med HTML, er du sandsynligvis fortrolig med HTML-attributter som <; a> tag’s href. I React kendes attributter som rekvisitter (forkortelse for "egenskaber"). Rekvisitter er, hvordan komponenter taler med hinanden.

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

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

; }
}

På grund af dette er Reacts datastrøm envejs : data kan kun gå fra forældrekomponenter til deres børn, ikke omvendt.

Nogle gange skal en komponent imidlertid reagere på data, der ikke kommer fra en overordnet komponent (f.eks. Brugerinput). Og det er her staten kommer ind.

En god metafor til at forstå forskellen mellem rekvisitter og tilstand ville være Etch-A-Sketch. I modsætning til ting som kropsfarven og drejepositionen på Etch-A-Sketch-tabletten ( rekvisitter ), er selve tegningen ( tilstand ) ikke en iboende egenskab ved Etch-A-Sketch. Det er bare det midlertidige resultat af brugerinput.

Bemærk, at en komponents tilstand også kan overføres til sine egne børn som en prop . Du kan tænke på dette som en stor flod, der strømmer ned ad bakke, med routeren, datalaget og forskellige komponenter, der hver tilføjer deres egen lille datastrøm for at danne den vigtigste app-tilstand.

Inde i en komponent styres tilstand ved hjælp af setStatefunktionen, som ofte kaldes inde i en begivenhedshåndterer:

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

I praksis vil langt de fleste data i en React-app være en støtte . Det er kun når du har brug for at acceptere brugerinput, at du bruger tilstanden til at håndtere ændringen.

Bemærk, at vi bruger en fed pil her til at tage os af at binde handleClickhandler. Du kan lære mere om denne teknik her.

Koncept # 4: Hvordan Component API fungerer

Vi har allerede nævnt, renderog setStatesom begge er en del af et lille sæt af komponent-API-metoder. En anden nyttig er den constructor, som du kan bruge til at initialisere din tilstand og bindemetoder.

Bortset fra disse tre funktioner giver React også et sæt tilbagekald, der udløses på forskellige punkter i komponentens livscyklus (inden indlæsning, efter indlæsning, efter afmontering osv.). Medmindre du laver noget avanceret React-voodoo, behøver du sandsynligvis næsten aldrig bekymre dig om disse.

Hvis dette afsnit virker kort, skyldes det, at læring af React faktisk handler meget mere om at mestre programmering og arkitektoniske begreber snarere end at lære et sæt kedelige API-metoder. Dette er, hvad der gør det så forfriskende!

Koncept # 5: Hvordan komponenttyper fungerer

Vi har set, hvordan man bruger klasser til at definere en komponent:

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

Hello World!

; }

}

Og vi har også talt om de komponentmetoder, der understøttes af disse klasser. Glem alt om dem nu! Mere og mere skriver folk React-komponenter som funktionelle komponenter .

En funktionel komponent er en funktion, der tager et propsobjekt som argument og returnerer en række HTML. Næsten som en traditionel skabelon med nøgleforskellen, at du stadig kan bruge den JavaScript-kode, du har brug for inden for den funktion:

const myComponent = props => {
 return 

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

}

Konsekvensen af ​​at bruge den funktionelle komponentsyntaks er, at du mister adgang til de komponentmetoder, vi lige har talt om. Men det viser sig, at det i praksis er helt fint, da langt størstedelen af ​​dine komponenter sandsynligvis ikke har brug for dem.

Forresten er en af ​​disse metoder setState, og det betyder, at funktionelle komponenter ikke kan have tilstand. Af den grund omtales de ofte som statsløse funktionelle komponenter.

Da funktionelle komponenter kræver meget mindre kedelpladekode, er det fornuftigt at bruge dem, når det er muligt. Af denne grund indeholder de fleste React-apps en sund blanding af begge syntakser.

Bemærk, at der også er en tredje, ældre syntaks, der bruger createClassfunktionen. Men enhver, der bruger det, skal skamme sig og kaldes navne for at turde stadig bruge kodningsmønstre fra 18 måneder siden:

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

Hello, {this.props.name}

; }
});

Koncept # 6: Hvordan komponentroller fungerer

OK, jeg løj. Der er faktisk seks ting, ikke fem. Men hvad kan jeg sige, filmen hedder ikke "Six Fingers Of Death." Selvom jeg nu tænker over det, lyder det som om det ville være en temmelig sej film, der sandsynligvis involverer en slags fremmed kung-fu-mester, der søger hævn.

Men tilbage til det aktuelle emne. Nu kommer de kedelige arkitektoniske koncepter, jeg talte om. Så hvis intet af dette giver mening, er du velkommen til at komme tilbage, når du har haft en chance for at lege med React mere.

Efter at have brugt React i et stykke tid begyndte folk at se to forskellige “smagsvarianter” af kode vises i deres komponenter: en smag var bekymret for UI- logik som at vise og skjule ting. Og den anden var alt om data logik, såsom indlæsning af data fra din server.

Dette førte til sondringen mellem container- og præsentationskomponenter (også undertiden kendt som " smarte " og " dumme " komponenter). Containerkomponenter skal håndtere dine data, men - og dette er den vigtige del - ikke din brugergrænseflade. Præsentationskomponenter er lige det modsatte.

Med andre ord, i det klassiske opgavelisteeksempel, vil en komponent indlæse dataene og derefter videregive disse data til en anden komponent, der har ansvaret for at udgive den aktuelle HTML-markering og håndtering af lokale tilstandsændringer.

Dette svarer meget til det visnings- / controller-mønster, du måske er bekendt med fra dine back-end-udviklerdage. ( 'medlem Rails?' medlem Django? )

Distinktionen mellem container og præsentation blev populær i dette blogindlæg af Dan Abramov (skaberen af ​​Redux), og jeg anbefaler at tjekke det ud, hvis du vil grave dybere.

Komponenter af højere orden

Inden vi afslutter tingene, skal vi tale lidt om en type containerkomponenter, der kaldes komponenter af højere orden (ofte forkortet som HoCs).

En HoC er en komponent, som du kan pakke rundt om en anden komponent for at give den specielle rekvisitter, og den oprettes typisk ved hjælp af en fabriksfunktion af højere orden . Bemærk, at folk ofte henviser til selve funktionen som en “HoC”, som måske ikke er 100% korrekt teknisk, men ikke er en stor ting i praksis.

Som et eksempel kaldes React Routers withRouterfabriksfunktion til 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!