• Самые распространенные ошибки в вашем React коде, которые вы (возможно) делаете
    0
    Все известные мне полифилы построены на этом принципе — использование переданного обьекта для хранение значения.
    Есть вырожденный случай для IE(IE8) конкретно для DOM обьектов, где для них _есть_ WeakMap (а для не-DOM его нет).
  • Самые распространенные ошибки в вашем React коде, которые вы (возможно) делаете
    0
    WeakMap полифилиться без проблем и есть в core-js, хотя уже в IE11 он нативный.
    Насчет immutable — все верно. Если ключа нет, и ключем является обьект — его изменение изменит ключ. На безрыбье и рак — рыба.
  • Самые распространенные ошибки в вашем React коде, которые вы (возможно) делаете
    0
    На самом деле все не так страшно — если уж что-то начало апдейт дерева, и добавляет всюду новые onClick — ну возможно можно использовать более «интересные» решения чтобы распространение этого апдейта прекратить.
  • Самые распространенные ошибки в вашем React коде, которые вы (возможно) делаете
    +3
    > react/forbid-component-props
    Передача классов между в компоненты, в случае следовании БЕМ-нотации, обязательна и полезно.
    Класс компонента определяет его как Блок, класс передаваемый ему из-вне — как Элемент.
    Их свойства не пересекаются, и никогда не конфликтуют.

    > react/no-array-index-key
    Очень часто у «данных» нет ID. Тут поможет библиотека типа react-uid, которая превратить в key сами данные.
  • Компоненты высшего порядка с использованием Recompose
    +1
    Как ответили выше — render prop. Точнее «renderless containers», которые предоставляют свои функции и могут быть использованы «одинаково».
    Нет разницы что это Context.Consumer, React-Powerplug, VisibilitySensor или Timer — render prop унифицирует интерфейс, и задача только сделать его удобным.

    Я для «удобства» использую react-gearbox.
  • Компоненты высшего порядка с использованием Recompose
    0
    recompose — удивительная вещь
    recompact — ничем не хуже
    Но меня не оставляет чувство, но их время уже немного прошло.
  • Фронтенд как у сына маминой подруги
    0
    Я работаю серьезным React програмистом в серьезной компании, а моя жена штампует лендинги на чем прийдется, в том числе и на реакте.
    Так вот — настоящий фронтенд именно у нее. И жизнь веселее. И задачи более интересные, более «емкие», охватывающие просто все сферы.
  • Фронтенд как у сына маминой подруги
    +1
    А где-то слышал, что после пары лет в Яндексе на одних опционах выходит 200+ в месяц.
    Главное эти опционы получить.
  • Фронтенд как у сына маминой подруги
    0
    А можно сильно поподробнее про logic review?
    PS: и про фиговину для Jira (и почему не для StarTrack?)
  • Совершенствуем Redux
    0
    Проблема про сервер сайд — _Одновременно_ генерятся страницы для _разных_ клиентов.
  • Совершенствуем Redux
    0
    Тот «стор» с которым работать можно, лежит в контексте и для каждого инстанса свой. Только протяни руки в контекст и возьми.
    Еще есть 100500 различных redux обвязок, которые берут этот «стор», что-то с ним делают, и кладут обратно. Простейщий пример — habr.com/post/346116, и таких десятки, на все-все случаи в жизни.
  • Совершенствуем Redux
    0
    Потому что две разные страницы будут шарить один глобальных «store», в то время как должны быть полностью изолированы друг от друга.
    «Обычный» redux поддерживает это из коробки. Rematch, react-copy-write и другие — этот принцип ломают.
  • Совершенствуем Redux
    0
    В случае с реактом есть 3 варианта рендеринга на сервер сайде:
    — старый добрый MVC, где все будет готово до «реакта», он сам будет renderToString
    — микс, где мы используем Реакт чтобы инициализировать данные, а потом renderToString
    — «новый», с renderToStream и «suspence» под капотом.
    Асинхронность на сервер-сайде, и использованием lifecycle Реакта — нычне стало легко и удобно. Но любой глобал это дело пресекает на корню.
  • Совершенствуем Redux
    0
    На сервере может выполнять множество рендеров одновременно. Кто-то все еще считает, что Js это только фронтенд, 1 процесс и ровно 1 задача на исполнение — и из-за этого этот самый Js все еще именно такой.
  • Совершенствуем Redux
    +2
    Кстати — одно из самых главный ограничений «всех этих библиотек»(убийц редакса) — они делает вещи простыми, делают «стор» доступным из любого места, и все такое.
    Круто и удобно для клиентсайда.
    Круто и удобно для старого доброго синхронного серверсайда.
    Вообще никак не работает с новым кленовым асинхронным SSR. Потому что стор не паралелиться.
    Выход тут только один, и многие по нему идут – один рендер == 1 процесс.

    Прощай nodejs, привет Apache prefork!
  • React HoC в TypeScript. Типизация без боли
    0
    Особая боль возникает когда от использования «старых» вариантов TS, когда заместо простого `connect` пишут `connect<StateProps, ComponentMappedProps, PublicComponentProps>`, при том что часть PublicComponentProps могут быть перекрыты ComponentMappedProps.

    «Такой» TypeScript сеет панику и ошибки в в рядах падаванов.

    Так и тут —
    withOnChangeString<InputProps>(SimpleInput)
    — «без проблем» может узнать тип события из переданного компонента.
    Да, всегда можно сказать — это чтобы перепроверить входящие значения, но имхо, лучше доверится типам.
  • GDPR на носу – прекращаем панику и начинаем спасаться
    0
    Так можно IP в логах хранить или нельзя?
  • GDPR как оружие массового поражения
    0
    Я понял, что мы все умрем. Но что делать *
    * — в конце или точка, так как «ну что поделать то», или восклицательный знак (гори оно все огнем), или вопросительный знак (И что делать?). Никак не могу решить.
  • Побег из ада async/await
    0
    это try/catch hell с бесконечными unhandled promise rejection, который может возникнуть, например, если разработчики не договорились на каком уровне эти ошибки обрабатывать.


    Вы хотели сказать — используют любую классическую библиотеку на основе промисов?
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    Ну вот потому и не переношу :)
    А про stateless — MemoizedFlow сам то stateful, но никак не регламентирует чем должны быть «вы».
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    Основых идей две:
    — все думаю перенести все дела из getDeviredStateFromState в componentDidUpdate, потому что второй представляет и данных побольше, и сайдэффекты «разрешает».
    — зачем писать свой getDeviredStateFromProps если он вам не нужен, и вообще у вас Stateless компонент?

    Но на самом деле — почему бы и не использовать прямо в render. Проблем нет.
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    Это тут все понятно. А если вы приходите на готовый проект (или уходите с такого) — было бы хорошо иметь совсем-совсем понятную логику.
    В принципе все так называемые «code smells» и антипатерны примерно об этом — оно вообще работает, но рано или поздно все сломается. Когда новый джун выйдет, например.
    У меня за джуна выступает жена, для которой до сих пор составляет проблему написать js, c правильным reselect она 100% не справится, в то время как такая вот развесистая конструкция у нее проблем не вызывает.
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    Нить нигде не потеряна, и поворот не пройден. Только кода получилось примерно в 6 раз больше чем в первом примере на мемоизацию.
      getSortedData = (lodash)memoize(magic)
      getPagedData = memoize(anotherMagic)
    
      render() {
        const sorted = this.getSortedData(this.props.data, this.props.sort);
        const pages = this.getPagedData(sorted, this.props.page);
      }
    

    Вся проблема в том как это написать так чтобы было просто, удобно и всем понятно. В случае с reselect или обычной мемозаиций — каждый шаг понятен, но не понятно как они сочетаются.
    Тут — сильно понятнее и короче. И декларативнее.
    memoizedFlow([
        ({data, sort}) => ({ data: magic(data, sort)}),
        ({data, page}) => ({ data: anotherMagic(sorted, page)});
    ])
    

    WeakMapов тут нет, это какой-то ботаник начал их городить непонятно зачем и почему. И proxy тут нет, так как работать должно под IE11/React Native. (на самом деле есть и то и другое, но не всегда)

    А скорость? memoize-state просто знает какие ключи были использованы для формирования результата и проверяет их. При этом достаточно умно, понимая вложеность обьектов и как вообще «современная иммутабельность» работает. Я к тому, что при холостой работе там будет те же самые два ===, под одному на каждую функцию. В общем perf тесты часть репозитория, согластно измерениям там сотни тысяч, а то и миллионы мемоизированных операций в секунду. Чуть чуть медленее reselect или memoize-one.
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    state.visible — это копипаст конкретной боли конкретного человека из конкретного issue. Разговор переходит на задачу с таблицей парой абзацев ниже.
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    +1
    Мне казалось, что вопрос о том что React не является view layer давно закрыт. Как и вопрос об уместности постоянного использования redux.
    Он вроде как должен помогать решать сложные задачи работы со стейтом, но тут нет стейта — только результат который надо показать на основе текущего стейта.
    Всегда и везде это было в mapStateToProps, на стороне view(в react-redux), но никак не в redux-core.
    Reselect composition в mapStateToProps сделает тоже самое, что и Reselect composition описанная в этой статье, только в возможно более «правильном» месте и будет болеть теми же самыми проблемами. Заменить reselect на memoize-state(он для того и был придуман) — и дело в шляпе.
  • Совершенствуем Redux
    +1
    Счастливые вы люди.
  • getDerivedStateFromState – или как сделать из простой проблемы сложную
    0
    Это, как не странно, может быть сложная задача. Проблема в именно в «Flow».
    Чтобы правильно (и оптимально, что важно) все посчитать redux должен по некому события сделать «что должен», после чего как-то тригернуть следуйщий этап. В редьсерах такого не сделать.
    Быть может сага? В принципе она может ожидать прихода событий и вызывать функции обработчики, а они уже будут вызывать известные им этапы и будет все работать просто и удобно. (надо будет написать хелпер для такого, спасибо за идею)
    А что делать если послали два события? Тогда все посчитается два раза, чтобы этого избежать, то прийдется «для расчета следуйщего этапа» тоже кидать событые, и надется что takeLatest сделает все правильно.

    В общем я постарался решить задачу без redux, потому что не redux-ом единым. В нем хорошо хранить данные, но переключение направления сортировки или страницы — личное дело компонента отображения.
  • Совершенствуем Redux
    0
    Уровень наркомании не достаточен.
    Например redux-restate может взять два стора на вход, и выдать один стор на выход (только для react «части»), а redux-loop может по некому redux action вызвать что-то из context текущего компонента, что может в итоге вызвать dispatch в сторе родительсткого приложения.

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

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

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

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

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

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

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

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

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

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

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

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

  • Как я написал самую быструю функцию мемоизации
    0
    В данном случае требуется только геттеры, для чего дескриптопы просто идеально подходят.