Статьи For Web

8 вещей, которые я хотел бы знать в начале карьеры

2015-01-17T00:00:00Z

Я работаю в сфере веб-разработки больше пяти лет, и это похоже на приключение — знакомство с новыми технологиями и эксперименты с разными подходами. Временами я был успешен, временами я разочаровывался в себе. В этой статье я хочу рассказать вам о некоторых идеях, которые я постепенно осознал, работая веб-разработчиком. Надеюсь, что вас научат чему-то мои ошибки.

1. Пишите чистый код

Первое, что вы понимаете, когда начинаете работу над большим приложением — это то, что для отладки требуется куча времени. Возможно вы проведёте больше времени за отладкой, чем за написанием нового кода.

В таких ситуациях чрезвычайно важно писать правильно отформатированный и задокументированный код, соответствующий лучшим практикам. Представьте, что у вас есть сотни строк кода, и вы не имеете понятия о том, какая из них вызывает маленький баг. Ещё хуже будет, если вы напишете нечитаемый код — через какое-то время вы просто не будете знать, что делает тот или иной кусок кода. Вы точно хотите всех этих проблем? Посмотрите советы по написанию чистого кода.

2. Язык в первую очередь, фреймворк потом

Люди зачастую сперва изучают фишки фреймворка, и только потом обращают внимание на язык. Это неправильный путь.

Популярность Django можно отнести к преимуществам Python — поэтому важно познакомиться с Python перед тем, как браться за Django. Нельзя поступать наоборот.

Простая причина такого подхода заключается в том, что если вы знаете язык — вы можете понять механизм работы фреймворка. Если вы не имеете никакого представления об языке, вы никак не сможете понять, почему что-то во фреймворке сделано определённым способом.

3. Изучайте JavaScript, а не jQuery

JavaScript является самым доступным языком в мире. Любое устройство с браузером может выполнять JavaScript-приложения.

Ошибка, которую совершают начинающие разработчики, заключается в изучении jQuery. Вопросы вроде этого на Quora дают понять, что jQuery весьма популярен среди людей, которые не имеют понятия о базовых принципах и возможностях JavaScript!

jQuery — это всего лишь набор вспомогательных функций, написанных на JavaScript. Единственная причина, по которой люди предпочитают jQuery — это то, что jQuery требует написания меньшего количества кода. Однако последние версии JavaScript (или ECMAScript в оригинале) имеют более дружелюбный синтаксис, благодаря чему в jQuery больше нет нужды.

Я не утверждаю, что использовать jQuery неправильно. Я всего лишь говорю вам о том, что надо следовать правильному пути обучения. Если вы не знаете о замыканиях и пространствах имён в JavaScript, как вы объясните использование $ в jQuery?

4. Не просто читайте, а делайте

Я часто видел разработчиков, которые читали туториалы или даже целые книги без всякой практики. Меня беспокоит одно — многое ли вы усвоите, только читая?

Если вы хотите изучить Ruby on Rails, попробуйте разработать небольшое приложение в процессе чтения туториалов и документации. Если вы хотите попробовать стэк MEAN, то запустите его на вашем компьютере и познакомьтесь с различными возможностями — это лучший способ изучения!

5. Дилетант, но не специалист

Хорошо изучать новые технологии, но следует иметь одну технологию для решения большинства задач. Для новичков изучение сразу нескольких языков выглядит весьма заманчиво, но лучше всего изучать только один язык пока вы не достигнете в нём определённого уровня мастерства.

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

6. Изучайте системы контроля версий

В наше время работа над проектом в одинучку — редкость. Чтобы взаимодействовать с командой, вам придётся изучить системы контроля версий.

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

7. Учитесь у других

Самостоятельное изучение технологии — это круто, но иногда можно многому научиться, всего лишь посмотрев на чужой код. Будь то ваши коллеги или какие-то туториалы в интернете — пытайтесь найти чьи-то подходы к решению определённых проблем. И задавайте вопросы, если это необходимо.

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

8. Просите о кодревью и наслаждайтесь им

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

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

Это перевод статьи 8 Things I Wish I’d Known When I Started as a Web Developer Шомика Дайтари.

Принципы написания однородного HTML

2015-03-03T00:00:00Z

Этот документ представляет собой общие рекомендации по стилю написания HTML-разметки. Данное руководство призывает к использованию общепринятых и устоявшихся подходов к написанию кода.

1. Основные принципы

Весь код в любой кодовой базе должен выглядеть так, будто его написал один человек, вне зависимости от реального количества разработчиков.

Строго следуйте принятому стилю.

Если вы сомневаетесь в том, какой стиль использовать, пользуйтесь общепринятыми и устоявшимися подходами.

2. Пустое пространство

В вашей кодовой базе должен быть лишь один стиль написания кода. Всегда согласованно используйте пустое пространство. Используйте пустое пространство для улучшения читаемости кода.

Никогда не смешивайте табы и пробелы в отступах.

Выберите между мягкой табуляцией (пробелы) и реальными табами. Придерживайтесь выбранного подхода (предпочтительны пробелы).

Если вы используете пробелы, выберите количество символов для отступа (предпочтительно 4 пробела).

Совет: настройте свой текстовый редактор так, чтобы он показывал непечатные символы. Это позволит вам устранить появление лишних пробелов и табов в конце строк или ещё где-либо.

3. Форматирование

Названия тегов и атрибутов всегда пишите в нижнем регистре.

На одной строке размещайте только один элемент.

Используйте дополнительный уровень отступов для каждого вложенного элемента.

Указывайте атрибуты без их значения, если это возможно (например, checked вместо checked="checked").

Всегда используйте двойные кавычки для значений атрибутов.

Не указывайте атрибут type в элементах link, style и script.

Всегда закрывайте теги.

Не используйте слеш в единичных тегах (<img> — правильно, <img/> — неправильно).

Сохраняйте длину строки в пределах разумного максимума, например 80 символов.

Пример:

<div class="tweet"> <a href="path/to/somewhere"> <img src="path/to/image.png" alt=""> </a> <p>[tweet text]</p> <button disabled>Reply</button> </div>

Исключения и небольшие допущения

В элементах с несколькими атрибутами эти атрибуты можно расположить на отдельных строках, чтобы улучшить читабельность:

<a class="[value]" data-action="[value]" data-id="[value]" href="[url]"> <span>[text]</span> </a>

4. Порядок атрибутов

HTML-атрибуты должны быть перечислены в порядке, учитывающем то, что названия классов — базовая вещь, которая позволяет выбирать элементы с помощью JavaScript или CSS:

class
id
data-*
Любые другие атрибуты

Пример:

<a class="[value]" id="[value]" data-name="[value]" href="[url]">[text]</a>

5. Именование

Именование — вещь сложная, но очень важная. Это ключевая часть процесса написания поддерживаемого кода. Без правильного именования невозможно иметь относительно масштабируемый интерфейс между HTML и CSS/JS.

Используйте простые, понятные и уместные имена для классов. Имена должны быть информативны вне зависимости от контекста — как в разметке, так и в CSS-файлах.

Избегайте систематического сокращения имён классов. Не усложняйте код.

Пример с плохим именованием классов:

<div class="cb s-scr"></div>

.s-scr { overflow: auto; } .cb { background: #000; }

Хороший пример именования:

<div class="column-body is-scrollable"></div>

.is-scrollable { overflow: auto; } .column-body { background: #000; }

6. Практический пример

Пример различных соглашений.

<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>Document</title> <link rel="stylesheet" href="main.css"> <script src="main.js"></script> </head> <body> <article class="post" id="1234"> <time class="timestamp">March 15, 2012</time> <a data-id="1234" data-analytics-category="[value]" data-analytics-action="[value]" href="[url]">[text]</a> <ul> <li> <a href="[url]">[text]</a> <img src="[url]" alt="[text]"> </li> <li> <a href="[url]">[text]</a> </li> </ul> <a class="link-complex" href="[url]"> <span class="link-complex__target">[text]</span> [text] </a> <input value="text" readonly> </article> </body> </html>

Это перевод Principles of writing consistent, idiomatic HTML Николаса Галлахера. Оригинал лицензирован по Creative Commons Attribution 3.0 Unported License. Лицензия распространяется на все документы и переводы.

О PostCSS от его создателя: интервью с Андреем Ситником

2015-07-18T00:00:00Z

В последнее время сообществом фронтенд-разработчиков довольно активно обсуждается PostCSS. О том, что это и где оно применяется мы расспросили создателя PostCSS Андрея Ситника.

Привет! Спасибо, что согласился побеседовать. Я думаю, разговор всё равно более-менее спонтанный получится, так что начну с одного вопроса, а дальше уже как пойдёт. Расскажи немного о себе?

Родился во Владивостоке. Детство прожил в Йемене. Университет закончил в Питере. Сейчас работаю фронтендером над Амплифером в Злых марсианах, поддерживаю Автопрефиксер и развиваю PostCSS.

А как ты вообще стал программистом? Когда и с чего начал увлекаться этим? Какой путь совершил прежде чем прийти к фронтенду?

В детстве я не хотел быть программистом — скорее хотел стать учёным. Но у меня была большая мечта — путешествовать по миру. И я подумал, что программирование — самый простой путь к этому. А потом я написал свою первую программу, запустил её и увидел, что она заработала. Это было непередаваемое ощущение — когда что-то, что ты сделал, живёт дальше само по себе.

Дальше был Basic, Pascal, школьные олимпиады. Затем я увидел мир PHP и веба — он мне сразу очень понравился. Там была настоящая свобода. Динамический язык для творчества. И результат доступный каждому. А потом я впервые увидел Ruby on Rails. Видео «блог за 5 минут» просто будоражило, так как оно показывало, что появляется совершенно новая эпоха.

Я бы не сказал, что я стремился во фронтенд. Просто мне было проще решать задачи с визуальной точки зрения. Проще понять дизайн. Так со временем становилось всё больше фронтенда и меньше бэкенда.

Получается, ты изначально немного занимался бэкендом, писал на PHP и Ruby? Насчёт PHP ничего не скажу, но вот Ruby весьма выразительный и красивый язык. Не жалеешь о переходе на JavaScript после него?

Скажем так, на чистом JS я бы вообще не смог программировать — но CoffeeScript, ES6 сильно развивают язык до какого-то приемлемого уровня. Многих вещей мне всё ещё не хватает, но уже терпимо.

JavaScript по сравнению с CSS развивается довольно быстро. Если с появлением ES6 в языке появилось достаточно нововведений, благодаря которым можно обойтись без дополнительных инструментов вроде CoffeeScript, то в случае CSS использование различных препроцессоров уже стало стандартом де-факто. Раньше ты использовал какой-то препроцессор?

Ты так говоришь, как будто ES6 поддерживается во всех браузерах. Мы просто сменили один препроцессор, CoffeeScript, на следующий — Babel. Даже когда браузеры будут поддерживать ES6 мы всё равно будем использовать Babel ради ES7 и так далее. Но в сравнении с этим мне действительно не нравится застой в мире препроцессоров CSS — за последний год в Sass, Less, Stylus ничего не изменилось, и это приговор.

Раньше я использовал Sass, так как я из мира Ruby.

Я раньше тоже использовал Ruby Sass, но он ооочень медленный.

В мире Sass/Less/Stylus действительно практически ничего не изменилось за последнее время. Хотя свои задачи они решают неплохо. Но стабильность без всякого развития губительна.

Зато в мире CSS появились такие инструменты как Rework, а затем PostCSS. Можешь для непросвещённых читателей вкратце рассказать, что это за инструмент такой — PostCSS, а главное, зачем он нужен?

Технически PostCSS — это инструмент, который позволяет его JS-плагинам перестраивать CSS-файл. Но в реальности этот инструмент позволяет нам совсем по другому подойти к написанию CSS. На PostCSS можно написать совершенно новые инструменты, которые будут помогать писать CSS-код. Инструменты, о которых мы даже раньше и не думали. Речь идёт не о переменных или примесях — PostCSS это следующий этап, где эти вещи уже не так важны.

Например, Автопрефиксер — он сам расставляет префиксы только там, где вам нужно. Не нужно писать примеси и тому подобное — он работает с обычным CSS. Или cssnext, который откомпилирует CSS4 в обычный CSS (как Babel для ES6). Или postcss-flexbugs-fixes — он содержит в себе базу данных ошибок реализации флексбокса в браузерах. И он автоматически исправляет или предупреждает вас, когда код будет не работать из-за этих ошибок.

То есть по сути PostCSS получает написанный нами CSS (возможно невалидный), производит с ним определённые манипуляции, как-то его модифицирует и отдаёт нам уже преобразованный, валидный CSS?

Да. Например, плагин postcss-nested в 60 строк просто проходиться по CSS и заменяет a { b { } } на a b {}. Но PostCSS не только про трансформацию CSS.

Например, Твиттер использует PostCSS, чтобы проверять БЭМ-нотацию. Или плагин doiuse,который проверяет по Can I Use все ли используемые свойства поддерживаются в нужных вам браузерах. Ну и недавно анонсированный stylelint — очень умный CSS-линтер, построенный по модульный архитектуре, как ESLint.

Интересно. Ты упомянул Твиттер. На страничке PostCSS на гитхабе сказано, что PostCSS также используют Google, Alibaba и Shopify. А можно об этом подробнее? Какие задачи они решают с помощью PostCSS?

Shopify использует Автопрефиксер. Google использует Автопрефиксер и рекомендует его как единственный инструмент для работы с браузерными префиксами. Точный список плагинов у Alibaba не знаю, но они разрабатывают cssgrace и несколько плагинов для cssnext. Так что точно используют эти два. В Китае просто большая проблема с IE — там до сих пор популярные версии 8, 7 и даже иногда 6. Поэтому cssgrace — это такой cssnext наоборот. Он находит вещи, которые не поддерживаются в старом IE и вставляет хаки для него.

Твиттер пошли дальше — они совсем отказались от препроцессоров. Когда я последний раз говорил с Николасом, он сказал, что они сейчас на Rework и переходят на PostCSS.

А ещё я слышал, что bootstrap 5, вероятно, будет переписан на PostCSS. Это похоже прямо-таки на революцию в мире CSS.

Опыт твиттера весьма любопытен. Многие разработчики боятся полностью переходить на PostCSS. Они в лучшем случае используют какой-нибудь препроцессор вместе с Автопрефиксером. Можно ли уже сейчас полностью отказаться от препроцессоров и продолжить решать те же задачи, но уже с PostCSS? Или он всё же не рассчитан на то, чтобы полностью заменить препроцессоры?

PostCSS сразу создавался чтобы заменить препроцессоры. Если мы можем делать такие сложные вещи, как Автопрефиксер или cssnext, то сделать вложенность или переменные очень легко. Как раз на этой неделе вышел PreCSS — набор плагинов для PostCSS, чтобы сделать что-то типа препроцессора.

Но тут есть важный нюанс. Если ваш проект уже написан на Sass — не переводите его на PreCSS, добавьте PostCSS после Sass. Дело в том, стагнация Sass длилась очень долго. В итоге у нас есть очень много не очень правильных способов организации код. Я видел как на Sass писали прямо целые программы — и это, конечно же, плохой подход. Это как делать SQL-запросы в шаблонах — сильное смешивание кода. Поэтому в PostCSS мы немного меняем философию. Ваши стили должны быть простыми. @for нужно использовать просто — чтобы не повторять одинаковые блоки, а не чтобы писать алгоритмы. Если вам нужна сложная логика — лучше всего её вынести в JS. И когда старый проект переписывается с Sass на PostCSS — это не просто вопрос смены синтаксиса, но скорее вопрос смены мышления. Лучше всего попробовать только PostCSS без препроцессоров на новом проекте — там вам буде легче понять философию PostCSS.

Расскажи, как вообще тебе в голову пришла идея создать PostCSS? Была необходимость решить какую-то задачу, которую не могли решить препроцессоры?

Всё началось из-за ненависти. Ненависти к Compass. У них было ужасное управление проектом — ты посылаешь PR, а они молчат по месяцам. Последней каплей было, когда моя знакомая закрыла ИП в российской бюрократии проще и быстрее, чем Compass принял мой PR.

Я понял, что Compass надо заменять. И главной вещью в Compass были префиксы. Я начал думать — как можно сделать управление префиксами ещё удобнее чем сейчас. Всё по ТРИЗ — как можно было бы управлять ими вообще идеально. И пришёл к идее Автопрефиксера, который сразу вырисовывался как проект, невозможный на препроцессорах.

Но полностью идею модульных процессоров придумал TJ Holowaychuk в проекте Rework. Первая версия Автопрефиксера даже называлась rework-vendors. Однако очень быстро Автопрефиксер перерос Rework: нам требовался парсер лучше, лучше поддержка карт кода. Ребята из Rework не хотели менять архитектуру. Так что я начал PostCSS как развитие идей Rework.

Теперь ты полностью отказался от препроцессоров и на работе используешь только PostCSS?

Да. Но мне от препроцессоров было нужно весьма мало: вложенность, какой-то простой конфиг с цветами сайта, простейшие циклы и примеси, чтобы не повторять код. Единственное чего не хватает из препроцессоров — простого синтаксиса типа Stylus. Но мы работаем над этим. В PostCSS 4.2 будут разные парсеры.

О, вот это действительно круто. А как решать вопрос с подсветкой синтаксиса? Ведь, насколько мне известно, нет никаких цветовых схем, заточенных конкретно под PostCSS. Да и обилие разных плагинов усложняет эту задачу.

Плагины никакой проблемы не создают — они же не вводят новые синтаксические конструкции. Только новые свойства или @директивы. Сейчас SCSS-подсветка прекрасно работает с PostCSS — собственно PostCSS же работает с обычным CSS, только с возможностью вложенности.

В нашем сообществе в комментариях к одному из постов сказали, что было бы разумно ввести какое-нибудь специальное расширение для файлов стилей, написанных для PostCSS — ну чтобы хотя бы никакой путаницы не возникало. Что-то вроде main.pcss. Ты задумывался об этом?

У нас точно будет специальное расширение для сокращённого синтаксиса — SugarSS.

А как быть с обычным синтаксисом?

Пока не решили :). Некоторые плагины типа Автопрефиксера, cssnext или postcss-focus ничего в CSS не добавляют, им расширение не нужно. Может быть внутри проекта PreCSS придумают какое-о расширение.

PostCSS называют постпроцессором. А чем постпроцессор отличается от препроцессора? Откуда вообще взялся этот термин?

Я сам не знаю откуда он взялся. Сейчас он уже потерял свой смысл — грань слишком стёрлась. Изначально постпроцессорами называли плагины PostCSS, которые работают с обычным CSS — например, Автопрефиксер, полифиллы будущих стандартов. Но для PostCSS есть набор плагинов PreCSS, который работает полностью как препроцессор. Я стараюсь уже не употреблять термин постпроцессоры :).

Раз сам создатель рекомендует не использовать этот термин, то грех теперь его произносить :). И, наверное, последний вопрос — сколько человек на данный момент работает над PostCSS и какие у вас планы на будущее?

Поскольку у нас модульный проект, то нельзя сказать о какой-то явной команде. Скорее это такое переплетение важных модулей.

Над ядром PostCSS работаю в основном я, хотя все остальные активно помогают мне с английским. Maxime Thirouin из Франции разрабатывает cssnext и stylelint и активно участвует в сообществе. Ben Briggs из Англии ведёт разработку важных инфраструктурных плагинов типа postcss-use и помогает новичкам в gitter-чате. Jonathan Neal из США разрабатывает PreCSS. 一丝 из Китая внедряет PostCSS в Таобао и другие проеты Алибабы и ответственен за пиар в Китае. David Clark из США занимается линтерами (Stylelint и postcss-bem-linter) и пишет отличные статьи, объясняющие PostCSS новичкам.

Это самое явное ядро проекта, но так или иначе участвует примерно 90 человек — кто-то пишет плагины, кто-то рассказывает про PostCSS. И жёсткой грани между «ядром» и остальными не существует.

Ого, неплохо. А что в планах?

В версии 4.2 добавим сменяемые парсеры. Можно будет парсить SCSS, Less, и специальный синтаксис типа Stylus, где не надо будет вводить фигурные скобки ({}) и точки с запятыми (;). В версии 4.3 добавим больше API — парсер селекторов, парсер значений. А потом будет большой релиз 5.0, где мы исправим API, сделав его более логичным — всё-таки некоторые части проекта развивались стихийно. Ещё в планах сайт и маленький митапчик PostCSSConf где-нибудь в Европе.

Класс! А в специальном синтаксисе типа Stylus двоеточия останутся или нет?

Пока ещё не решили. Хочется сохранить возможность писать многострочные значения (например для длинных градиентов).

Было бы круто реализовать лаконичный синтаксис из Stylus без двоеточий. Будем ждать новостей. Спасибо за беседу! Интересно было пообщаться. Желаем успехов тебе и твоему проекту!

Состояние загружаемых данных

2020-04-29T00:00:00Z

Одна из повседневных задач каждого фронтендера — загрузка данных с сервера. На время загрузки обычно требуется показывать пользователю спиннер, а в случае неудачи — сообщение об ошибке. В коде состояние загрузки часто описывают булевыми флагами:

const comments = { isLoading: false, isLoaded: false, isError: false, errorText: '', data: [], };

На первый взгляд такие флаги выглядят удобно. При их использовании код загрузки данных выглядит примерно так:

const comments = { isLoading: false, isLoaded: false, isError: false, errorText: '', data: [], }; function loadComments() { comments.isLoaded = false; comments.isError = false; comments.isLoading = true; fetch('/comments') .then((response) => response.json()) .then((data) => { comments.isLoading = false; comments.isLoaded = true; comments.data = data; }) .catch((error) => { commments.isLoading = false; comments.isError = true; comments.errorText = error.message; }); }

Получается запутанно и многословно. Нужно внимательно следить, значения каких флагов следует сбросить, иначе в вашем приложении появятся бессмысленные комбинации флагов вроде isLoading: true и isLoaded: true.

Более практичный подход, решающий эту проблему — описание состояния одним полем dataState и автоматическое вычисление флагов на основе значения этого поля:

const dataStates = { notAsked: 'notAsked', loading: 'loading', loaded: 'loaded', failed: 'failed', }; const comments = { dataState: dataStates.notAsked, errorText: '', data: [], get isLoading() { return this.dataState === dataStates.loading; }, get isLoaded() { return this.dataState === dataStates.loaded; }, get isError() { return this.dataState === dataStates.failed; }, };

Кода стало чуть больше, зато значения всех флагов меняются автоматически, и вероятность ошибки из-за неправильного обновления одного из флагов сведена к нулю. Функция загрузки комментариев становится значительно проще:

function loadComments() { comments.dataState = dataStates.loading; fetch('/comments') .then((response) => response.json()) .then((data) => { comments.dataState = dataStates.loaded; comments.data = data; }) .catch((error) => { comments.dataState = dataStates.failed; comments.errorText = error.message; }); }

Когда можно дублировать код?

2020-05-04T00:00:00Z

Анализируя большую кодовую базу, мы сразу видим случаи, в которых следовало переиспользовать код. Но если вы только начинаете проект, случаи переиспользования кода не так очевидны — сложно предугадать, как будет эволюционировать тот или иной участок кода.

Дублировать код хорошо на начальном этапе, когда вы ещё не знаете, как в дальнейшем он будет развиваться. Подумать о переиспользовании можно будет в будущем, когда кодовая база достаточно разрастётся и устаканится.

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

Итак, дублирование кода позволяет минимизировать количество зависимых от него участков приложения, а значит упростить его дальнейшую доработку. Из этого следует ещё одна рекомендация: дублируйте код, который в будущем с большой вероятностью будет меняться. Чем более код специфичен, с тем большей вероятностью он изменится в будущем. Например, бизнес-логика меняется гораздо чаще, чем низкоуровневая логика общения с сервером (стандарт HTTP обновляется раз в несколько лет).

UX drag-and-drop загрузки файлов

2020-05-05T00:00:00Z

При реализации формы с полем загрузки файлов хорошим тоном считается поддержка drag-and-drop, чтобы пользователь мог перетащить нужный файл из проводника в форму.

Часто размеры области, на которую нужно бросить перетаскиваемый файл, ограничивают:

Если поле загрузки файлов всего одно, такое ограничение обосновать сложно, а пользователю оно мешает: чем меньше доступная область, тем сложнее пользователю в неё попасть и тем проще промахнуться.

Более дружелюбный к пользователям подход — растянуть доступную для перетаскивания область на весь экран. Так, например, сделано в Амплифере и на ГитХабе:

Если полей для загрузки файлов на странице несколько (например, при загрузке сканов нескольких документов), доступную для перетаскивания область всё равно можно растянуть на весь экран и разделить на области для каждого поля. Скорее всего, эти области будут всё ещё достаточно большими.

Нюанс: перетаскивание текста

Чтобы при случайном или намеренном перетаскивании текста на странице не включалась полноэкранная область загрузки файлов, проверяйте тип содержимого в событиях перетаскивания:

function isFileDragEvent(event) { return event.dataTransfer.types.includes('Files'); } document.addEventListener('dragenter', (event) => { if (!isFileDragEvent(event)) { return; } // ... });

URL.createObjectURL вместо FileReader.readAsDataURL

2020-05-05T00:00:00Z

Если вам нужно отобразить картинку, которая изначально представлена в виде файла или блоба, не используйте для этого FileReader.readAsDataURL — он требует значительных ресурсов для чтения содержимого блоба и его конвертации в data URL, хоть это и происходит асинхронно и не блокирует основной поток.

Вместо него лучше применить синхронный URL.createObjectURL — он моментально сгенерирует и свяжет с блобом временный URL, который можно использовать как угодно, например, в качестве src для <img />. Генерация URL для блоба не требует чтения его содержимого, поэтому работает быстро и не расходует ресурсы (подробное описание алгоритма в спецификации).

Пока для блоба существуют временные URL, он не может быть удалён из памяти сборщиком мусора, поэтому по завершении использования URL не забудьте отвязать его от блоба с помощью вызова URL.revokeObjectURL.

Считаем время в JavaScript

2020-05-10T00:00:00Z

Во фронтенде встречаются задачи, требующие измерения времени: например, расчёт длительности загрузки какого-либо ресурса или расчёт прогресса анимации.

Велик соблазн использовать для расчёта Date.now:

const start = Date.now(); const result = await fetch('/data'); console.log('Elapsed time in milliseconds:', Date.now() - start);

Казалось бы, задача решена и можно отправляться пить кофе. Но есть нюанс: вычисленная таким способом длительность может оказаться отрицательной.

Что не так с Date.now?

Главные проблемы функции Date.now в контексте описанной задачи:

Date.now не монотонна, то есть она может как возрастать, так и убывать (это и приводит к получению отрицательных длительностей в вычислениях).
Она не гарантирует равномерность роста возвращаемых значений.

Корень этих проблем в том, что Date и его функции используют системные часы, которые подвержены внешним воздействиям:

системное время может быть изменено пользователем;
службы операционной системы регулярно синхронизируют время c точными часами через интернет, что может приводить к скачкам, если локальные часы сильно отстали или наоборот ушли вперёд.

Что использовать вместо Date.now?

В браузере

В спецификации High Resolution Time описана функция performance.now, которая не только решает озвученные проблемы, но и повышает точность измерений до микросекунд (в зависимости от браузера). Подробнее о ней можно прочитать в самой спецификации или на MDN.

В Node.js

Node.js предоставляет функции process.hrtime и process.hrtime.bigint, которые тоже не зависят от системных часов и повышают точность измерений до наносекунд.

Скачать или показать: заголовок Content-Disposition

2020-07-06T00:00:00Z

Открытие файла по прямой ссылке может привести либо к отображению файла прямо в браузере, либо к его скачиванию. Контролируется это поведение очень просто — HTTP-заголовком Content-Disposition в ответе сервера.

Если нужно отобразить файл прямо в браузере (если отображение не поддерживается, браузер скачает файл):

Content-Disposition: inline

Если нужно сразу скачивать файл (дополнительно можно указать имя файла в параметре filename):

Content-Disposition: attachment Content-Disposition: attachment; filename="kitten.jpg"

Будьте внимательны: если вы используете Content-Disposition: inline для видео, ваш сервер должен поддерживать HTTP-запросы с байтовыми диапазонами, иначе видео не будет воспроизводиться в Safari, а скачать его оттуда же не получится.

Неочевидная особенность регулярных выражений в JavaScript

2021-05-03T00:00:00Z

Когда одна и та же регулярка используется в нескольких местах, велик соблазн вынести её в отдельную переменную и избежать дублирования. Чтобы код после этого неожиданно не сломался, важно знать о неочевидной особенности регулярных выражений с флагом g в JavaScript.

Рассмотрим пример:

const digits = /\d+/; digits.test("123"); // -> true digits.test("456"); // -> true digits.test("789"); // -> true

Всё работает ожидаемо. А теперь добавим флаг g, с которым регулярка должна искать все совпадения:

const digits = /\d+/g; digits.test("123"); // -> true digits.test("456"); // -> false digits.test("789"); // -> true

Теперь проверка срабатывает через раз. Дело в том, что флаг g включает сохранение состояния поиска в поле lastIndex, регулярка становится stateful, а не stateless. При вызове методов test или exec поиск начинается с позиции lastIndex. При отсутствии совпадений lastIndex обнуляется, ~~как президентские сроки~~, а при обнаружении совпадения в lastIndex записывается позиция после совпадения.

Чтобы избежать этой проблемы, lastIndex можно перезаписывать вручную:

const digits = /\d+/g; digits.test("123"); // -> true digits.lastIndex = 0; digits.test("456"); // -> true digits.lastIndex = 0; digits.test("789"); // -> true

К сожалению, это не самое изящное решение, оно добавляет когнитивной нагрузки — нужно помнить о необходимости сброса индекса при каждом поиске. Можно намекать на природу регулярки префиксом stateful или global в названии переменной, чтобы при использовании не забывали обнулять lastIndex; можно писать и использовать собственные функции-обёртки, которые будут обнулять lastIndex при каждом вызове; а можно продолжать хардкодить регулярки в местах их использования — выбор за вами.

Почему стоит хранить зависимости в системе контроля версий

2022-01-16T00:00:00Z

Везде, где я раньше работал, было простое правило: не храните node_modules в системе контроля версий (в этой статье я буду для краткости называть её git).

Это правило выглядело разумным по нескольким причинам:

Код из node_modules не пишется командой.
Код из node_modules вызвал бы много шума в диффах git и пулреквестах.
Код из node_modules может быть легко воспроизведён через npm install.

Сейчас я работаю в Google в команде Chrome DevTools, и мы храним node_modules в системе контроля версий. Поначалу это показалось мне необычным, но со временем я обнаружил существенные преимущества такого подхода, которые, по моему мнению, достойны рассмотрения.

Нет нужды в `npm install`

Если вы храните node_modules в git, вам не нужно отдельно устанавливать зависимости, чтобы запустить проект. Это полезно не только для локальной разработки, но и для ботов на CI-платформах: они могут полностью пропустить шаг установки зависимостей. Я видел проекты, в которых установка зависимостей с нуля занимала 1–2 минуты — а в CI это могло быть ещё дольше. У вас легко может быть 50+ запусков ботов каждый день, если они запускаются на каждый пулреквест и деплой. Это большая экономия времени (и трафика!).

Гарантированно воспроизводимые сборки

Хранение node_modules в git гарантирует, что два разработчика запускают один и тот же код с одним и тем же набором зависимостей. Да, этого можно добиться, используя локфайлы или другие инструменты, однако я встречал случаи, когда они не спасали от изменения минорной версии какой-либо зависимости. Когда зависимости лежат в git, невозможно запустить проект с чем-то другим, каждый разработчик будет работать с одним и тем же кодом.

Лучшая осведомлённость о поставляемом коде

Я был удивлён тем, насколько я стал осведомлённее касательно зависимостей, когда стал видеть в диффе git весь код, попадающий в проект при их подключении. Это побудило нас поработать над инструментами, помогающими оценить влияние зависимостей на размер бандла и оптимизировать занимаемое на диске место.

Более вдумчивое добавление зависимостей, потому что они больше не скрыты

Я уже упоминал, что шум в диффах воспринимается людьми как недостаток хранения зависимостей в git, и я признаю, что это действительно может быть проблемой. Однако для меня этот шум оказался полезным знаком. Раньше я часто подключал новые зависимости, просто потому что не хотел сам писать несколько строчек кода. Теперь же я гораздо внимательнее отношусь к добавлению новых зависимостей, потому что я могу увидеть добавленный ими код и решить, стоит ли он того.

Примечание: это не означает, что у нас нет зависимостей! Бывают ситуации, когда подключить зависимость выгодно, но видимость кода в системе контроля версий сделала меня более осознанным — цена добавления зависимостей больше не скрыта.

C большими диффами можно справиться

Нельзя игнорировать тот факт, что добавление или обновление зависимостей может вызвать много шума в диффе. Одна из наших зависимостей — TypeScript, и каждое его обновление приносит огромный дифф в git, который, честно говоря, не стоит просмотра (за пределами CHANGELOG). Мы пришли к правилу, которое помогает в таких ситуациях: изменения в node_modules должны быть отделены от любых изменений в основной кодовой базе. Так что если я обновлю node_modules/typescript до свежей версии, наш инструментарий предупредит меня при обнаружении изменений за пределами node_modules.

Это правило помогает нам в большинстве случаев, потому что любая задача, требующая добавления или обновления зависимостей, может быть разделена на две части:

Обновление или добавление зависимости
Использование зависимости в коде

Иногда это не работает: например, обновление TypeScript может потребовать от нас исправления в коде ошибок, которые теперь обнаруживает новая версия TypeScript. В таких случаях мы отменяем правило.

Как и во всём, что касается программной инженерии, большинство «правил» — это рекомендации, которые мы можем при необходимости обойти.

Защита от очередного left_pad

Печально известный инцидент с left_pad (популярный npm-пакет был внезапно удалён, ломая сборки проектов по всему миру) не затронул бы команду, которая хранит зависимости в git. В долгосрочной перспективе команде всё ещё пришлось бы разбираться с вопросом «что теперь делать с более не поддерживаемой зависимостью», но в краткосрочной перспективе их сборки бы не сломались, а релизы бы не были заблокированы.

Выводы

Если бы я на этой неделе заводил новую кодовую базу или присоединялся к небольшому стартапу, только начинающему разработку, я бы настоял на хранении node_modules в системе контроля версий. Это определённо требует привыкания, но опыт применения этого подхода в течение последних двух лет убедил меня, что перечисленные выше преимущества существенно перевешивают дополнительный шум в git и небольшие накладные расходы.

Это перевод статьи Джека Франклина Why you should check-in your node dependencies. Переведено с разрешения автора.

За пределами NPM: выбираем зависимости с умом

2025-04-05T00:00:00Z

Немногие фронтенд-проекты обходятся без внешних зависимостей. Выбор зависимостей должен быть осознанным и вдумчивым процессом: неудачные решения могут привести к ухудшению UX и даже юридическим последствиям. В этой статье мы рассмотрим несколько инструментов, которые помогут вам с выбором зависимостей.

Поиск пакетов

Поиск пакетов на npmjs.com работает не лучшим образом. Например, поиск по запросам couchdb promise и couchdb promises выдаёт разные результаты.

Сервис npms стремится решить проблему поиска благодаря использованию продвинутых возможностей Elasticsearch и уникальной системе ранжированя пакетов.

Анализ зависимостей пакетов

Не лишним будет проверить транзитивные зависимости, которые попадут в ваш проект вместе с пакетом, который вы планируете использовать. Особенное внимание стоит обратить на:

лицензии, не подходящие вашему проекту
общее количество зависимостей и их мейнтейнеров (обычно чем больше зависимостей, тем хуже)

Для такого анализа есть два довольно похожих сервиса: npm.anvaka.com и npmgraph. Первый сервис генерирует более красивую визуализацию, а второй позволяет целиком загрузить ваш package.json, чтобы сразу проверить все уже добавленные пакеты.

Размер пакета на диске и в бандле

Наверняка вы видели мемы о размере node_modules. Будем честны: мем смешной, а ситуация страшная.

Когда речь заходит о размере пакета, есть два аспекта:

install size, размер установки: количество байтов, занимаемое пакетом на машине разработчика после установки
bundle size, размер бандла: количество байтов, занимаемое пакетом в конечном бандле приложения, который скачивается браузерами пользователей

Размер установки влияет на удобство разработки, время сборки и утилизацию ресурсов в CI. Размер бандла влияет в первую очередь на пользовательский опыт.

Через Packagephobia можно проверить размера установки пакета.

Через Bundlephobia и bundlejs можно проверить, как пакет повлияет на ваш бандл. Bundlephobia — первый инструмент подобного рода, без каких-либо особенных фич. Bundlejs — новый и гораздо более продвинутый инструмент, поддерживающий тришейкинг, сборку нескольких пакетов одновременно, и более тонкую настройку бандлинга.

Наконец, самый новый из всех сервис pkg-size позволяет сразу проверить и размер установки, и размер бандла для выбранного пакета.

Исследование содержимого пакета

Иногда может понадобиться заглянуть внутрь опубликованного пакета. Например, чтобы убедиться, что опубликованный код делает ровно то, что должен, и не включает ничего неожиданного и потенциально опасного.

Также иногда бывает полезно проверить разницу между двумя версиями пакета, чтобы убедиться в наличии нужного исправления бага (иногда ченджлоги врут) или провести аудит безопасности при обновлении зависимостей.

Сервис npmfs — подходящий для этих задач инструмент: он поддерживает просмотр содержимого пакета, сравнение версий пакета, ссылки на конкретные строки кода и диффы, а также скачивание любых файлов или целых директорий из пакета.

Просто посмотреть содержимое пакета также можно через сервис unpkg, но это не его основное предназначение.