Реагировать, как программирование без Реагировать

Question

Я вырос с использованием JQuery и следовали шаблон программирования, который можно было бы сказать, «Реагировать -как», но не с помощью Реагировать. Я хотел бы знать, как моя графика работает так хорошо, тем не менее.

В качестве примера, в моем интерфейсе у меня есть таблица, которая отображает некоторое «состояние» (в React). Однако это «состояние» для меня просто хранится в глобальных переменных. У меня есть функция update_table(), которая является центральным местом, где происходят обновления таблицы. Он принимает «состояние» и отображает таблицу с ним. Первое, что он делает, это вызвать $("#table").empty(), чтобы получить чистый старт, а затем заполнить строки информацией о состоянии.

У меня есть динамически изменяющиеся данные («состояние») каждые 2-3 секунды на стороне сервера, которые я опроса использую Ajax, и как только я получу данные/«состояние», я просто вызываю update_table().

Это идеальная проблема для решения с React, я знаю. Однако после реализации этого простого решения с JQuery я вижу, что он работает отлично (я не заполняю огромную таблицу здесь, у меня максимум 20 строк и 5 столбцов).

Я ожидал увидеть мерцание из-за вызова $("#table").empty() с последующим добавлением строк один за другим внутри функции update_table(). Тем не менее, браузер (хром/сафари) каким-то образом, похоже, делает очень хорошую работу по обновлению только тех элементов, которые фактически изменились (почти как если бы браузер имел реализацию Virtual DOM/diffing, например React!)

Answer 1

Я думаю, ваш вопрос в том, почему вы можете иметь такую ​​хорошую графическую производительность без React.

То, что вы видите как «хорошее графическое исполнение», действительно является вопросом определения или, что еще хуже, мнения.

Классический цикл обработки Netscape (который наследует все современные браузеры) имеет в основном четыре основных этапа. Here is the full-blown Gecko engine description.

До тех пор, пока вы манипулируете DOM, вы находитесь на стадии обновления «DOM», и рендеринг не выполняется во ВСЕХ. Только когда ваш код выйдет, начнется следующий этап. Из-за изменений DOM размеры или позиции некоторых элементов также могут измениться. Таким образом, этот этап пересматривает макет. После этого этапа следующий - рендеринг, где пиксели перерисовываются.

Это означает, что если ваш код изменяет очень большие числовые элементы в DOM, они все еще отображаются вместе, а не инкрементно. Таким образом, вызов empty() не отображается, если вы повторно заполняете таблицу сразу после.

Теперь, когда вы видите пиксели элемента типа «13872», этап рендеринга может отображать те, которые находятся в том же положении, с одинаковыми цветами. У вас нет каких-либо изменений в цвете пикселей, и, таким образом, вы не видите мерцание.

Тем не менее, ваша графическая производительность отличная - да. Но как вы его измерили? Вы просто посмотрели на него и решили, что это прекрасно. Теперь визуально это действительно может быть очень хорошо. Потому что все, что вам нужно, - это избежать стадии компоновки от калибровки/позиционирования что-то по-другому.

Но фактическое исполнение не измеряется ленивыми глазами людей (есть много исследований удобства использования в этой области, скажем, что один кадр с частотой 60 Гц занимает 16,6 мс, поэтому этого достаточно, чтобы сделать меньше) , Он измеряется с фактической метрикой (обновления в секунду или что-то еще). Учтите, что на старых компьютерах с более старыми браузерами и более медленными графическими картами ваша «отличная» производительность может выглядеть позорной. Как вы знаете, что он по-прежнему хорош на старом планшете Toshiba с 64-мегабайтной графической памятью?

А как насчет масштабирования? Если у вас есть 100x элементов, которые у вас есть сейчас, уверены ли вы, что он будет хорошо масштабироваться? Что делать, если некоторые данные занимают больше (или меньше) пространства и меняют весь макет? Все эти краевые условия могут не охватываться вашим простым подходом.

Библиотека, подобная React, учитывает те случаи, которые вы, возможно, еще не встречали, предлагает единый шаблон для их приближения.

Итак, если вы довольны своим решением, вам не нужен Реакт. Я часто избегаю jQuery, потому что ES5/ES6 уже очень хорош в наши дни, и я могу просто записать 3-4 строки кода, используя document.getElementById() и т. Д. Но я понимаю, что в больших проектах или сложных случаях jQuery - идеальный инструмент.

Посмотрите на так: инструмент, который полезен, когда вы понимаете, что вам это нужно, и громоздко, когда вы думаете, что можете обойтись без него. Это все до вас :)

Answer 2

Если у вас есть что-то вроде этого:

$("#table").empty() 
      .html("... new content of the table ... "); 

то происходит следующее:

1. .empty() удаляет содержимое и метки визуализации дерева/макета как недействительные.
2. .html() добавляет новый контент и маркирует рендеринг дерева/макета как недействительный.

знак недействительным среди прочего вызывает InvalidateRect() (на Windows), который вызывает окно получить WM_PAINT событие в какой-то момент в будущем.

Обращаясь с WM_PAINT, браузер вычислит макет и отобразит весь результат.

Поэтому несколько запросов на изменение будут свернуты в операцию рисования одного окна.