React-подобное программирование без React
Я вырос на JQuery и следовал шаблону программирования, который можно было бы назвать "похожим на React", но не использовал React. Тем не менее, я хотел бы знать, как хорошо обстоят дела с моей графической производительностью.
Например, в моем интерфейсе у меня есть таблица, которая отображает некоторое "состояние" (в терминах React). Однако это "состояние" для меня просто хранится в глобальных переменных. у меня есть update_table() функция, которая является центральным местом, где происходят обновления таблицы. Он принимает "состояние" и отображает таблицу вместе с ним. Первое, что он делает, это звонит $("#table").empty() чтобы начать все сначала, а затем заполняет строки информацией о состоянии.
У меня есть некоторые динамически изменяющиеся данные ("состояние") каждые 2-3 секунды на стороне сервера, которые я опрашиваю с помощью Ajax, и как только я получаю данные / "состояние", я просто вызываю update_table(),
Это идеальная проблема для решения с React, я знаю. Однако после реализации этого простого решения с помощью JQuery я вижу, что оно работает просто отлично (я не заполняю огромную таблицу здесь; у меня максимум 20 строк и 5 столбцов).
Я ожидал увидеть мерцание из-за $("#table").empty() вызов с последующим добавлением строк один за другим внутри update_table() функция. Однако браузер (chrome/safari) почему-то очень хорошо выполняет работу по обновлению только тех элементов, которые действительно изменились (почти как если бы в браузере была реализована виртуальная DOM/diffing, например, React!)
2 ответа
Я предполагаю, что ваш вопрос заключается в том, почему вы можете иметь такую хорошую графическую производительность без React.
То, что вы видите как "хорошую производительность графики", на самом деле является вопросом определения или, что еще хуже, мнения.
Классический цикл обработки Netscape (который наследуют все современные браузеры) состоит в основном из четырех основных этапов. Вот полное описание двигателя Gecko.
Пока вы манипулируете DOM, вы находитесь в стадии "обновления DOM", и рендеринг не выполняется ВСЕ. Только когда ваш код дает результат, начинается следующий этап. Из-за изменений в DOM размеры или положения некоторых элементов тоже могли измениться. Таким образом, этот этап пересчитывает макет. После этой стадии следующим является рендеринг, где пиксели перерисовываются.
Это означает, что если ваш код изменяет очень большое количество элементов в DOM, они все по-прежнему отображаются вместе, а не в пошаговом режиме. Таким образом, вызов empty() не отображается, если вы сразу же заполняете таблицу.
Теперь, когда вы видите пиксели элемента, такого как "13872", стадия рендеринга может рендерить пиксели в точно такой же позиции с одинаковыми цветами. У вас нет никаких изменений в цвете пикселей, и, следовательно, вы не можете увидеть мерцание.
Тем не менее, ваша графическая производительность превосходна - да. Но как ты это измерил? Вы просто посмотрели на это и решили, что это идеально. Теперь визуально это действительно может быть очень, очень хорошо. Потому что все, что вам нужно, это избегать стадии макета от изменения размера / расположения чего-либо по-другому.
Но фактическая производительность не измеряется ленивыми глазами людей (в этой области много исследований юзабилити, допустим, что один кадр при 60 Гц занимает 16,6 мс, поэтому этого достаточно для рендеринга меньше). Он измеряется с помощью фактической метрики (обновлений в секунду или чего-либо еще). Учтите, что на старых машинах с более старыми браузерами и медленными видеокартами ваша "отличная" производительность может выглядеть постыдной. Откуда вы знаете, что это все еще хорошо на старом планшете Toshiba с 64 МБ графической памяти?
А как насчет масштабирования? Если у вас есть 100х элементов, которые у вас есть сейчас, вы уверены, что они будут хорошо масштабироваться? Что если некоторые данные занимают больше (или меньше) места и изменяют весь макет? Все эти граничные условия могут не охватываться вашим простым подходом.
Библиотека, подобная React, учитывает те случаи, с которыми вы, возможно, еще не сталкивались, и предлагает единый шаблон для их решения.
Поэтому, если вы довольны своим решением, вам не нужен React. Я часто избегаю jQuery, потому что ES5/ES6 уже довольно хорош в наши дни, и я могу просто записать 3-4 строки кода, используя document.getElementById() и тому подобное. Но я понимаю, что в больших проектах или сложных случаях jQuery - идеальный инструмент.
Посмотрите на React так: инструмент, который полезен, когда вы понимаете, что он вам нужен, и громоздок, когда вы думаете, что можете обойтись без него. Все зависит от тебя:)
Когда у вас есть что-то вроде этого:
$("#table").empty()
.html("... new content of the table ... ");
тогда происходит следующее:
.empty()удаляет содержимое и помечает дерево / макет рендеринга как недействительные..html()добавляет новый контент и помечает рендеринг дерева / макета как недействительный.
пометить как недействительный среди прочего вызов InvalidateRect () (в Windows), который заставляет окно получать событие WM_PAINT в какой-то момент в будущем.
Обрабатывая WM_PAINT, браузер рассчитает макет и отобразит весь результат.
Поэтому несколько запросов на изменение будут объединены в одну операцию рисования окна.