Kā attīstīt savas React lielvaras, izmantojot HOC modeli

Sveiki visiem! ? Es ceru, ka jums bija priecīgi, priecīgi Ziemassvētki un laimīgs Jaunais gads!

2018. gads ir beidzies, un man ir jēga sākt jauno gadu ar rakstu par augstāka pasūtījuma komponentiem!

Es esmu apsolījis jums par to rakstīt, jo mēs esam vērsušies pie šī temata, kad esam runājuši par renderēšanas rekvizītiem un konteineru modeļiem, tāpēc ir jēga mazliet dziļi ienirt un pievērst tam uzmanību!

Personīgi tas nav viens no maniem iecienītākajiem modeļiem, bet tas ir spēcīgs rīks, kas jāzina, jāapgūst un jāpieliek pie sava rīka jostas.

Vienkārši paturiet prātā, ka nevajadzētu to pārmērīgi izmantot. Gandrīz visu, ko jūs varat iekapsulēt HOC, jūs noteikti varat ieviest, izmantojot renderēšanas rekvizītu modeli - skatiet manu rakstu par renderēšanas rekvizītiem šeit un otrādi.

01. Kas ir augstākas pakāpes komponents?

Augstākas kārtas komponents (HOC) ir uzlabota tehnoloģija React, lai atkārtoti izmantotu komponentu loģiku. HOC nav daļa no React API. Tie ir modelis, kas izriet no Reakta dabas, kas dod priekšroku kompozīcijai pār mantojumu.

JavaScript ir labi piemērota valoda funkcionālai programmēšanai, jo tā var pieņemt augstāka līmeņa funkcijas. Augstākas kārtas funkcija ir funkcija, kas var izmantot citu funkciju kā argumentu un / vai kā rezultātā atgriež funkciju.

Tādā pašā veidā augstākas pakāpes komponents ir funkcija, kas ņem (aptina) komponentu un atgriež jaunu komponentu .

Augstākas pakāpes funkcijas ļauj mums abstrakt darbībām, nevis tikai vērtībām.

HOC ir izplatīti trešo pušu React libs, piemēram, Redux vai React Router. Varu derēt, ka jūs esat izmantojis dažus no tiem, varbūt nemaz nezinot.

React augstākas pakāpes komponenta galvenais mērķis ir kopīgas funkcionalitātes koplietošana starp komponentiem, neatkārtojot kodu.

02. Augstākas kārtas komponentu veidi

Būtībā ir divi galvenie HOC ieviešanas veidi: Props Proxy un Mantojuma inversija .

Atbalsta starpniekserveris (ppHOC)

Atbalsta starpniekservera HOC elementāri tiek izteikti šādi:

Tas ir nekas cits kā funkcija propsProxyHOC, kas kā komponentu saņem komponentu (šajā gadījumā mēs esam saukuši argumentu WrappedComponent) un atgriež jaunu komponentu ar WrappedComponent iekšpusē.

Paturiet prātā, ka, atgriežot WrappedComponent, mēs arī izlaižam caur rekvizītiem, kurus HOC saņem. Tas izskaidro šim tipam piešķirto nosaukumu: props proxy .

Atgriežot iesaiņoto komponentu, mums ir iespēja manipulēt ar rekvizītiem un abstrahēties, pat ietot stāvokli kā balstu iesaiņotajā komponentā.

Iesaiņoto komponentu varat arī ietīt ar citiem JSX elementiem, mainot tā lietotāja saskarni atbilstoši jūsu lietotnes vajadzībām.

Atbalsta starpniekservera HOC ir noderīgi šādās situācijās:

  1. Manipulējošie rekvizīti
  2. Piekļuve instancei, izmantojot Refs (esiet piesardzīgs, izvairieties no refs lietošanas)
  3. Abstraktā valsts
  4. WrappedComponent iesaiņošana / komponēšana ar citiem elementiem

Mantojuma inversija (iiHOC)

Apgrieztā mantojuma HOC elementāri tiek izteikti šādi:

Šajā situācijā atgrieztā klase paplašina WrappedComponent. To sauc par Mantojuma inversiju, jo tā vietā, lai WrappedComponent paplašinātu kādu Enhancer klasi, tā tiek pasīvi paplašināta. Tādā veidā attiecības starp tām šķiet apgrieztas .

Mantojuma inversija nodrošina HOC piekļuvi WrappedComponent instancei, izmantojot šo , kas nozīmē, ka jūs varat izmantot stāvokli, rekvizītus, komponentu dzīves ciklu un pat renderēšanas metodi .

Inversijas mantojuma HOC ir noderīgi šādās situācijās:

  1. Render Highjacking
  2. Manipulējošais stāvoklis

03. Netīras mūsu rokas

Labi visiem? Lai nedaudz ilustrētu iepriekš izklāstītos jēdzienus, izdarīsim kodu.

Ja vēlaties vēlāk spēlēt ar kodu, kuru mēs darām, varat to izvilkt šeit no šī mana repo?

Mēģināsim ieviest komponentu, kas atgriež sveiciena ziņojumu atbilstoši lietotājam, kurš ir pieteicies sistēmā.

Esmu pārveidojis savu App.js komponentu, lai parādītu tekstu un renderētu komponentu ar nosaukumu Welcome, pie kura es nododu rekvizītu lietotāju.

Labi, mēs to varam izdarīt ar šādu vienkāršu komponentu:

Bet ...

Ko darīt, ja es vēlos, lai komponents atgrieztos sveiciena viesa statusā, ja neviens lietotājs nav pieteicies?

Nu ... es to varu izdarīt tajā pašā Welcome komponentā, ar vienkāršu, ja tas pārbauda, ​​vai lietotāja rekvizīts pastāv, un ja nē, tas vienkārši atgriež “Welcome Guest”.

Pieņemsim, ka es vēlos apkopot šo loģiku, lai to izmantotu ar vairākiem / dažādiem Welcome komponentiem.

Tātad ceļš ir izveidot props starpniekserveri HOC:

Ko mēs šeit esam izdarījuši? Mēs saglabājām mūsu Welcome komponentu vienkāršu un esam izveidojuši JavaScript funkciju ar nosaukumuUser, kas kā argumentu iegūst komponentu Welcome (WrappedComponent) un pārbauda, ​​vai pastāv rekvizītu lietotājs. Ja tas tā nav, tas vienkārši atgriež vienkāršu “Welcome Guest!” ziņu.

Tas ir ļoti noderīgi. Iedomājieties, ka jums bija 30 sveiciena komponentu dažādās valodās (dumjš piemērs, bet tas liek loģiku iekapsulēt HOC).

Patīkami, tāpēc tagad mums ir HOC, lai pārbaudītu, vai ir pieteicies lietotājs, pretējā gadījumā tas nosūta sveiciena viesa ziņojumu!

Tagad iedomāsimies, ka informācija par lietotāju nāk no ārējas API (piemēram, Auth0) un nonāk mūsu priekšējā lietojumprogrammā, izmantojot Redux reduktoru, kas pārvalda lietotnes stāvokli.

Tātad, pirms pārbaudām, vai ir kāds lietotājs, mums jāpārbauda, ​​vai dati ir ielādēti sistēmā!

Oho! Tādā veidā mēs varētu parādīt ielādes ziņojumu, kamēr dati nav ielādēti!

Tātad ... par šo lietošanas gadījumu es domāju, ka mēs vēlamies kaut ko padarīt par izcēlušos un padarīt citu lietu, ja dati nav ielādēti.

Render highjacking jāizmanto iiHOC. Oho! Tāda sakritība! Tātad darīsim to un sastādīsim abus HOC visus kopā? Tas spēcīgi iesitīs nagu galvā.

Pievērsiet uzmanību mūsu paveiktajam:

Mēs esam izveidojuši withLoader iiHOC, kas paplašina WrappedComponent. Tādējādi tas var piekļūt saviem rekvizītiem un izraisīt atšķirīgu renderēšanu.

Šajā situācijā mēs iegūstam isLoaded rekvizītu, un, ja tas nav ielādēts, mēs vienkārši atgriežam iekraušanas ziņojumu! Pretējā gadījumā mēs ļaujam renderēt WrappedComponent, vienkārši atgriežot super.render ().

Eksporta paziņojumā mēs vienkārši sastādām divas JavaScript funkcijas, piemēram, f1 (f2 (f3))). Nekas vairāk par to!

Ir rīki, lai sakārtotu funkcijas glītākā veidā, bet tas ir cits stāsts citam rakstam!

04. Pēdējais, bet ne mazāk svarīgais

Es mēģināju izmantot vienkāršus piemērus, lai jūs pēc iespējas skaidrāk saprastu jēdzienus.

Mans padoms jums ir tāds, ka, ja jūs nepārzināt šos jēdzienus, lūdzu, pavelciet manu repo šeit un nedaudz spēlieties ar to.

Pārbaudiet kodu un mēģiniet to saprast pa rindai.

Ir vajadzīgs zināms laiks, lai pierastu un justos ērti, veicot šāda veida abstrakcijas, tāpēc nezaudējiet savu motivāciju vai uzmanību HOC.

Tāpat kā es teicu iepriekš, visu, ko mēs šeit esam izdarījuši, var sasniegt ar renderēšanas rekvizītiem vai konteinera modeli, tāpēc nav obligāti jāizvēlas HOC vai divi, lai veiktu tīru kodu ar šāda veida iekapsulēšanu!

Es ceru, ka jums bija tikpat jautri lasīt šo rakstu, kā man to rakstot! Ja jums tas patiešām patika, lūdzu, iedodiet man dažus klapus (lūdzu, ne mazāk par 50)? un vienmēr atcerieties: “Esiet spēcīgs un kodējiet!

Vai arī, ja vēlaties saņemt dziļākus un sarežģītākus paskaidrojumus, lūdzu, izlasiet saites, kuras esmu pievienojis tālāk esošajai sadaļai Bibliogrāfija?

05. Bibliogrāfija

  1. Reaģēt dokumentāciju

2. Daiļrunīgs Javascript

3. Padziļināti reaģējiet augstākas kārtas komponentus

Liels paldies!

priekšvakarā, 2018. gada decembrī