– Não é renderização do lado do servidor.
O ano 2020 tem sido uma viagem louca para todos nós. Para este fim de ano de férias, a equipe React anunciou recentemente uma pesquisa empolgante sobre uma nova maneira de construir aplicações React com React Server Components.
>
Por favor tenha em mente que React Server Components ainda está em desenvolvimento e ainda não é recomendado para produção. O recurso é completamente opcional e você ainda pode escrever seu componente como faz hoje.
Você pode assistir a palestra de uma hora e a demonstração aqui, mas aqui está um guia de 5 minutos que destaca e explica as partes importantes.
Também, se você está curioso sobre como os novos componentes do React desempenham um papel em futuros sistemas de design, eu recomendo que você leia:
React Server Component é uma forma de escrever o componente React que é renderizado no lado do servidor com o propósito de melhorar o desempenho do aplicativo React.
Um dos problemas enfrentados ao desenvolver aplicações com React é o alto número comum de solicitações de rede feitas enquanto os usuários aguardam a página/dados que eles solicitaram para ficar disponível:
Por exemplo, a abordagem comum para a obtenção de dados hoje é chamar APIs usando o gancho useEffect:
useEffect(() => {
axios.get("URL HERE")
.then((response) => {
// set data into state setData(response.data);
})
.catch((error) => {
console.log(error);
});
}, );
Embora não haja nada de errado com isso, essa abordagem de busca de dados sempre custará algum tempo para tornar algo significativo para o usuário.
O outro problema é, claro, o tamanho do pacote. Minificação, divisão de código, eliminação de código morto são alguns exemplos de métodos usados para reduzir o tamanho do pacote da aplicação React. Porquê? Porque um grande tamanho de pacote leva tempo para ser descarregado. Nem todos têm acesso a um dispositivo rápido e internet rápida:
React Server Components ajudará a resolver os dois problemas acima e muito mais.
Como funcionam os componentes do React Server
Porque os componentes do React Server ainda estão em fase experimental, os detalhes de implementação deste recurso podem mudar. Mesmo assim, você pode pegar alguns de seus conceitos centrais olhando para a demonstração.
A primeira coisa a notar é que existem vários pacotes com uma versão experimental no arquivo package.json:
"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",
O react , react-dom e react-server-dom-webpack está usando uma versão experimental que habilita o React Server Component, enquanto react-fetch , react-fs e react-pg é um grupo de pacotes wrapper usados para interagir com o sistema de entrada/saída (Eles são chamados de React IO Libraries)
O próximo ponto é que este demo é alimentado pelo Express.js, o que faz sentido porque você precisa de um servidor para renderizar os componentes. Mas isso também levanta a questão: isso significa que os componentes do servidor só funcionam em um ambiente JavaScript? E quanto a Go, Java e outros ambientes do lado do servidor?
Pode haver suporte para outros ambientes no futuro, então vamos deixar esse ponto de lado por enquanto.
Obviamente, todos esses detalhes de implementação podem mudar no futuro, à medida que a pesquisa progredir.
Movendo para o código dentro da pasta src/, você pode ver três tipos de extensões para os arquivos de componentes:
-
.server.jsextensão indica um Componentes do Servidor -
.client.jsextensão indica Componentes do Cliente Reagir - A extensão regular
.jsé para componentes compartilhados. Estes componentes podem ser executados no servidor ou no cliente, dependendo de quem os está importando.
Quando você inicia a aplicação com o comando npm start, duas tarefas serão executadas simultaneamente:
- O servidor de Nodos rodando usando o script
server/api.server.js - O build do Webpack para o pacote React do lado do cliente, usando o script
scripts/build.js
Olhando para o script do servidor, você pode ver que o app.server.js está sendo importado para o arquivo:
const ReactApp = require('../src/App.server').default;
E depois é processado como Node Writable stream:
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);
}
O código sob .server.js extensão incluindo suas dependências não está incluído no pacote cliente, o que significa que ele tem efeito zero no tamanho do pacote.
Os componentes do servidor têm acesso direto ao banco de dados ou ao sistema de arquivos no servidor, assim você pode pegar os dados que precisar e enviá-los para o cliente no primeiro renderizador. Você pode ver o exemplo em NoteList.server.js file:
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>
);
}
Server Components can’t have any interactivity, which means you can’t useState or create listeners on the server-side. Você precisa colocar estado no lado do cliente e importá-los do lado do servidor.
Qual é o benefício dos componentes do React Server?
- Os componentes do servidor não estão incluídos no pacote. Eles nunca são baixados pelo navegador, tendo efeito zero sobre o tamanho do pacote
- Você pode reduzir o tamanho do seu pacote movendo os componentes estáticos, renderizando apenas para o lado do servidor e mantendo os componentes interativos no lado do cliente
- Os componentes do servidor podem acessar os recursos do lado do servidor. Você pode buscar dados do banco de dados ou do sistema de arquivos diretamente, e também pode buscar de APIs como no lado do cliente
- Os componentes do servidor também podem ler consultas de GraphQL
Como isso é diferente da renderização do lado do servidor?
SSR como funciona hoje em dia em aplicações React está simplesmente enviando componentes renderizados como HTML para o cliente para que sua aplicação pareça ter uma resposta rápida. O usuário não pode fazer nada com o seu aplicativo até que o JavaScript seja baixado.
React Server Components é diferente. Como mostrado na demonstração, os componentes do servidor não são renderizados como HTML, mas como um formato especial que é transmitido para o cliente. O stream não tem protocolo padrão por enquanto, mas se parece muito com o formato JSON. Aqui está uma parte da resposta:
M1:{"id":"./src/SearchField.client.js","chunks":,"name":""}
Onde o SSR é usado apenas uma vez para a renderização inicial, os Componentes do Servidor podem ser buscados várias vezes para renderizar novamente os dados (no caso do demo, as postagens de markdown).
Conclusion
React Server Components é um novo recurso excitante que pode mudar a forma como os desenvolvedores escrevem sua aplicação React. Ele permite que as aplicações React importem pacotes sem afetar o tamanho do pacote do cliente, criando uma representação estática da aplicação que pode ser interativa usando os Componentes do Cliente.
Os desenvolvedores também podem usar tanto os Componentes do Servidor quanto os Componentes do Cliente sob uma única árvore DOM, permitindo que você volte a buscar os componentes do servidor sem destruir o estado dos componentes do cliente.
Mas como esta característica ainda é experimental, é difícil determinar como ela será realmente útil na natureza. Por exemplo, esta funcionalidade só pode ser usada sob o ambiente servidor Node.js atualmente.
A equipe React está atualmente focada em trazer esta funcionalidade para meta-frameworks como Next.js e Gatbsy, o que significa que pode demorar algum tempo (se algum dia) até vermos suporte para outras linguagens do lado do servidor como PHP, Python, Go, ou Ruby.
Para recapitular, o Client-side React não vai embora. Server-side React é opcional.
Também, eu partilhei os meus pensamentos acerca de Should you create a design system for React Server Components? que possa interessar-lhe.