[ARCHIVED] Поговорим об импортах...

[azinit]

🔥 Не нужны нам ваши импорты!

Среди некоторых разработчиков все чаще встречаю заявления из разряда:

• "Уже несколько месяцев живу со свернутой шапкой импортов"
• "Никогда не читаю импорты. Студия их заботливо скрывает чтобы не мешали код читать. Неиспользуемые если есть - подскажет. Потому я не особенно понимаю зачем сортировать и ещё с этим возиться."
• "Не забочусь об импортах, автоматически подтягиваются"
• "А зачем сортировать импорты? А что это даёт? Ускоряет разработку, позволяет делать меньше багов?"

🔥 Но есть и другой лагерь

• "Есть особое эстетическое удовольствие, когда импорты расположены в нужном порядке"
• "Импорты часто вызывают холивары при ревью, и код-ревьюверы порой заваливают этим правки" - а потому их линтование и автоформатирование, помогает этого избежать
• "Автоимпорты подходят, только когда ты явно знаешь, что ты хочешь импортить (автокомплит же при ручном указании импортов - в этом помогает)"
• "Также, человек со скрытыми импортами - не видит внутренних ошибок линтера, например касаемо того - "какие модули можно импортить, а какие нет", и если мы завязываем глаза в этом моменте, то недалеко так дойти снова до импорта "кишков" фич, а не его Public API"
• "Плюс к предыдущему пункту - многие сущности могут называться одинаково в модулях (initialState, actions, selectors, effects, ...) - и где гарантии, что при автоимпорте заимпортиться именно то? Где в принципе гарантии, что автоимпорт будет работать нормально, если мы говорим про серьезное приложение, где "нельзя импортить все откуда угодно"?"
• "Чаще всего гораздо практичнее сразу писать импорты вручную, т.к. таким образом в том числе мы можем обнаружить Public API модулей более явно, особенно когда приходим в большой проект, в котором мало знаем что экспортиться (как вы будете импортить "не знаю-что"-"но знаю откуда" автокомплитом?)"

---

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

[azinit]

В каком вы лагере?

[azinit]

• Не вижу смысла вручную задавать импорты
• Уже давно не смотрю/не работаю с шапкой импортов
• Автоимпорты наше все

[azinit]

• Предпочитаю быть уверенным в том, что я импортирую
• Для меня бывает полезно, если работа с импортами линтуется и форматируется
• Не всегда/Никогда не доверяю автоимпортам

[azinit]

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

[azinit]

Возвращаясь к методологии, я вижу еще следующую проблему "нормально ли использовать всегда относительные импорты? Абсолютные нас спасут?"

[azinit]

Лично я стараюсь придерживаться следующего:

• использовать абсолютные импорты для основных и верхнеуровневых абстракций

  import { skinsModels } from "entities/skins"

  у нас ведь features/pages/processes/entities/shared/app - основные абстракции, и к ним должен быть всегда доступ "свыше" - т.е. привет абсолютные импорты

• использовать относительные импорты только для ресурсов - которые инкапсулированы ВНУТРИ текущей абстракции

  import { actions } from "../../../models"

Как по мне эта проблема коррелирует еще с "Public API" - #41

[Lonli-Lokli]

Мое мнение - если я лезу внутрь ('./') - это моя зона ответственности, если я лезу наружу ('../') - чужая.
ПС Брать чужое нехорошо

[Affiction]

@Lonli-Lokli

pages/
    /parent-route
        /child-route // models - store for current page
            /grand-child-route-1   // import { modelsFromChildRoute } from '../models';
            /grand-child-route-2   // import { modelsFromChildRoute } from '../models';
            /grand-child-route-3   // import { modelsFromChildRoute } from '../models';

В этом случае нормально лезть наружу

[ilyaagarkov]

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

[azinit]

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

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

Привет, import/order, sort-imports, eslint-plugin-boundaries

[azinit]

@zarabotaet приглашаю к дискуссии))

[zarabotaet]

Так выглядят файлы для меня 95% времени разработки

Вот так выглядит секция импортов

Иногда заглядывая делаю сворачиваю в неймспейс пачку импортов средствами vscode

Мой конфиг линта для сортировки и автоматического разбиения на группы импортов

[azinit]

@zarabotaet спасибо за ответ)

1. я пользуюсь полуавтоматическим автоимпортом

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

И то что ты привел - конечно ооооччч, было бы здорово, если бы показывало только Public API разрешенный, но скорее всего автокомплит показывает только "все возможные варианты", и среди них найти только Public API... Ну оке, допустим "засчитано" в данном пункте))

Хотя не особо вижу супер-профит писать полностью путь через автокомплит или же через импорты напрямую

[azinit]

2. Паблик апи любого модуля у меня выделен сразу (если у модуля есть экспортируемые не паблик сущности)

В любом случае новым ребятам в команде (или тем кто вернется к проекту позже) - придется "итеративно" путем уточнения импорта получать информацию о модулях, т.е. обычным автокомплитом будет сложно это сделать, т.к. тебе как правило надо "знать что именно должно экспортиться из модуля"

А кроме как "подбором импорта" и "залезания в кишки" - ты этого не узнаешь

И поскольку мы так топим против второго, то лучше уже "постепенно уточнять импорт", добираясь до Public API нужной вложенности

[azinit]

3. любые прекоммит хуки решают все разом для всей команды (я использую lefthook).

Ага, только человек узнает проблему "не сразу как она появилась", а только на этапе коммита/пуша

И например из-за этого он мог архитектуру построить по фиче совсем не тем путем, каким надо было
Потому своевременная подсветка варнингов в импортах - могла бы быть полезна, если бы "не сворачивали каждый раз шапку импортов" (разраб бы сразу увидел проблему при попытке "заимпортить что-то не то", а не гораздо позже)

[azinit]

(3) Если у тиммейта появляются вопросы почему что то откуда то нельзя импортировать то вся логика описана в соотвествующем файле md (LEGACY.md или ARCHITECTURE.md) или вики страничке

Так вот мы как раз и хотим убежать от того когда "нужно написать и прочесть кучу документации", чтобы понимать что происходит в проекте

Хотелось бы, чтобы у разраба появлялись объяснения сразу на этапе линтования (это не значит что он не должен читать доку, но значит - что он не обязан блин помнить все эти простыни текста про то какая у нас здоровская и заморочистая архитектура0

[azinit]

5. кастомный снипет сразу мне создает экспортируемый FC c импортом React и строкой стейта

Вот и цена плохо настроенной автоматизации)))

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