Javascript-форум (https://javascript.ru/forum/)
-   Библиотеки/Тулкиты/Фреймворки (https://javascript.ru/forum/library-toolkit-framework/)
-   -   вопрос стратегии React (https://javascript.ru/forum/library-toolkit-framework/86390-vopros-strategii-react.html)

fxobject 15.04.2025 23:15

вопрос стратегии React
 
Уважаемые форумчане! Ну что ж вы такие пассивные?
Подскажите, наверняка сталкивались со следующим вопросом:
на Vue была ранее реализована таблица. Неважно что там и как - достаточно, что в ней стилем подсвечивается строка и клавиатурой можно управлять этой строкой. двигаться так сказать по строкам таблицы.
Перевел задачу на React. И сразу столкнулся с производительностью. В Vue нажимаем и держим клавишу - бежит ровненько и быстренько. В React - движение замедленно и какие то строки "проглатываются". В смысле 1,2 3. перескакивает на 5 и т.д.
Понимаю - вопрос отрисовки и взаимодействие компонентов. Подскажите стратегически как правильно решать подобные задачи.
Как решено:
Таблица выводится в отдельном компоненте. Данные для нее поступают как props.
render таблицы осуществляется map в котором каждый элемент является отдельной компонентой - row (в нем осуществляется вывод строки)
для компонента row - данные поступают как props
события нажатия обрабатываются в компоненте table (делать в row) было бессмысленно, все равно пришлось бы "выходить" на уровень table
итак в обработчике нажатия клавиши setState изменение текущей активной строки и далее пошла отрисовка всей!!!! таблицы.
Тут также замечу, что отрисовка происходит, даже если меняется переменная из state, которая ну никак не задействована в выводе. Просто - есть setState - есть отрисовка.
Далее в row также задействована процедура shouldComponentUpdate
которая возвращает true только для прошлой текущей активной строки и новой будущей. по идее отрисовка должна проходить только для двух строк. ну я так думаю.....
но все таки медленно....... пока остановка... чух чух чух. подскажите стратегию!!!

Aetae 16.04.2025 00:16

Скорее всего надо чтоб лишние row не перерисовывались, для этого map должен проставлять key, данные передающиеся в row не меняться, а сами row должны быть memo...
Ну и нафиг реакт, используй vue.:)

fxobject 16.04.2025 08:41

React, взгляд со стороны. (не более чем личное мнение). Итак React или Vue?
Rect изучаю ну может быть с неделю, но мнение о нем уже составлено.
Итак:
возможности фрейморков, здесь говорить не о чем. В принципе все что можно сделать в одном, можно сделать в другом.
Очень важный параметр как скорость и тяжеловесность для браузера. Здесь тоже особенно говорить не о чем.
В принципе результаты сопоставимы. Очень важный момент, который бы хотелось отметить в отношении React, - он спроектирован и реализован очень профессионально.
"Голубая кровь" в нем так и прет наружу. Уж извините за сравнение. В нем вам никогда не придется возвращаясь к задаче, "вспоминать" как все было сделано.
То что часто пишут - "разбираться в чужом коде", в React с этим дело иметь не придется.
Если вы любите программировать, и считаете что ковыряние компонент js это ваше любимое занятие - vue. Если вы считаете что визуализация задачи -
это ремесло (сделал, забыл идем дальше...) - это React.
Есть у меня претензии (шероховатости) к React? Ну конечно - есть.
И несмотря на это Vue - это сделано в китае, React - это facebook. Вот просто вынужден признать, - качество! Дальше думайте сами.
Теперь также хочу высказать свое понимание стратегии создания компонентов в React.
Первое что нужно понимать - никто за вашим кодом не следит ( типа оптимальность, если не изменилось, то не перерисовывается... - хрень ).
Ну может при переходе от виртуальной DOM к браузерой что то подобное и есть, но я сомневаюсь в этом. Исхожу теперь из гипотезы:
Есть setState - есть render. Независимо что там у вас setState, render в полном объеме.
Поэтому если создается приложение (как правило - система меню, отдельные блоки новости,строки состояний и прочее) в котором есть основной App
а все остальное как компоненты внутри этого App, то это неправильно. С точки зрения производительности необходимо разделять компоненты (делать из несвязными)
и разделение такое осуществляется по экранным блокам выводимой информации. Например если есть меню - то меню это отдельный компонент, в нем вложены кнопки,
ссылки, меню других уровней. Но этот компонент меню не вложен ни в какой другой компонент. т.е. у него нет родителя. Аналогично все остальные блоки приложения.
Т.е. под рекомендацией React разделять компоненты (дробить) я понимаю именно это. При таком подходе у вас никогда не возникнет вопрос производительности.
Добиться этого не сложно. Остается вопрос связи таких "независимых" компонентов между собой. Это тот вопрос, который я поднимал в предыдущем топике. И у него есть решения.

Теперь, как был все-таки решен заданный мной вопрос. memo в данном случае не подходит. Это решение суть - то же самое что shouldComponentUpdate.
Итак данный пример чудненько решается если перенести обработку ArrowUp ArrowDown в компонент row. получение события обеспечивает фокусировка.
При получении события только одна строка (ативная) перерисовывается (становится неактивной) и передает родительскому компоненту сообщение о перерисовке.
Родительский компонент, фиксирует у себя номер новой активной строки и обращается в дочернему классу (используя дочерний this) этой новой строки с ненавязчивой просьбой перерисоваться. )))
Результат круче чем в Vue.
В любом случае рекомендую всякие раз создавая компоненту закладывать shouldComponentUpdate. Без этого в React не обойтись. дело утопающих дело рук самих утопающих.
Всем спасибо за терпение

ksa 16.04.2025 08:54

Цитата:

Сообщение от fxobject
Понимаю - вопрос отрисовки и взаимодействие компонентов.

Т.е. свое участие ты полностью исключил? :D

Вместо рассказа, лучше бы пример тестовый сделал и тут показал...
Так хоть будет понятно чего ты там накрутил.


Часовой пояс GMT +3, время: 02:42.