WARNING

Эта статья сгенерирована AI и требует ручной доработки.

Производительность и FEOD

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

1. Разделение по страницам и модулям

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

// app/router.ts
const routes = [
  {
    path: '/reports',
    load: () => import('@/pages/reports')
  }
]

2. Тонкий Common уменьшает размер бандлов

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

3. Публичный API помогает tree-shaking

Экспортируйте только то, что реально используется. Чем меньше лишних экспортов в index.ts, тем проще сборщику отрезать неиспользуемый код.

// modules/Reports/index.ts
export { buildReport } from './api/buildReport'
export type { Report } from './types'

4. Изоляция модулей снижает связность

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

5. Избегайте "монолитных" модулей

Если один модуль включает всё подряд, это почти всегда приводит к росту объёма загрузки. В FEOD лучше дробить модуль на подмодули по доменным задачам.

modules/
  Analytics/
    modules/
      Events/
      Dashboards/

6. App остаётся лёгким

app должен содержать только запуск, роутинг и интеграции. Чем меньше логики в app, тем меньше кода попадает в критический путь загрузки.