Comments 13
Неплохой гайд для полного новичка. Но это всё уже было в Симпсонах. И на Хабре раз 10 в год точно.
Не раскрыто про порядок импортов. Почему плохо забить на этот порядок и почему важно соблюдать?
п.с. Сам на забитом отношусь к порядку этих самых импортов. Но во время ревью смотрю чтобы никто случайно не импортнул что-нибудь "не из того места"
Это надо, чтобы визуально отличать импорт внешних и внутренних зависимостей. Очень помогает при рефакторинге, когда надо перетащить в другую папку компонент, у которого штук 10 импортов, и нужно перебить все относительные пути.
Вообще, в целом визуальная составляющая кода очень важна. Поэтому все линтеры и проверяют всякие пробелы, отступы, двойные/одинарные кавычки и т.д. Когда код следует этим правилам, что глаз очень легко выцепляет всякие ошибки. Если же всё в кучу, то визуальный ритм сбивается и для ревью или отладки приходится внимательно перечитывать каждую строчку кода.
2-ой абзац согласен полностью.
Очень помогает при рефакторинге, когда надо перетащить в другую папку компонент, у которого штук 10 импортов, и нужно перебить все относительные пути.
Вроде уже все IDE помогает делать это автоматически
Это надо, чтобы визуально отличать импорт внешних и внутренних зависимостей
Как вы проводите черту между двумя этими типами? Пустой строкой?
Вроде уже все IDE помогает делать это автоматически
Вроде да, но почему-то срабатывает не всегда. Наверное, надо делать через Refactor - Move File, а не просто перетаскивать мышкой по дереву папок.
Как вы проводите черту между двумя этими типами? Пустой строкой?
Раньше использовал пустую строку, сейчас никак не отделяю.
сейчас никак не отделяю
я бы сказал, что это плохо, что вы так делаете. То есть смотрите, изначально аргументом было, что визуально просто определить. Вот приду я к вам на проект и визуально смогу определить только то, что это набор импортов и пока не прочитаю каждый - не пойму что откуда и куда, а потом еще останется проследить, что оказывается это два типа.
Клоню к тому, что если вы топите за то, чтобы отделять. То надо отделять каким-либо видимым(бросающимся в глаза) образом. Ведь визуально я сразу замечу условно "черту", что сразу вызовет вопросы. А вот если нет, ну вы поняли. На ревью только всплывет, что я намешал вам импортов
Обычно того факта, что глобальные в начале, а локальные в конце, достаточно. К слову, создатели eslint-config-airbnb, который я использую в своих проектах, придерживаются такой же точки зрения.
видимо зря я относился к этому "на забитом". Целая наука оказывается
Да, но в этой науке очень много вкусовщины. Например, можно написать свой правило eslint для пустой строки между глобальными и локальными импортами и использовать его. Скорее всего, уже кто-то его создал, просто надо установить соответствующий пакет. В разных организациях и в разных проектах могут использоваться разные правила. Но вообще, на мой взгляд, если речь идёт о чистом коде, то использование автоматизированных инструментов проверки качества кода, таких как eslint должно стоять на первом месте.
В том числе читаемость файлов повышается. Порядок импортов позволяет увидеть "позодрительные" вещи на ревью.
Да, многое IDE делают (тот же Webstorm), но это не всегда срабатывает и может быть не настроено. Статья рассчитана на новичков, поэтому надежда что они это применят:)
потому что мердж конфликты ресолвить... 10 удалено, 10 добавлено (в таком случае, кстати, проще всего взять лефт и райт и потом оптимизировать импорты), то же, кстати, относится к package.json.
по поводу "не из того места" я бы порекомендовал NX, даже если там одно приложение (пока что) –https://nx.dev/core-features/enforce-module-boundaries (заодно избавит от проблемы " и нужно перебить все относительные пути" из следующего комментария), алсо, NX имеет правило для линтера как раз для разделения глобальные/3rd party/локальные импорты.
Typescript — это типизируемый язык программирования, компилирующийся в Javascript.
Если уж занудствовать, то занудствовать: ts - это типизированное надмножество javascript, транслируемое в js.
Всегда было интересно, почему тип с большой буквы, а имя с маленькой?
Вот если задать любому человеку (необязательно программисту), что проще и привычнее читается
City new_york
или
city NewYork,
мне кажется большинство выберут второй вариант. Но в программировании почему-то большинство учат, что "правильно" писать первый вариант. Почему правильно-то? Почему имя нарицательное (тип) с большой буквы, а имя собственное (имя переменной) с маленькой? Не понимаю. Все естественные языки учат нас другому
После прочтения применить, или Чистый код на практике