Na React Conf 2019 nós anunciamos uma versão experimental do React que acrescenta suporte ao Modo Concorrente e Suspense. Nesse artigo nós vamos introduzir as melhores práticas para seu uso que nós identificamos durante o processo de construção do novo facebook.com.
\n\n\nEsse artigo será mais relevante para pessoas que trabalham com as bibliotecas de obtenção de dados (data fetching) para React.
\nMostramos como integrar melhor elas com o Modo Concorrente e o Suspense. Os padrões introduzidos aqui são baseados no Relay — nossa biblioteca para construir interfaces de usuário orientadas a dados com GraphQL. De qualquer forma, as ideias desse artigo se aplicam a outros clientes GraphQL também assim como bibliotecas que usam REST ou outras abordagens.
\n
Esse artigo é dedicado aos autores de bibliotecas. Se você for principalmente desenvolvedor de aplicações, você ainda pode encontrar ideias interessantes aqui, mas não se sinta obrigado a lê-lo inteiramente.
\nSe você preferir assistir vídeos, algumas das ideias desse artigo foram abordadas em diversas apresentações da React Conf 2019:
\nEsse artigo apresenta um mergulho na implentação de uma biblioteca de obtenção de dados com Suspense.
\nA equipe do React e a comunidade tem constantemente enfatizado a experiência do desenvolvedor: garantindo que o React tenha boas mensagens de erro, focando em componentes como uma maneira de pensar localmente no comportamento do app, desenvolvendo APIs que são previsíveis e encorajando o correto uso via design, etc. Mas nós não temos difundido o suficiente as melhores práticas para garantir uma ótima experiência de usuário em grandes aplicações.
\nPor exemplo, a equipe do React tem focado na performance da biblioteca e provido ferramentas para desenvolvedores debugarem e refinarem a performance da aplicação (ex. React.memo). Mas nós não temos opinado sobre padrões de alto nível que fazem a diferença entre aplicativos rápidos e fluídos e aplicativos lentos e travados. Nós sempre queremos garantir que o React se mantenha acessível a novos usuários e suporte vários de casos uso — nem todo app tem que ser “super” rápido. Mas como uma comunidade nós podemos e devemos sonhar alto. Nós devemos fazer ser tão fácil quanto possível construir aplicativos que iniciam rápido e continuam rápidos, mesmo quando eles crescem em complexidade, para usuários utilizando uma variedade de dispositivos e redes no mundo todo.
Modo Concorrente e Suspense são funcionalidades experimentais que podem ajudar os desenvolvedores a alcançarem esse objetivo. Nós inicialmente apresentamos eles na JSConf Iceland em 2018, intencionalmente compartilhando detalhes muito antecipadamente para dar a comunidade tempo para digerir os novos conceitos e para se prepararem para as alterações seguintes. Desde então nós completamos trabalhos correlacionados, como a nova API de Contexto e a introdução do Hooks, que foram desenhados em parte para ajudar os desenvolvedores a escreverem código que seja naturalmente mais compatível com o Modo Concorrente. Mas nós não queremos implementar essas funcionalidades e liberá-las sem garantir que funcionam. Então ao longo do ano passado, as equipes do React, Relay, infraestrutura web, e produto do Facebook têm todas colaborado fortemente para construir uma nova versão do facebook.com que integre profundamente o Modo Concorrente e o Suspense para criar uma experiência com uma sensação mais fluída e similar a de um app.
\nGraças a esse projeto, nós estamos mais confiantes do que nunca de que o Modo Concorrente e o Suspense podem tornar mais fácil entregar uma experiência de usuário ótima e rápida. Mas fazer isso requer repensar como nós abordamos o carregamento do código e dos dados em nossos apps. Efetivamente toda a obtenção de dados no novo facebook.com é realizada pelo Relay Hooks — novas APIs do Relay baseadas em Hooks que integram com o Modo Concorrente e o Suspense sem configurações adicionais.
\nRelay Hooks — e GraphQL — não são para todos, e tudo bem com isso! Através do nosso trabalho nessas APIs nós identificamos um conjunto de padrões em geral para utilizar com Suspense. Mesmo que o Relay não se encaixe para você, nós acreditamos que os padrões chave que nós introduzimos com o Relay Hooks podem ser adaptados para outras bibliotecas
\nÉ tentador focar apenas no tempo total de inicialização de um app — mas ocorre que a percepção de performance pelo usuário é determinada por mais do que o tempo absoluto de carregamento. Por exemplo, quando comparados dois aplicativos com o mesmo tempo absoluto de inicialização, nossos estudos mostram que os usuários geralmente irão perceber aquele que tiver menos estados de carregamento intermediários e menos alterações de layout como o que carrega mais rápido. Suspense é uma ferramenta poderosa por orquestrar cuidadosamente uma elegante sequência de carregamento com poucos, e bem definidos, estados que revelam progressivamente o conteúdo. Mas melhorar a performance percebida vai além disso — nossos apps não deveriam demorar uma eternidade para obter todo o código, dados, imagens, e outros artefatos.
\nA abordagem tradicional para carregar dados nos apps React envolvem o que nos referimos como “renderização-conforme-você-busca”. Primeiro nós renderizamos um componente com um spinner, então carregamos dados na montagem (componentDidMount ou useEffect), e finalmente atualizamos para renderizar os dados resultantes. É certamente possível usar esse padrão com Suspense: ao invés de inicialmente renderizar um placeholder por si mesmo, um componente pode “suspender” — indicar ao React que ele não está pronto ainda. Isso irá dizer ao React para buscar o ancestral mais próximo <Suspense fallback={<Placeholder/>}>, e renderizar o seu fallback no lugar. Se você viu os demos do Suspense anteriormente este exemplo pode parecer familiar — é como nós originalmente imaginamos usar o Suspense para obtenção de dados.
Ocorre que esta abordagem tem algumas limitações. Considere uma página que mostra uma postagem de mídia social feita por um usuário, com comentários nessa postagem. Ela pode ser estruturada como um componente <Post> que renderiza tanto o corpo da postagem como a <CommentList> para mostrar os comentários. Usando a abordagem de renderização-conforme-você-busca descrita acima para implementar isso pode causar idas e voltas sequenciais (muitas vezes conhecido como uma “cachoeira”). Primeiro os dados para o componente <Post> seriam obtidos e então os dados para a <CommentList>, aumentando o tempo que para mostrar a página completamente.
Há também outra desvantagem muitas vezes esquecida nessa abordagem. Se o <Post> requisita (ou importa) o componente <CommentList> de maneira completa, nosso app terá de esperar para mostrar o corpo da postagem enquanto o código para os comentários é baixado. Nós poderíamos carregar a <CommentList> de maneira preguiçosa, mas dessa forma nós iríamos atrasar a obtenção dos dados dos comentários e aumentar o tempo para exibir a página inteira. Como nós resolvemos esse problema sem comprometer a experiência do usuário?
A abordagem de renderização-conforme-você-busca é amplamente utilizada pelos apps React atualmente e pode certamente ser usada para criar ótimos apps. Mas nós conseguiríamos fazer ainda melhor? Vamos voltar um passo atrás e considerar nosso objetivo.
\nNo exemplo acima do <Post>, nós idealmente deveríamos mostrar o conteudo mais importante — o corpo da postagem — o mais rápido possível, sem impactar negativamente o tempo para mostrar a página completamente (incluindo comentários). Vamos considerar as restrições em qualquer solução e observar como nós podemos atendê-las:
<CommentList> é baixado, por exemplo.Isso pode soar difícil de alcançar — mas essas restrições são na verdade incrivelmente facilitadoras. Elas descartam uma série de abordagens e nos desenham um rascunho da solução. Isso nós leva aos padrões chave que nós implementamos no Relay Hooks, e que podem ser adaptados para outras biblotecas de obtenção de dados. Veremos cada desses padrões de maneira a entender como podem nos ajudar a alcançar nosso objetivo de experiências de carregamento rápidas e encatadoras:
\nUma das coisas mais atraentes no padrão de renderização-conforme-você-busca é que ele combina quais dados o componente precisa com como renderizar esses dados. Essa combinação é ótima — um exemplo de como faz sentido agrupar código por responsabilidades e não por tecnologias. Todos os problemas que nós vimos acima foram sobre quando nós obtemos os dados nessa abordagem: após a renderização. Nós precisamos precisamos ser capazes de obter dados antes de renderizar o componente. A única forma de alcançar isso é extraindo as dependências de dados em dados em paralelo e árvores de visualização.
\nAqui mostramos como isso funciona no Relay Hooks. Continuando nosso exemplo de uma postagem de mídia social com corpo e comentários, aqui está como definimos isso no Relay Hooks:
\n// Post.js\nfunction Post(props) {\n // Dado uma referência para alguma postagem - `props.post` - *de quais* dados\n // nós precisamos sobre essa postagem?\n const postData = useFragment(graphql`\n fragment PostData on Post @refetchable(queryName: \"PostQuery\") {\n author\n title\n # ... mais campos ...\n }\n `, props.post);\n\n // Agora que nós temos os dados, como renderizá-lo?\n return (\n <div>\n <h1>{postData.title}</h1>\n <h2>by {postData.author}</h2>\n {/* mais campos */}\n </div>\n );\n}Embora o GraphQL esteja escrito junto ao componente, Relay tem um passo de build (Compilador do Relay) que extrai essas dependências-de-dados em arquivos separados e agrega o GraphQL para cada visualização em uma única consulta. Então nós obtemos os benefícios de combinar responsabilidades, enquanto no tempo de execução temos dados em paralelo e árvores de visualização. Outras bibliotecas poderiam alcançar resultados similares ao permitir que os desenvolvedores definam lógica de obtenção de dados em um arquivo irmão (talvez Post.data.js), ou então integrar com um bundler para permitir definição de dependência de dados com código de interface de usuário e automaticamente extraí-lo, de maneira semelhante ao Compilador do Relay.
O segredo é que independente da tecnologia que estamos usando para carregar nossos dados — GraphQL, REST, etc — nós podemos separar quais dados carregar de como e quando fazê-lo. Mas uma vez feito isso, como e quando nós carregamos nossos dados?
\nImagine que nós estamos para navegar da listagem de postagens de um usuário para a página de uma postagem específica. Nós vamos precisar baixar o código para aquela página — Post.js — e também obter seus dados.
Aguardar até que a gente renderize os dados gera os problemas que nós vimos acima. O segredo é começar a obter o código e os dados para a nova visualização no mesmo manipulador de evento que dispara a visualização. Nós ainda podemos obter os dados com nosso roteador — se nosso roteador suporta pré-carregamento de dados para as rotas — ou no evento de clique no link que disparou a navegação. Vale lembrar que os colegas do React Router já trabalharam arduamente para construir APIs para suportarem pré-carregamento de dados para rotas. Mas outras bibliotecas de roteamento podem implementar essa ideia também.
\nConceitualmente, nós queremos que a definição de cada rota inclua duas coisas: qual componente renderizar e que dados pré-carregar, como uma função de rota/parâmetros de url. Aqui está o que esta definição de rota pode parecer. Este exemplo é um pouco inspirado pelas definições de rota do React Router e principalmente se dedica a demonstrar o conceito, não uma API específica:
\n// PostRoute.js (GraphQL version)\n\n// Consulta do Relay para carregamento dos dados do Post\nimport PostQuery from './__generated__/PostQuery.graphql';\n\nconst PostRoute = {\n // uma expressão que associa qual rota tratar\n path: '/post/:id',\n\n // que componente renderizar para essa rota\n component: React.lazy(() => import('./Post')),\n\n // dados a serem carregados para essa rota, como uma função dos parâmetros\n // da rota\n prepare: routeParams => {\n // Relay extrai consultas de componentes, nos permitindo referenciar\n // as dependências de dados -- árvore de dados -- de fora.\n const postData = preloadQuery(PostQuery, {\n postId: routeParams.id,\n });\n\n return { postData };\n },\n};\n\nexport default PostRoute;Por definição, um roteador pode:
\nprepare() para iniciar o carregamento dos dados da rota. Note que prepare() é síncrona — nós não queremos esperar pelos dados, dado que nós queremos começar a renderizar as partes mais importantes da visualização (como o corpo da postagem) o mais rápido que possível.React.lazy terminou — o componente irá renderizar e tentar acessar os seus dados. Do contrário, o React.lazy irá suspender até que o código esteja pronto.Esta abordagem pode ser generalizada para outras soluções de obtenção de dados. Um app que usa REST poderia definir uma rota dessa forma:
\n// PostRoute.js (versão em REST)\n\n// Lógica escrita manualmente para carregamento dos dados para o componente\nimport PostData from './Post.data';\n\nconst PostRoute = {\n // uma expressão que associa qual rota tratar\n path: '/post/:id',\n\n // que componente renderizar para essa rota\n component: React.lazy(() => import('./Post')),\n\n // dados a serem carregados para essa rota, como uma função dos parâmetros\n // da rota\n prepare: routeParams => {\n const postData = preloadRestEndpoint(\n PostData.endpointUrl, \n {\n postId: routeParams.id,\n },\n );\n return { postData };\n },\n};\n\nexport default PostRoute;Esta mesma abordagem pode ser empregada não apenas para roteamento, mas em outros lugares onde nós queiramos mostrar conteúdo de maneira preguiçosa ou baseada na interação do usuário. Por exemplo, um componente de aba poderia carregar completamente os dados e o código para a primeira aba, e então usar o mesmo padrão acima para carregar o código e os dados para as outras abas que estão no manipulador de evento de troca de aba. Um componente que mostra um modal poderia pré-carregar o código e os dados para o modal no manipulador de clique que dispara a abertura do modal, e assim por diante.
\nUma vez que implementamos a habilidade de começar a carregar código e dados de uma visualização de maneira independente, nós temos a opção de ir um passo além. Considere um componente <Link to={path} /> que faz o link para uma rota. Se o usuário passa sobre este link, existe uma chance razoável de que ele irá clicá-lo. E se ele pressionar o mouse, existe uma chance ainda maior de que ele irá completar o clique. Se nós podemos carregar o código e os dados para uma visualização depois de o usuário clicar, nós também podemos iniciar o trabalho antes deles clicarem, começando a preparar a visualização.
O melhor de tudo, nós podemos centralizar essa lógica em poucos lugares chave — um roteador ou em componentes centralizadores de interação com o usuário — e obter quaisquer benefícios de performance automaticamente em todo nosso app. Claro que pré-carregar nem sempre é benéfico. É algo que um aplicativo pode otimizar baseado no dispositivo do usuário ou velocidade de rede para evitar consumir os planos de dados do usuário. Mas este padrão torna mais fácil centralizar a implementação do pré-carregamento e a decisão de quando habilitá-lo ou não.
\nOs padrões acima — dados em paralelo/árvores de visualização e obtenção em manipuladores de evento — nos permitem iniciar o carregamento dos dados de uma visualização antecipadamente. Mas nós ainda queremos poder mostrar as partes mais importantes da visualização sem ter que esperar por todos os nossos dados. No Facebook nós implementamos o suporte para isso no GraphQL e Relay na forma de algumas novas diretivas de GraphQL (anotações que afetam quando/como os dados são entregues, mas não quais dados). Essas novas diretivas, chamadas @defer e @stream, nos permitem recuperar dados de maneira incremental. Por exemplo, considere nosso componente <Post> acima. Nós queremos mostrar o corpo sem ter que esperar que os comentários estejam prontos. Nós podemos alcançar isso com @defer e <Suspense>:
// Post.js\nfunction Post(props) {\n const postData = useFragment(graphql`\n fragment PostData on Post {\n author\n title\n\n # obter dados para os comentários, mas sem bloquear até que estejam carregados\n ...CommentList @defer\n }\n `, props.post);\n\n return (\n <div>\n <h1>{postData.title}</h1>\n <h2>by {postData.author}</h2>\n {/* @defer trabalha naturalmente com <Suspense> para criar uma interface de usuário não bloqueada também */}\n <Suspense fallback={<Spinner/>}>\n <CommentList post={postData} />\n </Suspense>\n </div>\n );\n}Aqui, nosso servidor GraphQL devolve os resultados por stream, primeiro retornando os campos author e title e então retornando os dados de comentário quando estiver pronto. Nós envolvemos a <CommentList> em uma tag <Suspense> então nós podemos renderizar o corpo da postagem antes da <CommentList> e seus dados estarem prontos. Esse padrão pode ser aplicado a outras biblotecas. Por exemplo, apps que chamam uma API REST podem fazer requisições em paralelo para obter os dados para o corpo e comentários para uma postagem evitando bloquear até que todos os dados estejam prontos.
Mas ainda tem uma coisa faltando. Nós mostramos como pré-carregar dados para uma rota — mas e o código? O exemplo acima nos enganou um pouco e usou React.lazy. De qualquer forma, React.lazy é, como o nome indica, preguiçoso. Ele não irá começar a baixar o código até que o componente preguiçoso esteja renderizado — é uma “obtenção-de-dados-na-renderização” para código!
Para resolver isso, a equipe do React está considerando APIs que nos permitiriam dividir o bundle e pré-carregar completamente o código também. Isso permitiria um usuário passar de alguma forma um componente preguiçoso para uma rota, e a rota disparar o carregamento do código e dos seus dados o mais antecipadamente possível.
\nPara recaptular, atingir uma ótima experiência de usuário significa que nós precisamos começar a carregar código e dados o mais antecipadamente possível, mas sem esperar que tudo seja completado. Dados em paralelo e árvores de visualização nos permitem carregar os dados para uma visualização em paralelo com o carregamento da própria visualização (código). Obtenção de dados em um manipulador de eventos significa que nós podemos começar a carregar os dados o mais antecipadamente possível, e otimamente até mesmo pré-carregar uma visualização quando nós tivermos confiança suficiente de que o usuário irá navegar para ela. Carregar dados de maneira incremental nos permite carregar os dados mais importantes antecipadamente sem atrasar a obtenção de dados de menos importância. E tratar código como dados — e pré-carregar esse código com APIs similares — nos permite carregá-lo de maneira antecipada também.
\nEsses padrões não são apenas ideias — nós os implementamos no React Hooks e estamos usando eles em produção ao longo do novo facebook.com (o que está atualmente em teste beta). Se você estiver interessado em utilizá-lo ou aprender mais sobre esses padrões, aqui estão algumas referências:
\nNós implementamos dois aplicativos de exemplo que demonstram esses conceitos:
\nMesmo que as APIs do Modo Concorrente e Suspense ainda sejam experimentais, nós estamos confiantes que as ideias desse artigo são comprovadas na prática. De qualquer forma, nós entendemos que o Relay e GraphQL não são aplicáveis a todos. E tudo bem! Nós estamos explorando como generalizar esses padrões para abordagens como REST, e também explorando ideias para uma API mais genérica (isto é, não-GraphQL) para composição de árvores de dependência de dados. Enquanto isso, estamos animados por ver que novas bibliotecas irão surgir implementando os padrões descritos nesse artigo para criar de maneira mais fácil, experiências de usuário rápidas.
","excerpt":"Na React Conf 2019 nós anunciamos uma versão experimental do React que acrescenta suporte ao Modo Concorrente e Suspense. Nesse artigo nós vamos introduzir as melhores práticas para seu uso que nós identificamos durante o processo de construção do novo facebook.com. Esse artigo será mais relevante para pessoas que trabalham com as bibliotecas de obtenção de dados (data fetching) para React. Mostramos como integrar melhor elas com o Modo Concorrente e o Suspense. Os padrões introduzidos aqui são…","frontmatter":{"title":"Construindo Ótimas Experiências de Usuário com Modo Concorrente e Suspense","next":null,"prev":null,"author":[{"frontmatter":{"name":"Joseph Savona","url":"https://twitter.com/en_JS"}}]},"fields":{"date":"06 de novembro de 2019","path":"content/blog/2019-11-06-building-great-user-experiences-with-concurrent-mode-and-suspense.md","slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}},"allMarkdownRemark":{"edges":[{"node":{"frontmatter":{"title":"React v17.0"},"fields":{"slug":"/blog/2020/10/20/react-v17.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo JSX Transform"},"fields":{"slug":"/blog/2020/09/22/introducing-the-new-jsx-transform.html"}}},{"node":{"frontmatter":{"title":"React v17.0 Candidato à lançamento: Sem novas funcionalidades"},"fields":{"slug":"/blog/2020/08/10/react-v17-rc.html"}}},{"node":{"frontmatter":{"title":"React v16.13.0"},"fields":{"slug":"/blog/2020/02/26/react-v16.13.0.html"}}},{"node":{"frontmatter":{"title":"Construindo Ótimas Experiências de Usuário com Modo Concorrente e Suspense"},"fields":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}}},{"node":{"frontmatter":{"title":"Preparando para o Futuro com as Prereleases React"},"fields":{"slug":"/blog/2019/10/22/react-release-channels.html"}}},{"node":{"frontmatter":{"title":"Apresentando o novo React DevTools"},"fields":{"slug":"/blog/2019/08/15/new-react-devtools.html"}}},{"node":{"frontmatter":{"title":"React v16.9.0 e a atualização do Roadmap"},"fields":{"slug":"/blog/2019/08/08/react-v16.9.0.html"}}},{"node":{"frontmatter":{"title":"O React já esta traduzido? ¡Sí! Sim! はい！"},"fields":{"slug":"/blog/2019/02/23/is-react-translated-yet.html"}}},{"node":{"frontmatter":{"title":"React v16.8: O React com Hooks"},"fields":{"slug":"/blog/2019/02/06/react-v16.8.0.html"}}}]}},"pageContext":{"slug":"/blog/2019/11/06/building-great-user-experiences-with-concurrent-mode-and-suspense.html"}},"staticQueryHashes":[]}