Тот подход который выбрала команда реакта для реализации файберов не является единственно возможным. Мне кажется у них немного сбились критерии.
На мой взгляд можно было бы сделать все намного проще без полного переписывания движка и без появления различных проблем со стейт-менеджерами и нюансов с консистентностью (когда чуть ли не с каждым стейт-менеджером появляются проблемы касательно работы в конкарент-моде или взять хотя бы обычные ref-ы когда туда записывают значения).
Суть в чем - в реакте решили переписать старый движок который просто делал рекурсивный diff дерева объектов (верстка с компонентами) с рекурсии на цикл чтобы можно было бы в любой момент прервать и отложить чтобы не блочить поток (а вместе с ним и css-анимации со скроллом).
И получается что на части (по времени) они разбивают и рендер самих компонентов тем самым получая проблемы с консистетностью состояния компонентов из-за наличия нескольких версий дерева рендера (из-за переключения на рендер по более приоритетным событиям)
А можно было бы оставить рекурсию и сделать синхронно дифф всего дерева компонентов а вот сами дом-операции собрать в список и уже их разбивать по времени. С одной стороны мы можем получить затык на диффе так как все дерево компонентов будет сравниваться синхронно с другой стороны у нас теперь не будет проблем с консистетностью и если подумать то все тормоза по большому счету исходят не от диффа а от работы с dom-апи.
А если в каких-то бенчах показывают что реакт синхронно тормозит при diff-e то это только потому что сам он тормоз потоу что они написали код без учета оптимизаций (например я в своих экспериментах с кастомным virtual-dom/diff-ом и оптимизациями под мономорфность v8 и инлайнинг js-кода в ассемблер получал производительность diff-а в 20-раз быстрее чем у реакта)
Цель команды реакта в первую очередь написать то, что нужно фейсбуку, так же было с graphql, например
Потому говорить, что они ошиблись и пошли не туда не очень правильно, на мой взгляд
