Комментарии 13
Люблю наблюдать, как натягивание какой-то абстракции на имеющийся домен внезапно рушит вещи, которые в абстракцию не очень вписываются. Это даже не про реакт 17, а про реакт вообще. Скажем, вот есть у нас модель, схематично описываемая объектом со структурой a.b.c, и соответствующие вкладывающиеся друг в друга реакт-компоненты A, B, и С. Что можно сделать в парадигме реакта, чтоб перерисовать B и только B? А ничего. Даже не смотря на то, что при неизменности C не произойдет собственно обновления соответствующего узла DOM, это очень слабое утешение, потому что море бесполезной работы (рендер в VDOM, сравнение VDOM и DOM) всё равно будет безусловно проделано. Что очень даже больно, если у вас не один C, а тысячи.

Всё, что может предложить в ответ реакт — это «делите компоненты», и вот мне уже нужно иметь компонент «обертка (списка) C», который не имеет никакого смысла для моей модели UI и нужен исключительно для того, чтоб реакт мог «догадаться», что эта часть дерева компонентов не поменялась. Просто потому, что концепция частичных изменений (которую очень легко реализовать с vanillaJS, потому что взаимодействие с DOM идёт по отдельным элементам, очень легко не трогать тот DOM, который трогать не надо) в реакте просто не ночевала.

И это я даже не говорю про то, что даже после всего дробления всё равно нужно выполнять довольно неочевидные действия в модели (новый объект b, указывающий на старый (список) c) просто потому, что реакт предлагает исключительно referential equality в деле сравнения пропсов.

ЗЫ: А, так вот. Вангую, что с concurrent mode масса реактопрограммистов просто будет дергать эти самые перерисовки длинных списков везде, где не надо (как это сейчас уже происходит), и будет радоваться тому, что браузер больше не подвисает и вообще всё шоколадно. А юзеры на не очень крутых машинах будут наблюдать, как у них куски страниц неторопливо и торжественно обновляются по частям туда-сюда прямо на глазах. Зато браузер не подвисает, ага.

Строго говоря, с помощью React и соответствующего драйвера можно рисовать что угодно и где угодно. Хоть на Canvas, хоть в командной строке. Но это все в теории, а на практике у нас SyntheticEvent и Concurrent Mode.


Я думаю, в каком-то новом React будет более близкое API к браузеру. Может быть даже и работа напрямую с DOM там, где это необходимо. Shadow DOM, опять же, пока React обходит стороной.


Одно радует, что API React меняется, не держится сильно за старое, и есть надежда на светлое будущее =)

Или в каком-то новом браузере будет вменяемое API близкое к React, с реализацией на расте.
Что можно сделать в парадигме реакта, чтоб перерисовать B и только B? А ничего.


Ну ты можешь убрать лишние рендеры, если тебе это нужно
const Header = ({title}) => {title}
export default React.memo(Header);
Это и есть создание никому (кроме реакта) не нужных обёрток.

Вы так говорите, как будто в этом есть что-то плохое.
Все программирование — это обертки. Обертки над обертками. Или абстракции.


В данном случае мы жертвуем унификацией использования этой абстракции производительностью.
В следующий раз, как вы будете писать какое-нибудь замыкание, задумайтесь о никому не нужных обертках =)

Таки да, в этом очень много плохого. Когда обертки порождены невыразительностью абстракций самого фреймворка — это говорит только о том, что фреймворк не так уж и хорош.
Это особенно хорошо видно, стоит только лишь взять любой нормальный FRP (от того же MobX или RxJS до, скажем, той реактивности, что из коробки предлагает Svelte), и обнаружить, что с нормальными абстракциями лишние обертки не появляются; да и описывать изменения моделей без принудительной referential equality гораздо легче.

Конкретно с React.memo ситуация вообще интересная — если просто почитать документацию в контексте всей остальной документации реакта (настоятельных рекомендаций делать «глупые» компоненты, выносить работу с данными, и так далее) — становится очевидным, что вообще-то согласно всё той же документации React.memo следует применять везде, а ситуации, где он таки не используется, должны быть редкими исключениями. А не наоборот. Это вообще явно указывает на кривизну изначально заложенных в фреймворк абстракций.
Простите за оффтоп, но ждал появления Svelte еще в первом вашем комменте. Когда вижу кого-то, кто цепляется к каким-то незначительным недостаткам ведущей тройки фреймворков (на уровне вкусовщины), а потом огромными комментами с использованием множества аббревиатур и англицизмов пытается раздуть их до астрономических размеров, понимаю — передо мной поклонник этого молодого фреймворка)
незначительным недостаткам

Кривые идеи в основе реакта — это конечно же незначительные недостатки, полностью с вами согласен.

А напишите статью про кривые идеи в основе реакта!
Было бы интересно это еще и подкрепить мотивацией авторов для добавления таких кривых идей. Для большей объективности.


С радостью бы почитал такое и улучшил скилл мета-программирования.

Посмотрел по-диагонали. Этот странный человек борется с пробросом пропсов написанием странного костыля, вместо того, что-бы использовать React.Context. И где-то походя ругает редукс.
Вопрос что произойдет со ссылкой на компонент после анмаунта, как я понял, не рассматривается даже.
«Решение», которое автор предлагает — довольно кривое, и его за это уже там покритиковали все кому не лень. Но я не про решение, а про проблему, которую он описывает, если уж мы говорим о проблемах реакта. Проблема описывается самая что ни на есть животрепещущая.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Минуточку внимания

Разместить