Пользователь пока ничего не рассказал о себе

Достижения

Все достижения (12)

Наибольший вклад в теги

Все теги (39)

Лучшие ответы пользователя

Все ответы (31)
  • Стоит ли переходить на 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
    Ответ написан
  • Meteor.js расцветает или чахнет?

    PQR
    @PQR
    Не согласен с предыдущим оратором (@geeek), в частности с утверждением
    В общем если хочешь быть в тренде - бери
    - Meteor совсем не в тренде.

    Если дать краткий и резкий ответ на вопрос "расцветает или чахнет?" - отвечу: интерес к Meteor чахнет, не смотря на все усилия команды разработки.

    Компания MDG (Meteor Development Group) подняла $31M инвестиций (https://www.crunchbase.com/organization/meteor) и хотела всё сделать круто, стать мейнстримом, а потом зарабатывать на хостинге Meteor проектов - такой план монетизации. Хостинг они, кстати, сделали. И в какой-то момент было много хайпа вокруг Meteor, казалось, что всё идёт по плану. Полтора года назад вышел Meteor 1.0 (октябрь 2014), потом была пара хороших релизов, которые убрали всю "сырость": Meteor 1.1 и 1.2.

    Но в середине 2015 стало понятно, что никаким мейнстримом они не стали, мейнстрим нынче React!
    Не смотря на простоту старта и скорость разработки с Meteor, были очевидны следующие минусы:

    1. Собственная система пакетов со своим центральным репозиторием https://atmospherejs.com - посмотрите на счётчики скачивания пакетов, это крохи по сравнению с npm. Посмотрите на активность разработки основных пакетов - всё очень тухленько.

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

    3. Собственный шаблонизатор blaze (похож на handlebars). В начале blaze выглядел хорошо, но теперь все внезапно пишут на React и многие потирают руки в ожидании Angular 2, в итоге blaze оказался ещё один велосипедом, с которым не понятно что делать.

    4. На бекенде всё ещё Node 0.10. Даже с Node 0.12 Meteor уже не работает из-за некоторых бинарных зависимостей! Обещали в будущих версиях обновиться с поддержкой Node 4.

    5. Метеор сильно завязан на MongoDb. Чтобы реактивно доставлять новые/изменившиеся данные от сервера в бразуер они парсят логи Mongo. Были попытки сделать аналогичное для SQL баз, но не увенчались успехом. В итоге встречайте их новый проект Apollo, который поверх GraphQL и не привязан к конкретной реализации бекенда www.apollostack.com А что теперь будет со старым добрым DDP?

    6. Ваше Meteor приложение одной командой можно упаковать в мобильное приложение Cordova - выглядит круто, но сейчас время ReactNative и вот мы читаем обсуждения на форумах, что возможно, они таки интегрируются с ReactNative, но когда?

    Подводя итог: ребята из MDG подняли кучу денег и хотели сделать всё сами: свои пакеты, свою сборку, свой шаблонизатор, свой реактивный протокол (DDP) и чтобы всё работало из коробки. И они сделали это!

    Только это оказалось никому не нужно, т.к. для пакетов все сидят на npm, сборка должна быть гибкой (и поэтому у нас есть gulp и webpack), самый модный шаблонизатор нынче - это React, реактивный протокол GraphQL и базы на сервере люди любят разные, а не только MongoDb. А Meteor, по сути, остался на обочине всей экосистемы и движухи вокруг JavaScript. Поняв это, MDG начали двигаться в сторону JS комьюнити и первый шаг сделан: Meteor 1.3 поддерживает нормальные модули ES2015, npm пакеты, рендринг через React и Angular. Но Meteor 1.3 - это куча костылей поверх старого велосипедного Meteor. Почитайте их планы на будущее в официальном блоге, хотя бы в этом посте: info.meteor.com/blog/announcing-meteor-1.3 - им по сути предстоит переписать всё заново! И первые ласточки такого "переписывания" - это выделение проекта Apollo.

    Возможно, со второй попытки они всё сделают правильно и Meteor 2.0 действительно выстрелит. Если только у них деньги не закончатся раньше.

    Сейчас можно взять Meteor и эффективно зарабатывать на маленьких/средних фриланс проектах, когда нужно сделать быстро и не думать о долгосрочной поддержке.
    Если же вы делаете большой продукт, то вас ждут большие потрясения и изменения в экосистеме Meteor.
    Ответ написан
  • Что делать, если от программирования уже подташнивает?

    PQR
    @PQR
    Понаписали комментов тут много, а толку мало. Хоть бы кто работу предложил! Человек знает паттерны, отвечает на 90% вопросов и готов работать за 80К - я таких не видел, это ж просто клад! Даёшь нормальный Symfony проект и 100К!

    А вообще странно, что за пол года поисков работы при таких знаниях и опыте не нашлось вакансии посолиднее, чем то, что описано. Оп что-то не договаривает.

    Ну и пару слов по делу
    - не читайте советы про фриланс, это другая тема, проблемы самоорганизации, демпинг и проч...
    - не стоит сломя голову менять стек технологий, в зарплатах там всё так же, а вакансий меньше
    - PHP очень динамично развивается последние 5 лет, замыкания в нём появились раньше чем в Java, а генераторы раньше чем в JavaScript движках; на подходе PHP 7, который вообще всех порвёт!
    - и да, на PHP много говнокода, но и нормальных, классных, современных проектов много. Тут как везде: принцип парето 80/20. Но в пересчёте на абсолютное число вакансий классной PHP работы полно!
    - и главное: пишите в резюме ожидания ЗП не по нижней границе "только бы взяли", а по верхней: "Интересует работа ведущего/архитектора от 150К, есть опыт highload (mvideo)" - всё, послезавтра вы уже работаете мидлом в badoo за 120К. Схема проверена.
    Ответ написан
  • Как правильно смонтировать cifs (ubuntu 14.04) с доступом на запись для nginx/php (www-data)?

    PQR
    @PQR Автор вопроса
    Прочитал вот этот мануал linux.die.net/man/8/mount.cifs и добавил в параметры монтирования в /etc/fstab параметр noperm - внезапно доступ на запись появился у обоих пользователей (у моего консольного и веб-сервера www-data).

    Итого, строка подключения в fstab выглядит так: //192.168.20.115/filesfolders$ /mnt/filesfolder cifs user=guest,pass=,iocharset=utf8,noperm,uid=www-data,gid=www-data,dir_mode=0777,file_mode=0777,sec=lanman 0 0

    Однако, это не снимает общих вопросов на понимание: почему у директории я вижу права drwxrwxrwx, а на деле писать в неё может только owner? Почему файлы при сообщениях permission denied файлы всё-таки создаются, но пустые (если нет доступа, то его не должно быть совсем, так ведь?)
    Ответ написан
  • Как в phpStorm 3.0 создать проект удаленный?

    PQR
    @PQR
    Редактировать файлы напрямую на ftp — это PhpStorm не позволяет. Цитирую разрабаточкиво PhpStorm:
    You can't use IDE w/out making a local copy first. There is a principal *technical* restriction. Same goes for all kinds of mapped remote folders. This is strictly unsupported. Please use «File|Create project from remote...» wizard to quickly setup remote project.

    По этому поводу были разные дискуссии, вот две наиболее содержательные на тему «как правильно работать с удалёнными файлами/проектами»
    devnet.jetbrains.net/message/5287181
    devnet.jetbrains.net/thread/287045
    Ответ написан

Лучшие вопросы пользователя

Все вопросы (16)