1) Где был компонентный подход к разработке, когда появился BEM (2008 год)?
2) Мы (не Яндекс) тоже написали свой feature-starter-kit вместо create-react-app — наши задачи не влезали в готовый инструмент для широкого использования и поэтому ограниченого по функциональности.
BEM — хороший пример Соглашения по конфигурации, когда js/css/шаблоны находятся в предсказуемых местах. Соглашение позволяют легко войти в другой проект, созданный по таким же соглашением с минимальным количеством «WAT».
Также, по моему, это выглядит довольно странно:
tag()('button')
Тело шаблона — это отдельный вызов функции, которая ожидает аргумент.
Можно использовать сокращенный синтаксис, который выглядит привычнее:
Достаточно вольный перевод (либо автор, Cory House, отредактировал свою статью):
Мне нравится Redux, но я часто использую стандартный стейт React, когда это возможно. На данный момент мы выпустили кучу React приложений, и решили что Redux худший выбор. Я предпочитаю делать много маленьких автономных приложений поверх одного большого приложения.
Оригинал:
I’m a fan of Redux, but I often use plain React since it’s simpler. In my current role, we’ve shipped about a dozen React apps, and decided Redux was worth it for two. I prefer shipping many, small, autonomous apps over a single large app.
Скорее всего имелось ввиду, что из 12 проектов для 2 Redux был обоснованным выбором. Не указывается, остальные 10 не нуждались в усложнении или еще по каким причинам Redux для них не подходил.
Так и сделали. Но не хватает возможности полноценный проект собрать и функционально/вручную прогнать.
Хотя полный проект может и не надо собирать по PR, достаточно сделать такую сборку по кнопке и собирать только релизы.
Возможно, тормозит неоптимально написанный геттер — сам сталкивался с такой проблемой, когда плохо декомпозировал Селекторы и не работала мемоизация.
Идея в том, что при повторном вызове селектора с неизменившимися параметрами результат будет выдан из кеша без повторного вычисления.
Если кратко: есть более полезные практики, которые имеет смысл внедрить ДО «статической» типизации:
покрытия тестами
соглашение по стилю кода, особенно наименованию переменных
jsDoc — Совершенные редакторы могут проверять код по jsdoc. При этом, на мой взгляд, код не загрязняется визуально «типизацией» (кавычки, потому что «типизация» в JS — только сахар.
Расскажите пожалуйста о колонках и особенно наушниках для таких проигрывателей.
Интересно будет продолжение — методики снижения стоимости внедрения и особенно унификации.
twitter.com/hapijs/status/1275887984114413569
Оказывается, что-то полезное можно сделать и одному :)
Пустые офисы у многих компаний прекрасны :)
Про аудио и визуальный шум — это точно отвлекает, экстраветров тоже :)
Можно сделать сайт «все про IT в ДОДО», как например:
A12 вроде неплох https://www.macrumors.com/2018/07/02/2018-iphone-a12-benchmark/
2) Мы (не Яндекс) тоже написали свой feature-starter-kit вместо create-react-app — наши задачи не влезали в готовый инструмент для широкого использования и поэтому ограниченого по функциональности.
Тело шаблона — это отдельный вызов функции, которая ожидает аргумент.
Можно использовать сокращенный синтаксис, который выглядит привычнее:
Посмотрите пример
Оригинал:
Скорее всего имелось ввиду, что из 12 проектов для 2 Redux был обоснованным выбором. Не указывается, остальные 10 не нуждались в усложнении или еще по каким причинам Redux для них не подходил.
Хотя полный проект может и не надо собирать по PR, достаточно сделать такую сборку по кнопке и собирать только релизы.
По flow: делаем rebase в ветках PR, а в GitHub есть возможность «Squash and Merge» — классная штука, github.com/blog/2141-squash-your-commits.
Еще один довод поднять staging со сборкой на каждый PR. У нас такого пока нет, страдаем.
Возможно, тормозит неоптимально написанный геттер — сам сталкивался с такой проблемой, когда плохо декомпозировал Селекторы и не работала мемоизация.
Идея в том, что при повторном вызове селектора с неизменившимися параметрами результат будет выдан из кеша без повторного вычисления.
Видео: https://youtu.be/Yxsf06JSGCE?t=3h9m49s ((с 3:09:49)
Презентация: https://easy-deep-learning.github.io/types-sugar-in-javascript/
Если кратко: есть более полезные практики, которые имеет смысл внедрить ДО «статической» типизации: