Эффективная стратегия хранения и извлечения данных в React для высокопроизводительных корпоративных приложений
В настоящее время я изучаю стратегии оптимизации хранения и извлечения данных для приложения корпоративного уровня, требующего высокой масштабируемости и производительности. В своем стремлении повысить эффективность я рассмотрел возможность использования таких возможностей React, как memoization, PureComponent и React.memo.
Один из подходов, который я рассматриваю, предполагает хранение данных приложения в элементах DOM и доступ к ним через ссылку. Вот фрагмент, демонстрирующий мой подход:
<div
ref = {myRef}
data-my-data = {myData}
>
<MyReactComponents />
</div>
Мне интересно узнать, соответствует ли эта методология лучшим практикам достижения производительности, удобства обслуживания и масштабируемости в приложениях React. В частности, я ищу информацию о следующем:
- Повысит ли эффективность хранение данных в элементах DOM, как показано выше?
- Какие потенциальные проблемы могут возникнуть с точки зрения масштабирования и удобства обслуживания?
- Существуют ли альтернативные стратегии или способы оптимизации, которые мне следует рассмотреть для достижения оптимальной производительности в корпоративном контексте?
Мы будем очень признательны за любые указания или рекомендации от опытных разработчиков React. Спасибо!
Проблем с производительностью пока нет. Я размышляю вслух, является ли этот подход достаточно быстрым и масштабируемым по сравнению с другими традиционными подходами реагирования.
Хорошо. Я просто пытаюсь понять, что заставляет вас использовать это как инструмент. Большинство проблем с производительностью реакции сводятся к рендерингу большего количества раз, чем необходимо, или к большему количеству элементов, чем необходимо. Помогает ли атрибут data- в одном из них, и если да, то как он помогает?
@NicholasTower, моя главная цель - узнать, установлю ли я данные в DOM в атрибутах data-, будет ли это быстрее с точки зрения чтения и повышения производительности по сравнению с сокращением или как значение состояния. Поскольку масштабирование будет высоким, мне нужно понимать последствия и соответствующим образом планировать свой подход.
Я работаю фронтенд-архитектором крупного приложения React для электронной коммерции, доход которого составляет около 10 миллиардов долларов США в год. Короткий ответ: короткого ответа не существует. В этом масштабе единственный ответ — «проверяйте все», никакие общие советы в Интернете вам не помогут. Например, с точки зрения чистого коэффициента конверсии CSR превосходит SSR (как ни странно) примерно на 200 базисных пунктов. Стоит ли тогда забывать о РСБ? Нет, если только ваша клиентская база не похожа на нашу! И даже среди наших клиентов есть значительная группа, которую SSR лучше обслуживает. Не думайте, мера мера мера!
Подход к хранению данных в элементах DOM будет эффективен в тех случаях, когда вам необходимо часто получать доступ к данным внутри ваших реагирующих компонентов. Но когда дело доходит до удобства обслуживания. Если вам пришлось реструктурировать ваши компоненты, то манипулирование данными, хранящимися в существующих элементах, стало бы проблемой. Поэтому я бы не рекомендовал такой подход. @devil-0-per
![Безумие обратных вызовов в javascript [JS]](https://i.imgur.com/WsjO6zJb.png)
Ответы 2
Повысит ли эффективность хранение данных в элементах DOM, как показано выше?
Я не понимаю, как это может помочь. Если у вас есть данные, необходимые для рендеринга, их необходимо так или иначе привести в состояние. Это потому, что состояние — это единственный способ, которым React знает, что ему нужно выполнить повторный рендеринг. В редких случаях, когда данные не нужны для рендеринга, вы можете поместить их куда угодно (включая атрибут data-), но это также вряд ли повлияет на производительность.
Большинство проблем с производительностью реакции сводятся к рендерингу большего количества раз, чем необходимо, или к большему количеству элементов, чем необходимо. Что касается общих советов, я бы рекомендовал вам делать ваши компоненты небольшими и располагать состояния ближе к месту их использования. В сочетании с упомянутыми вами инструментами запоминания они могут минимизировать количество элементов, которые необходимо повторно отображать при изменении состояния.
Если переменная состояния необходима для больших частей приложения (глобальное состояние), то стандартный подход реагирования заключается в том, чтобы поднять ее на вершину дерева компонентов и передать вниз. Если вы передаете его через реквизиты, это может привести к повторной визуализации всего дерева компонентов. Поэтому часто лучше передать его через контекст и поместить запомненный компонент прямо под поставщиком контекста, который может заблокировать рендеринг большей части дерева компонентов.
Библиотеки глобальных менеджеров состояний могут быть еще одним инструментом, поскольку они обычно пишутся так, чтобы эффективно использовать скрытое состояние. Например, в Redux хук useSelector используется для подписки на магазин. Если соответствующая часть хранилища изменится, она установит состояние в конкретном компоненте, который вызвал useSelector, чтобы состояние было как можно ближе к тому месту, где оно используется. Таким образом, только этот компонент и его потомки должны перерисовываться.
И последний совет: если вы размещаете на странице много вещей, но большая их часть находится за кадром, рассмотрите возможность создания виртуализированного списка, например, с помощью Reaction-Window. Это может существенно повысить производительность, если вы отображаете большой список.
Задача фрейма: производительность НЕ является целью
Если вы задаете абстрактный вопрос как академическое упражнение, конечно, ничего страшного, но вы явно структурировали это как корпоративное приложение. Производительность не является целью бизнеса. Увеличение доходов и сокращение затрат являются целями бизнеса. Производительность полезна тогда и только тогда, когда она способствует достижению этих целей, и только в той степени, в которой она способствует этим целям. Что касается этого, ну...
Я работаю фронтенд-архитектором крупного приложения React для электронной коммерции, доход которого составляет около 10 миллиардов долларов США в год. Короткий ответ: короткого ответа не существует. В этом масштабе единственный ответ — «проверяйте все», никакие общие советы в Интернете вам не помогут.
Конечно, в нашем случае существует измеримая корреляция, например, между Основные показатели Google Web Vitals и доход. Но вы не можете просто предполагать Moar Performance === Moar $$$, например, с точки зрения чистого коэффициента конверсии для нас CSR превосходит SSR (как ни странно) примерно на 200 базисных пунктов. Стоит ли тогда забывать о РСБ? Нет, если только ваша клиентская база не похожа на нашу! И даже среди наших клиентов есть значительная группа, которую SSR лучше обслуживает. Не предполагайте, мера мера мера!
Если вы не настроены на отслеживание таких показателей, забудьте о микрооптимизации JS и сделайте это в первую очередь. Если вы уже настроили отслеживание этих показателей, то почему вы спрашиваете нас?
Мне не удается увидеть связь между сохранением значений в атрибутах
data-и повышением производительности. С каким узким местом в производительности вы столкнулись?