Борьба за кодстайл или Bracket Wars

Мы в команде при работе с WebStorm/Idea пришли к следующему:

eslint ставится в каждый проект, конфиги для него вынесены в отдельный репозиторий, который также подключается в каждый проект
в шторме включен eslint с конфигом, лежащим в node_modules, и в репозиторий закоммичена директория .idea/jsLinters. Это позволяет автоматически включать линтер в шторме на каждой машине (естественно, нужно сначала выполнить npm i)
в каждом проекте лежит .editorconfig с настройками отступов и прочего

Есть одна тонкость, шторм при указании конфига внутри проекта, почему-то не может автоматически подставить $PROJECT_DIR$ в путь, так что это нужно сделать руками в .idea/jsLinters/eslint.xml

Vidom — blazingly fast alternative to React

Так гораздо лучше, спасибо!

Vidom — blazingly fast alternative to React

Сходу прочитал так же, может поправить?

Jsqry — библиотека для запросов к JS объектам и массивам

Кстати, это очень здорово, что Вы упомянули этот момент в ангуляре. В свое время он доставил немало «удовольствия» в поиске места, куда приткнуться, чтобы понять странность получаемого результата и отладить это их «небольшое усовершенствование». Думаю, что с jsqry рано или поздно случилось бы то же самое…

Jsqry — библиотека для запросов к JS объектам и массивам

К сожалению, тут проблема двусторонняя… И «гнусный извращенец» может пролезть к вам в сборку с 50-ой зависимостью какого-нибудь npm-пакета :)

Jsqry — библиотека для запросов к JS объектам и массивам

Ну окей. Что, если мне нужно показать сообщение об ошибке, что с сервера пришли битые данные (без services — просто абстрактный пример)? Ваша библиотека, так сказать, прибила гвоздями проверку на undefined, и, соответственно, молча продолжит выборку, когда, используя стандартные функции, можно добавить и/или исключить все необходимые проверки.
Это гибко и удобно, хоть и не позволяет сэкономить лишние пару строк.

Jsqry — библиотека для запросов к JS объектам и массивам

На самом деле тут вариантов несколько.
Если нужна лаконичнось, все укладывается в 1 reduce:

hotel.facilities.reduce(
 (acc, f) => acc.concat(f.services.filter(s => s.visible !== false).map(s => s.name)), 
 []
);
// ["Service 2", "Service 3", "Service 5"]

Если нужна скорость — пожалуйста.

hotel.facilities.reduce((acc, f) => {
 f.services.forEach(s => {
  if (s.visible !== false) {
   acc.push(s.name);
  }
 });
 return acc;
}, []);
// ["Service 2", "Service 3", "Service 5"]

Это я все к тому, что вариантов много и есть возможность использовать нужный, потому-что JS гибок. Но данная библиотека только повышает количество возможных способов, хотя краевые задачи все-равно придется решать с использованием нативных средств.

Jsqry — библиотека для запросов к JS объектам и массивам

Вся необходимая логика (да и вообщем-то любые проходы по коллекциям) так или иначе сводится к map/reduce. Собственно, вся логика выборки (в том числе и все-возможные проверки на undefined/null/коня_в_вакууме) прекрасно умещается в лямбдах для них.

«ES-кунг-фу» гораздо более предсказуемо, его проще и удобнее отлаживать и, что самое важное, поддерживать — это часть стандарта.

Jsqry — библиотека для запросов к JS объектам и массивам

Вот да, только хотел спросить, чем стандартные map/reduce/filter не угодили.

Синхронизация данных в приложениях реального времени c Theron

Так не костыли это вовсе, а нормальный функциональный подход. Другое дело, что ни js, ни ts не предоставляют нормальных конструкций под это дело, когда все элегантно решается через pattern-matching. А вообще при знакомстве с redux перед глазами упорно маячил gen_server из erlang/otp.

Правильное использование require в node.js

Это не совсем то, такой экспорт «пробрасывает» все экспорты из подключаемого модуля. Полезен, если нужно объединить несколько модулей в одном, например в index.js. Есть одно важное уточнение — экспорты пробрасываются только именные, default нет.

Правильное использование require в node.js

Тут вопрос не в практичности, а в идеологии.
Используя динамический require, Вы рискуете нарваться на runtime-ошибку (отсутствие файла, поврежденный контент и т.д.), когда, подключая все нужные файлы заранее на верхнем уровне, можно было бы избежать ненужных проверок на существование, целостность и т.д.
Опять же, теряется статический анализ.

Правильное использование require в node.js

Ну почему, Вы в предисловии статьи приводите заключение в виде плюсов и минусов commonjs, причем явно упоминая о том, что в es6-модулях все импорты должны быть на верхнем уровне. Такое ограничение сделано как раз для возможности статического анализа, потому как require внутри функции или, например, по условию проанализировать не получится. Так что можно было бы в минусах упомянуть каких преимуществ лишается разработчик без статического анализа.

Про «множество отдельных файлов с одним методом» все же не соглашусь. Если в модуле 200 функций, нужно завести 200 файлов? Достаточно непрактично. Таким образом, учитывая, что, как я упомянул выше, require внутри функции не анализируется, то, так как по схожей причине невозможно понять, вызывается ли функция, ничего не остается, как включать и функцию и подключаемый внутри нее модуль. Хотя это легко избегается с помощью es6-модулей.

Правильное использование require в node.js

Справедливости ради, можно было упомянуть в минусах commonjs невозможность статического анализа и, как следствие, отсутствие tree-shaking и прочего.