Крошечные компоненты: что может пойти не так? Используем принцип единственной ответственности

[vintage]

То есть вместо одного простого компонента предлагается создать 10 тривиальных, но жёстко зависящих друг от друга? В отсутствии IoC, который в Реакт не завезли, это выливается в груды копипасты, когда в одном месте нужен Main с MobileSidebar, а в другом Main с BetaMobileSidebar.

[biziwalker]

Вы путаете принципы IoC с чем-то другим… с DI контейнерами?
В Реакте часто применяются приницпы инверсии контроля, когда например передаете в компонент функцию для обратного вызова в качестве пропса.

[vintage]

Не путаю. В Main зашит конкретный Layout, в котором зашит конкретный Sidebar, в котором зашит конкретный MobileSidebar, в котором наверняка ещё много чего так же зашито на 10 уровней вглубь. А когда пытаешься прикрутить к Реакту IoC, код превращается в адскую лапшу.

[gnaeus]

А в чем проблема, если мы будем внедрять компоненты-зависимости через props? Например:

const Layout = ({ Header, Sidebar, ...props }) => (
  <div>
    <Header />
    <Sidebar {...props} />
  </div>
);

А где-нибудь потом на этапе бутстрапа приложения:

Layout.defaultProps.Sidebar = isMobile() ? MobileSidebar : DesktopSidebar

Или, если надо в каком-то локальном поддереве компонентов:

const LayoutContainer = props => (
  <Layout Header={MyHeader} Sidebar={MySidebar} {...props} />
)

[vintage]

Это даёт переопределение лишь на один уровень. Если надо поменять что-то на 5 уровне — нужно скопипастить все промежуточные, добавив им переопределения.

[vintage]

Я не понял вопроса. В $mol точно так же создаются компоненты, которые используются внутри компонент следующего уровня. Разве что классы компонент достаются через контекст, через который их можно переопределять.

[gnaeus]

Тогда еще два вопроса:

• Что мешает и в React передавать компоненты через контекст?
• Можно какой-нибудь пример из реальной жизни, когда класс одного и того же компонента переопределяется по-разному в двух разных частях DOM-дерева? Я как-то сходу не могу придумать.

[vintage]

1. Бойлерплейта много. Поэтому так никто и не делает.
2. Например, компонент рендеринга маркдауна, который внутри себя создаёт параграфы, а нам надо, чтобы у каждого параграфа отображался его номер с пермалинком. Переопределили компонент параграфа и реализовали любую нужную нам логику, не зашивая её в компоненте рендеринга маркдауна.

[Druu]

А в чем проблема, если мы будем внедрять компоненты-зависимости через props? Например:

Но ведь в header тоже надо пропсы прокинуть. Откуда вы знаете, какие пропсы надо в header, а какие — в sidebar?

[Druu]

Мы назначаем эту функцию компоненту SidebarDisplay, который передает необходимые методы или состояние компонентам Header и Sidebar.

Руки надо отрывать за такое. Худшее, что позволяет сделать реакт — это подобные SidebarDisplay компоненты.