[ARCHIVED] Обсуждение первого показа новой структуры команде

[azinit]

Итоги

• models => entities
• processes => controllers?
• models есть организмы?
• models - могут вызываться и не до фич
• graphql : queries.tsx (api) для использования в моделях/фичах и т.д.

  Но это для меня это и так было ясно на самом деле, что папка api вряд ли на таком уровне нужна будет =)
  

[azinit]

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

Но когда нам пригождается там шарить стейт?)

[azinit]

На стриме по-моему похожий пример обсуждали (где-то после середины вродь)

[azinit]

UPD: Обсудили вчера еще раз с @sergeysova и @karina-drummer ситуацию по features/.../models

@karina-drummer
Полагаю, что причина в том, что сущность может иметь не только shared state, но и компоненты. Модель — это только про данные, поэтому наличие компонентов в models/.../ может запутать

Скорее всего имелось в виду следующее:

• features/{foo} - конкретная фича (максимально близкая к бизнес-ценности, в зависимости от проекта и точки зрения его архитектора)
• enitites/{bar} - какая-либо сущность/модель из БЛ - которые помогают реализовать логику выше стоящим абстракциями (features, pages, ...)

А вот

• features/{foo}/models - это скорее некий store фичи (хотя ребята побьют меня за это определение, но пока я его трактую именно так)
  • Т.е. это именно некая средняя абстракция, которая помогает фича общаться событиями с внешним миром (т.е. его модель или для нас редуксоидов - store)

[azinit]

@ilyaagarkov если захочешь продолжить дискуссию "Что есть фича" - welcome :)

[akaia-shadowfox]

Я понимаю это так: у фичи в модели state, который нужен только этой фичи, сама фича первична. В случае с entities первичен сам state, к которому можно получить доступ из разных мест приложения. Components же в данном случае либо предоставляют этот доступ, либо позволяют взаимодействовать со state.

Вот теперь похоже понемножку начинаю понимать... Т.е. у нас стейт сущности (user) может жить отдельно от стейта фичи (user-...)?

Да, именно, если этот стэйт должен быть доступен за рамками фичи

[sergeysova]

Обсуждали вопрос на 1 созвоне комитета

[azinit]

Обычно под словом темплейт, я представляю что-то родственное с Layout

И скорее всего это просто какая-то разметка зон, в которые можно что-то вставить

Layout.Header, Layout.Aside, LayoutSidebar, Layout.Nav и т.д.

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

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

// src/pages/tasks/index.tsx
const TasksPage = () => {
  ...
  return (
      <Layout className="tasks-page">
          <Layout.Aside>
              <FeatureFirst ... />
          </Layout.Aside>
          <Layout.Main>
              <FeatureSecond ... />
          </Layout.Main>
          <Layout.Sidebar>
              {/* И даже так*/}
             <FeatureThird ...>
                 <FeatureFourth ... />
             </FeatureThird>
          </Layout.Sidebar>
      </Layout >
  )
}

Мб зря набрасываюсь, просто не понял прикол в entities хранить темплейты))

[sergeysova]

А если страниц пользователя гораздо больше, чем одна, но шаблон общий?

[azinit]

А если страниц пользователя гораздо больше, чем одна, но шаблон общий?

Т.е.:

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

Не значит ли разве все это вместе взятое, что наш шаблон страницы пользователя, уже не просто шаблон для пользователя? А какая-то конкретная версия шаблона, не относящаяся прямо к нему

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

[azinit]

И по итогу получится какой-нибудь DetailsLayout (условно)

Который и юзается в нескольких местах, и в том числе прямо не привязан к пользователю

Потому что с тем же накидом можно (как будто) сказать - а вот что если лэйаут для страниц пользователя используется еще для организаций? (ну вот так решили по дизайну, там схожие элементы: Основная часть, Список чего либо, Сайдбар и ...)

[sergeysova]

В этом и прикол, что шаблон пользователя позволяет сгруппировать схожие страницы с общим layout

[sergeysova]

Не значит ли разве все это вместе взятое, что наш шаблон страницы пользователя, уже не просто шаблон для пользователя? А какая-то конкретная версия шаблона, не относящаяся прямо к нему

И по итогу получится какой-нибудь DetailsLayout (условно)
Который и юзается в нескольких местах, и в том числе прямо не привязан к пользователю

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

В таких случаях не зазорно его положить в entities/user/template/*.tsx

[azinit]

@karina-drummer

templates у нас в app будут? 🤔
Просто не могу представить где их ещё хранить, если речь идёт не о темплейте, который нужен только конкретной странице

[azinit]

@Lehakos я обычно такие вещи так разруливал:

1. Раз хедер используется на всех страницах - либо я заявляю об этом на уровне pages (Сначала Header в разметке, и рядом Switch для роутов), либо на уровне app

   Оч зависит от того - должен ли иметь доступ хедер к роуту, и в целом - о чем должен знать хедер

   А также от того - может ли быть так, что на определенных страницах этого хедера все же не будет

2. Поскольку чаще всего выбирал app - то, обычно в src/app/ и располагал компонент хедера (т.к. другим абстракциям он не нужен просто)

Здесь пример как я раньше делал обычно - мб не самый лучший пример, но суть ясна

---

Но т.к. у наших товарищей (@sergeysova , @karina-drummer ) общий Layout может оччч сильно видоизменяться от странице к страницы - думаю они получше развернут (так понимаю - выше рассуждения про это как раз)

[azinit]

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

[ilyaagarkov]

Давайте попробуем поискать место для хедера.

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

processes - процесс навигации звучит неплохо, но проблемы те же самые что с app

pages - могут импортить любые фичи, но в pages у нас не отведено место под общие компоненты

featrues - фича навигация звучит почти не плохо(хотя уже и спорно), но фичи не должны импортить другие фичи

все что ниже не имеет смысла описывать, так как уровень ниже не могут импортить в себя фичи.

Я вижу два варианта,

1. мы размещаем каким-то образом это все в pages, тогда никакие границы нарушены не будут. И в целом пользователи хедера это только pages
2. мы делаем фичу навигации и нарушаем правило импорта фичи из фичи.

Мне ближе первый вариант

P.S. нужно подумать какие еще компоненты могут вызвать такие же проблемы. Помимо хедера могут быть еще сайд бары, как пример

[ilyaagarkov]

В дополнение к предыдущему

Класть навигацию в featrues, так же кажется не правильным, ведь фича это что-то что несет бизнес ценность, а когда у нас навигация предполагается в 100% проектах, разрабатываемых по feature-sliced, то можно сразу сказать что навигация это ни разу не про бизнес ценность, а значит ей не место в featrues

[azinit]

навигация это ни разу не про бизнес ценность, а значит ей не место в featrues

Согласен, поэтому обычно стараюсь резолвить навигацию/роутинг на уровне pages

Хотя как говорил @sergeysova - чаще всего не всегда так просто, и приходится резолвить на уровне тех же processes