Tälle loppuvuoden lomakaudelle React-tiimi on hiljattain ilmoittanut jännittävästä tutkimuksesta, joka koskee uutta tapaa rakentaa React-sovelluksia React Server Componentsin avulla.

Kannattaa muistaa, että React Server Components on vielä kehitteillä, eikä sitä suositella vielä tuotantoon. Ominaisuus on täysin valinnainen ja voit edelleen kirjoittaa komponenttisi kuten nykyäänkin.

Voit katsoa tunnin mittaisen puheen ja demon täältä, mutta tässä on 5 minuutin opas, joka korostaa ja selittää tärkeät asiat.

Myös, jos olet utelias siitä, miten Reactin uusilla komponenteilla on rooli tulevaisuuden suunnittelujärjestelmissä, suosittelen lukemaan:

Reactin palvelinkomponentti on tapa kirjoittaa React-komponentti, joka renderöidään palvelinpuolella tarkoituksena parantaa React-sovelluksen suorituskykyä.

Yksi ongelmista, joita kohdataan kehitettäessä sovelluksia Reactilla, on yleisesti suuri määrä verkkopyyntöjä, joita tehdään, kun käyttäjät odottavat, että heidän pyytämänsä sivu/tieto tulee saataville:

Datan hakeminen useEffectin avulla aiheuttaa viiveen mielekkäässä vuorovaikutuksessa

Yleinen lähestymistapa datan hakemiseen on nykyään esimerkiksi kutsua API-rajapintoja useEffectkoukulla:

useEffect(() => {
axios.get("URL HERE")
.then((response) => {
// set data into state setData(response.data);
})
.catch((error) => {
console.log(error);
});
}, );

Vaikka siinä ei olekaan mitään väärää, tämä tiedonhakua koskeva lähestymistapa maksaa aina jonkin verran aikaa, ennen kuin käyttäjälle renderöidään jotain mielekästä.

Toinen ongelma on tietysti nipun koko. Minifiointi, koodin pilkkominen, kuolleen koodin poistaminen ovat muutamia esimerkkejä menetelmistä, joita käytetään React-sovelluksen nipun koon pienentämiseen. Miksi? Koska suuri bundle-koko vie aikaa lataamiseen. Kaikilla ei ole käytössään nopeaa laitetta ja nopeaa internetiä:

Reactin bundle-ongelma

React-palvelinkomponentit auttavat ratkaisemaan kaksi edellä mainittua ongelmaa ja paljon muuta.

Miten React Server Components toimii

Koska React Server Components on vielä kokeiluvaiheessa, tämän ominaisuuden toteutuksen yksityiskohdat saattavat muuttua. Siitä huolimatta voit napata joitakin sen keskeisiä käsitteitä katsomalla demoa.

Ensimmäisenä huomaa, että package.json-tiedostossa on useita paketteja, joilla on kokeellinen versio:

"react": "0.0.0-experimental-3310209d0",
"react-dom": "0.0.0-experimental-3310209d0",
"react-fetch": "0.0.0-experimental-3310209d0",
"react-fs": "0.0.0-experimental-3310209d0",
"react-pg": "0.0.0-experimental-3310209d0",
"react-server-dom-webpack": "0.0.0-experimental-3310209d0",

react , react-dom ja react-server-dom-webpack käyttää kokeellista versiota, joka mahdollistaa React Server Componentin, kun taas react-fetch , react-fs ja react-pg on ryhmä wrapper-paketteja, joita käytetään vuorovaikutuksessa tulo/lähtöjärjestelmän kanssa (Niitä kutsutaan nimellä React IO-kirjastot)

Ylempänä on se, että tämä demo toimii Expressillä.js, mikä on järkevää, koska komponenttien renderöintiin tarvitaan palvelin. Mutta tämä herättää myös kysymyksen: tarkoittaako tämä, että palvelinkomponentit toimivat vain JavaScript-ympäristössä? Entä Go, Java ja muut palvelinpuolen ympäristöt?

Voi olla, että näemme tulevaisuudessa tuen muille ympäristöille, joten jätetään tämä kohta toistaiseksi sivuun.

Kaikki nämä toteutuksen yksityiskohdat voivat tietysti muuttua tulevaisuudessa tutkimuksen edetessä.

Siirryttäessä src/-kansion sisällä olevaan koodiin, voit nähdä kolmenlaisia laajennuksia komponenttitiedostoille:

  • .server.js-laajennus ilmaisee palvelinkomponentit
  • .client.js-laajennus ilmaisee React-asiakaskomponentit
  • Säännöllinen .js-laajennus on jaetuille komponenteille. Näitä komponentteja voidaan ajaa palvelimella tai asiakkaalla riippuen siitä, kuka ne tuo.

Kun sovellus käynnistetään npm start-komennolla, suoritetaan samanaikaisesti kaksi tehtävää:

  • Node-palvelin, joka suoritetaan server/api.server.js-skriptin avulla
  • Webpack-rakennus asiakaspuolen React-kokonaisuutta varten, jossa käytetään scripts/build.js-skriptiä

Katsomalla palvelinskripti, näet, että app.server.js tuodaan tiedostoon:

const ReactApp = require('../src/App.server').default;

Ja myöhemmin käsitellään Node Writable -virtana:

const {pipeToNodeWritable} = require('react-server-dom-webpack/writer');async function renderReactTree(res, props) {
await waitForWebpack();
const manifest = readFileSync(
path.resolve(__dirname, '../build/react-client-manifest.json'),
'utf8'
);
const moduleMap = JSON.parse(manifest);
pipeToNodeWritable(React.createElement(ReactApp, props), res, moduleMap);
}

.server.jslaajennuksen alla olevaa koodia riippuvuuksineen ei sisällytetä asiakaspakettiin, mikä tarkoittaa, että sillä ei ole mitään vaikutusta paketin kokoon.

Palvelinkomponenteilla on suora pääsy palvelimen tietokantaan tai tiedostojärjestelmään, joten voit poimia minkä tahansa tarvitsemasi tiedon ja lähettää sen asiakkaalle ensimmäisellä renderöinnillä. Näet esimerkin NoteList.server.js tiedostossa:

export default function NoteList({searchText}) {const notes = db.query(
`select * from notes where title ilike order by id desc`,

).rows;
return notes.length > 0 ? (
<ul className="notes-list">
{notes.map((note) => (
<li key={note.id}>
<SidebarNote note={note} />
</li>
))}
</ul>
) : (
<div className="notes-empty">
{searchText
? `Couldn't find any notes titled "${searchText}".`
: 'No notes created yet!'}{' '}
</div>
);
}

Palvelinkomponenteilla ei voi olla vuorovaikutteisuutta, mikä tarkoittaa, että et voi useState tai luoda kuuntelijoita palvelinpuolelle. Sinun täytyy laittaa tilat asiakaspuolelle ja tuoda ne palvelinkomponenteista.

Palvelinkomponentteihin ladataan dataa palvelimelta

Mikä on Reactin palvelinkomponentin hyöty?

  • Palvelinkomponentteja ei ole sisällytetty pakettiin. Selain ei koskaan lataa niitä, joten niillä ei ole mitään vaikutusta nipun kokoon
  • Voit pienentää nipun kokoa siirtämällä staattiset, vain renderöintikomponentit palvelinpuolelle ja pitämällä vuorovaikutteiset, tilalliset komponentit asiakaspuolella
  • Palvelinkomponentit voivat käyttää palvelinpuolen resursseja. Voit noutaa dataa suoraan tietokannasta tai tiedostojärjestelmästä, ja voit myös noutaa tietoja API:ista aivan kuten asiakaspuolella
  • Palvelinkomponentit voivat myös lukea GraphQL-kyselyitä

Miten se eroaa palvelinpuolen renderöinnistä?

SSR sellaisena, kuin se nykyään toimii React-sovelluksissa, on yksinkertaisesti HTML:ksi renderöityjen komponenttien lähettämistä asiakaspalvelimelle niin, että sovelluksellasi näyttäisi olevan nopea vastaus. Käyttäjä ei voi tehdä sovelluksellasi mitään ennen kuin JavaScript on ladattu.

Reactin palvelinkomponentit ovat erilaisia. Kuten demossa näkyy, palvelinkomponentteja ei renderöidä HTML:nä, vaan erityisessä muodossa, joka suoratoistetaan asiakkaaseen. Virralla ei ole toistaiseksi standardiprotokollaa, mutta se näyttää paljon JSON-muodolta. Tässä on pala vastausta:

M1:{"id":"./src/SearchField.client.js","chunks":,"name":""}

Mikäli SSR:ää käytetään vain kerran alustavaan renderöintiin, Server Components voidaan kutsua uudelleen useita kertoja datan (demon tapauksessa markdown-postien) uudelleen renderöimiseksi.

Johtopäätökset

Reactin Server Components on uusi jännittävä ominaisuus, joka voi muuttaa kehittäjien tapaa kirjoittaa React-sovelluksiaan. Sen avulla React-sovellukset voivat tuoda paketteja vaikuttamatta asiakkaan bundle-kokoon, luoden staattisen esityksen sovelluksesta, joka voidaan tehdä vuorovaikutteiseksi Client-komponenttien avulla.

Kehittäjät voivat myös käyttää sekä Server-komponentteja että Client-komponentteja yhden DOM-puun alla, mikä mahdollistaa palvelinkomponenttien noutamisen uudestaan ilman, että Client-komponenttien tila tuhoutuu.

Mutta, koska tämä ominaisuus on vielä kokeellinen, on vaikea määritellä, miten se on todella hyödyllinen vapaassa käytössä. Ensinnäkin tätä ominaisuutta voi tällä hetkellä käyttää vain Node.js-palvelinympäristössä.

React-tiimi keskittyy tällä hetkellä tämän ominaisuuden tuomiseen Next.js:n ja Gatbsyn kaltaisiin metakehyksiin, mikä tarkoittaa, että saattaa kestää jonkin aikaa (jos koskaan), ennen kuin näemme tuen muille palvelinpuolen kielille, kuten PHP:lle, Pythonille, Go:lle tai Rubylle.

Yhteenvetona voidaan todeta, että asiakaspuolen React ei ole katoamassa. Palvelinpuolen React on valinnainen.

Olen myös jakanut ajatuksiani aiheesta Pitäisikö luoda suunnittelujärjestelmä Reactin palvelinkomponenteille, mikä saattaa kiinnostaa sinua.

Articles

Vastaa

Sähköpostiosoitettasi ei julkaista.