Небольшое практическое исследование было вдохновлено статьей https://itnext.io/using-css-to-speed-up-your-react-apps-a26470829472, а конкретно следующим отрывком (перевод мой):
Hiding instead of unmounting
Представьте, что у вас есть 2 вкладки. При переключении между ними стандартными методами “React” происходит размонтирование “таба из” и монтирование “таба в”. ... пример из Твиттера ...
Ответ кроется в React runtime. Каждый раз при монтировании нового компонента, React должен создать virtual DOM (связанный список всех подкомпонентов внутри смонтированного дерева),выполнить всю логику внутри каждого из компонентов (или deprecated
componentWillMount
) и затем добавить компоненты в DOM. В то же время, React должен размонтировать предыдущий компонент,что означает - свернуть virtual DOM, прогнатьcomponentWillUnmount
и затем удалить соответствующие элементы из DOM.Возможно, это окажется сюрпризом, но размонтирование - не дешевая операция. Вы можете подумать, что это просто удаление, но React должен удалить рефы из многих участков virtual DOM и прогнать жизненные циклы всех компонентов, которые будут отмонтированы (unmounted). Это может происходить не быстро. До времен React Fiber (перед React 15.x.x.) размонтирование предыдущего и монтирование следующего компонента было последовательным. Нынче, React производит это параллельно для экономии времени, с учетом того, что эти процессы не зависят друг от друга.
Фокус в том,чтобы не заставлять React монтировать\размонтировать,а использовать CSS для показа\скрытия содержимого табов.
Дальше было про тот же пример из Твиттера и то, что при таком подходе к разработке - DOM дерево может слишком разрастись. Как разработчик приложения, которое потенциально может генерировать очень много компонентов и огромное количество табов (и человек, получивший задачу разобраться - а не будет ли это хорошей оптимизацией))) - я решил написать простой код для проверки этой теории и соотвественно последствий:
import './App.css';
import uniqid from 'uniqid';
import React,{useState} from 'react';
function App() {
const [tab, setTab] = useState(true)
const Row = (quantity, bColor) => {
const result = []
for (let i =0; i< quantity; i+=1){
result.push(<div key={uniqid + i} style={{height: '30px', width: '200px', border:'1px solid '+ bColor }}>Row {i} Tab {tab?1:2}</div>)
}
return result
};
const handleClick = () => {
console.log(tab)
setTab(tabState=>!tabState)
}
return (
<div className="App">
<button type='button' onClick={handleClick}>Вкладка {tab?1:2}</button>
<div style={{height: '300px', width: '300px', overflow:'auto', border:'1px solid gray', margin: '0 auto' }}>
{/* { <ul>
{tab && Row(50000, 'tomato')} */}
{ <ul style={{display:!tab?'none':'block'}}>
{Row(50000, 'tomato')}
</ul>}
{/* { <ul>
{!tab && Row(50000, 'green')} */}
{ <ul style={{display:tab?'none':'block'}}>
{Row(50000, 'green')}
</ul>}
</div>
</div>
);
}
export default App;
Единственная бибилиотека, которая была установлена после CRA и дальнейшей чистки от лишнего - это uniqueId (для дополнительной нагрузки и дополнительный демонстрации - как работают ключи). Код имитирует переключение между двумя табами по нажатию кнопок - закомментированный участок кода из 2х строк заменяет собой раскомментированный и наоборот. Мы генерируем 2 списка по 50000 строк (в зависимости от мощности вашего компьютера - для наглядности, попробуйте поиграть с этой цифрой, если отрабатывает слишком быстро или слишком медленно) с немного разными стилями.
Как это работает, уверен, каждый в состоянии проверить сам, так что перейду сразу к выводам:
в случае с работой через React-way у меня на ноутбуке переключение между табами составляет от 7 до 10 секунд
в случае с работой через скрытие display:none\display:block - переключение от 1.5 до 2.5 секунд
Казалось бы вопросы сняты - можно пользоваться, но давайте посмотрим на выделение памяти для chrome.exe(для win10 - это найти через поиск "монитор ресурсов"):
потребление памяти находится в рамках 600-1200мб в случае с рендером методами React
от 1800 до 3200мб в случае со скрытием табов через стили
Итог: для твиттера и таба настроек\юзера- очень даже неплохой вариант, а вот если что-то потенциально более нагруженное или с бОльшим (или непредсказуемым) количеством тяжелых табов- то лучше не надо(в перевод статьи этот вывод не вошел для сохранения интриги).
Update: в ближайшее время ожидаем в react@18+ Offscreen api, что должно снять вообще этот вопрос.