Делал перевод статьи The land of undocumented react.js: The Context, где сослался на статью Dan Abramov про умные и глупые компоненты, но почему-то думал что она есть на habrahabr. Думаю эта небольшая статья ни для кого лишней не будет.
Перевод статьи Smart and Dumb Components

Есть простой шаблон, который я нахожу чрезвычайно полезным, когда пишу приложения на React. Если Вы работали с React какое-то время, то, вероятно Вы уже поняли это. Это хорошо объяснено в этой статье, но я хочу добавить пару пунктов.

Вы найдете, что Ваши компоненты намного проще в реиспользовании и обсуждении, если Вы поделите их на две категории. Я называю их Умные (Smart) и Глупые (Dumb), но я так же слышал Fat и Skinny, Stateful и Pure, Screens и Components и так далее. Все это не абсолютно тоже самое но идея похожа.

Мои глупые компоненты:

1. не зависят от остальной части приложения, например Flux actions или stores
2. часто содержатся в this.props.children
3. получают данные и колбэки исключительно через props
4. имеют свой css файл
5. изредка имеют свой state
6. могут использовать другие глупые компоненты
7. примеры: Page, Sidebar, Story, UserInfo, List

Мои умные компоненты:

1. оборачивает один или несколько глупых или умных компонентов
2. хранит состояние стора и пробрасывает его как объекты в глупые компоненты
3. вызывает Flux actions и обеспечивает ими глупые компоненты в виде колбэков
4. никогда не имеют собственных стилей
5. редко сами выдают DOM, используйте глупые компоненты для макета
6. примеры: UserPage, FollowersSidebar, StoryContainer, FollowedUserList

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

Профит от такого подхода

1. Лучшее разделение ответственности. Вы понимаете Ваше приложение и Ваш UI лучше, если пишете компоненты таким способом.
2. Лучшая реюзабельность. Вы можете использовать один и тот же глупый компонент с абсолютно разными источниками состояния.
3. Глупые компоненты — это фактически «палитра» Вашего приложения, Вы можете поместить их все на одну страницу и дать дизайнеру их настроить, на залезая в логику приложения. Вы можете запустить регрессивное тестирование на такой странице.
4. Это заставляет Вас извлекать «компоненты макеты», такие как Sidebar, Page, ContextMenu и использовать this.props.children вместо дублирования одной и той же верстки в различных умных компонентах.

Помните, компоненты не должны выдавать DOM. Они должны только обеспечить границы между UI.