Привет! Интересно, что ты считаешь хорошим примером запрос на оповещения от TJ. Как по мне, это антипример, чёрный паттерн. Вопрос специально сформулирован так, чтобы человек по привычке ткнул на «Нет» (отстань), и получил ровно противоположный результат.

Привет! Я считаю его хорошим (= более эффективным в этом контексте) только относительно стандартного запроса. Так-то мне эта фишка с «Нет» мне самому не нравится

Вчера вышел Реакт 16 (об этом вы уже, наверное, слышали). В релизе — несколько новых фич и полностью переписанные внутренности.

А команда Реакта написала, как переписывание библиотеки выглядело с их стороны. Почему feature-флаги эффективнее feature-веток, как разработчики проверяли, что API продолжает работать точно так же, и другие детали → React 16: A look inside an API-compatible rewrite of our frontend UI library

Я много раз слышал, что функции должны быть небольшими (например, не больше экрана). Кто-то (например, «Clean Code») уводит это в экстремум и вообще рекомендует делать функции настолько маленькими, насколько возможно.

А вот Синди Сридхаран написала, какие проблемы могут быть, если чересчур увлечься разбиением всего на мелкие функции. Некоторые мысли:
— Код, который разбит на много мелких функций, сложнее понять:
 1) При чтении такого кода придётся постоянно переключаться между функциями (и в редакторе кода, и в голове).
 2) Каждая функция сама по себе несёт дополнительную сложность из-за того, что она абстрактная.

— Каждая вынесенная функция фиксирует код в том состоянии, в котором он уже есть. Простым языком: переместить какое-то выражение на строку ниже, когда оно внутри одного большого метода foo(), просто. А переместить его, когда foo() разбит на кучу маленьких функций, и выражение находится в одной из них, сложнее.

— Есть риск чрезмерно увлечься DRY — то есть начать выносить весь код так, чтобы потом его было проще реиспользовать. Это вредная идея: вы не знаете, как этот код понадобится вам в будущем, и можете вынести его неправильно.

Статья рассказывает это подробнее и добавляет другие важные мысли. Читайте: https://medium.com/@copyconstruct/small-functions-considered-harmful-91035d316c29

Никита Прокопов истину глаголет:

Никогда не надо делать свой, кастомный скролл. Скроллить можно миллионом разных устройств. Человек чем скроллит, к тому и привык. А к вашему потестированному пять минут на дешевой виндовой мыше onscroll-у не привык. Только системный. Тут даже вариантов как-то и быть не может. Кто не согласен приглашется поскроллить табличку http://оквэд.рф на тачпаде

А вообще, основная проблема кастомных скроллов, селектов и инпутов — это не то, что разработчики делают их плохо. Основная проблема — то, что браузеры не дают нормально стилизовать нативные. Если бы для для нативных элементов можно было бы без проблем писать свои стили, никто бы даже не возился с написанием кастомных. Но ¯\_(ツ)_/¯

Что делать с этим на практике
1. Моё мнение: всё равно по умолчанию используйте нативные компоненты. С нативными вы пострадаете день или два, пока будете делать их, и потом забудете, а с кастомными будут ежедневно страдать ваши тысячи пользователей.

2. Если дизайнер приносит вам макет со своими кастомными скроллами и селектами, убедите его использовать нативные. Расскажите, какие проблемы будут, если использовать кастомные — дизайнеры не всегда знают про это.

3. Стилизируйте нативные элементы там, где нужно: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Advanced_styling_for_HTML_forms

CEO Lunar Logic пишет, почему вам не нужны разработчики-суперзвёзды и почему командные навыки гораздо важнее.

Спойлер: самая большая продуктивность у команд, люди в которых слушают друг друга и проявляют эмпатию.

Этот же CEO пишет, как Lunar Logic нанимает разработчиков — и, в частности, проверяет их командные навыки. Интересные моменты (в статье больше):
— Кандидаты перед наймом проводят несколько часов с командой, общаясь и знакомлясь с процессом работы. Это помогает команде оценить кандидата, а кандидату увидеть компанию изнутри
— Идеальный кандидат — такой, про которого почти все скажут «да», но несколько человек скажут «нет». Это значит, что подходит «почти, но не совсем», и это «не совсем» может развить команду в неожиданном направлении

#Хинт (точнее, два) про Вебпак:

Оптимизации бандла можно включать консольным параметром
CLI Вебпака поддерживает флаг -p:

$ webpack -p

Этот флаг расшифровывается как production и включает самые простые оптимизации (минификацию и NODE_ENV=production). Для реальных проектов этого вряд ли будет достаточно (я писал, что для них нужно), но для прототипов — хороший вариант, чтобы не возиться с конфигом.

Переменные окружения можно передавать проще
Если вы передаёте переменные окружения с помощью DefinePlugin:

module.exports = {
 plugins: [
   new webpack.DefinePlugin({
     'process.env.NODE_ENV': JSON.strinfigy(process.env.NODE_ENV),
   }),
 ],
};

то посмотрите на EnvironmentPlugin. Он работает так же, как и DefinePlugin, но передаёт переменные окружения автоматически:

module.exports = {
 plugins: [
   new webpack.EnvironmentPlugin(),
   // Теперь все process.env.* в коде будут заменены
   // на аналогичные переменные из реального окружения
 ],
};

Женя Родионов написал неочевидные штуки про Редакс. Там клёво, почитайте: https://medium.com/@evgeny.rodionov/6a95feefcf29

(У Жени, кстати, ещё и канал есть: https://t.me/rodionovrodionovrodionov)

От этого я сам ещё недавно болел, например

А я уже писал про критерий, по которому можно выбирать между Редаксом и setState() в Реакте: https://iamakulov.com/notes/redux-vs-react-setstate/

​​Отличная статья Джейка Арчибальда про кеширование.

Два основных подхода к кешированию и опасности max-age: https://jakearchibald.com/2016/caching-best-practices/

Сергей советует русский перевод:

Про кеширование уже давно перевели на русский — http://prgssr.ru/development/luchshie-praktiki-keshirovaniya.html

Друзья, нужна ваша помощь.

Мне нужно для статьи собрать информацию про использование пары фич Вебпака в продакшене.

Если вы используете или использовали:
— AggressiveSplittingPlugin с HTTP/2
— или несколько entry-поинтов в одном конфиге (кроме entry-поинта типа vendor)
в продакшен-проектах, напишите мне, пожалуйста, в личку → @iamakulov

С меня — набор телеграм-стикеров, которого у вас нет :–)

Чтоб прояснить — я пытаюсь понять:
— Насколько AggressiveSplittingPlugin реально помогает с кешированием (и ускоряет загрузку) + нет ли у него каких-то побочных эффектов, которые видны только в продакшене

— И в каких случаях разработчики выбирают явные entry-поинты вместо динамического import()

Если вы что-то знаете по этому поводу, пишите тоже → @iamakulov

​​В эту субботу проведу онлайн-воркшоп по Вебпаку. Воркшоп для киевского сообщества Kottans, но попасть могут все :–)

Приходите! Темы:
— Когда и зачем Вебпак нужен
— Как избежать его настройки
— Как настраивать его вручную для разработки и продакшена (если избежать настройки не удалось)

Покажу процесс настройки вживую и отвечу на все вопросы.

Регистрируйтесь — я пришлю ссылку на трансляцию и чат: https://iamakulov.com/webpack-workshop

​​Сергей Крыжановский написал про минусы (и плюсы) больших компаний. Читайте, чтобы понимать, что вас ждёт в Яндексе, ЕПАМе и Гугле: «Проблемы больших компаний»

Главное:
— Много встреч, на которые тратится куча времени
— Много легаси-кода со старыми технологиями
— Велосипеды (на моём проекте в ЕПАМе, например, был собственный фронтенд-фреймворк)
— Много руководителей, и, как следствие, бюрократия и политические игры

Из плюсов:
— Всё, что выше — это опыт, который учит ненавидеть чрезмерные встречи/легаси/велосипеды и избегать их
— Много возможностей для роста: процессы обычно заточены на рост (внутренние тренинги и вот это всё) + есть много узкоспециализированных позиций, в которые можно развиваться

https://felixit.blog/2017/11/08/problemy-bolshih-kompanii/