Корзунов Антон
@kashey
javascript, webgl, maps, react, орфография(нет)
Информация
- В рейтинге
- Не участвует
- Откуда
- Sydney, New South Wales, Австралия
- Дата рождения
- Зарегистрирован
- Активность
javascript, webgl, maps, react, орфография(нет)
Ваш аккаунт
Вот именно этот момент мемоизация и обеспечивает. Именно этот момент является источником проблем. Совсем чуть чуть повычисляли значения — map/filter или просто getInitialProps() какой либо вызвали — и до свидания.
Всегда есть куча событий, которые изменяют стор, и дергают mapStateToProps, но совершенно не относятся к ВСЕМУ приложению — что-то одно маленькое должно обновиться, а все остальное — нет.
Основная задача mapStateToProps — быть pure и idempotent. А если вы с этим не согласны — лучше вообще redux не использовать.
— полифил примерно для всего — github.com/tvcutsem/harmony-reflect
— полифил только для прокси — github.com/GoogleChrome/proxy-polyfill
Оба достаточно просты — используют дескрипторы для перехвата доступа к полям обьектов, что в принципе не медленно, но сильно медленнее чем прямой доступ к обьектам.
К сожалению скрипт который измеряет скорость работает не в браузере, и показать чиселки для сравнения я сейчас не могу. Но то что работает — 100%
В итоге и получается, что и коробки Vue, да и Angular, могут работать сильно быстрее. Ну просто потому что програмисты такие програмисты. Глаз за глаз за ними нужен. Ну или костыль. И memoize-state – фабрика костылей. Подопрет где нужно и все окей.
2. И да и нет. Для того чтобы возможная «другая» мемоизация работала требуется предоставлять «одинаковые» обьекты завернутые в «однаковые» прокси. В общем там внутри все созданные прокси храняться в WeakMap, и без надобности не создаются.
Почему нет — потому что сам state между вызовами будет разный, и для него прокси будет создаваться каждый раз.
Как говорилось выше — без проблем пару миллионов в секунду.
Если у вас есть два инстанса компонента, то в начале первый что-то возьмет из state на основе своих props, а потом второй, а потом опять первый. И всегда кеш будет чистый, так как то что там храниться — «не подходит».
Полуофициальное решение проблемы — re-reselect, который позволяет указать как «разделять» компоненты.
Второе полуофициальное решение — завернуть createSelector в замыкание, так чтобы проблемы с кешом не будет. Но тогда они не смогут «шарить» кеш между инстансами.
beautiful-react-redux оборачивает mapStateTopProps в memoize-state «снаружи», и еще раз «внутри». Те для каждого отдельного элемента, и для всех целиком, на случай если разницы между ними нет.
В общем универсальное решение.
Есть и другая проблема — заливки (defs) не поддерживаются от слова вообще.
Вот хороший пример — codesandbox.io/s/k26937poxr, достаточно просто потыкать мышкой в html код, чтобы увидеть глубину падения.
Вот есть у вас форма — пользователь ввел в нее данные и (!)обновил страницу.
— пользователь видит форму какой она была — пользователь очень рад.
— пользователь видит форму такой какой она _должна_ быть (со старыми данными) — пользователь не рад.
И оба этих варианта имеют право на жизнь. А то тот же самый пользователь не сохранит данные, потому что и так же все нормально.
А где есть два варианта — там есть и три.
V3 работал только для компонентов, доступных как переменные. V4 работает на уровне отрендереного React-дерева, в котором НЕ компонент не бывает. А вот то, что hot требует на вход компоненту — как раз логично. Это же базовый строительный блок. И обернуть достаточно «Application»(точку входа). Которая компонента по умолчанию.
— работает не всегда (изменения cW/DM)
К сожалению сложно опять что компонент немного по другому должен старотовать, так как изменение может находиться вне пределов функции. RHL ругнется в консоль, если заметит что-то странное, но обновлять ничего не будет.
— а порой и не работает (для HOC молча падает)
Кто?
— Ради экономии одного нажатия F5?
F5 вы можете сами нажать, а вот для того чтобы привести все приложение в старый стейт — потребуется 5-20 секунд.
— чтобы F5 восстанавливал его в том же состоянии
В общем случае это или не возможно (половине UI сложно прокинуть стейт из redux/mobx), или не нужно (половина элементов UI работают через свои стейты).
Как уже говорилась — версия 4 работает практически для любого приложения. Единственный способ «сломать» — добавить новую ноду перед старыми — следуя дефолтному поведению React все перемаунтит. Решили не бороться со своей стороны.
Некоторые люди считают, что RHL — «вреден». Имхо он позволяет использовать реальный IDE заместо браузерной консоли, чтобы поправить стили или поведение элементов, тем самым позволяя быстрее создать более приятный пользователю look-n-feel.
Тесты — очень вредное явление. Главное потыкать мышкой и убедиться что приложение для пользователя удобно и приятно. То что согластно тестам оно работает правильно — для пользователя не значит ровным счетом ничего.
А насчет оборачивая «их кодом» — имхо — это супер минор.
По другому идею не продать.
Вообще вещать побольше connectов исключительно для контроля над распространением изменений — интересная практика.
Connect — начало любого изменения, потому что дергается непосредственно стором как бы глубоко он не сидел
Connect — конец любого изменения, потому что SCU не пропустит никакие нежданные изменения прилетевшие сверху.
Подробнее можно вот тут почитать -> medium.com/@alexandereardon/performance-optimisations-for-react-applications-round-2-2042e5c9af97
Далее — по тексту.