9.2. Export

❗Избегайте дефолтных экспортов или почему лучше использовать именованные экспорты

9.2.1. Обзорные статьи с аргументацией отказа от дефолтных импортом

9.2.2. Почему export default плохо

• У всех есть автоимпорт
• Переименование не гарантирует переименование импортов
• В целом, работа с именами дефолтных импортов - магия
• Возможность экспортировать анонимные функции
• Возможность указать любое имя при импорте значения
• В случае множественных импортов создается неконсистентность
• Многострочность
• Отсутствие строгости нейминга -> дубликаты имен

9.2.3. Почему именованные экспорты

• Гарантия корректности нейминга (TS)
• Унификация экспортов, отсутствие когнитивной нагрузки для принятия решения
• Лучшая читаемость, особенно при множественных экспортах (хотя это больше про export const foo vs export {foo}- для изменения значения не нужно скроллить туда-сюда, чтобы понять, экспортируется ли оно
• Public API
• Мы всегда можем увидеть, что экспортирует модуль без необходимости лезть внутрь
• Полная явность и открытость содержимого модуля
• Автокомплит
• Реэкспорты без алиасинга
• dynamic imports (кроме React.lazy/dynamic из некста)

9.2.4. Случаи когда export default нужно использовать

• Требования фреймворков/библиотек (например, страницы в NextJS)
• Финальные компоненты для lazy динамик импортов
• Библиотечный экспорт (те же реакт/лодаш)
• Специфичные потребители
• Конфиги/схемы/etc. в том случае, когда их будет потреблять сокрытая автоматика (webpack, next, tailwind, etc.)