Лучше бы реализовали Promise.prototype.cancel() который реализован в том же Bluebird. Очень полезен в случаях когда установка стейта react-компонента уже неактуальна потому как компонент успел размонтироваться пока промис исполнялся.
Redux ужасно себя проявляет в понастоящему крупных проектах. Помимо раздутой кодовой базы, вы начинаете сталкиваться с проблемами когда огромная стора еле ворочается на каждый чих. А если у вас структура данных представляет из себя ссылочный граф, а не дерево, то с Redux вы приехали.
Для нас выходом из этого кошмара стал MobX + наша библиотека управления крупными графами моделей: github.com/wearevolt/mobx-model, которая одинаково хорошо подходит как для маленьких, так и очень крупных проектов.
Так в этом суть Реакта: пишите компоненты и инкапсулируйте в них поведение. Вместо этого автор статьи под видом того «как надо» предлагает уродливые костыли. Зачем для каждого из элементов списка создавать свою функцию обработчик и потом заморачиваться с её кешированием, когда можно обойтись одним методом и не сломать при этом сам React?
Зачем нужны эти костыли с кешированием функций если проблема описанная во втором примере элементарно решается созданием обработчика события onClick внутри дочернего компонента (в примере это <Button />) и передачи ему отдельным параметром элемента списка?
При клике, сам компонент <Button item={listItem} onClick={this.handleClick} \/> зная переданный ему в параметрах элемент списка, спокойно возвращает связанные с ним данные в хендлер родительского компонента handleClick().
Полифил метода Function.prototype.bind() не возвращает замыкание. Он возвращает функцию, которая исполняется в контексте для которого применяется замыкание.
Суть реализации полифила метода bind() — замыкание контекста исполнения передаваемой ему функции.
Потому что у большинства молодых разработчиков redux головного мозга. Мы когда искали фронтенд-джунов. Разбирали буквально несколько десятков тестовых заданий. На 25 заданий, только один использовал «не Redux». Когда спрашивал «почему?», говорят «посмотрите на вакансии на рынке — везде Redux». При этом у нас стоит условие «dataflow» на ваше усмотрение.
Мы занимаемся разработкой и поддержкой крупных проектов. В своё время в ужасе убежали с Redux на MobX + наша библиотека github.com/wearevolt/mobx-model которая позволяет держать в памяти модели-сторы с перекрёстными связями. Это позволяет легко загружать и обрабатывать сложные графы десятков видов моделей, и при этом не сходить с ума.
Вы видимо не поняли концепцию. Модуль dotenv подключает переменные окружения из файла .env в стандартный process.env.
Т.е. пока вы запускаетесь локально, вы имитируете в удобной форме передачу параметров процессу в виде человеко читаемого текстового файла. А потом, при запуске в продакшн окружении внутри doker-контейнера например или в качестве heroku-application вы уже не будете указывать .env файл и ваш код без изменений получит эти же переменные от среды исполнения по стандартному механизму передачи переменных окружения (doker, heroku или как в примере у автора azure).
А цепляя config.json с помощью require вы по сути хардкодите у себя параметры в модуле, полностью игнорируя стандартные механизмы передачи конфигурационных данных через переменные окружения.
Описанный в статье способ, удобен при работе с сервисами деплой кода на которые осуществляется из систем контроля версий. В вашем случае, вы будете вынуждены задеплоить свой условный config.json с приватными данными (токены, авторизация в базах данных, etc) в репозиторий. Иначе у вас не получится передать ваш файл с конфигурацией сервису исполнения. Переменные окружения полностью решают эту проблему.
Mac OS не бесплатная. Вы покупаете её вместе с устройством. Т.е. её цена заложена в стоимость компьютера от Apple. Какой бы шильдик «Free» вам сверху не вешали. И сколько бы потом вас бесплатно не обновляли.
Некорректно сравнивать OS/платформу (MacOS) и приложение (Parallels Desktop) эти продукты имеют разную бизнес модель. Если бы MacOS была бы единственным продуктом Apple — она не была бы бесплатной, но это платформа, у неё иные задачи в маркетинговом плане.
Также некорректно рассуждать по малозаметные изменения. Для таких больших и сложных продуктов всегда есть потребность в технической поддержке, в том числе и кодовой базы. Это сильно не бесплатно для компании выпустишей продукт.
Если вас опять же не впечатляют малые изменения, оставайтесь на предыдущей версии продукта.
У нас практика показала, что если prettier что то форматирует странно, это значит изначально код написан сильно криво. Я своих ребят ещё какое-то время отучал от фраз типа «это претир так сформатировал». Писать надо так чтобы форматировалось нормально. Выносить вычисления в константы, не совмещать вычисления с возвратами, особенно тринарники. И всё сразу нормально форматироваться начинает.
Полтора года работаю в компании полного цикла. Полный цикл это значит что у нас есть все: бизнес-аналитик, продактовнеры, дизайнеры, фронтенд и бекенд команды со своими тимлидами и тестировщики. 100% сотрудников работают удалённо и находятся не просто по разным городам, а странам.
Всё работает как часы. Работа построена таким образом, что митинги сведены к минимуму. В основном это узкие встречи. Например планирование работ на следующую итерацию PM-а с тимлидами. Необходимость в митингах даже в рамках продуктовых команд, при правильном прожект менеджменте минимальна. Раз в месяц есть большая встреча всех сотрудников компании на 2 часа, для неформального общения в корпоративном хенгауте (и это поверьте, даже слишком).
Все перечисленные в статье сомнения определяются неспособностью организовать рабочий процесс и подобрать правильных людей в команду, а также незнанием продуктов и сервисов обеспечивающих качественное планирование, управление и контроль за качеством работ, организацией и автоматизацией проверки кодстайла, CI-тестирования, выработкой человеко-часов. Гораздо проще писать вот такие, извините глупости.
Для нас выходом из этого кошмара стал MobX + наша библиотека управления крупными графами моделей: github.com/wearevolt/mobx-model, которая одинаково хорошо подходит как для маленьких, так и очень крупных проектов.
MobX
При клике, сам компонент
<Button item={listItem} onClick={this.handleClick} \/>зная переданный ему в параметрах элемент списка, спокойно возвращает связанные с ним данные в хендлер родительского компонента handleClick().Суть реализации полифила метода bind() — замыкание контекста исполнения передаваемой ему функции.
Мы занимаемся разработкой и поддержкой крупных проектов. В своё время в ужасе убежали с Redux на MobX + наша библиотека github.com/wearevolt/mobx-model которая позволяет держать в памяти модели-сторы с перекрёстными связями. Это позволяет легко загружать и обрабатывать сложные графы десятков видов моделей, и при этом не сходить с ума.
Т.е. пока вы запускаетесь локально, вы имитируете в удобной форме передачу параметров процессу в виде человеко читаемого текстового файла. А потом, при запуске в продакшн окружении внутри doker-контейнера например или в качестве heroku-application вы уже не будете указывать .env файл и ваш код без изменений получит эти же переменные от среды исполнения по стандартному механизму передачи переменных окружения (doker, heroku или как в примере у автора azure).
А цепляя config.json с помощью require вы по сути хардкодите у себя параметры в модуле, полностью игнорируя стандартные механизмы передачи конфигурационных данных через переменные окружения.
Описанный в статье способ, удобен при работе с сервисами деплой кода на которые осуществляется из систем контроля версий. В вашем случае, вы будете вынуждены задеплоить свой условный config.json с приватными данными (токены, авторизация в базах данных, etc) в репозиторий. Иначе у вас не получится передать ваш файл с конфигурацией сервису исполнения. Переменные окружения полностью решают эту проблему.
Некорректно сравнивать OS/платформу (MacOS) и приложение (Parallels Desktop) эти продукты имеют разную бизнес модель. Если бы MacOS была бы единственным продуктом Apple — она не была бы бесплатной, но это платформа, у неё иные задачи в маркетинговом плане.
Также некорректно рассуждать по малозаметные изменения. Для таких больших и сложных продуктов всегда есть потребность в технической поддержке, в том числе и кодовой базы. Это сильно не бесплатно для компании выпустишей продукт.
Если вас опять же не впечатляют малые изменения, оставайтесь на предыдущей версии продукта.
Да и крайние потора года работы в компании с отлично организованным удалённым рабочим процессом в качестве тимлида, тоже достаточно «охрененный опыт».
Если лично вам ни как не обойтись без сапога в ****, это ваши личные эротические предпочтения. Не надо остальных мазать тем же миром.
Будте мудрее.
Полтора года работаю в компании полного цикла. Полный цикл это значит что у нас есть все: бизнес-аналитик, продактовнеры, дизайнеры, фронтенд и бекенд команды со своими тимлидами и тестировщики. 100% сотрудников работают удалённо и находятся не просто по разным городам, а странам.
Всё работает как часы. Работа построена таким образом, что митинги сведены к минимуму. В основном это узкие встречи. Например планирование работ на следующую итерацию PM-а с тимлидами. Необходимость в митингах даже в рамках продуктовых команд, при правильном прожект менеджменте минимальна. Раз в месяц есть большая встреча всех сотрудников компании на 2 часа, для неформального общения в корпоративном хенгауте (и это поверьте, даже слишком).
Все перечисленные в статье сомнения определяются неспособностью организовать рабочий процесс и подобрать правильных людей в команду, а также незнанием продуктов и сервисов обеспечивающих качественное планирование, управление и контроль за качеством работ, организацией и автоматизацией проверки кодстайла, CI-тестирования, выработкой человеко-часов. Гораздо проще писать вот такие, извините глупости.