Задать вопрос
  • Стоит ли переходить на React.PureComponent по-умолчанию?

    PQR
    @PQR
    React.PureComponent реализует метод shouldComponentUpdate таким образом, что он делает поверхностное сравнение props и state (не глубокое). Вот собственно код:
    https://github.com/facebook/react/blob/c8fbdac2271...
    shouldUpdate =
                !shallowEqual(prevProps, nextProps) ||
                !shallowEqual(inst.state, nextState);


    Что такое shallowEqual? Это по сути сравнение оператором === каждого элемента из prevProps с каждым элементом из nextProps. На всякий случай дам ссылку на реализацию для полного понимания: https://github.com/facebook/react/blob/6963ea4bfcd...

    В итоге всё зависит от структуры ваших props. Если в props вы передаёте объекты которые иногда мутируются, т.е. по ссылке они равны ===, но внутри какие-то данные поменялись (что само по себе выглядит странно в экосистеме redux + reselect, но вполне возможно технически), тогда использование PureComponent вам всё поломает, т.к. на экране какие-то компоненты перестанут перересовываться!

    Если же у вас всё по уму, данные которые передаются через props являются скалярными типами (string, int, float, bool) или immutable объектами, тогда смело используйте PureComponent - в некоторых случаях он поможет избавиться от лишних вызовов render.

    Важное замечание: PureComponent нужно использовать только для так называемых presentational components, т.е. для тех компонент, которые НЕ обёрнуты в вызов redux connect().

    Для container components (т.е. тех компонент, которые обёрнуты в redux connect()) нет смысла наследоваться от PureComponent, т.к. метод connect() оборачивает ваш компонент своей реализацией shouldComponentUpdate, которая также использует shallowEqual. Если вы по недосмотру унаследуете container component от PureComponent - ошибок не будет, но это не имеет никакого смыла, т.к. ваш код по сути будет дважды делать shallowEqual, а зачем делать лишнюю работу?

    Подводя итог, рецепт такой:
    - presentational components наследуем от React.PureComponent
    - container components (которые обёрнуты в redux connect()) наследуем от старого доброго React.Component
    Ответ написан
    1 комментарий
  • Что делает этот код?

    t3h_l3w1z
    @t3h_l3w1z
    Обкашливаю вопросики.
    Возможно, нечто вроде preventDefault, возвращает для клика false => браузер никуда не переходит.
    Ответ написан
    1 комментарий
  • Front-end разработка, правильная сборка?

    search
    @search
    мама говорит что я особенный
    Если компания дорожит качеством продукта и безопасностью данных своих клиентов, то сборка и выкат новой версии проводится автоматически Continuous Intrgration сервером. У программистов вобще нет доступа к проду. Доступ к проду есть только у CI-сервера. У программиста есть доступ только к GIT репозиторию проекта. Вся работа проводится в своём окружении и в отдельной ветке. Затем ветка тестируется на тестовом окружении (близком к продакшену), если надо правится, и затем вливается в главную ветку проекта. После этого CI подхватывает изменения, билдит фронт и бэк и выкатывает это дело на прод. Это очень общий вариант. Там есть куча нью-ансов.

    Лично я предпочитаю идти по вышеописанному пути с первого дня работы даже когда работаю один. Потому что в этом случае ты всегда можешь откатиться на последний стабильный релиз, уйти дамой и доделать всё на следующий день. Вместо того чтоб с выпученными глазами и трясущимися губами всю ночь что-то там фиксить (что есть признаком очень низкокачественного проекта).

    UPD
    Забыл сказать, что этот путь не даётся легко. Нужно потренироваться где-то полгодика. Но зато на всю жизнь получаешь спокойные ночи и здоровый цвет лица, так что оно того стоит.
    Ответ написан
    2 комментария
  • В чём смысл натягивать лендинги на cms?

    maxxannik
    @maxxannik
    Сайты на WordPress + Интернет магазины WooCommerce
    Первая причина в том что LP как одна страница - это понятие изуродованное в РФ.
    LP далеко не всегда есть одна страница. Мы делали сайт из 100 LP, структурированные в дерево.

    Вторая причина в том что по большей части оптимально начинать с одностраничника (это сайт из одной LP), но кто сказал что на этом стоп? Если бизнес адекватный, то через неделю захочется продолжения банкета. Делать блог, каталог продуктов, или другие LP. Из одностраничника превращаться в каталог смежных продуктов, с кросспродажами и прочим блекджеком.

    Третья причина в том что сделать LP на WP можно без излишних затрат. Как уже сказали выше это может быть VC или PageBuilder. Страница собирается за 15-30 минут. Без кривой верстки, кроссбраузерная, адаптивная. По конверсии такие страницы не уступают ручным сборкам (от 2 до 20% легко выжимается), а по затратам в 10 раз меньше.

    Четвертая причина. Это решение на много гибче. Проще делать сплит тесты. Поправить блоки местами можно парой кликов или движением мышки. Править может маркетолог без знаний верстки или кодинга.
    Ответ написан
    1 комментарий