Ленивая загрузка в React
React использует такие сборщики, как WebPack, для упаковки своего кода и его развертывания в браузере. Этот пакет используется браузером для визуализации вашего приложения React.
Теперь представьте, что вы создаете приложение с сотнями компонентов. По умолчанию, упаковщик объединит все эти компоненты в один bundle.js и загрузит ваше приложение. Это, в свою очередь, увеличит первоначальный размер бандла, что приведет к увеличению времени загрузки.
Существует так называемое правило 3х секунд, которое гласит, что для привлечения внимания потребителя требуется примерно 3 секунды. Таким образом, если загрузка занимает больше времени, клиент / пользователь может даже не остаться, чтобы проверить конечный продукт, скорее он может потратить больше времени на поиск альтернативы.
Так, что мы можем сделать, чтобы улучшить нашу работу и не заставлять нашего клиента ждать?
Ответ прост: сначала загрузите компоненты, которые требуются, и, когда потребуются, загрузите остальные. Это и есть ленивая загрузка, загрузка приложения по частям, а не одним пакетом.
Подумайте об этом, у вас есть приложение со следующей структурой:
По умолчанию, когда вы загружаете React приложение, оно загружает все компоненты одновременно. Но требуются ли нам компоненты User Dashboard и Logout, когда пользователь даже не вошел в систему. Первыми мы можем загрузить только компоненты Home и Login / Register, и это уменьшит размер вдвое, увеличив время загрузки. Когда пользователь входит в приложение, мы можем загрузить два других компонента.
Теперь мы знаем, почему давайте начнем с того, КАК?
В этой статье я покажу вам два способа реализации отложенной загрузки
Я предполагаю, что вы обладаете базовыми знаниями о React и перейдете непосредственно к реализации.
У меня есть основной компонент App.js, в котором я буду определять два маршрута:
Использование React.lazy и Suspense
Эта функция была впервые представлена в React версии 16.6.0, чтобы обеспечить ленивую загрузку в экосистеме.
Пока не поддерживается при рендеринге на стороне сервера.
В React мы используем ключевое слово import для извлечения компонента, который в основном является модулем JavaScript.
По умолчанию импорт извлекает модуль и объединяет его в файл пакета. Нам требуется импорт, который по своей природе более динамичен, то есть импорт происходит только тогда, когда это требуется.
React.lazy делает возможным этот динамический импорт, который также прост в реализации.
На данный момент React.lazy не поддерживает именованные экспорты, поэтому не забудьте использовать экспорт по умолчанию для компонентов, которые вы хотите динамически импортировать.
Как только модуль загружен, он вернет новый пакет с Компонентом, объединенным с предыдущим кодом.
Этот обновленный пакет также обновляется в кеше, то есть после загрузки компонента веб-пакет не будет пытаться импортировать тот же компонент снова.
Как указано выше, динамический импорт возвращает обещание, что означает, что требуется время, чтобы получить модуль, обновить пакет и загрузить необходимый компонент. Поэтому нам может понадобиться резервный контент, который будет отображаться во время загрузки компонента, и именно здесь нам понадобится Suspense.
Во-первых, нам нужно импортировать модуль Suspense из React:
Компонент входа отображается с использованием React.lazy и Suspense
Чтобы проверить, работают ли наши изменения или нет, мы можем проверить dev-tools:
1.chunk вызывается, когда компонент динамически импортируется
Мы также можем определить отоборажение ошибок в Suspense для обработки пользовательских ошибок, если компонент не загружается.
Создание своего собственного HOC
Создавая наш собственный компонент высшего порядка для загрузки компонентов, мы получаем свободу вносить любые изменения по мере необходимости.
Давайте посмотрим на вызов этого HOC, вы можете увидеть сходство вызывающих методов с методом React.lazy.
Компонент Register, отображаемый с использованием нашего пользовательского HOC
Как и в приведенном выше примере, давайте проверим dev-tools: 2
2.chunk загружается
Как мы видим, когда был вызван компонент Register, был отправлен новый чанк с обновленным пакетом.
Вы можете найти репозиторий для приведенного выше примера здесь.
Suspense for Data Fetching (Experimental)
This page was about experimental features that aren’t yet available in a stable release. It was aimed at early adopters and people who are curious.
Much of the information on this page is now outdated and exists only for archival purposes. Please refer to the React 18 Alpha announcement post for the up-to-date information.
Before React 18 is released, we will replace this page with stable documentation.
React 16.6 added a component that lets you “wait” for some code to load and declaratively specify a loading state (like a spinner) while we’re waiting:
Suspense for Data Fetching is a new feature that lets you also use to declaratively “wait” for anything else, including data. This page focuses on the data fetching use case, but it can also wait for images, scripts, or other asynchronous work.
What Is Suspense, Exactly?
Suspense lets your components “wait” for something before they can render. In this example, two components wait for an asynchronous API call to fetch some data:
This demo is a teaser. Don’t worry if it doesn’t quite make sense yet. We’ll talk more about how it works below. Keep in mind that Suspense is more of a mechanism, and particular APIs like fetchProfileData() or resource.posts.read() in the above example are not very important. If you’re curious, you can find their definitions right in the demo sandbox.
Suspense is not a data fetching library. It’s a mechanism for data fetching libraries to communicate to React that the data a component is reading is not ready yet. React can then wait for it to be ready and update the UI. At Facebook, we use Relay and its new Suspense integration. We expect that other libraries like Apollo can provide similar integrations.
In the long term, we intend Suspense to become the primary way to read asynchronous data from components — no matter where that data is coming from.
What Suspense Is Not
Suspense is significantly different from existing approaches to these problems, so reading about it for the first time often leads to misconceptions. Let’s clarify the most common ones:
What Suspense Lets You Do
So what’s the point of Suspense? There are a few ways we can answer this:
Using Suspense in Practice
At Facebook, so far we have only used the Relay integration with Suspense in production. If you’re looking for a practical guide to get started today, check out the Relay Guide! It demonstrates patterns that have already worked well for us in production.
The code demos on this page use a “fake” API implementation rather than Relay. This makes them easier to understand if you’re not familiar with GraphQL, but they won’t tell you the “right way” to build an app with Suspense. This page is more conceptual and is intended to help you see why Suspense works in a certain way, and which problems it solves.
What If I Don’t Use Relay?
If you don’t use Relay today, you might have to wait before you can really try Suspense in your app. So far, it’s the only implementation that we tested in production and are confident in.
Over the next several months, many libraries will appear with different takes on Suspense APIs. If you prefer to learn when things are more stable, you might prefer to ignore this work for now, and come back when the Suspense ecosystem is more mature.
You can also write your own integration for a data fetching library, if you’d like.
For Library Authors
We expect to see a lot of experimentation in the community with other libraries. There is one important thing to note for data fetching library authors.
Although it’s technically doable, Suspense is not currently intended as a way to start fetching data when a component renders. Rather, it lets components express that they’re “waiting” for data that is already being fetched. Building Great User Experiences with Concurrent Mode and Suspense describes why this matters and how to implement this pattern in practice.
Unless you have a solution that helps prevent waterfalls, we suggest to prefer APIs that favor or enforce fetching before render. For a concrete example, you can look at how Relay Suspense API enforces preloading. Our messaging about this hasn’t been very consistent in the past. Suspense for Data Fetching is still experimental, so you can expect our recommendations to change over time as we learn more from production usage and understand the problem space better.
Traditional Approaches vs Suspense
We could introduce Suspense without mentioning the popular data fetching approaches. However, this makes it more difficult to see which problems Suspense solves, why these problems are worth solving, and how Suspense is different from the existing solutions.
Instead, we’ll look at Suspense as a logical next step in a sequence of approaches:
This is a bit simplified, and in practice solutions tend to use a mix of different approaches. Still, we will look at them in isolation to better contrast their tradeoffs.
To compare these approaches, we’ll implement a profile page with each of them.
Approach 1: Fetch-on-Render (not using Suspense)
A common way to fetch data in React apps today is to use an effect:
We call this approach “fetch-on-render” because it doesn’t start fetching until after the component has rendered on the screen. This leads to a problem known as a “waterfall”.
If you run this code and watch the console logs, you’ll notice the sequence is:
If fetching user details takes three seconds, we’ll only start fetching the posts after three seconds! That’s a “waterfall”: an unintentional sequence that should have been parallelized.
Waterfalls are common in code that fetches data on render. They’re possible to solve, but as the product grows, many people prefer to use a solution that guards against this problem.
Approach 2: Fetch-Then-Render (not using Suspense)
Libraries can prevent waterfalls by offering a more centralized way to do data fetching. For example, Relay solves this problem by moving the information about the data a component needs to statically analyzable fragments, which later get composed into a single query.
On this page, we don’t assume knowledge of Relay, so we won’t be using it for this example. Instead, we’ll write something similar manually by combining our data fetching methods:
waits for both requests but starts them in parallel:
The event sequence now becomes like this:
Of course, this is possible to fix in this particular example. We could remove the Promise.all() call, and wait for both Promises separately. However, this approach gets progressively more difficult as the complexity of our data and component tree grows. It’s hard to write reliable components when arbitrary parts of the data tree may be missing or stale. So fetching all data for the new screen and then rendering is often a more practical option.
Approach 3: Render-as-You-Fetch (using Suspense)
In the previous approach, we fetched data before we called setState :
With Suspense, we still start fetching first, but we flip the last two steps around:
With Suspense, we don’t wait for the response to come back before we start rendering. In fact, we start rendering pretty much immediately after kicking off the network request:
Here’s what happens when we render
suspended, React shows the closest fallback above it in the tree:
Loading profile.
As more data streams in, React will retry rendering, and each time it might be able to progress “deeper”. When resource.user is fetched, the
component will render successfully and we’ll no longer need the
Loading profile.
Note how we eliminated the if (. ) “is loading” checks from our components. This doesn’t only remove boilerplate code, but it also simplifies making quick design changes. For example, if we wanted profile details and posts to always “pop in” together, we could delete the boundary between them. Or we could make them independent from each other by giving each its own boundary. Suspense lets us change the granularity of our loading states and orchestrate their sequencing without invasive changes to our code.
Start Fetching Early
If you’re working on a data fetching library, there’s a crucial aspect of Render-as-You-Fetch you don’t want to miss. We kick off fetching before rendering. Look at this code example closer:
Note that the read() call in this example doesn’t start fetching. It only tries to read the data that is already being fetched. This difference is crucial to creating fast applications with Suspense. We don’t want to delay loading data until a component starts rendering. As a data fetching library author, you can enforce this by making it impossible to get a resource object without also starting a fetch. Every demo on this page using our “fake API” enforces this.
You might object that fetching “at the top level” like in this example is impractical. What are we going to do if we navigate to another profile’s page? We might want to fetch based on props. The answer to this is we want to start fetching in the event handlers instead. Here is a simplified example of navigating between user’s pages:
With this approach, we can fetch code and data in parallel. When we navigate between pages, we don’t need to wait for a page’s code to load to start loading its data. We can start fetching both code and data at the same time (during the link click), delivering a much better user experience.
This poses a question of how do we know what to fetch before rendering the next screen. There are several ways to solve this (for example, by integrating data fetching closer with your routing solution). If you work on a data fetching library, Building Great User Experiences with Concurrent Mode and Suspense presents a deep dive on how to accomplish this and why it’s important.
We’re Still Figuring This Out
Suspense itself as a mechanism is flexible and doesn’t have many constraints. Product code needs to be more constrained to ensure no waterfalls, but there are different ways to provide these guarantees. Some questions that we’re currently exploring include:
Relay has its own answers to some of these questions. There is certainly more than a single way to do it, and we’re excited to see what new ideas the React community comes up with.
Suspense and Race Conditions
Race conditions are bugs that happen due to incorrect assumptions about the order in which our code may run. Fetching data in the useEffect Hook or in class lifecycle methods like componentDidUpdate often leads to them. Suspense can help here, too — let’s see how.
To demonstrate the issue, we will add a top-level component that renders our
with a button that lets us switch between different profiles:
Let’s compare how different data fetching strategies deal with this requirement.
Race Conditions with useEffect
First, we’ll try a version of our original “fetch in effect” example. We’ll modify it to pass an id parameter from the
props to fetchUser(id) and fetchPosts(id) :
Note how we also changed the effect dependencies from [] to [id] — because we want the effect to re-run when the id changes. Otherwise, we wouldn’t refetch new data.
If we try this code, it might seem like it works at first. However, if we randomize the delay time in our “fake API” implementation and press the “Next” button fast enough, we’ll see from the console logs that something is going very wrong. Requests from the previous profiles may sometimes “come back” after we’ve already switched the profile to another ID — and in that case they can overwrite the new state with a stale response for a different ID.
This problem is possible to fix (you could use the effect cleanup function to either ignore or cancel stale requests), but it’s unintuitive and difficult to debug.
Race Conditions with componentDidUpdate
This code is deceptively easy to read.
Unfortunately, neither using a class nor the async / await syntax helped us solve this problem. This version suffers from exactly the same race conditions, for the same reasons.
React components have their own “lifecycle”. They may receive props or update state at any point in time. However, each asynchronous request also has its own “lifecycle”. It starts when we kick it off, and finishes when we get a response. The difficulty we’re experiencing is “synchronizing” several processes in time that affect each other. This is hard to think about.
Solving Race Conditions with Suspense
Let’s rewrite this example again, but using Suspense only:
Again, notice that we’re not waiting for the response to set the state. It’s the other way around: we set the state (and start rendering) immediately after kicking off a request. As soon as we have more data, React “fills in” the content inside components.
This code is very readable, but unlike the examples earlier, the Suspense version doesn’t suffer from race conditions. You might be wondering why. The answer is that in the Suspense version, we don’t have to think about time as much in our code. Our original code with race conditions needed to set the state at the right moment later, or otherwise it would be wrong. But with Suspense, we set the state immediately — so it’s harder to mess it up.
When we write code with Promises, we might use catch() to handle errors. How does this work with Suspense, given that we don’t wait for Promises to start rendering?
With Suspense, handling fetching errors works the same way as handling rendering errors — you can render an error boundary anywhere to “catch” errors in components below.
First, we’ll define an error boundary component to use across our project:
And then we can put it anywhere in the tree to catch errors:
It would catch both rendering errors and errors from Suspense data fetching. We can have as many error boundaries as we like but it’s best to be intentional about their placement.
We’ve now covered the basics of Suspense for Data Fetching! Importantly, we now better understand why Suspense works this way, and how it fits into the data fetching space.
Suspense answers some questions, but it also poses new questions of its own:
To answer these questions, we will refer to the next section on Concurrent UI Patterns.
Практические рекомендации по разработке крупномасштабных React-приложений. Часть 2: управление состоянием, маршрутизация
Сегодня мы публикуем вторую часть перевода материала, который посвящён разработке крупномасштабных React-приложений. Здесь речь пойдёт об управлении состоянием приложений, о маршрутизации и о разработке интерфейсов.
Управление состоянием приложения, интеграция с Redux, организация маршрутизации
Здесь мы поговорим о том, как можно расширить функционал Redux для того, чтобы получить возможность упорядоченно выполнять в приложении сложные операции. Если подобные механизмы реализовать некачественно — они могут нарушить паттерн, используемый при проектировании хранилища.
Функции-генераторы в JavaScript могут решить множество проблем, сопутствующих асинхронному программированию. Дело в том, что эти функции можно запускать и останавливать по желанию программиста. ПО промежуточного уровня redux-saga использует эту концепцию для управления проблемными аспектами приложения. В частности, речь идёт о решении таких задач, решить которые не получается с помощью редьюсеров, представленных в виде чистых функций.
▍Решение задач, которые нельзя решить с помощью чистых функций
Рассмотрим следующий сценарий. Вам предложили поработать над приложением, предназначенным для компании, которая работает на рынке недвижимости. Клиент хочет обзавестись новым, более качественным веб-сайтом. В вашем распоряжении имеется REST API, у вас есть макеты всех страниц, подготовленные с помощью Zapier, вы набросали план приложения. Но тут подкралась здоровенная проблема.
Компания-клиент уже очень давно использует некую систему управления контентом (CMS). Сотрудники компании отлично знают эту систему, поэтому заказчик не хочет переходить на новую CMS только ради того, чтобы облегчить написание новых постов в корпоративный блог. Кроме того, вам нужно ещё и скопировать на новый сайт существующие публикации из блога, а это тоже может вылиться в проблему.
Хорошо то, что CMS, используемая клиентом, имеет удобный API, через который можно получить доступ к публикациям из блога. Но, если вы создали агент для работы с этим API, ситуацию осложняет то, что оно находится на некоем сервере, на котором данные представлены совсем не так, как вам нужно.
Это — пример проблемы, чего-то такого, что может загрязнить код приложения, так как тут приходится включать в проект механизмы для работы с новым API, используемым для загрузки публикаций, сделанных в блоге. Справиться с этой ситуацией можно с помощью redux-saga.
Взгляните на следующую схему. Так выглядит схема взаимодействия нашего приложения и API. Мы загружаем публикации в фоне, используя redux-saga.
Схема приложения, в котором используется хранилище Redux и redux-saga
Вот пример того, как в описываемой ситуации может выглядеть функция-генератор для загрузки публикаций (такие функции называют «сагами»). Саги можно использовать и в других сценариях. Например — для организации хранения данных пользователя (скажем, это могут быть токены), так как это — ещё один пример задачи, для решения которой чистые функции не подходят.
▍Внедрение редьюсеров
При разработке больших приложений невозможно заранее спланировать устройство всех необходимых моделей. Более того, по мере того, как размер приложения увеличивается, использование техники внедрения редьюсеров помогает сэкономить большой объём человеко-часов. Эта техника позволяет разработчикам добавлять в систему новые редьюсеры, не переписывая всё хранилище.
Существуют библиотеки, которые предназначены для создания динамических хранилищ Redux. Однако мне больше нравится механизм внедрения редьюсеров, так как он даёт разработчику определённый уровень гибкости. Например, этим механизмом можно оснастить существующее приложение и при этом не столкнуться с необходимостью серьёзной реорганизации приложения.
Внедрение редьюсеров — это форма разделения кода. Сообщество React-разработчиков с энтузиазмом осваивает эту технологию. Я буду пользоваться этим фрагментом кода для того чтобы продемонстрировать внешний вид и особенности работы механизма внедрения редьюсеров.
Для начала посмотрим на его интеграцию с Redux:
Из документации к Redux можно узнать о том, что функция compose позволяет создавать трансформации глубоко вложенных функций. При этом программист освобождается от необходимости использования очень длинных конструкций. Эти конструкции выглядят как строки кода, представляющие собой вызовы одних функций с передачей им в виде аргументов результатов вызова других функций. В документации отмечается, что функцией compose стоит пользоваться с осторожностью.
▍Маршрутизация и Redux
Существует целый ряд инструментов, которые используются для решения задач маршрутизации в приложениях. В этом разделе мы, однако, остановимся на библиотеке react-router-dom. Мы расширим её возможности таким образом, чтобы она могла бы работать с Redux.
Новой системой маршрутизации, после завершения её настройки, можно пользоваться посредством Redux. Так, навигация в приложении может быть реализована путём отправки действий.
Для того чтобы воспользоваться возможностями библиотеки connected-react-router в компоненте, мы просто выполняем мэппинг метода dispatch на хранилище, делая это в соответствии с нуждами приложения. Вот пример кода, который демонстрирует использование библиотеки connected-react-router (для того чтобы подобный код заработал, нужно, чтобы и остальные части системы были бы настроены на использование connected-react-router).
Динамический пользовательский интерфейс и нужды растущего приложения
Со временем, несмотря на наличие у приложения адекватного бэкенда и качественной клиентской части, некоторые элементы пользовательского интерфейса начинают плохо влиять на работу пользователей. Происходит это из-за нерациональной реализации компонентов, которая, на первый взгляд, кажется очень простой. В этом разделе мы рассмотрим рекомендации, касающиеся создания некоторых виджетов. Их правильная реализация, по мере роста приложения, усложняется.
▍Ленивая загрузка и React.Suspense
Самое приятное в асинхронной природе JavaScript то, что она позволяет задействовать весь потенциал браузера. Пожалуй, истинным благом можно назвать то, что для запуска некоего процесса не нужно ждать окончания выполнения предыдущего задания. Однако разработчики не могут воздействовать на сеть, и на то, с какой скоростью загружаются различные материалы, необходимые для функционирования сайтов.
Сетевые подсистемы обычно воспринимаются как ненадёжные и подверженные ошибкам.
Разработчик, в стремлении сделать своё приложение как можно более качественным, может подвергнуть его множеству проверок и добиться их успешного прохождения. Но всё равно есть некоторые вещи, наподобие состояния сетевого подключения или времени ответа сервера, на которые разработчик повлиять не может.
Но создатели программного обеспечения не стремятся оправдывать некачественную работу приложений фразами вроде «это не моё дело». Они нашли интересные способы борьбы с сетевыми проблемами.
В некоторых частях фронтенд-приложения может понадобиться показать некие резервные материалы (такие, которые загружаются гораздо быстрее, чем реальные материалы). Это позволит избавить пользователя от созерцания «дёргано» загружающихся страниц или, что ещё хуже, примерно таких значков.
Пользователям лучше ничего подобного не видеть
Здесь можно посмотреть хорошее видео о Suspense, в котором Джаред Палмер знакомит аудиторию с этой технологией и показывает некоторые из её возможностей на примере реального приложения.
Вот как работа приложения выглядит без использования Suspense.
Приложение, в котором Suspense не используется
Приложение, в котором используется Suspense
▍Адаптивные компоненты
В больших фронтенд-приложениях проявление повторяющихся паттернов — обычное дело. При этом, в самом начале работы, это может быть практически совершенно неочевидным. С этим ничего не поделать, но вы, наверняка, с этим сталкивались.
Например, в приложении есть две модели. Одна из них предназначена для описания гоночных трасс, а вторая — для описания автомобилей. На странице списка автомобилей используются квадратные элементы. Каждый из них содержит изображение и краткое описание.
В списке трасс используются похожие элементы. Их главная особенность заключается в том, что на них, помимо изображения и описания трассы, имеется ещё и небольшое поле с указанием на то, можно ли зрителям гонки, проходящей на данной трассе, купить что-нибудь поесть.
Элемент для описания автомобиля и элемент для описания трассы
Эти два компонента незначительно отличаются друг от друга в плане стиля (у них разный фоновый цвет). Компонент, описывающий трассу, содержит некоторые дополнительные сведения об описываемом им объекте реального мира, в то время как у компонента, символизирующего автомобиль, таких сведений нет. В этом примере показано всего две модели. В большом приложении может набраться немало подобных моделей, различающихся лишь в мелочах.
Создание отдельных самостоятельных компонентов для каждой из подобных сущностей противоречит здравому смыслу.
Программист может избавить себя от необходимости написания фрагментов кода, которые почти полностью повторяют друг друга. Сделать это можно благодаря разработке адаптивных компонентов. Они, в ходе работы, учитывают окружение, в котором были загружены. Рассмотрим поисковую панель некоего приложения.
Она будет использоваться на многих страницах. При этом на разных страницах в её внешний вид и в порядок её работы будут вноситься небольшие изменения. Например, на домашней странице проекта она будет немного больше, чем на других страницах. Для того чтобы решить эту задачу можно создать один единственный компонент, который будет выводиться в соответствии с переданными ему свойствами.
Используя эту методику можно управлять использованием HTML-классов при рендеринге подобных элементов, что позволяет влиять на их внешний вид.
Ещё одна интересная ситуация, в которой могут найти применение адаптивные компоненты — это механизм разбиения неких материалов на страницы. Навигационная панель может присутствовать на каждой странице приложения. Экземпляры этой панели на каждой из страниц будут практически точно такими же, как на других страницах.
Панель разбивки материалов на страницы
Предположим, что в некоем приложении нужна подобная панель. При работе над этим приложением разработчики придерживаются своевременно сформулированных требований. В подобной ситуации адаптивному компоненту, используемому для разбиения материалов на страницы, нужно передать всего пару свойств. Это — URL и число элементов на странице.
Итоги
Экосистема React в наши дни стала настолько зрелой, что вряд ли у кого-нибудь возникнет нужда в «изобретении велосипеда» на любом этапе разработки приложения. Хотя это играет на руку разработчикам, это приводит к тому, что сложно становится выбрать именно то, что хорошо подходит для каждого конкретного проекта.
Каждый проект уникален в плане его масштабов и функциональности. В разработке React-приложений нет единого подхода или универсальных правил. Поэтому, прежде чем приступить к разработке, важно её правильно спланировать.
При планировании очень легко понять то, какие инструменты прямо-таки созданы для проекта, а какие ему явно не подходят, являясь слишком масштабными для него. Например, приложение, состоящее из 2-3 страниц и выполняющее очень мало запросов к неким API, не нуждается в хранилищах данных, похожих на те, о которых мы говорили. Я готов пойти в этих рассуждениях ещё дальше, и сказать, что в маленьких проектах не нужно использовать Redux.
На этапе планирования приложения, в ходе рисования макетов его страниц, легко увидеть то, что на этих страницах используется много похожих компонентов. Если постараться повторно использовать код подобных компонентов или стремиться к написанию универсальных компонентов — это поможет сэкономить немало времени и сил.
И наконец, мне хотелось бы отметить, что данные — это стержень любого приложения. И React-приложения — не исключение. С ростом масштабов приложения растут и объёмы обрабатываемых данных, появляются дополнительные программные механизмы для работы с ними. Нечто подобное, если приложение было плохо спроектировано, легко может прямо-таки «раздавить» программистов, завалив их сложными и запутанными задачами. Если же, в ходе планирования, заранее были решены вопросы использования хранилищ данных, если заранее был продуман порядок работы действий, редьюсеров, саг, то работать над приложением будет уже гораздо легче.
Уважаемые читатели! Если вам известны какие-нибудь библиотеки или методологии разработки, которые хорошо показывают себя при создании крупномасштабных React-приложений — просим ими поделиться.