c
братва, а есть какие интересные репы по архитектуре фронта?
featureslices гляди
Size: a a a
2020 July 06
c
AP
featureslices гляди
от души, братан)
OR
от души, братан)
ну и лексикон...
AP
@sovasergey , а еще такой вопрос, может конечно он больше холиварный. В новом проекте лучше использовать CRA или все-таки с нуля писать webpack-конфиг?
V
по возможности, СРА это тоже норм
c
@sovasergey , а еще такой вопрос, может конечно он больше холиварный. В новом проекте лучше использовать CRA или все-таки с нуля писать webpack-конфиг?
Кра много проблем завозит. Можно же начать с parcel. Он куда лучше поддерживает инструменты сообщества
AP
Кра много проблем завозит. Можно же начать с parcel. Он куда лучше поддерживает инструменты сообщества
а по поводу проблем. Какие к примеру из наиболее частых?
c
а по поводу проблем. Какие к примеру из наиболее частых?
Бабель плагин не поставить
LS
Бабель плагин не поставить
Craco решает большинство проблем же.
c
Craco решает большинство проблем же.
И приносит еще одну
EM
А что вообще от среднестатистического вебпак конфига требуется?:)
c
А что вообще от среднестатистического вебпак конфига требуется?:)
Добавлять неожиданные возможности
EM
Пару лоадеров и билд?:)
Б
Ну сайд-эффектики, идемпотентность и вот это вот все. Но это что касается юзер-кода. А могут быть ситуации, когда конкуренции приходят из IO: резолв эффекта, дом поменялся / задиспатчил чета и т.п. И тут нужно выстраивать стратегии решения конфликтов, которые абсолютно универсальными не бывают… Приходится делать advanced апи / доку что бы учить пользователя как-то на это влиять, в эдж-кейсах, а это оч сложно (особенно по DX).
Тот подход который выбрала команда реакта для реализации файберов не является единственно возможным. Мне кажется у них немного сбились критерии.
На мой взгляд можно было бы сделать все намного проще без полного переписывания движка и без появления различных проблем со стейт-менеджерами и нюансов с консистентностью (когда чуть ли не с каждым стейт-менеджером появляются проблемы касательно работы в конкарент-моде или взять хотя бы обычные ref-ы когда туда записывают значения).
Суть в чем - в реакте решили переписать старый движок который просто делал рекурсивный diff дерева объектов (верстка с компонентами) с рекурсии на цикл чтобы можно было бы в любой момент прервать и отложить чтобы не блочить поток (а вместе с ним и css-анимации со скроллом).
И получается что на части (по времени) они разбивают и рендер самих компонентов тем самым получая проблемы с консистетностью состояния компонентов из-за наличия нескольких версий дерева рендера (из-за переключения на рендер по более приоритетным событиям)
А можно было бы оставить рекурсию и сделать синхронно дифф всего дерева компонентов а вот сами дом-операции собрать в список и уже их разбивать по времени. С одной стороны мы можем получить затык на диффе так как все дерево компонентов будет сравниваться синхронно с другой стороны у нас теперь не будет проблем с консистетностью и если подумать то все тормоза по большому счету исходят не от диффа а от работы с dom-апи.
А если в каких-то бенчах показывают что реакт синхронно тормозит при diff-e то это только потому что сам он тормоз потоу что они написали код без учета оптимизаций (например я в своих экспериментах с кастомным virtual-dom/diff-ом и оптимизациями под мономорфность v8 и инлайнинг js-кода в ассемблер получал производительность diff-а в 20-раз быстрее чем у реакта)
На мой взгляд можно было бы сделать все намного проще без полного переписывания движка и без появления различных проблем со стейт-менеджерами и нюансов с консистентностью (когда чуть ли не с каждым стейт-менеджером появляются проблемы касательно работы в конкарент-моде или взять хотя бы обычные ref-ы когда туда записывают значения).
Суть в чем - в реакте решили переписать старый движок который просто делал рекурсивный diff дерева объектов (верстка с компонентами) с рекурсии на цикл чтобы можно было бы в любой момент прервать и отложить чтобы не блочить поток (а вместе с ним и css-анимации со скроллом).
И получается что на части (по времени) они разбивают и рендер самих компонентов тем самым получая проблемы с консистетностью состояния компонентов из-за наличия нескольких версий дерева рендера (из-за переключения на рендер по более приоритетным событиям)
А можно было бы оставить рекурсию и сделать синхронно дифф всего дерева компонентов а вот сами дом-операции собрать в список и уже их разбивать по времени. С одной стороны мы можем получить затык на диффе так как все дерево компонентов будет сравниваться синхронно с другой стороны у нас теперь не будет проблем с консистетностью и если подумать то все тормоза по большому счету исходят не от диффа а от работы с dom-апи.
А если в каких-то бенчах показывают что реакт синхронно тормозит при diff-e то это только потому что сам он тормоз потоу что они написали код без учета оптимизаций (например я в своих экспериментах с кастомным virtual-dom/diff-ом и оптимизациями под мономорфность v8 и инлайнинг js-кода в ассемблер получал производительность diff-а в 20-раз быстрее чем у реакта)
c
Пару лоадеров и билд?:)
Плагины.
Алиасы
Лоадеры
Резолверы
Точки входа
Алиасы
Лоадеры
Резолверы
Точки входа
c
Плагины.
Алиасы
Лоадеры
Резолверы
Точки входа
Алиасы
Лоадеры
Резолверы
Точки входа
Зависимость от ENV