docs(thinking-in-react): Add "Single Responsibility Principle" expression.

Author: Nkzn

content/docs/thinking-in-react.md

@@ -35,7 +35,7 @@ React のすばらしい特長がいくつもありますが、あなたがど
 
 まず最初に行うのは、モックを形作っている各コンポーネント（構成要素）を四角で囲んで、それぞれに名前をつけていくことです。もしあなたがデザイナーと一緒に仕事をしている場合は、彼らがすでにこれに相当する作業を終えている可能性がありますので、話をしに行きましょう。彼らが Photoshop でレイヤ名にしていた名前が、最終的にはあなたの React コンポーネントの名前になりうるのです！
 
-しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。
+しかし、どうやってコンポーネントとして括るべき範囲を見つけられるのでしょうか。ちょうど、関数やオブジェクトをどのような責任範囲で作るのかを決めるときと、同じ手法が使えます。このような手法のひとつに、[単一責任の原則（Single Responsibility Principle）](https://en.wikipedia.org/wiki/Single_responsibility_principle)があり、これに沿って考えると、ひとつのコンポーネントはひとつのことだけができるべきである、という指針が得られます。将来、コンポーネントが肥大化してしまった場合には、小さなコンポーネントに分割するべきである、という話でもあります。
 
 皆さんがこれまで JSON で作ったデータモデルをユーザーに向けて表示してきた経験から、モデルを正しく構築できていれば、UI（つまりコンポーネントの構造）へのデータマッピングも上手くいくであろうことは想像に難くないでしょう。これは、UI とデータモデルが同じ **情報の構造** を持つ傾向があるためです。このおかげで、UI をコンポーネントに切り分ける作業は自明なものになりがちです。データモデルの 1 要素を表現するコンポーネントに、モックを分割して落とし込んでみましょう。