\n\nCuidado:
\nEsta página descreve recursos experimentais que ainda não estão disponíveis em uma versão estável. Não confie nas versões experimentais do React em aplicativos de produção. Esses recursos podem mudar significativamente e sem aviso antes de se tornarem parte do React.
\nEsta documentação é destinada a adotantes precoces e pessoas curiosas. Se você é novo no React, não se preocupe com esses recursos — você não precisa aprendê-los agora. Por exemplo, se você estiver procurando por um tutorial de busca de dados que funcione hoje, leia este artigo.
\n
O React 16.6 adicionou um componente <Suspense> que permite você “esperar” para que algum código seja carregado e especifique declarativamente um estado de carregamento (como um spinner) enquanto esperamos:
const ProfilePage = React.lazy(() => import('./ProfilePage')); // Carregado quando necessário\n\n// Mostrar um spinner enquanto o perfil está carregando\n<Suspense fallback={<Spinner />}>\n <ProfilePage />\n</Suspense>Suspense para Busca de Dados é um novo recurso que permite usar <Suspense> também para declarativamente “esperar” por qualquer outra coisa, incluindo dados. Esta página se concentra no caso de uso de busca de dados, mas também pode aguardar imagens, scripts ou outro recurso assíncrono.
O Suspense permite que seus componentes “esperem” por algo antes que eles possam renderizar. Neste exemplo, dois componentes aguardam uma chamada de API assíncrona para buscar alguns dados:
\nconst resource = fetchProfileData();\n\nfunction ProfilePage() {\n return (\n <Suspense fallback={<h1>Loading profile...</h1>}>\n <ProfileDetails />\n <Suspense fallback={<h1>Loading posts...</h1>}>\n <ProfileTimeline />\n </Suspense>\n </Suspense>\n );\n}\n\nfunction ProfileDetails() {\n // Tenta ler as informações do usuário, embora ele ainda não tenha sido carregado\n const user = resource.user.read();\n return <h1>{user.name}</h1>;\n}\n\nfunction ProfileTimeline() {\n // Tenta ler as postagens, embora elas ainda não tenham sido carregadas\n const posts = resource.posts.read();\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}Esta demo é um teaser. Não se preocupe se ainda não faz sentido. Falaremos mais sobre como isso funciona abaixo. Lembre-se de que o Suspense é mais um mecanismo, e APIs específicas como fetchProfileData() ou resource.posts.read() no exemplo acima não são muito importantes. Se você estiver curioso, poderá encontrar as definições deles no sandbox de demonstração.
Suspense não é uma biblioteca de busca de dados. É um mecanismo para as bibliotecas de busca de dados para comunicar o React que os dados que um componente está lendo ainda não estão prontos. O React pode esperar que esteja pronto e atualizar a UI. No Facebook, usamos o Relay e sua nova integração com Suspense. Esperamos que outras bibliotecas como Apollo possam fornecer integrações semelhantes.
\nA longo prazo, pretendemos que o Suspense se torne a principal maneira de ler dados assíncronos dos componentes — não importa de onde esses dados sejam provenientes.
\nO Suspense é significativamente diferente das abordagens existentes para esses problemas, portanto, ler sobre isso pela primeira vez geralmente leva a conceitos errôneos. Vamos esclarecer os mais comuns:
\nfetch ou Relay com Suspense. Mas você pode usar uma biblioteca integrada com o Suspense (por exemplo, as novas APIs do Relay).Então, qual é o sentido do Suspense? Existem algumas maneiras de responder a isso:
\nawait, o código assíncrono geralmente está sujeito a erros. O Suspense parece mais com a leitura de dados de forma síncrona — como se já estivesse carregado.No Facebook, até agora, usamos apenas a integração do Relay com o Suspense em produção. Se você está procurando um guia prático para começar hoje, confira o Guia do Relay! Ele demonstra padrões que já funcionaram bem para nós em produção.
\nAs demos de código desta página usam uma implementação de API “fake” no lugar do Relay. Isso os torna mais fáceis de entender se você não estiver familiarizado com o GraphQL, mas eles não mostrarão o “caminho certo” para criar um aplicativo com o Suspense. Esta página é mais conceitual e tem como objetivo ajudá-lo a entender por que o Suspense funciona de uma certa maneira e quais problemas ele resolve.
\nSe você não usa o Relay hoje, pode ser necessário aguardar antes de experimentar o Suspense no seu aplicativo. Até agora, é a única implementação que testamos em produção e confiamos.
\nNos próximos meses, muitas bibliotecas aparecerão com diferentes usos das APIs do Suspense. Se você prefere aprender quando as coisas estão mais estáveis, pode preferir ignorar esse trabalho por enquanto e voltar quando o ecossistema do Suspense estiver mais maduro.
\nVocê também pode escrever sua própria integração para uma biblioteca de busca de dados, se desejar.
\nEsperamos ver muitas experiências na comunidade com outras bibliotecas. Há uma coisa importante a ser observada para os autores de bibliotecas de busca de dados.
\nEmbora seja tecnicamente possível, o Suspense não se destina atualmente como uma maneira de começar a buscar dados quando um componente é renderizado. Em vez disso, permite que os componentes expressem que estão “aguardando” os dados que já estão sendo buscados. Criando Excelentes Experiências de Usuário com o Modo de Concorrência e Suspensedescreve por que isso é importante e como implementar esse padrão na prática.
\nA menos que você tenha uma solução que ajude a evitar cascatas, sugerimos que você prefira APIs que favorecem ou reforçam a busca antes da renderização. Para um exemplo concreto, você pode ver como API de Relay Suspense impõe o pré-carregamento. Nossas mensagens sobre isso não foram muito consistentes no passado. O Suspense para Busca de Dados ainda é experimental, portanto, você pode esperar que nossas recomendações mudem com o tempo, à medida que aprendemos mais sobre o uso em produção e entendemos melhor o espaço do problema.
\nPoderíamos introduzir o Suspense sem mencionar as abordagens populares de busca de dados. No entanto, isso torna mais difícil ver quais problemas o Suspense resolve, por que vale a pena resolvê-los e como o Suspense é diferente das soluções existentes.
\nEm vez disso, veremos o Suspense como um próximo passo lógico em uma sequência de abordagens:
\nfetch em useEffect): Comece a renderizar componentes. Cada um desses componentes pode acionar a busca de dados em seus efeitos e métodos de ciclo de vida. Essa abordagem geralmente leva a “cascatas”.\n\nNota
\nIsso é um pouco simplificado e, na prática, as soluções tendem a usar uma mistura de diferentes abordagens. Ainda assim, vamos analisá-los isoladamente para contrastar melhor seus prós e contras.
\n
Para comparar essas abordagens, implementaremos uma página de perfil com cada uma delas.
\nUma maneira comum de buscar dados nos aplicativos React hoje é usar um efeito:
\n// Utilizando componente de função:\nuseEffect(() => {\n fetchSomething();\n}, []);\n\n// Ou, utilizando componente de classe:\ncomponentDidMount() {\n fetchSomething();\n}Chamamos essa abordagem de “busca-na-renderização” porque ela não começa a buscar até que o componente seja renderizado na tela. Isso leva a um problema conhecido como “cascata”.
\nConsidere estes components <ProfilePage> e <ProfileTimeline>:
function ProfilePage() {\n const [user, setUser] = useState(null);\n\n useEffect(() => { fetchUser().then(u => setUser(u)); }, []);\n if (user === null) {\n return <p>Loading profile...</p>;\n }\n return (\n <>\n <h1>{user.name}</h1>\n <ProfileTimeline />\n </>\n );\n}\n\nfunction ProfileTimeline() {\n const [posts, setPosts] = useState(null);\n\n useEffect(() => { fetchPosts().then(p => setPosts(p)); }, []);\n if (posts === null) {\n return <h2>Loading posts...</h2>;\n }\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}Se você executar esse código e olhar os logs no console, notará que a sequência é:
\nSe a busca de detalhes do usuário demorar três segundos, começaremos a buscar as postagens após três segundos! Isso é uma “cascata”: uma sequência não intencional que deveria ter sido paralelizada.
\nCascatas são comuns no código que busca dados na renderização. É possível resolver, mas à medida que o produto cresce, muitas pessoas preferem usar uma solução que proteja contra esse problema.
\nAs bibliotecas podem impedir cascatas, oferecendo uma maneira mais centralizada de buscar dados. Por exemplo, o Relay resolve esse problema movendo as informações sobre os dados que um componente precisa para analisar estaticamente fragments, que mais tarde são compostos em uma única consulta.
\nNesta página, não assumimos o conhecimento de Relay, portanto não o usaremos neste exemplo. Em vez disso, escreveremos algo semelhante manualmente combinando nossos métodos de busca de dados:
\nfunction fetchProfileData() {\n return Promise.all([\n fetchUser(),\n fetchPosts()\n ]).then(([user, posts]) => {\n return {user, posts};\n })\n}Neste exemplo, <ProfilePage> espera as duas requisições, mas inicia-os em paralelo:
// Comece a buscar o mais cedo possívelconst promise = fetchProfileData();\nfunction ProfilePage() {\n const [user, setUser] = useState(null);\n const [posts, setPosts] = useState(null);\n\n useEffect(() => { promise.then(data => { setUser(data.user); setPosts(data.posts); }); }, []);\n if (user === null) {\n return <p>Loading profile...</p>;\n }\n return (\n <>\n <h1>{user.name}</h1>\n <ProfileTimeline posts={posts} />\n </>\n );\n}\n\n// O filho não aciona mais a busca\nfunction ProfileTimeline({ posts }) {\n if (posts === null) {\n return <h2>Loading posts...</h2>;\n }\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}A sequência de eventos agora fica assim:
\nResolvemos a “cascata” de rede anterior, mas acidentalmente introduzimos uma diferente. Esperamos que todos os dados retornem com Promise.all() dentro de fetchProfileData, portanto, agora não podemos renderizar os detalhes do perfil até que as postagens também sejam buscadas. Temos que esperar pelos dois.
Obviamente, isso é possível de ser corrigido neste exemplo em particular. Podemos remover a chamada Promise.all() e aguardar as duas Promises separadamente. No entanto, essa abordagem fica progressivamente mais difícil à medida que a complexidade da nossa árvore de dados e componentes aumenta. É difícil escrever componentes confiáveis quando partes arbitrárias da árvore de dados podem estar ausentes ou obsoletas. Portanto, buscar todos os dados para a nova tela e depois renderizar é frequentemente uma opção mais prática.
Na abordagem anterior, buscamos dados antes de chamarmos setState:
Com o Suspense, ainda começamos a buscar primeiro, mas nós invertemos de posição os dois últimos passos:
\nCom o Suspense, não esperamos a resposta voltar antes de começarmos a renderizar. De fato, começamos a renderizar praticamente imediatamente após iniciar a requisição na rede:
\n// Isto não é uma Promise. É um objeto especial da nossa integração com Suspense.\nconst resource = fetchProfileData();\nfunction ProfilePage() {\n return (\n <Suspense fallback={<h1>Loading profile...</h1>}>\n <ProfileDetails />\n <Suspense fallback={<h1>Loading posts...</h1>}>\n <ProfileTimeline />\n </Suspense>\n </Suspense>\n );\n}\n\nfunction ProfileDetails() {\n // Tenta ler as informações do usuário, embora ele ainda não tenha sido carregado\n const user = resource.user.read(); return <h1>{user.name}</h1>;\n}\n\nfunction ProfileTimeline() {\n // Tenta ler as postagens, embora elas ainda não tenham sido carregadas\n const posts = resource.posts.read(); return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}Aqui está o que acontece quando renderizamos <ProfilePage> na tela:
fetchProfileData(). Isso nos deu um “resource” especial em vez de uma Promise. Em um exemplo realista, ele seria fornecido pela integração do Suspense com a nossa biblioteca de dados, como o Relay.<ProfilePage>. Retorna <ProfileDetails> e <ProfileTimeline> como filhos.<ProfileDetails>. Ele chama resource.user.read(). Como nenhum dos dados foi buscado ainda, esse componente “suspende”. O React ignora ele e tenta renderizar outros componentes na árvore.<ProfileTimeline>. Ele chama resource.posts.read(). Novamente, ainda não há dados, portanto esse componente também “suspende”. O React também ignora ele e tenta renderizar outros componentes na árvore.<ProfileDetails> foi suspenso, o React mostra o fallback do <Suspense> mais próximo acima dele na árvore: <h1>Loading profile...</h1>. Nós terminamos por enquanto.Este objeto resource representa os dados que ainda não existem, mas que podem eventualmente ser carregados. Quando chamamos read(), obtemos os dados ou o componente “suspende”.
À medida que mais dados fluem, o React tenta novamente a renderização e cada vez pode progredir “mais fundo”. Quando o resource.user é buscado, o componente <ProfileDetails> será renderizado com êxito e não precisaremos mais do fallback <h1>Loading profile...</h1>. Eventualmente, obteremos todos os dados e não haverá fallbacks na tela.
Isso tem uma implicação interessante. Mesmo se usarmos um cliente GraphQL que coleta todos os requisitos de dados em uma única requisição, o streaming da resposta nos permite mostrar mais conteúdo mais rapidamente. Como renderizamos-à-medida-que-buscamos (ao contrário de depois de buscar), se user aparece na resposta antes dos posts, poderemos “desbloquear” o boundary externo do <Suspense> antes que a resposta termine. Podemos ter esquecido isso antes, mas mesmo a solução busca-então-renderiza continha uma cascata: entre buscar e renderizar. O Suspense não sofre inerentemente dessa cascata, e bibliotecas como o Relay tiram proveito disso.
Observe como eliminamos as verificações if (...) “carregando” de nossos componentes. Isso não apenas remove código repetitivo, mas também simplifica fazermos alterações rápidas no design. Por exemplo, se quisermos que os detalhes e as postagens do perfil sempre “apareçam” juntos, poderemos excluir o boundary do <Suspense> entre eles. Ou poderíamos torná-los independentes um do outro, atribuindo a cada um seu próprio boundary <Suspense>. O Suspense nos permite alterar a granularidade de nossos states de carregamento e orquestrar seu sequenciamento sem alterações invasivas em nosso código.
Se você estiver trabalhando em uma biblioteca de busca de dados, há um aspecto crucial do Render-as-You-Fetch que você não deseja perder. Iniciamos a busca antes da renderização. Veja este exemplo de código mais de perto:
\n// Comece a buscar cedo!\nconst resource = fetchProfileData();\n\n// ...\n\nfunction ProfileDetails() {\n // Tente ler as informações do usuário\n const user = resource.user.read();\n return <h1>{user.name}</h1>;\n}Note que a chamada read() neste exemplo não inicia a busca. Ele apenas tenta ler os dados que já estão sendo buscados. Essa diferença é crucial para criar aplicativos rápidos com o Suspense. Não queremos atrasar o carregamento de dados até que um componente comece a renderizar. Como autor da biblioteca de busca de dados, você pode impor isso, tornando impossível obter um objeto resource sem também iniciar uma busca. Todas as demonstrações nesta página usando nossa “API falsa” impõem isso.
Você pode objetar que a busca “no nível superior”, como neste exemplo, é impraticável. O que faremos se navegarmos para a página de outro perfil? Podemos querer buscar com base em adereços. A resposta é queremos começar a buscar os manipuladores de eventos. Aqui está um exemplo simplificado de navegação entre as páginas do usuário:
\n// Primeira busca: o mais rápido possívelconst initialResource = fetchProfileData(0);\nfunction App() {\n const [resource, setResource] = useState(initialResource);\n return (\n <>\n <button onClick={() => {\n const nextUserId = getNextId(resource.userId);\n // Próxima busca: quando o usuário clicar setResource(fetchProfileData(nextUserId)); }}>\n Next\n </button>\n <ProfilePage resource={resource} />\n </>\n );\n}Com essa abordagem, podemos buscar código e dados em paralelo. Quando navegamos entre as páginas, não precisamos esperar o código de uma página carregar para começar a carregar seus dados. Podemos começar a buscar código e dados ao mesmo tempo (durante o clique no link), proporcionando uma experiência de usuário muito melhor.
\nIsso coloca uma questão de como sabemos o que buscar antes de renderizar a próxima tela. Existem várias maneiras de resolver isso (por exemplo, integrando a busca de dados mais próxima à sua solução de roteamento). Se você trabalha em uma biblioteca de busca de dados, Criando Excelentes Experiências de Usuário com o Modo de Concorrência e Suspense apresenta um mergulho profundo sobre como fazer isso e por que é importante.
\nO próprio Suspense como mecanismo é flexível e não possui muitas restrições. O código do produto precisa ser mais restrito para garantir que não haja cascatas, mas existem diferentes maneiras de fornecer essas garantias. Algumas perguntas que estamos explorando atualmente incluem:
\nread() por todo o lado?O Relay tem suas próprias respostas para algumas dessas perguntas. Certamente, existe mais do que uma maneira única de fazê-lo, e estamos empolgados em ver que novas idéias a comunidade React apresentará.
\nAs condições de concorrência são erros que ocorrem devido a suposições incorretas sobre a ordem em que nosso código pode ser executado. A busca de dados no Hook useEffect ou nos métodos de ciclo de vida de classe como componentDidUpdate geralmente os leva a eles. O Suspense também pode ajudar aqui — vamos ver como.
Para demonstrar o problema, adicionaremos um componente <App> de nível superior que renderiza nosso <ProfilePage> com um botão que permite alternar entre perfis diferentes:
function getNextId(id) {\n // ...\n}\n\nfunction App() {\n const [id, setId] = useState(0);\n return (\n <>\n <button onClick={() => setId(getNextId(id))}> Next </button> <ProfilePage id={id} />\n </>\n );\n}Vamos comparar como diferentes estratégias de busca de dados lidam com esse requisito.
\nuseEffect Primeiro, tentaremos uma versão do nosso exemplo original de “busca no efeito”. Vamos modificá-lo para passar um parâmetro id das props de <ProfilePage> para fetchUser(id) e fetchPosts(id):
function ProfilePage({ id }) { const [user, setUser] = useState(null);\n\n useEffect(() => {\n fetchUser(id).then(u => setUser(u)); }, [id]);\n if (user === null) {\n return <p>Loading profile...</p>;\n }\n return (\n <>\n <h1>{user.name}</h1>\n <ProfileTimeline id={id} /> </>\n );\n}\n\nfunction ProfileTimeline({ id }) { const [posts, setPosts] = useState(null);\n\n useEffect(() => {\n fetchPosts(id).then(p => setPosts(p)); }, [id]);\n if (posts === null) {\n return <h2>Loading posts...</h2>;\n }\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}Observe como também mudamos as dependências do efeito de [] para [id] — porque queremos que o efeito seja executado novamente quando o id mudar. Caso contrário, não buscaremos novamente os dados.
Se tentarmos esse código, a princípio pode parecer que ele funcione. No entanto, se aleatorizarmos o tempo de atraso em nossa implementação da “fake API” e pressionarmos o botão “Next” com rapidez suficiente, veremos nos logs do console que algo está saindo muito errado. Às vezes, as requisições dos perfis anteriores podem “voltar” depois que já mudamos o perfil para outro ID — e, nesse caso, elas podem sobrescrever o novo state com uma resposta obsoleta para um ID diferente.
\nÉ possível corrigir esse problema (você pode usar a função de limpeza de efeito para ignorar ou cancelar requisições obsoletas), mas é pouco intuitivo e difícil de depurar.
\ncomponentDidUpdate Pode-se pensar que este é um problema específico para useEffect ou Hooks. Talvez se portarmos esse código para classes ou usarmos uma sintaxe conveniente como async / await, isso resolverá o problema?
Vamos tentar isso:
\nclass ProfilePage extends React.Component {\n state = {\n user: null,\n };\n componentDidMount() {\n this.fetchData(this.props.id);\n }\n componentDidUpdate(prevProps) {\n if (prevProps.id !== this.props.id) {\n this.fetchData(this.props.id);\n }\n }\n async fetchData(id) {\n const user = await fetchUser(id);\n this.setState({ user });\n }\n render() {\n const { id } = this.props;\n const { user } = this.state;\n if (user === null) {\n return <p>Loading profile...</p>;\n }\n return (\n <>\n <h1>{user.name}</h1>\n <ProfileTimeline id={id} />\n </>\n );\n }\n}\n\nclass ProfileTimeline extends React.Component {\n state = {\n posts: null,\n };\n componentDidMount() {\n this.fetchData(this.props.id);\n }\n componentDidUpdate(prevProps) {\n if (prevProps.id !== this.props.id) {\n this.fetchData(this.props.id);\n }\n }\n async fetchData(id) {\n const posts = await fetchPosts(id);\n this.setState({ posts });\n }\n render() {\n const { posts } = this.state;\n if (posts === null) {\n return <h2>Loading posts...</h2>;\n }\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n }\n}Este código é enganosamente fácil de ler.
\nInfelizmente, nem o uso de uma classe nem a sintaxe async / await nos ajudaram a resolver esse problema. Esta versão sofre exatamente as mesmas condições de concorrência, pelas mesmas razões.
Os componentes do React possuem seu próprio “ciclo de vida”. Eles podem receber props ou atualizar o state a qualquer momento. No entanto, cada requisição assíncrona também possui seu próprio “ciclo de vida”. Começa quando iniciamos e termina quando obtemos uma resposta. A dificuldade que estamos enfrentando é “sincronizar” vários processos no tempo que se afetam. Isso é difícil de pensar.
\nVamos reescrever este exemplo novamente, mas usando apenas Suspense:
\nconst initialResource = fetchProfileData(0);\n\nfunction App() {\n const [resource, setResource] = useState(initialResource);\n return (\n <>\n <button onClick={() => {\n const nextUserId = getNextId(resource.userId);\n setResource(fetchProfileData(nextUserId));\n }}>\n Next\n </button>\n <ProfilePage resource={resource} />\n </>\n );\n}\n\nfunction ProfilePage({ resource }) {\n return (\n <Suspense fallback={<h1>Loading profile...</h1>}>\n <ProfileDetails resource={resource} />\n <Suspense fallback={<h1>Loading posts...</h1>}>\n <ProfileTimeline resource={resource} />\n </Suspense>\n </Suspense>\n );\n}\n\nfunction ProfileDetails({ resource }) {\n const user = resource.user.read();\n return <h1>{user.name}</h1>;\n}\n\nfunction ProfileTimeline({ resource }) {\n const posts = resource.posts.read();\n return (\n <ul>\n {posts.map(post => (\n <li key={post.id}>{post.text}</li>\n ))}\n </ul>\n );\n}No exemplo anterior utilizando Suspense, tínhamos apenas um resource, portanto mantivemos em uma variável de nível superior. Agora que temos vários recursos, o movemos para o state do componente <App>:
const initialResource = fetchProfileData(0);\n\nfunction App() {\n const [resource, setResource] = useState(initialResource);Quando clicamos em “Next”, o componente <App> inicia uma requisição para o próximo perfil e passa esse objeto para o componente <ProfilePage>:
<>\n <button onClick={() => {\n const nextUserId = getNextId(resource.userId);\n setResource(fetchProfileData(nextUserId)); }}>\n Next\n </button>\n <ProfilePage resource={resource} /> </>Mais uma vez, observe que não estamos aguardando a resposta para definir o state. É o contrário: definimos o state (e começamos a renderizar) imediatamente após iniciar uma requisição. Assim que tivermos mais dados, o React “preenche” o conteúdo dentro dos componentes <Suspense>.
Esse código é muito legível, mas, ao contrário dos exemplos anteriores, a versão Suspense não sofre condições de concorrência. Você pode estar se perguntando o porquê. A resposta é que, na versão Suspense, não precisamos pensar tanto em tempo em nosso código. Nosso código original com condições de concorrência precisava definir o state no momento certo depois ou, caso contrário, estaria errado. Mas com o Suspense, definimos o state imediatamente — por isso é mais difícil estragar tudo.
\nQuando escrevemos código com Promises, podemos usar catch() para lidar com erros. Como isso funciona com o Suspense, já que não esperamos pelas Promises para começar a renderizar?
Com Suspense, o tratamento de erros de busca funciona da mesma maneira que o tratamento de erros de renderização — você pode renderizar um error boundary em qualquer lugar para “capturar” erros nos componentes abaixo.
\nPrimeiro, definiremos um componente error boundary para usar em nosso projeto:
\n// Error boundaries atualmente tem que ser classes.\nclass ErrorBoundary extends React.Component {\n state = { hasError: false, error: null };\n static getDerivedStateFromError(error) {\n return {\n hasError: true,\n error\n };\n }\n render() {\n if (this.state.hasError) {\n return this.props.fallback;\n }\n return this.props.children;\n }\n}E então podemos colocá-lo em qualquer lugar da árvore para detectar erros:
\nfunction ProfilePage() {\n return (\n <Suspense fallback={<h1>Loading profile...</h1>}>\n <ProfileDetails />\n <ErrorBoundary fallback={<h2>Could not fetch posts.</h2>}> <Suspense fallback={<h1>Loading posts...</h1>}>\n <ProfileTimeline />\n </Suspense>\n </ErrorBoundary> </Suspense>\n );\n}Ele pegaria erros de renderização e erros da busca de dados do Suspense. Podemos ter quantos error boundaries quisermos, mas é melhor ser intencional sobre o posicionamento deles.
\nAgora, abordamos o básico do Suspense para Busca de Dados! Importante, agora entendemos melhor por que o Suspense funciona dessa maneira e como ele se encaixa no espaço de busca de dados.
\nO Suspense responde a algumas perguntas, mas também trás suas próprias novas questões:
\nPara responder a essas perguntas, veremos a próxima seção sobre Padrões de UI Concorrente.
","frontmatter":{"title":"Suspense para Busca de Dados (Experimental)","next":"concurrent-mode-patterns.html","prev":"concurrent-mode-intro.html"},"fields":{"path":"content/docs/concurrent-mode-suspense.md","slug":"docs/concurrent-mode-suspense.html"}}},"pageContext":{"slug":"docs/concurrent-mode-suspense.html"}},"staticQueryHashes":[]}