日本語訳: Presentational and Container Components




Presentational and Container Components

There’s a simple pattern I find immensely useful when writing React applications. If you’ve been doing React for a while, you have probably already discovered it. This article explains it well, but I want to add a few more points.
You’ll find your components much easier to reuse and reason about if you divide them into two categories. I call them Container and Presentational components* but I also heard Fat and SkinnySmart and Dumb, Stateful and PureScreens and Components, etc. These all are not exactly the same, but the core idea is similar.

ご存知だと思いますが、コンポーネントをうまく再利用するためには、そしてうまく整理するためには、コンポーネントを2種類に切り分けると良いのです。その二つを私はContainer ComponentとPresentational Componentと名付けることにしました。ですが人によってはFatとSkinny、SmartとDumb、StatefulとPure、ScreensとComponentsと、様々な呼び方をしています。これらは全てが完全に同じものではありませんが、中心的な役割は同じです。

My presentational components:


  • Are concerned with how things look.
  • どのような見た目になるか、ということと関連づいている
  • May contain both presentational and container components** inside, and usually have some DOM markup and styles of their own.
  • PresentatinalコンポーネントとContainerコンポーネントの両方を内部に持つことができ、たいていの場合は自分自身のためのDOMマークアップとスタイルを持つ。
  • Often allow containment via this.props.children.
  • たいていの場合は、コンテンツをthis.props.childrenを用いて保持している。(訳注:公式参照 コンポーネントの<Component>ここ<Component>ここの部分入れらたものがthis.props.childrenで参照できる部分。通常、これは自動的にレンダリング時に参照され、内部で保持され、表示される。)
  • Have no dependencies on the rest of the app, such as Flux actions or stores.
  • アプリケーションの他の部分に対して依存している部分が一切ない。例えばFluxのactionやstoreに依存している部分がない。
  • Don’t specify how the data is loaded or mutated.
  • dataがどのようにロードされるか、もしくは変更されるか、といったことは定義しない。
  • Receive data and callbacks exclusively via props.
  • dataやコールバックは外部からprops経由で受け取る。
  • Rarely have their own state (when they do, it’s UI state rather than data).
  • 独自の状態を保つことは基本的にはない。(あるとすれば、UIの状態を持つ場合であってDateではない。)
  • Are written as functional components unless they need state, lifecycle hooks, or performance optimizations.
  • Functional コンポーネントとしてかかれる。状態やライフサイクルフック、パフォーマンス調整が必要とされない限りは。
  • Examples: Page, Sidebar, Story, UserInfo, List.
  • 例としては、Page, Sidebar, Story, UserInfo, Listなどがあげられる。

My container components:


  • Are concerned with how things work.
  • どのように機能するか、ということと結びついてる。
  • May contain both presentational and container components** inside but usually don’t have any DOM markup of their own except for some wrapping divs, and never have any styles.
  • PresentatinalコンポーネントとContainerコンポーネントの両方を内部に持つことができるが、たいていの場合は自分自身のためのDOMマークアップとスタイルを「持たない」。
  • Provide the data and behavior to presentational or other container components.
  • データと挙動を、Presentationalコンポーネントや、他のContainerコンポーネントに対して提供する。
  • Call Flux actions and provide these as callbacks to the presentational components.
  • Fluxのアクションをcallしたり、アクションをコールバックとしてPresentatinalコンポーネンへ提供する。
  • Are often stateful, as they tend to serve as data sources.
  • たいていの場合は状態を持ち、データの源としての役割を担う。
  • Are usually generated using higher order components such as connect()from React Redux, createContainer() from Relay, or Container.create() from Flux Utils, rather than written by hand.
  • higher order componentを用いることで生成される。例えばReact Reduxのconnect()やRelayのcreateContainer()やFlux UtilsのContainerCreate()である。
  • Examples: UserPage, FollowersSidebar, StoryContainer, FollowedUserList.

I put them in different folders to make this distinction clear.


(訳注:ということは、Reduxのconnect()を使う層は、基本的にContainer Component。connectはなぜ使うかといえば、state,reducer,actionとpresentationalコンポーネントを、Containerコンポーネント内で結びつけるため。presentationalコンポーネントとactionをロードして、connectでstate,dispatchと結びつける。するとpresentationalコンポーネントにstate,dispatchが渡されるので、presentationalコンポーネントがそれを使えるようになる。connectで結びつけて作った新しい高次階層コンポーネントをexportし、これを他のコンポーネントから呼び出して使う。)

Benefits of This Approach


  • Better separation of concerns. You understand your app and your UI better by writing components this way.
  • 役割の分割をうまくできる。コンポーネントをこう書くことで、アプリケーションとUIがどうなっているのか、より理解しやすくなる。
  • Better reusability. You can use the same presentational component with completely different state sources, and turn those into separate container components that can be further reused.
  • 使い回しが効く。Presentationalコンポーネントを全く異なるStateを持つ状況において使用することができる。また異なるContainerコンポーネントの中で使用することができる。
  • Presentational components are essentially your app’s “palette”. You can put them on a single page and let the designer tweak all their variations without touching the app’s logic. You can run screenshot regression tests on that page.
  • Presentatinalコンポーネントは、本質的にはアプリケーションの「パレット」である。ページのどこにでも配置することができ、デザイナーがアプリのロジックに触ることなく変更することができる。
  • This forces you to extract “layout components” such as Sidebar, Page, ContextMenu and use this.props.children instead of duplicating the same markup and layout in several container components.
  • こうすることで「layout Component」を強制的に取り除くことになるので、同じマークアップやレイアウトを様々なContainerコンポーネントになんども複製する必要がなくなる。this.props.childrenを使えばいい。

Remember, components don’t have to emit DOM. They only need to provide composition boundaries between UI concerns.


Take advantage of that.


When to Introduce Containers?

I suggest you to start building your app with just presentational components first. Eventually you’ll realize that you are passing too many props down the intermediate components. When you notice that some components don’t use the props they receive but merely forward them down and you have to rewire all those intermediate components any time the children need more data, it’s a good time to introduce some container components. This way you can get the data and the behavior props to the leaf components without burdening the unrelated components in the middle of the tree.


This is an ongoing process of refactoring so don’t try to get it right the first time. As you experiment with this pattern, you will develop an intuitive sense for when it’s time to extract some containers, just like you know when it’s time to extract a function. My free Redux Egghead series might help you with that too!

これはリファクタリンの際に継続的におこなうことなので、最初から行う必要はありません。このパターンで書く際に経験していることだと思いますが、いつコンテイナーを導入するのかということを感じ取るセンスを育む必要があります。これはちょうど、どの段階でFunctionにまとめるべきなのかを判断するセンスと似ています。 free Redux Egghead series も参考になるはず!


Other Dichotomies

It’s important that you understand that the distinction between the presentational components and the containers is not a technical one. Rather, it is a distinction in their purpose.


By contrast, here are a few related (but different!) technical distinctions:

  • Stateful and Stateless. Some components use React setState() method and some don’t. While container components tend to be stateful and presentational components tend to be stateless, this is not a hard rule. Presentational components can be stateful, and containers can be stateless too.
  • Stateful and Stateless.  ReactのsetState()を使うコンポーネントもあれば、使わないコンポーネントもあります。ContainerコンポーネントはStateを持つ傾向にあり、Presentationalコンポーネントがstateを持たない傾向にありますが、とはいえこれは厳密なルールではありません。Presentationalコンポーネントがstateを持つこともありますし、ContainerコンポーネントがStateを持たないこともあります。
  • Classes and Functions. Since React 0.14, components can be declared both as classes and as functions. Functional components are simpler to define but they lack certain features currently available only to class components. Some of these restrictions may go away in the future but they exist today. Because functional components are easier to understand, I suggest you to use them unless you need state, lifecycle hooks, or performance optimizations, which are only available to the class components at this time.
  • Classes and Functions. React 0.14から、コンポーネントはクラスとしてもファンクションとしても宣言できるようになりました。ファンクショナルコンポーネントは宣言がよりシンプルですが、クラスコンポーネントにしかない機能を持っていません。そういった制限が将来撤廃されるかもしれませんが、今のところは存在します。ファンクショナルコンポーネントは把握するのが簡単ですので、ステイト/ライフサイクルフック/パフォーマンスの調整といったクラスコンポーネントだけにしかない機能が必要でない場合には、ファンクショナルコンポーネントを使うことを推奨します。
  • Pure and Impure. People say that a component is pure if it is guaranteed to return the same result given the same props and state. Pure components can be defined both as classes and functions, and can be both stateful and stateless. Another important aspect of pure components is that they don’t rely on deep mutations in props or state, so their rendering performance can be optimized by a shallow comparison in their shouldComponentUpdate() hook. Currently only classes can define shouldComponentUpdate() but that may change in the future.
  • Pure and Impure. コンポーネントのうち、同じpropsと状態を与えれば、同じ結果を返すものを、Pureコンポーネント、と言ったりします。ピュアコンポーネントは、クラスでもファンクションでもどちらでも定義することができます。またステイトを持つことも持たないこともできます。(残りの部分わからず)

Both presentational components and containers can fall into either of those buckets. In my experience, presentational components tend to be stateless pure functions, and containers tend to be stateful pure classes. However this is not a rule but an observation, and I’ve seen the exact opposite cases that made sense in specific circumstances.


Don’t take the presentational and container component separation as a dogma. Sometimes it doesn’t matter or it’s hard to draw the line. If you feel unsure about whether a specific component should be presentational or a container, it might be too early to decide. Don’t sweat it!



This gist by Michael Chan pretty much nails it.

Further Reading



React そのものは次の記事も参照。(React 公式よりももっと低レベルなところから始める、React チュートリアル, React チュートリアル 日本語翻訳) React は State を元にバーチャルDOMを作成し、バーチャルDOMを元にDOMを生成するシステムを担うライブラリ。state の更新があった場合、その差分だけを DOM に反映することができ、パフォーマンスが良い。つまり、PC への負担が少ない。React を用いる利点のうち、一番大きなものは、状態 state と view 実際の見た目をどうするか、という「二つの問題を完全に切り分ける」ことができる。つまり、state をどう変化させるか、という問題と、state を DOMにどう反映させれるか、の2つを完全に切り分けて実装できる。

React Component

React はコンポーネントと呼ばれる最小単位を、積み重ねることでバーチャルDOM全体の構成を行う。具体的には、HTMLに直接紐付けられたトップのコンポーネントの中に、さらにコンポーネントを配置し、またさらにその下にコンポーネントを配置していくことができる。入れ子状に。(マトリョーシカのように一つのコンポーネントの中に、一つのコンポーネントしか配置できないわけではない。ある階層のコンポーネントには、複数の下位コンポーネントを配置することができる。)

state を持つコンポーネントと持たないコンポーネント

React コンポーネントは、コンポーネント自身が状態 state を持つものと(一般的にES6のクラス構文で書かれ、extended React.componentし、コンストラクタ内でsuper(props)によってReact.componentを継承し、this.stateに状態をオブジェクトとして持たせる / 公式ref  もしくはこれ 参照)ともたない functional component がある。

持つコンポーネントの場合、stateはprivateであり、つまり状態はコンポーネントの外からアクセスできない。アクセスできるようにするためには、react の機能だけで実装する場合には、stateを下位のコンポーネントへpropsとして渡す方法がある。(反対に上位のコンポーネントに渡すことも原理的には可能だが、上下二方向にデータが流れると設計が破綻することが多く、そのため基本的には下位コンポーネントへstateを流していく。)

原理的にはすべてのコンポーネントにstateを持たせることができるが、reduxと連携する場合には、stateはすべてreduxによって管理するため、コンポーネントにstateを持たせず、すべてのコンポーネントをfunctional componentで書く。(ただし、UI用のstateを持たせることはある)

state の更新と取得

stateの更新は、this.state.setState(オブジェクト)によって行われ、その際に新しいstate用のオブジェクトを与えれば良い。stateの取得は、this.state.value によって可能である


Redux 公式ドキュメント 日本語に一部翻訳

Redux は state 管理のためのライブラリで、必ずしもReactと連携する必要はなく、単体で動作するが(公式チュートリアル参照)、React と共に用いられることが多いのは事実である。ここでは基本的にReactと連携することを前提に進める。また、当然だが React の状態管理は必ずしもReduxを用いる必要はなく、前述したreactコンポーネントのstateを用いることが第一の方法である。

Redux によって、React を用いたアプリケーションの状態を管理させる第一の利点は、データフローの設計と構造のベストプラクティスのうちの一つを、同時に取り込むことができる点にある。つまりどのようにstateを更新するのかという仕組みと、それを実装するための手段を、Reduxによって同時に取り込むことができる。Redux は具体的には、stateを1つの単なるオブジェクトで管理し、その更新にはreducerというこれまた単なる関数を用いる。Reducer ファンクションに対して二つの引数、現在の状態と、その変更に必要なパラメーターをactionを渡し、その二つの引数を元に更新されたstateを生成し、これをreturnする。

returnしたstateがどのように、更新されるか。それはstore = createStore(reducer)によってreducerを紐付けて、state管理用のstoreという変数を作ることからはじまる。これによって、reducerのreturnしたstateが、storeに返され、stateが更新される。

Redux と Flux の関係

Reduxは、stateの管理とその更新のシステムを書く方法を、単一に定義している。そのシステムは基本的にFluxに従っている。Fluxは状態管理の設計思想である。そのためライブラリではない。(ただしfluxというそのためのライブラリもある) つまりFluxが概念としては一番大きいもので、ReduxはFluxに基づいた実装のための方法の一つを担うライブラリである。

Redux は、そのシステムに則って書けば、結果的にFluxになるので、初学者にはむしろ易しい。Reduxを書くことによって、Fluxの概念を理解することが容易になるのではないか。またReduxは公式チュートリアルが非常に丁寧であり、その点もFluxを理解するためによい。





import { createStore } from 'redux';


let store = createStore(counter);




import { Provider } from 'react-redux';

コンポーネントの最上部にstoreをProviderによって紐付ける。ここではTestコンポーネント以下にstoreを紐付けるために、TestコンポーネントをProviderでラップした上で、それにstore={ store } というpropsを与えることで実現している。

const AppRoot = () => (
    <Provider store={ store }>
        <Test />




import { connect } from 'react-redux';


const Test = ({dispatch, num}) => (
        <button onClick={()=>{dispatch({ type: 'INCREMENT' })}}>+</button>
        <button onClick={()=>{dispatch({ type: 'DECREMENT' })}}>-</button>


Testコンポーネントをexport defaultで書き出す際に、connect(関連づけるstate)(関連づけるTestコンポーネント)という記述で、conncetされたTestコンポーネントを書き出している。

function mapStateToProps(state) {
    return { num: state }

export default connect(mapStateToProps)(Test)


const Test = ({dispatch, num}) => (
        <button onClick={()=>{dispatch({ type: 'INCREMENT' })}}>+</button>
        <button onClick={()=>{dispatch({ type: 'DECREMENT' })}}>-</button>


  1. createStoreでstoreを作る。storeでstateを管理する。createStoreをする際に、reducerを紐付ける。reducerはstateの更新を担当するもの。storeにreducerが紐付いているので、store.dispatch({action:content})でstateを変更できる。
  2. providerを用いてreactコンポーネントの階層の一番上にstoreをprospsとして渡すことで、その下の階層でconnectを使うことができる。そのためにはreactコンポーネント階層の一番上のコンポーネントをProviderコンポーネントでラップし、Providerコンポーネントに、storeという名前で{ store }  を渡す。
  3. Providerコンポーネントによって渡されたstoreを、様々な階層の位置にあるコンポーネントから参照するためにはconnect()を用いる。コンポーネントを出力するexport defalut 以降に export defalut connect(propsを紐付ける中間関数)(紐付けるコンポーネント)とする。propsを紐付ける中間関数は、storeに保持されているstateのうち、必要なものだけを選んで使用するためのもの。

reducer や action の効率的な取りまとめ




state = {counter:0,text:”text”}

そのためには、reducersフォルダの中にindex.jsを作り、ここで全てのreducerをimportし、それをcombineReducerでまとめる。そしてこれをimport reducer from ‘./reducers’として、reducerをcreateStore(reducer)で紐付ける。


// reducers/index.js
import counter from './counter'
import text from './text'

 import { combineReducers } from 'redux'

const main = combineReducers({

export default main;

//{counter: 内容, text:内容}というオブジェクトになる。


import React from 'react';
import { createStore } from 'redux';
import { Provider } from 'react-redux';
import Test from './Test';
import reducer from './reducers';

//redux の createStore で Reducer と結びつける
const store = createStore(reducer);

const AppRoot = () =&gt; (
    &lt;Provider store={ store }&gt;
        &lt;Test /&gt;

store.subscribe(() =&gt;

export default AppRoot;

Actionを作成するaction creator

一つの方法として、actionsディレクトリ内にindex.jsというファイルを作り、その中でAction Creatorを作成し、作成したものをexportしておく。それをContainer層で読み込み、 同様にContainer層で読み込まれたComponentと結びつけるために、mapDispatchToProps内dispatchを呼び出す際に使用する。

疑問 ToDoListというcomponentを引っ張ってきて、Container層で各種要素をconnectしたものをVisualTodoListとしてexportしている。



Redux video チュートリアル










26 Redux: storeをReact Redux の<provider>を用いて下層へと渡していく

Redux: Passing the Store Down with <Provider> from React Redux


In the previous session, we implemented the provider component that uses the react advanced context feature to make this tool from the props available to every component in our rev.

一つ前のレッスンにおいて、私たちは provider コンポーネントを実装しました。これは react の アドヴァンスドな contect 機能を用いて、props をどのコンポーネントからも利用できるようにするものでした。

If we pass it through the provider, we can read it in any other component from the context, which is really convenient for the container components. In fact, this is so convenient that you don’t need to actually write the provider yourself, because it is included in a special library called React-Redux.

provider を通して値を渡すことで、どのコンポーネントからも context を通じて値を取得できるので、コンテナーコンポーネントにとってこれは非常に便利なことです。でも実は、 provider を自分自身で書く必要もありません。React-Redux という別のライブラリーにこの機能があるからです。

Note that it is not the same as Redux. This is a different library. These are react bindings to the Redux library. You can import the provider by destructuring the react-redux global object in JS bin, or if you use Babel, and something like NPM, you can import provider with the braces, because it’s a named expert from React-Redux package. Or if you write ES5 code, you can write var provider equals require react redux, or react redux global.provider.

注意して欲しいのですが、これは Redux とは別のライブラリーです。React-Redux は react とRedux をつなぐ効能を提供します。これを使うためには react-react global object を分解して provider を import するか(const Provider = ReactRedux;)、もしくは Babel と npm などを使っているのであれば、provider を{} を使ってインポートしましょう。(import {Provider} = ‘react-redux’;) このようにかけるのは、React-Redux の中でそのように名前が定義されているからです。さらに他の方法としてES5で書いているのであれば、var Provider = require(‘react-redux’).Provider; とします。

Just like the provider we wrote before, the provider that comes with react-redux exposes this store you passed through. There’s a prop on the context so the components can specify the context types, and then use this context store to subscribe to the store updates and dispatch actions.

前のレッスンで我々が書いた providerと同じように、react-redux によって提供される provider も redux の store を露出させます。(わからない。おそらく前のレッスンでcontext等を理解する必要がある。⇨) There’s a prop on the context so the components can specify the context types, and then use this context store to subscribe to the store updates and dispatch actions. とにかく結論としては、store のアップデートとディスパッチをreactに紐付ける。その際に context が関係してくる。

27 Redux: React-Reduxのconnect()を用いたコンテナを生成する

Redux: Generating Containers with connect() from React Redux (VisibleTodoList)

In the previous lesson, I added React Redux bindings to the project and I used a provider component from React Redux to pass this chore down the context so that the container components can re-dischore from the context and subscribe to these changes. All container components are very similar.

ここまでのレッスンにおいて、React Redux の bindings をプロジェクトに加えたので、

They need to re-render when the store state changes, they need to unsubscribe from the straw when they amount and they take the current state of the Redux store and use it to render the presentational components with some props that they calculate from the state of this chore, and they also need to specify the context stripes to get this chore from the context.


I’m going to write this component in a different way now. I’ll declare a function called “MapsStateToProps” which takes the redux store state and returns the props that I need to parse through the presentation to do this component, to render it with the current state.

ですが今回は少し違った方法でコンポーネントを書いていきます。まずは MapsStateToProps という名前の関数を宣言します。これはredux の state を受け取ってprops を return するためのものです。そしてこの props は presantation で分解されコンポーネントへ渡され、現在の状態によってレンダーされます。

In this case, there is a single prop called ToDo. I copy-paste this expression to the MapStateToProps function. It returns the props that depend on the current state of the redux store. In this case, this is just the ToDo list prop.

components/TodoList.jsx の TodoListというコンポーネントはToDOという名前のpropだけを用いていますね。これをコピペして、MapStateToPropsに加えます。そうすることで 現在のredux storeの状態に基づいたpropsを返し、Todoという名前で使うことができるようになります。(ただしの後の作業、connect()を行った後に。)

const mapStateToProps = (
) => {
  return {
    todos: getVisibleTodos(

I’m creating another function that a core map dispatched the props. It accepts the dispatch method from this chore as the only argument and returns the props that should be parsed through the list component and that depend on the dispatch method.

The only prop that uses chore dispatch is called OnToDo click. Some copy-paste onto the click, into map dispatch the props. Now that I don’t have the reference to this chore here anymore. Instead, I’m changing it to use the dispatch, which is provided as an argument to map dispatch the props.

I will add some punctuation to make it appear easier on my eyes. OnToDo click ease of function that accepts the ID of the ToDo, and dispatches an action. Now, I’ve got two different functions.

The first one maps the redux chore state to the props of the ToDo list component that are related to the data from the redux chore. The second function maps the dispatch method of this chore to the callback props of ToDo list component. It specifies the behavior which callback prop dispatches which action.

To gather this, your function has described a container component so well that instead of writing it, I can generate it by using the connect function provided by react redux library. If you use Babble and NPM, you will likely input it like this instead. Don’t forget the curly braces.

Now, instead of declaring a class, I’m going to declare a variable. I will call the connect method to obtain it. I’m parsing MapsStateToProp as the first argument and MapDispatchTheProps as the second argument. Notice that this is a correct function, so I have to call it once again. This time, I parse the presentational component that I wanted to wrap and parse the props to you.

The connect function will generate the component, just like the one I previously wrote by hand. I don’t need to write the code to subscribe to this chore or to specify the context stripes, because the connect function takes care of that.

Now, let’s recap how to generate the container component using the connect function. First, I’ll write a function called MapStateToProps that takes the state of the redux chore and returns the props for the presentational component calculated from it.

These props will be updated anytime the state changes. Next, I write a function that I call MapDispatchTheProps. It takes these chores dispatch method as its first argument. It returns the props that used the dispatch method to dispatch options, so it returns the callback props needed for the presentational component.

To create the container component from them, I import connect from the react redux library and I call it parsing MapsStateToProps as the first argument and will dispatch the props as a second argument.

Finally, I close the function called Param and I open another param, because this is a parent function and it needs to be called twice. The last argument is the presentational component that I want to connect to the redux chore.

The result of the connect call is the container component that is going to render my presentational component. It will calculate the props to pass through the presentational component by merging the objects returned from MapStateToProps, map dispatched to props, and its own props.




クリッピングマスクは一旦解除する。グループを選んで、alt + cmd + 7






img で文字やロゴを作成し、

.image {
  display: block;
  margin: 10px auto; //これは縦に並んだ要素の間隔調整用
  padding: 0 3px 5px; //ここで文字と線の間隔を調整
  border-bottom: solid 1px transparent; 線が出た時に高さが変わらないように

  &:hover {
    border-bottom: solid 1px $colorBlack; 


imageをinline-blockにして、そのうえのaはそのまま、そのさらに上のlist要素にtext alighn centerを実施


.target {
  &::after {
    content: "";
    display: block;
    margin: 25px auto 0;
    border-bottom: 1px solid $colorBlack;
    width: 140px;