Pull to refresh
54
0
Корзунов Антон @kashey

javascript, webgl, maps, react, орфография(нет)

Send message
Уровень наркомании не достаточен.
Например redux-restate может взять два стора на вход, и выдать один стор на выход (только для react «части»), а redux-loop может по некому redux action вызвать что-то из context текущего компонента, что может в итоге вызвать dispatch в сторе родительсткого приложения.

Мы сейчас используем и первое и второе чтобы как-то связать вроде бы два независимых приложения с независимыми сторами, вложенные одно в другое.
Давайте обратимся к Wikipedia:
Фре́ймворк (иногда фреймво́рк; англицизм, неологизм от framework — остов, каркас, структура)…
где любая конфигурация программы строится из двух частей:
1. Постоянная часть — каркас, не меняющийся от конфигурации к конфигурации и несущий в себе гнёзда, в которых размещается вторая, переменная часть;
2. Сменные модули (или точки расширения).

При этом React, Vue и другие «компоненты» — это вторая часть, а первая часто не жесткая, точнее зависит от других фреймворков, используемых в приложении.
Итого часть приложения может следовать принципам построения React(компоненты по своим папочкам), часть — Redux(как-то что-то группируем, вариантов много), BEM(чисто наименование), и так далее.
Очень часто главного фреймворка, который бы определял как это все сочетать и нет. В итоге любые два приложения будут разными.
И это главная причина существования фреймворков — работы поле непаханное, есть куда развернуться. Вот они и разворачиваются.

Самое главное тут — «фреймворк» может не содержать свой собственный код, а просто правильным образом настраивать, регламентировать или управлять нижележащими библиотеками.
Фреймворк — как приложение построено, а не как написано.
Вопрос на 5 — что будет если кривую Гильберта заменить на Мортон, и как могут быть полезны Коды Грея?
Свойство Гильбертовой кривой, заключающееся в том, что точки, которые находятся рядом на ней, находятся рядом и в пространстве, и тот факт что CellID у нас — просто число, позволяют нам для поиска пользоваться обычным деревом типа B-дерева. В зависимости от того, что мы ищем (точку или область), мы будем пользоваться или get, или range scan, то есть поиском «от» и «до».

С этим можно ознакомиться немного подробнее в статье про Смерть Кащееву.
Я только вчера смотрел в терминал, где крутился старина gulp. 500 ns на ребилд (очень) простого приложения.
Если бы люди на самом деле заботились бы о «кеше» — они бы загружали React или, прости господи, moment.js, с какого либо CDN, того же unpkg.
Опять же — большая часть «приложения» сидит в node_modules и при ребилде не меняется.
Vendor chunk чтука хорошая, но как зашарить общие для всех продуктов компании зависимости?

Все понимается в сравнении, у меня есть одно старое приложение которым все еще пользуются миллионы, с оно занимает до gzip меньше меньше чем наше новое приложение после. Раза так в 2. И логики там раз в 10 больше. А кода меньше.
Мистика последние годы с фронтендом творятся. Просто мистика.
Будем честны — с какой вероятностью пользователь зайдет на конкретно ваш сайт через неделю, месяц, год?
Для 99% приложений один бандл — оптимален. Для 1% выделение vendor chunk имеет смысл.
Code splitting? Отдельная песня, и webpack 4 пытается ее решить через авторазбиение, и достаточно успешно.
Но code splitting не зависит от бандлера или «не-бандлера» — он либо есть, либо его нет. Текущие ES6 модули это всегда статическая линковка.
>Во-первых, излишний transpile синтаксических конструкций и замены его на эмулирующий код приводит к замедлению и затруднению оптимизаций.

Смешались вместе, бандлеры и бабел…

>Предварительное разрешение и связывание модулей и их последующее bundle-ирование, еще недавно бывшее основным способом поддержки ES6 modules в большинстве браузеров, сейчас оказывает на них негативное влияние и мешает оптимизациям и средствам кэширования

Двойку за подготовку. Команда webpack производила исследования после появления HTTP/2, которое показало что HTTP/2 не решает ничего. Пару месяцев назад я перепроверил их результаты — конечно же ничего не изменилось.

Так как узнать зависимости загружаемого файла можно только после его загрузки — загрузка реального приложения разбивается на «волны» дозагрузок, которых можно быть под два десятка без проблем. Берем «обычный» сервер в Германии с пингом 60мс — получили 1с потраченого времени.

В настоящий момент бандер жизненно необходим для практически любого приложения. Это факт с которым поспорить сложно — слишком легко проверяем. Слишком логичен.
Возможно прямо так сравнивать не совсем корректно, но второй вариант сам добавит «иммутабельность», в виде sCU из connect врапера redux.
Если же добавить memoize-state из моей другой статьи, но «контейнер» будет регировать только на изменение колличества todo или ID, полностью игнорируя данные внутри todo элементов, что уже может быть интересно в некоторых случаях.

Еще один плюс — данный подход позволяет «разорвать» связь стейта, его использования и редьюсера.
Сейчас редьюсер и селектор в неком смысле «симметричны», возможность модифицировать стейт под нужды клиента позволяет это ограничение(это — ограничение) разорвать.
Tree был использован как пример «погружения» и «всплытия». Просто как удобный пример.
Прошла неделя, вышла новая версия — время повторить измерения.
(должно быть лучше)
Спасибо что описали как оно работает. Единственное отличие — функция должна следить за тем что она возвращает, так как если какой-то промежуточные значение, которое вообще можно проигнорировать, оказалось в результате — «ниже» этого ключа ходить не надо.
И насчет грани все правильно написали. Очень тонкая грань. Но! в рамках react/redux на самом деле можно использовать функции пожирнее без особых проблем.

Вообщем надо будет будет подумать о том как НЕ мемоизировать функции, которые мемоизировать не надо. Например как все ваши.

В данном случае требуется только геттеры, для чего дескриптопы просто идеально подходят.
Я общем почти гарантирую что если убрать ...ownProps то для вас ничего не изменится (mergeProps сделает тоже самое), а в прокси прилетит сильно меньше данных.
"...ownProps" заставляет прокси думать что вам нужны все значения в ownProps, что многократно увеличивает накладные расходы и вообще не совсем правда.
Это операций в секунду.
Ок, и таких 80 чтук? А что меняется посредством 1043 ивентов? Я бы ожидал, что они на основе своих props что-то из state таскают, но вроде как нет.
Что будет если ownProps не спредить? (редакс всеравно передаст их в компонент) Поскольку они НЕ используются для доступа в стейт их вообще не надо использовать и в аргументы не просить.
В крайнем случае у connect есть mergeProps опция.
Возможно постоянные изменения убивают возможность что либо мемоизировать, тем самым время затраченное на сахар сильно выпирает, но тут надо смотреть конкретный пример — по тестам 160000 вызовов (1000 экшенов на 84 компонента на двойную обертку) должны занять доли секунды.
Был бы очень признателен увидеть ваш mapStateToProps. Возможно другая моя подделка — redux restate — сможет исправить ситуацию.

Ээээ… красота требует жертв. Но можно узнать что за примерчик 2 секунды рендерится, я думал что обычно в 60 FPS, или 16 мс уложится надо.

Наверное надо было указать на этот момент — если у вас есть state, и вы из этого state запросили state.todos[0].id — то memoize state будет агриться на изменения только в state.todos[0].id. Одновременно с этим — если сам стейт или state.todos или state.todos[0] остались без изменения — более глубокие проверки не будут производится в принципе.
В начале производиться shallow сравнение тех частей которые могут быть «flexible», и если они не изменились — значит можно вернуть закешированный результат.
Если же они изменились — можно пойти глубже проверять. В планах есть немного передумать этот алгоритм и сильно-сильно ускорить.
Пока только есть незарелизенная автомагия beautiful-react-redux, который areStatesEqual настроить чтобы полностью и «быстро» игнорировать изменения которые не нужны, а потом уже «сравнивать» долго и упорно прошедшие.
Ну в рендере точно не надо. Он должен быть тупой по определению. Обычно это делается в componentWillReceiveProps, что не всегда удобно.
И да — react-memoize про который я в этой статье добавил сноску именно «там» и работает.

Information

Rating
Does not participate
Location
Sydney, New South Wales, Австралия
Date of birth
Registered
Activity