Comments 13
Всё, что может предложить в ответ реакт — это «делите компоненты», и вот мне уже нужно иметь компонент «обертка (списка) C», который не имеет никакого смысла для моей модели UI и нужен исключительно для того, чтоб реакт мог «догадаться», что эта часть дерева компонентов не поменялась. Просто потому, что концепция частичных изменений (которую очень легко реализовать с vanillaJS, потому что взаимодействие с DOM идёт по отдельным элементам, очень легко не трогать тот DOM, который трогать не надо) в реакте просто не ночевала.
И это я даже не говорю про то, что даже после всего дробления всё равно нужно выполнять довольно неочевидные действия в модели (новый объект b, указывающий на старый (список) c) просто потому, что реакт предлагает исключительно referential equality в деле сравнения пропсов.
ЗЫ: А, так вот. Вангую, что с concurrent mode масса реактопрограммистов просто будет дергать эти самые перерисовки длинных списков везде, где не надо (как это сейчас уже происходит), и будет радоваться тому, что браузер больше не подвисает и вообще всё шоколадно. А юзеры на не очень крутых машинах будут наблюдать, как у них куски страниц неторопливо и торжественно обновляются по частям туда-сюда прямо на глазах. Зато браузер не подвисает, ага.
Строго говоря, с помощью React и соответствующего драйвера можно рисовать что угодно и где угодно. Хоть на Canvas, хоть в командной строке. Но это все в теории, а на практике у нас SyntheticEvent и Concurrent Mode.
Я думаю, в каком-то новом React будет более близкое API к браузеру. Может быть даже и работа напрямую с DOM там, где это необходимо. Shadow DOM, опять же, пока React обходит стороной.
Одно радует, что API React меняется, не держится сильно за старое, и есть надежда на светлое будущее =)
Что можно сделать в парадигме реакта, чтоб перерисовать B и только B? А ничего.
Ну ты можешь убрать лишние рендеры, если тебе это нужно
const Header = ({title}) => {title}
export default React.memo(Header);Вы так говорите, как будто в этом есть что-то плохое.
Все программирование — это обертки. Обертки над обертками. Или абстракции.
В данном случае мы жертвуем унификацией использования этой абстракции производительностью.
В следующий раз, как вы будете писать какое-нибудь замыкание, задумайтесь о никому не нужных обертках =)
Это особенно хорошо видно, стоит только лишь взять любой нормальный FRP (от того же MobX или RxJS до, скажем, той реактивности, что из коробки предлагает Svelte), и обнаружить, что с нормальными абстракциями лишние обертки не появляются; да и описывать изменения моделей без принудительной referential equality гораздо легче.
Конкретно с React.memo ситуация вообще интересная — если просто почитать документацию в контексте всей остальной документации реакта (настоятельных рекомендаций делать «глупые» компоненты, выносить работу с данными, и так далее) — становится очевидным, что вообще-то согласно всё той же документации React.memo следует применять везде, а ситуации, где он таки не используется, должны быть редкими исключениями. А не наоборот. Это вообще явно указывает на кривизну изначально заложенных в фреймворк абстракций.
незначительным недостаткам
Кривые идеи в основе реакта — это конечно же незначительные недостатки, полностью с вами согласен.
А напишите статью про кривые идеи в основе реакта!
Было бы интересно это еще и подкрепить мотивацией авторов для добавления таких кривых идей. Для большей объективности.
С радостью бы почитал такое и улучшил скилл мета-программирования.
React 17: Ничего нового?