@@ -127,7 +127,7 @@ export default function App() {
}
```
-This is why most apps that use Create React App solve add routing with a routing library like [React Router](https://reactrouter.com/) or [Tanstack Router](https://tanstack.com/router/latest). With a routing library, you can add additional routes to the app, which provides opinions on the structure of your app, and allows you to start sharing links to routes. For example, with React Router you can define routes:
+Именно поэтому большинство приложений, использующих Create React App, решают проблему добавления маршрутизации с помощью библиотеки маршрутизации, такой как [React Router](https://reactrouter.com/) или [Tanstack Router](https://tanstack.com/router/latest). С помощью библиотеки маршрутизации вы можете добавлять дополнительные маршруты в приложение, что определяет структуру вашего приложения и позволяет начать делиться ссылками на маршруты. Например, с React Router вы можете определить маршруты:
```js
import {RouterProvider, createBrowserRouter} from 'react-router';
@@ -135,7 +135,7 @@ import {RouterProvider, createBrowserRouter} from 'react-router';
import Home from './Home';
import Dashboard from './Dashboard';
-// ✅ Each route has it's own URL
+// ✅ Каждый маршрут имеет свой собственный URL
const router = createBrowserRouter([
{path: '/', element:
}
@@ -148,21 +148,21 @@ export default function App() {
}
```
-With this change, you can share a link to `/dashboard` and the app will navigate to the dashboard page . Once you have a routing library, you can add additional features like nested routes, route guards, and route transitions, which are difficult to implement without a routing library.
+С этим изменением вы можете поделиться ссылкой на `/dashboard`, и приложение перейдет на страницу панели управления. Как только у вас появится библиотека маршрутизации, вы сможете добавлять дополнительные функции, такие как вложенные маршруты, маршрутные охранники и переходы между маршрутами, которые сложно реализовать без библиотеки маршрутизации.
-There's a tradeoff being made here: the routing library adds complexity to the app, but it also adds features that are difficult to implement without it.
+Здесь идет компромисс: библиотека маршрутизации добавляет сложности в приложение, но также добавляет функции, которые сложно реализовать без нее.
-### Data Fetching {/*data-fetching*/}
+### Получение данных {/*data-fetching*/}
-Another common problem in Create React App is data fetching. Create React App does not include a specific data fetching solution. If you're just getting started, a common option is to use `fetch` in an effect to load data.
+Еще одна распространенная проблема в Create React App — получение данных. Create React App не включает конкретного решения для получения данных. Если вы только начинаете, распространенным вариантом является использование `fetch` в эффекте для загрузки данных.
-But doing this means that the data is fetched after the component renders, which can cause network waterfalls. Network waterfalls are caused by fetching data when your app renders instead of in parallel while the code is downloading:
+Но делая это, данные загружаются после рендеринга компонента, что может привести к сетевым водопадам. Сетевые водопады возникают из-за получения данных при рендеринге вашего приложения вместо параллельной загрузки кода во время загрузки кода:
```js
export default function Dashboard() {
const [data, setData] = useState(null);
- // ❌ Fetching data in a component causes network waterfalls
+ // ❌ Получение данных в компоненте вызывает сетевые водопады
useEffect(() => {
fetch('/api/data')
.then(response => response.json())
@@ -177,9 +177,9 @@ export default function Dashboard() {
}
```
-Fetching in an effect means the user has to wait longer to see the content, even though the data could have been fetched earlier. To solve this, you can use a data fetching library like [React Query](https://react-query.tanstack.com/), [SWR](https://swr.vercel.app/), [Apollo](https://www.apollographql.com/docs/react), or [Relay](https://relay.dev/) which provide options to prefetch data so the request is started before the component renders.
+Получение данных в эффекте означает, что пользователю приходится дольше ждать, чтобы увидеть контент, хотя данные могли быть получены раньше. Чтобы решить эту проблему, вы можете использовать библиотеку получения данных, такую как [React Query](https://react-query.tanstack.com/), [SWR](https://swr.vercel.app/), [Apollo](https://www.apollographql.com/docs/react) или [Relay](https://relay.dev/), которые предоставляют опции для предварительной загрузки данных, чтобы запрос начинался до рендеринга компонента.
-These libraries work best when integrated with your routing "loader" pattern to specify data dependencies at the route level, which allows the router to optimize your data fetches:
+Эти библиотеки лучше всего работают при интеграции с вашим шаблоном "загрузчика" маршрутизации для определения зависимостей данных на уровне маршрута, что позволяет маршрутизатору оптимизировать получение данных:
```js
export async function loader() {
@@ -188,7 +188,7 @@ export async function loader() {
return data;
}
-// ✅ Fetching data in parallel while the code is downloading
+// ✅ Получение данных параллельно во время загрузки кода
export default function Dashboard({loaderData}) {
return (
@@ -198,21 +198,21 @@ export default function Dashboard({loaderData}) {
}
```
-On initial load, the router can fetch the data immediately before the route is rendered. As the user navigates around the app, the router is able to fetch both the data and the route at the same time, parallelizing the fetches. This reduces the time it takes to see the content on the screen, and can improve the user experience.
+При первоначальной загрузке маршрутизатор может получить данные немедленно перед рендерингом маршрута. Когда пользователь перемещается по приложению, маршрутизатор может одновременно получать как данные, так и маршрут, параллелизируя запросы. Это сокращает время, необходимое для отображения контента на экране, и может улучшить пользовательский опыт.
-However, this requires correctly configuring the loaders in your app and trades off complexity for performance.
+Однако это требует правильной настройки загрузчиков в вашем приложении и сопряжено с увеличением сложности ради производительности.
-### Code Splitting {/*code-splitting*/}
+### Разделение кода {/*code-splitting*/}
-Another common problem in Create React App is [code splitting](https://www.patterns.dev/vanilla/bundle-splitting). Create React App does not include a specific code splitting solution. If you're just getting started, you might not consider code splitting at all.
+Еще одна распространенная проблема в Create React App — [разделение кода](https://www.patterns.dev/vanilla/bundle-splitting). Create React App не включает конкретного решения для разделения кода. Если вы только начинаете, вы можете вообще не рассматривать разделение кода.
-This means your app is shipped as a single bundle:
+Это означает, что ваше приложение поставляется как единый пакет:
```txt
- bundle.js 75kb
```
-But for ideal performance, you should "split" your code into separate bundles so the user only needs to download what they need. This decreases the time the user needs to wait to load your app, by only downloading the code they need to see the page they are on.
+Но для идеальной производительности вы должны "разделять" свой код на отдельные пакеты, чтобы пользователь загружал только то, что ему нужно. Это сокращает время, которое пользователь должен ждать для загрузки вашего приложения, загружая только тот код, который ему нужен для просмотра страницы, на которой он находится.
```txt
- core.js 25kb
@@ -220,101 +220,100 @@ But for ideal performance, you should "split" your code into separate bundles so
- dashboard.js 25kb
```
-One way to do code-splitting is with `React.lazy`. However, this means that the code is not fetched until the component renders, which can cause network waterfalls. A more optimal solution is to use a router feature that fetches the code in parallel while the code is downloading. For example, React Router provides a `lazy` option to specify that a route should be code split and optimize when it is loaded:
+Один из способов разделения кода — использовать `React.lazy`. Однако это означает, что код не загружается до тех пор, пока компонент не будет отрендерен, что может привести к сетевым водопадам. Более оптимальным решением является использование функции маршрутизатора, которая загружает код параллельно во время загрузки кода. Например, React Router предоставляет опцию `lazy` для указания того, что маршрут должен быть разделен по коду и оптимизирован при его загрузке:
```js
import Home from './Home';
import Dashboard from './Dashboard';
-// ✅ Routes are downloaded before rendering
+// ✅ Маршруты загружаются до рендеринга
const router = createBrowserRouter([
{path: '/', lazy: () => import('./Home')},
{path: '/dashboard', lazy: () => import('Dashboard')}
]);
```
-Optimized code-splitting is tricky to get right, and it's easy to make mistakes that can cause the user to download more code than they need. It works best when integrated with your router and data loading solutions to maximize caching, parallelize fetches, and support ["import on interaction"](https://www.patterns.dev/vanilla/import-on-interaction) patterns.
+Оптимизированное разделение кода сложно реализовать правильно, и легко допустить ошибки, которые могут привести к тому, что пользователь загрузит больше кода, чем ему нужно. Оно лучше всего работает при интеграции с вашим маршрутизатором и решениями для загрузки данных, чтобы максимизировать кеширование, параллелизировать запросы и поддерживать шаблоны ["импорт по взаимодействию"](https://www.patterns.dev/vanilla/import-on-interaction).
-### And more... {/*and-more*/}
+### И многое другое... {/*and-more*/}
-These are just a few examples of the limitations of Create React App.
+Это всего лишь несколько примеров ограничений Create React App.
-Once you've integrated routing, data-fetching, and code splitting, you now also need to consider pending states, navigation interruptions, error messages to the user, and revalidation of the data. There are entire categories of problems that users need to solve like:
+После интеграции маршрутизации, получения данных и разделения кода вам также необходимо учитывать состояния ожидания, прерывания навигации, сообщения об ошибках для пользователя и повторную проверку данных. Существуют целые категории проблем, которые пользователям необходимо решать, такие как:
- - Accessibility
- - Asset loading
- - Authentication
- - Caching
+ - Доступность
+ - Загрузка ресурсов
+ - Аутентификация
+ - Кеширование
- - Error handling
- - Mutating data
- - Navigations
- - Optimistic updates
+ - Обработка ошибок
+ - Изменение данных
+ - Навигация
+ - Оптимистичные обновления
- - Progressive enhancement
- - Server-side rendering
- - Static site generation
- - Streaming
+ - Прогрессивное улучшение
+ - Рендеринг на стороне сервера
+ - Генерация статических сайтов
+ - Потоковая передача
-All of these work together to create the most optimal [loading sequence](https://www.patterns.dev/vanilla/loading-sequence).
+Все это работает вместе, чтобы создать наиболее оптимальную [последовательность загрузки](https://www.patterns.dev/vanilla/loading-sequence).
-Solving each of these problems individually in Create React App can be difficult as each problem is interconnected with the others and can require deep expertise in problem areas users may not be familiar with. In order to solve these problems, users end up building their own bespoke solutions on top of Create React App, which was the problem Create React App originally tried to solve.
+Решение каждой из этих проблем по отдельности в Create React App может быть сложным, поскольку каждая проблема взаимосвязана с другими и может требовать глубоких знаний в областях, с которыми пользователи могут быть не знакомы. Чтобы решить эти проблемы, пользователи в конечном итоге создают свои собственные индивидуальные решения поверх Create React App, что и было проблемой, которую изначально пытался решить Create React App.
-## Why we Recommend Frameworks {/*why-we-recommend-frameworks*/}
+## Почему мы рекомендуем фреймворки {/*why-we-recommend-frameworks*/}
-Although you could solve all these pieces yourself in a build tool like Create React App, Vite, or Parcel, it is hard to do well. Just like when Create React App itself integrated several build tools together, you need a tool to integrate all of these features together to provide the best experience to users.
+Хотя вы могли бы решить все эти задачи самостоятельно в инструменте сборки, таком как Create React App, Vite или Parcel, это сложно сделать хорошо. Точно так же, как Create React App сам интегрировал несколько инструментов сборки, вам нужен инструмент для интеграции всех этих функций, чтобы обеспечить лучший пользовательский опыт.
-This category of tools that integrates build tools, rendering, routing, data fetching, and code splitting are known as "frameworks" -- or if you prefer to call React itself a framework, you might call them "metaframeworks".
+Эта категория инструментов, которые интегрируют инструменты сборки, рендеринг, маршрутизацию, получение данных и разделение кода, известна как "фреймворки" — или, если вы предпочитаете называть сам React фреймворком, вы можете назвать их "метафреймворками".
-Frameworks impose some opinions about structuring your app in order to provide a much better user experience, in the same way build tools impose some opinions to make tooling easier. This is why we started recommending frameworks like [Next.js](https://nextjs.org/), [React Router](https://reactrouter.com/), and [Expo](https://expo.dev/) for new projects.
+Фреймворки навязывают некоторые мнения о структурировании вашего приложения, чтобы обеспечить гораздо лучший пользовательский опыт, так же, как инструменты сборки навязывают некоторые мнения, чтобы упростить инструментарий. Именно поэтому мы начали рекомендовать фреймворки, такие как [Next.js](https://nextjs.org/), [React Router](https://reactrouter.com/) и [Expo](https://expo.dev/) для новых проектов.
-Frameworks provide the same getting started experience as Create React App, but also provide solutions to problems users need to solve anyway in real production apps.
+Фреймворки предоставляют такой же опыт начала работы, как и Create React App, но также предлагают решения проблем, которые пользователи в любом случае должны решать в реальных продакшн-приложениях.
-#### Server rendering is optional {/*server-rendering-is-optional*/}
+#### Серверный рендеринг необязателен {/*server-rendering-is-optional*/}
-The frameworks we recommend all provide the option to create a [client-side rendered (CSR)](https://developer.mozilla.org/en-US/docs/Glossary/CSR) app.
+Все рекомендуемые нами фреймворки предоставляют возможность создавать приложение с [рендерингом на стороне клиента (CSR)](https://developer.mozilla.org/en-US/docs/Glossary/CSR).
-In some cases, CSR is the right choice for a page, but many times it's not. Even if most of your app is client-side, there are often individual pages that could benefit from server rendering features like [static-site generation (SSG)](https://developer.mozilla.org/en-US/docs/Glossary/SSG) or [server-side rendering (SSR)](https://developer.mozilla.org/en-US/docs/Glossary/SSR), for example a Terms of Service page, or documentation.
+В некоторых случаях CSR является правильным выбором для страницы, но во многих случаях это не так. Даже если большая часть вашего приложения находится на стороне клиента, часто есть отдельные страницы, которые могут выиграть от функций серверного рендеринга, таких как [генерация статических сайтов (SSG)](https://developer.mozilla.org/en-US/docs/Glossary/SSG) или [серверный рендеринг (SSR)](https://developer.mozilla.org/en-US/docs/Glossary/SSR), например, страница "Условия обслуживания" или документация.
-Server rendering generally sends less JavaScript to the client, and a full HTML document which produces a faster [First Contentful Paint (FCP)](https://web.dev/articles/fcp) by reducing [Total Blocking Time (TBD)](https://web.dev/articles/tbt), which can also lower [Interaction to Next Paint (INP)](https://web.dev/articles/inp). This is why the [Chrome team has encouraged](https://web.dev/articles/rendering-on-the-web) developers to consider static or server-side render over a full client-side approach to achieve the best possible performance.
+Серверный рендеринг обычно отправляет меньше JavaScript клиенту и полный HTML-документ, что обеспечивает более быструю [первую отрисовку контента (FCP)](https://web.dev/articles/fcp) за счет уменьшения [общего времени блокировки (TBD)](https://web.dev/articles/tbt), что также может снизить [время до следующего взаимодействия (INP)](https://web.dev/articles/inp). Именно поэтому [команда Chrome призывает](https://web.dev/articles/rendering-on-the-web) разработчиков рассматривать статический или серверный рендеринг вместо полного клиентского подхода для достижения наилучшей возможной производительности.
-There are tradeoffs to using a server, and it is not always the best option for every page. Generating pages on the server incurs additional cost and takes time to generate which can increase [Time to First Byte (TTFB)](https://web.dev/articles/ttfb). The best performing apps are able to pick the right rendering strategy on a per-page basis, based on the tradeoffs of each strategy.
+Использование сервера сопряжено с компромиссами, и это не всегда лучший вариант для каждой страницы. Генерация страниц на сервере влечет за собой дополнительные расходы и требует времени для генерации, что может увеличить [время до первого байта (TTFB)](https://web.dev/articles/ttfb). Наиболее производительные приложения способны выбирать правильную стратегию рендеринга для каждой страницы, основываясь на компромиссах каждой стратегии.
-Frameworks provide the option to use a server on any page if you want to, but do not force you to use a server. This allows you to pick the right rendering strategy for each page in your app.
+Фреймворки предоставляют возможность использовать сервер на любой странице, если вы этого хотите, но не заставляют вас использовать сервер. Это позволяет вам выбирать правильную стратегию рендеринга для каждой страницы в вашем приложении.
-#### What About Server Components {/*server-components*/}
+#### А как насчет серверных компонентов? {/*server-components*/}
-The frameworks we recommend also include support for React Server Components.
+Рекомендуемые нами фреймворки также включают поддержку серверных компонентов React.
-Server Components help solve these problems by moving routing and data fetching to the server, and allowing code splitting to be done for client components based on the data you render, instead of just the route rendered, and reducing the amount of JavaScript shipped for the best possible [loading sequence](https://www.patterns.dev/vanilla/loading-sequence).
+Серверные компоненты помогают решить эти проблемы, перемещая маршрутизацию и получение данных на сервер и позволяя разделять код для клиентских компонентов на основе данных, которые вы отображаете, а не только на основе отображаемого маршрута, и уменьшая объем JavaScript, отправляемый для наилучшей возможной [последовательности загрузки](https://www.patterns.dev/vanilla/loading-sequence).
-Server Components do not require a server. They can be run at build time on your CI server to create a static-site generated app (SSG) app, at runtime on a web server for a server-side rendered (SSR) app.
+Серверные компоненты не требуют сервера. Они могут быть запущены во время сборки на вашем CI-сервере для создания приложения со статической генерацией сайта (SSG) или во время выполнения на веб-сервере для приложения с серверным рендерингом (SSR).
-See [Introducing zero-bundle size React Server Components](/blog/2020/12/21/data-fetching-with-react-server-components) and [the docs](/reference/rsc/server-components) for more info.
+См. [Представляем серверные компоненты React с нулевым размером бандла](/blog/2020/12/21/data-fetching-with-react-server-components) и [документацию](/reference/rsc/server-components) для получения дополнительной информации.
-#### Server Rendering is not just for SEO {/*server-rendering-is-not-just-for-seo*/}
+#### Серверный рендеринг — это не только для SEO {/*server-rendering-is-not-just-for-seo*/}
-A common misunderstanding is that server rendering is only for [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO).
+Распространенное заблуждение заключается в том, что серверный рендеринг нужен только для [SEO](https://developer.mozilla.org/en-US/docs/Glossary/SEO).
-While server rendering can improve SEO, it also improves performance by reducing the amount of JavaScript the user needs to download and parse before they can see the content on the screen.
+Хотя серверный рендеринг может улучшить SEO, он также повышает производительность, уменьшая объем JavaScript, который пользователю необходимо загрузить и разобрать, прежде чем он сможет увидеть контент на экране.
-This is why the Chrome team [has encouraged](https://web.dev/articles/rendering-on-the-web) developers to consider static or server-side render over a full client-side approach to achieve the best possible performance.
+Именно поэтому [команда Chrome призывает](https://web.dev/articles/rendering-on-the-web) разработчиков рассматривать статический или серверный рендеринг вместо полного клиентского подхода для достижения наилучшей возможной производительности.
---
-_Thank you to [Dan Abramov](https://bsky.app/profile/danabra.mov) for creating Create React App, and [Joe Haddad](https://github.com/Timer), [Ian Schmitz](https://github.com/ianschmitz), [Brody McKee](https://github.com/mrmckeb), and [many others](https://github.com/facebook/create-react-app/graphs/contributors) for maintaining Create React App over the years. Thank you to [Brooks Lybrand](https://bsky.app/profile/brookslybrand.bsky.social), [Dan Abramov](https://bsky.app/profile/danabra.mov), [Devon Govett](https://bsky.app/profile/devongovett.bsky.social), [Eli White](https://x.com/Eli_White), [Jack Herrington](https://bsky.app/profile/jherr.dev), [Joe Savona](https://x.com/en_JS), [Lauren Tan](https://bsky.app/profile/no.lol), [Lee Robinson](https://x.com/leeerob), [Mark Erikson](https://bsky.app/profile/acemarke.dev), [Ryan Florence](https://x.com/ryanflorence), [Sophie Alpert](https://bsky.app/profile/sophiebits.com), [Tanner Linsley](https://bsky.app/profile/tannerlinsley.com), and [Theo Browne](https://x.com/theo) for reviewing and providing feedback on this post._
-
+_Благодарим [Дэна Абрамова](https://bsky.app/profile/danabra.mov) за создание Create React App, а также [Джо Хаддада](https://github.com/Timer), [Иэна Шмитца](https://github.com/ianschmitz), [Броди МакКиба](https://github.com/mrmckeb) и [многих других](https://github.com/facebook/create-react-app/graphs/contributors) за поддержку Create React App на протяжении многих лет. Благодарим [Брукса Лайланда](https://bsky.app/profile/brookslybrand.bsky.social), [Дэна Абрамова](https://bsky.app/profile/danabra.mov), [Девона Говетта](https://bsky.app/profile/devongovett.bsky.social), [Эли Уайта](https://x.com/Eli_White), [Джека Херрингтона](https://bsky.app/profile/jherr.dev), [Джо Савону](https://x.com/en_JS), [Лорен Тан](https://bsky.app/profile/no.lol), [Ли Робинсона](https://x.com/leeerob), [Марка Эриксона](https://bsky.app/profile/acemarke.dev), [Райана Флоренса](https://x.com/ryanflorence), [Софи Алперт](https://bsky.app/profile/sophiebits.com), [Таннера Линсли](https://bsky.app/profile/tannerlinsley.com) и [Тео Брауна](https://x.com/theo) за рецензирование и предоставление отзывов по этой статье._