Корзунов Антон
@kashey
javascript, webgl, maps, react, орфография(нет)
Information
- Rating
- Does not participate
- Location
- Sydney, New South Wales, Австралия
- Date of birth
- Registered
- Activity
javascript, webgl, maps, react, орфография(нет)
Information
Например redux-restate может взять два стора на вход, и выдать один стор на выход (только для react «части»), а redux-loop может по некому redux action вызвать что-то из context текущего компонента, что может в итоге вызвать dispatch в сторе родительсткого приложения.
Мы сейчас используем и первое и второе чтобы как-то связать вроде бы два независимых приложения с независимыми сторами, вложенные одно в другое.
При этом React, Vue и другие «компоненты» — это вторая часть, а первая часто не жесткая, точнее зависит от других фреймворков, используемых в приложении.
Итого часть приложения может следовать принципам построения React(компоненты по своим папочкам), часть — Redux(как-то что-то группируем, вариантов много), BEM(чисто наименование), и так далее.
Очень часто главного фреймворка, который бы определял как это все сочетать и нет. В итоге любые два приложения будут разными.
И это главная причина существования фреймворков — работы поле непаханное, есть куда развернуться. Вот они и разворачиваются.
Самое главное тут — «фреймворк» может не содержать свой собственный код, а просто правильным образом настраивать, регламентировать или управлять нижележащими библиотеками.
Фреймворк — как приложение построено, а не как написано.
С этим можно ознакомиться немного подробнее в статье про Смерть Кащееву.
Опять же — большая часть «приложения» сидит в node_modules и при ребилде не меняется.
Vendor chunk чтука хорошая, но как зашарить общие для всех продуктов компании зависимости?
Все понимается в сравнении, у меня есть одно старое приложение которым все еще пользуются миллионы, с оно занимает до gzip меньше меньше чем наше новое приложение после. Раза так в 2. И логики там раз в 10 больше. А кода меньше.
Мистика последние годы с фронтендом творятся. Просто мистика.
Для 99% приложений один бандл — оптимален. Для 1% выделение vendor chunk имеет смысл.
Code splitting? Отдельная песня, и webpack 4 пытается ее решить через авторазбиение, и достаточно успешно.
Но code splitting не зависит от бандлера или «не-бандлера» — он либо есть, либо его нет. Текущие ES6 модули это всегда статическая линковка.
Смешались вместе, бандлеры и бабел…
>Предварительное разрешение и связывание модулей и их последующее bundle-ирование, еще недавно бывшее основным способом поддержки ES6 modules в большинстве браузеров, сейчас оказывает на них негативное влияние и мешает оптимизациям и средствам кэширования
Двойку за подготовку. Команда webpack производила исследования после появления HTTP/2, которое показало что HTTP/2 не решает ничего. Пару месяцев назад я перепроверил их результаты — конечно же ничего не изменилось.
Так как узнать зависимости загружаемого файла можно только после его загрузки — загрузка реального приложения разбивается на «волны» дозагрузок, которых можно быть под два десятка без проблем. Берем «обычный» сервер в Германии с пингом 60мс — получили 1с потраченого времени.
В настоящий момент бандер жизненно необходим для практически любого приложения. Это факт с которым поспорить сложно — слишком легко проверяем. Слишком логичен.
Если же добавить memoize-state из моей другой статьи, но «контейнер» будет регировать только на изменение колличества todo или ID, полностью игнорируя данные внутри todo элементов, что уже может быть интересно в некоторых случаях.
Еще один плюс — данный подход позволяет «разорвать» связь стейта, его использования и редьюсера.
Сейчас редьюсер и селектор в неком смысле «симметричны», возможность модифицировать стейт под нужды клиента позволяет это ограничение(это — ограничение) разорвать.
(должно быть лучше)
И насчет грани все правильно написали. Очень тонкая грань. Но! в рамках react/redux на самом деле можно использовать функции пожирнее без особых проблем.
Вообщем надо будет будет подумать о том как НЕ мемоизировать функции, которые мемоизировать не надо. Например как все ваши.
"...ownProps" заставляет прокси думать что вам нужны все значения в ownProps, что многократно увеличивает накладные расходы и вообще не совсем правда.
Что будет если ownProps не спредить? (редакс всеравно передаст их в компонент) Поскольку они НЕ используются для доступа в стейт их вообще не надо использовать и в аргументы не просить.
В крайнем случае у connect есть mergeProps опция.
Был бы очень признателен увидеть ваш mapStateToProps. Возможно другая моя подделка — redux restate — сможет исправить ситуацию.
Ээээ… красота требует жертв. Но можно узнать что за примерчик 2 секунды рендерится, я думал что обычно в 60 FPS, или 16 мс уложится надо.
В начале производиться shallow сравнение тех частей которые могут быть «flexible», и если они не изменились — значит можно вернуть закешированный результат.
Если же они изменились — можно пойти глубже проверять. В планах есть немного передумать этот алгоритм и сильно-сильно ускорить.
Пока только есть незарелизенная автомагия beautiful-react-redux, который areStatesEqual настроить чтобы полностью и «быстро» игнорировать изменения которые не нужны, а потом уже «сравнивать» долго и упорно прошедшие.
И да — react-memoize про который я в этой статье добавил сноску именно «там» и работает.