\n\nВнимание:
\nНа странице описаны экспериментальные функции, которых ещё нет в стабильной версии. Не используйте экспериментальные сборки React в продакшн приложениях. Эти функции могут значительно измениться без предупреждения перед тем, как попасть в React.
\nЭта документация нацелена на ранних пользователей и интересующихся. Если вы новичок в React, не беспокойтесь об этих возможностях — вам не нужно изучать их прямо сейчас. Например, если вы ищете актуальное на сегодня руководство по получению данных, прочитайте эту статью.
\n
В React 16.6 добавлен компонент <Suspense>, который позволяет «ждать» загрузки кода и декларативно показывать состояние загрузки (например, спиннер), пока мы ожидаем:
const ProfilePage = React.lazy(() => import('./ProfilePage')); // Ленивая загрузка\n\n// Показать спиннер, во время загрузки профиля\n<Suspense fallback={<Spinner />}>\n <ProfilePage />\n</Suspense>Задержка при получении данных — это новая возможность, которая позволяет использовать <Suspense> и декларативно «ждать» чего-либо ещё, включая данные. Эта страница описывает получение данных, однако это применимо к изображениям, скриптам и другим асинхронным действиям.
Задержка позволяет вашим компонентам «ждать» чего-то до их рендера. В этом примере два компонента ждут асинхронного вызова API, чтобы получить данные:
\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 // Пробуем прочитать информацию о пользователе, хотя она может быть ещё не загружена\n const user = resource.user.read();\n return <h1>{user.name}</h1>;\n}\n\nfunction ProfileTimeline() {\n // Пробуем прочитать сообщения, хотя они могут быть ещё не загружены\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}Посмотреть пример на CodeSandbox
\nЭто раннее демо. Не переживайте, если оно кажется бессмысленным. Мы поговорим о том, как оно работает ниже. Имейте ввиду, что задержка — это больше механизм и определенные API, такие как fetchProfileData() или resource.posts.read() в примере выше не очень важны. Если интересно, вы можете найти их определения прямо в демо песочнице.
Задержка — это не библиотека для получения данных. Это механизм для библиотек получения данных, который сообщает React, что данные, которые читает компонент ещё не готовы. React в этом случае может подождать, пока они будут готовы и обновить пользовательский интерфейс. В Facebook, мы используем Relay с интеграцией новой задержки. Мы ожидаем, что другие библиотеки, такие как Apollo смогут предоставить подобную интеграцию.
\nВ долгосрочной перспективе мы собираемся сделать задержку основным способом чтения асинхронных данных из компонентов, независимо от того, откуда эти данные пришли.
\nЗадержка — это совершенно иной подход среди существующих для решения этих проблем, поэтому на первый взгляд это часто ведёт к заблуждениям. Давайте проясним самые распространенные:
\nfetch или Relay задержкой. Но вы можете использовать библиотеку, в которую интегрирована задержка (например новый API у Relay).Итак, в чём идея задержки? Есть несколько вариантов ответа на этот вопрос:
\nawait асинхронный код часто подвержен ошибкам. Задержка дает ощущение синхронного чтения данных, как если бы они уже были загружены.До настоящего времени в Facebook мы использовали в продакшн только Relay с интегрированной задержкой. Если вы ищете практическое руководство как начать сегодня, посмотрите руководство Relay! Там рассмотрены подходы, которые уже хорошо работают у нас в продакшн.
\nКод примеров на этой странице использует «фальшивую» реализацию API, а не Relay. Это позволяет легче их понимать, если вы не знакомы с GraphQL, но они не расскажут вам о «правильном способе» как построить приложение с использованием задержки. Эта страница скорее о концептуальных принципах и нацелена помочь вам понять почему задержка работает определенным образом и какие проблемы она решает.
\nЕсли вы не используете Relay сегодня, вам возможно придётся подождать, прежде чем вы действительно сможете попробовать задержку в вашем приложении. Это пока что единственная реализация, которую мы протестировали в продакшн и в которой уверены.
\nВ течение нескольких месяцев, появится много библиотек с различными подходами к API задержки. Если вы предпочитаете изучать более стабильные технологии, вы можете пока проигнорировать то, что сделано сейчас и вернуться, когда экосистема задержки станет более зрелой.
\nВы можете написать свою собственную интеграцию с библиотекой получения данных, если хотите.
\nМы ожидаем увидеть в сообществе много экспериментов с другими библиотеками. Есть одна важная деталь на заметку авторам библиотек получения данных.
\nНесмотря на то, что это технически выполнимо, задержка сейчас не предназначена для получения данных во время рендера компонента. Скорее она позволяет компонентам показать, что они «ждут» данные, которые уже были получены. Построение хорошего опыта взаимодействия пользователя с интерфейсами в Конкурентном режиме с задержкой описывает почему это важно и как реализовать этот подход на практике.
\nЕсли у вас нет решения, которое помогает предотвращать водопады, мы предлагаем использовать API, которые поддерживают или обеспечивают получение данных до рендера. В качестве конкретного примера, посмотрите как в Relay Suspense API организована предзагрузка. Наша информация про это была не очень последовательной. Задержка для получения данных все ещё в экспериментальном режиме, наши рекомендации могут измениться со временем, так как мы учимся новому во время использования технологии в продакшн и лучше понимаем предметную область.
\nМы могли бы рассказать о задержке без упоминания популярных способов получения данных. В этом случае было бы сложнее увидеть какие проблемы решает задержка, почему эти проблемы нужно решать и как задержка отличается от существующих решений.
\nНаоборот, мы взглянем на задержку, как на следующий логический шаг в перечне подходов:
\nfetch в useEffect): Начинаем рендерить компоненты. Каждый из этих компонентов может вызвать получение данных в своих «эффектах» и методах жизненного цикла. Этот подход обычно ведёт к «водопадам».\n\nПримечание
\nЭто немного упрощено и на практике требуется использование нескольких подходов. Тем не менее, мы будем рассматривать их отдельно, чтобы лучше отразить компромиссы, которые они требуют.
\n
Для сравнения подходов мы реализуем страницу с профилем пользователя используя каждый из них.
\nРаспространённый сегодня способ получения данных в React с использованием эффекта:
\n// В функциональном компоненте:\nuseEffect(() => {\n fetchSomething();\n}, []);\n\n// Или в классовом компоненте:\ncomponentDidMount() {\n fetchSomething();\n}Мы зовем этот подход «получаем после рендера» потому что получение данных начинается после рендера компонента на экране. Это приводит к проблеме, известной как «водопад».
\nВзгляните на компоненты <ProfilePage> и <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}Посмотреть пример на CodeSandbox
\nЕсли вы запустите этот код в логах консоли вы увидите следующую последовательность:
\nЕсли получение информации о пользователе занимает три секунды, мы начнём получать сообщения пользователя только через три секунды! Это «водопад»: непреднамеренная последовательность, которая должна выполняться параллельно.
\nВодопады распространены в коде который получает данные после рендера. Их можно устранить, но по мере роста продукта, многие люди предпочитают использовать решение, которое защищает от этой проблемы.
\nБиблиотеки могут предотвратить появление водопадов предлагая более централизованный способ получения данных. Например, Relay решает эту проблему перемещением информации о данных, которые нужны компоненту в статически анализируемые фрагменты, которые позже собираются в единый запрос.
\nНа этой странице, мы не ожидаем, что вы знаете Relay, поэтому не используем его в примере. Вместо этого, мы напишем что-то подобное самостоятельно, комбинируя наши методы получения данных:
\nfunction fetchProfileData() {\n return Promise.all([\n fetchUser(),\n fetchPosts()\n ]).then(([user, posts]) => {\n return {user, posts};\n })\n}В этом примере <ProfilePage> ждёт окончания обоих запросов, но запускает их параллельно:
// Запускаем получение данных как можно раньшеconst 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// Дочерний компонент теперь не запускает получение данных\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}Посмотреть пример на CodeSandbox
\nПоследовательность событий теперь выглядит так:
\nМы разрешили предыдущий сетевой «водопад», но случайно организовали другой. Мы ждем все данные используя Promise.all() внутри fetchProfileData, поэтому мы не можем рендерить профиль пользователя пока все его сообщения не будут получены. Нам приходится ждать и то и другое.
Конечно, это можно исправить в данном примере. Мы можем убрать вызов Promise.all() и ждать оба промиса отдельно. Однако этот подход прогрессивно усложняется с увеличением количества данных и ростом дерева компонентов. Сложно писать надежные компоненты когда произвольные части дерева данных могут исчезать или устаревать. Поэтому рендер после получения всех данных для нового экрана часто является более практичным вариантом.
В предыдущем подходе мы получали данные перед вызовом setState:
С задержкой мы все ещё начинаем сначала получать данные, но мы меняем последние два пункта местами:
\nС задержкой мы не ждём ответа перед тем, как начать рендерить. На самом деле, мы начинаем рендерить почти сразу после отправки сетевого запроса:
\n// Это не промис. Это специальный объект из нашей интеграции задержки.\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 // Пробуем прочитать информацию о пользователе, хотя она всё ещё может быть не загружена\n const user = resource.user.read(); return <h1>{user.name}</h1>;\n}\n\nfunction ProfileTimeline() {\n // Пробуем прочитать сообщения пользователя, хотя они всё ещё могут быть не загружены\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}Посмотреть пример на CodeSandbox
\nВот что происходит, когда мы рендерим <ProfilePage> на экране:
fetchProfileData(). Это дает нам специальный «ресурс» вместо промиса. В более реалистичном примере, он был бы предоставлен нашей задержкой интегрированной в библиотеку данных, например Relay.<ProfilePage>. Он возвращает <ProfileDetails> и <ProfileTimeline> в виде дочерних компонентов.<ProfileDetails>. Он вызывает resource.user.read(). Данные ещё не получены, поэтому компонент «задерживается». React пропускает его и пробует рендерить другие компоненты в дереве.<ProfileTimeline>. Он вызывает resource.posts.read(). Снова, данных ещё нет, этот компонент тоже «задерживается». React пропускает его тоже и пробует рендерить другие компоненты в дереве.<ProfileDetails> задерживается, React показывает ближайшую заглушку <Suspense> поверх него в дереве: <h1>Loading profile...</h1>. На данный момент мы закончили.Объект resource представляет данные, которых ещё нет, но они в итоге могут загрузиться. Когда мы вызываем read(), мы или читаем данные или компонент «задерживается».
Чем больше потоков данных поступает, React будет пробовать рендерить и каждый раз он сможет продвигаться «глубже». Когда данные resource.user получены, компонент <ProfileDetails> успешно отрендерится и нам больше не потребуется заглушка <h1>Loading profile...</h1>. В итоге мы получим все данные и заглушек больше не будет на экране.
Здесь есть интересный момент. Даже если мы используем клиент GraphQL, который собирает все требования к данным в единый запрос, потоковая передача ответа позволяет нам быстрее показать больше контента. Так как мы рендерим во время получения (в отличии от после получения) и если user появится в ответе раньше, чем posts, мы сможем «убрать» внешнюю заглушку <Suspense> до окончания ответа. Мы могли упустить это ранее, но даже при подходе «получаем потом рендерим» решение содержит водопад: между получением и рендером. Задержка не страдает от этого водопада и библиотеки, такие как Relay пользуются этим.
Обратите внимание, как мы избавились от проверок if (...) «идет загрузка» в наших компонентах. Это не только убирает шаблонный код, но и упрощает быстрые изменения в дизайне. Например, если мы хотим, чтобы информация о пользователе и его сообщения всегда появлялись вместе, мы можем удалить разделение <Suspense> между ними. Или мы можем сделать их независимыми от друг друга, предоставив каждому собственный <Suspense>. Задержка позволяет нам изменить степень раздробленности наших состояний загрузки и управлять их последовательностью без больших изменений в коде.
Если вы работает над библиотекой получения данных, есть важный аспект в подходе «рендерим во время получения данных», который не стоит упускать. Мы запускаем получение данных перед рендером. Посмотрите внимательно на этот пример:
\n// Начинаем получать данные рано!\nconst resource = fetchProfileData();\n\n// ...\n\nfunction ProfileDetails() {\n // Пытаемся прочитать информацию о пользователе\n const user = resource.user.read();\n return <h1>{user.name}</h1>;\n}Посмотреть пример на CodeSandbox
\nОбратите внимание, что вызов read() в этом примере не начинает получение данных. Он всего лишь пытается прочитать данные, которые уже были получены. Это различие очень важно для создания быстрых приложений с задержкой. Мы не хотим откладывать загрузку данных до начала рендера компонента. Как автор библиотеки получения данных, вы можете предотвратить это сделав невозможным получить объект resource до начала получения данных. Каждый пример на этой странице использует наш «фальшивый API», который обеспечивает это.
Вы можете возразить, что получение «в самом начале», как в этом примере — это не практично. Что мы собираемся делать, если перейдем на профиль другого пользователя? Мы хотели бы получать данные на основе пропсов. Ответ на этот вопрос: вместо этого нужно начать получение данных в обработчике событий. Ниже упрощенный пример навигации между страницами пользователей:
\n// Первое получение данных: как можно скорееconst initialResource = fetchProfileData(0);\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 Next\n </button>\n <ProfilePage resource={resource} />\n </>\n );\n}Посмотреть пример на CodeSandbox
\nС таким подходом мы можем получать код и данные параллельно. Когда мы перемещаемся между страницами, нам не нужно ждать загрузки кода страницы, чтобы начать получать данные для этой страницы. Мы можем начать получать и данные и код одновременно (во время клика по ссылке), улучшив опыт взаимодействия пользователя с интерфейсом.
\nВозникает вопрос, как узнать что получать перед рендером следующего экрана. Есть несколько способов понять это (например, через интеграцию получения данных с роутером). Если вы работаете над библиотекой получения данных, Построение хорошего опыта взаимодействия пользователя с интерфейсами в Конкурентном режиме с задержкой подробно расскажет о том, как этого добиться и почему это важно.
\nЗадержка — гибкий механизм без большого количества ограничений. А код продукта должен быть более ограничен, чтобы гарантировать отсутствие водопадов и есть различные способы предоставить эти гарантии. На данный момент мы изучаем вопросы, которые включают в себя:
\nread()?Relay отвечает по своему на некоторые из этих вопросов. Есть определенно больше чем один способ сделать это и мы с нетерпением хотим увидеть, какие новые идеи появятся в сообществе разработчиков React.
\nСостояние гонки — это баги, которые возникают во время неправильного предположения о том, в каком порядке код может исполняться. Получение данных в хуке useEffect или в жизненных методах класса, например componentDidUpdate часто приводит к ним. Задержка поможет решить проблему, давайте посмотрим как.
Для демонстрации проблемы, мы добавим на верхний уровень компонент <App>, который рендерит наш <ProfilePage> с кнопкой, которая позволяет переключаться между разными профилями:
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}Давайте сравним, как разные стратегии получения данных работают с этим требованием.
\nuseEffect Сначала мы попробуем версию оригинального примера «получаем в эффекте». Мы модифицируем его для передачи параметра id из пропсов <ProfilePage> в fetchUser(id) и 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}Посмотреть пример на CodeSandbox
\nОбратите внимание, как мы изменили зависимости эффекта с [] на [id] — потому что мы хотим перезапускать эффект, когда меняется id. В противном случае мы не будем получать новые данные.
Если мы запустим этот код, то на первый взгляд может показаться, что он работает. Однако, если мы сделаем случайным время задержки в реализации нашего «фальшивого API» и быстро нажмем кнопку «Next», мы увидим в логе консоли, что что-то пошло не так. Запросы из предыдущих профилей могут иногда «возвращаться» после того, как мы переключились на профиль с другим ID, в этом случае они могут перезаписать новое состояние устаревшим ответом от другого ID.
\nЭту проблему можно решить (вы можете использовать функцию очистки эффекта, чтобы игнорировать или отклонять устаревшие запросы), но это не интуитивно и усложняет отладку.
\ncomponentDidUpdate Можно подумать, что проблема специфична для useEffect или хуков. Возможно, если мы перепишем этот код классами или используем удобный синтаксис async / await это решит проблему?
Давайте попробуем:
\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}Посмотреть пример на CodeSandbox
\nЭтот код обманчиво легко читаем.
\nК сожалению, ни использование классов, ни синтаксис async / await не помог нам решить эту проблему. Эта версия подвержена состоянию гонки по тем же самым причинам.
Компоненты React имеют собственный «жизненный цикл». Они могут получать пропсы или обновлять состояние в любой момент времени. Однако, каждый асинхронный запрос тоже имеет собственный «жизненный цикл». Он начинается когда мы его отправляем и заканчивается когда мы получаем ответ. Сложность которую мы испытываем заключается в «синхронизации» нескольких процессов во времени, которые влияют друг на друга. Об этом сложно думать.
\nДавайте перепишем этот пример с использованием задержки:
\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}Посмотреть пример на CodeSandbox
\nВ предыдущем примере с задержкой у нас был только один resource, поэтому мы запишем его в переменную на верхнем уровне. Сейчас у нас несколько ресурсов, мы переместили их в состояние компонента <App>:
const initialResource = fetchProfileData(0);\n\nfunction App() {\n const [resource, setResource] = useState(initialResource);Когда мы кликаем «Next», компонент <App> делает запрос для следующего профиля и передает этот объект вниз к компоненту <ProfilePage>:
<>\n <button onClick={() => {\n const nextUserId = getNextId(resource.userId);\n setResource(fetchProfileData(nextUserId)); }}>\n Next\n </button>\n <ProfilePage resource={resource} /> </>Снова обратите внимание, что мы не ждём ответа, чтобы поместить в состояние. Наоборот, мы устанавливаем состояние (и начинаем рендерить) сразу после отправки запроса. Как только у нас будет больше данных, React «наполнит» содержимым компоненты внутри <Suspense>.
Код хорошо читаем, но в отличие от предыдущих примеров, версия с задержкой не подвержена состоянию гонки. Вам интересно почему? В версии с задержкой нам не нужно так много думать о времени в нашем коде. Предыдущие примеры с состоянием гонки требуют установить состояние в правильный момент позднее иначе будет неверно. А с задержкой мы устанавливаем состояние сразу, поэтому здесь сложнее что-то перепутать.
\nКогда мы пишем код с промисами, мы используем catch() для обработки ошибок. Как это работает с задержкой, ведь мы не ждём промисов, чтобы начать рендер?
С задержкой, обработка ошибок при получении данных работает так же, как обработка ошибок при рендере — мы можем рендерить предохранитель в любом месте, чтобы «ловить» ошибки в компонентах ниже.
\nСначала мы создадим компонент-предохранитель, чтобы использовать его в нашем проекте:
\n// Предохранители на данный момент должны быть классами.\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}Теперь мы можем добавить его в любую часть дерева, чтобы отлавливать ошибки:
\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}Посмотреть пример на CodeSandbox
\nОн будет ловить ошибки рендера и ошибки получения данных в задержке. У нас может быть столько предохранителей, сколько мы захотим, но лучше расставлять их избирательно.
\nМы рассмотрели основы задержки для получения данных! Важно, что теперь мы лучше понимаем почему задержка работает таким образом и как вписывается в область получения данных.
\nЗадержка отвечает на некоторые вопросы, но и поднимает свои собственные:
\nЧтобы ответить на эти вопросы, мы ссылаемся на следующий раздел о Паттернах Конкурентных Пользовательских Интерфейсов.
","frontmatter":{"title":"Задержка при получении данных (экспериментально)","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":[]}