Да, спасибо, реактом создаем контейнер и получаем его ref, а содержимое наполняем через unstable_renderSubtreeIntoContainer() + заполняем контейнер отрендереными компонентами чистым javascript.
Спасибо, посмотрю еще раз. Тестовый код - https://jsfiddle.net/86e855mh/ Скорость рендеринга падает пропорционально сложности верстки, кроме того, по Timeline цифры в несколько раз больше, чем console.time(). На чистом js рендеринг в ~5 раз быстрее. Но, судя по всему, это то, как работает реакт...
Да, просто рендер тоже тормозит. Т.е. если просто смонтировать компонент с несколькими сотнями элементов (в сумме пара тысяч нод). И чем их больше, тем больше тормозит. Что, в принципе, нормально и понятно, но не понятно, почему это все начинается на относительно небольших списках.
Уточню проблему - реакт медленно рендерит статический список из нескольких тысяч html элементов - т.е. обычную статику типа some textanother text. Прямая вставка в DOM в десятки раз быстрее.
Дело не в фото, т.к. без них та же ситуация. Сбрасывать список по кнопке назад можно, но это как раз один из тех костылей, за который не любят бесконечные списки.
Все дело в том, что на vanilla js список отрисовывается в разы быстрее, как и должен, поэтому возник вопрос почему реакт это делает так долго, не смотря на то, что никакого сравнения виртуального DOM с реальным в этом случае не нужно.
Спасибо, но все решения такого рода не подойдут - не известна высота блоков, т.к. там может быть разное кол-во текста и разная высота фото. Кроме того, список строится в виде masonry layout, что еще больше усложняет задачу расчета высоты плейсхолдеров.
"просто создавать наследника class MyRoute extends Route" - будет ли это семантически правильнее иметь заранее сконфигурированный класс? Читая код будет сложно понять, что конфигурация хранится непосредственно в "MyRoute". Откуда появляются роуты будет неочевидно.