JSといえばjQueryだったWebデザイナーが、Reactを1年間使って感じたメリット

ほそだ

2016.01.20

JSといえばjQueryだったWebデザイナーが、Reactを1年間使って思ったこと

ENGINEERING

はじめまして、ほそだと申します。昨年秋まで個人事業主の立場でドワンゴでお仕事させていただいておりましたが、いろいろ経緯がありまして中の人になりました。ドワンゴ歴はそこそこ長い新入りです。よろしくお願いいたします。

さて、今回はデザイナー（HTML/CSS/JSは扱えるいわゆる「Webデザイナー」）として1年間ほどReactを使ってみたので、そのメリットを書いてみようかと思います。

Reactとの出会い

ReactとはFacebook製のJSライブラリです。
https://facebook.github.io/react/

WebアプリケーションのView部分を実装します。2014年の暮れにエンジニアの方々が魂を震わせているのを見て存在を知りました。2015年はReact元年な感じでしたよね。

僕自身、以前から比較的JSを書くタイプのデザイナーではありましたが、正直なところ自分が関わってきたタイプの案件ではjQueryが使えていれば不自由しなかったので、BackboneやらAngularといったJSフレームワークが出てきた時も、自分とは関係ないエンジニア向けの話だと思って横目で見ながらスルーしていました。なのでほとんど、

JavaScript = jQuery

であったと言えます。非エンジニアでいつの間にかJSを書くようになったタイプ（元々HTML/CSSを書いていて、その延長でJSに来たタイプ）の方々には割と多いのではないでしょうか。まずは$からが当たり前になっていました。

ですがドワンゴで現在まで関わっている直近のプロジェクトにおいて、いつまでもjQuery前提でJSを考えてたら痛い目見るぞということを思い知らされまして、ちょうど1年くらい前に、どうも流行ってるらしいReactを通して、麗しきデータバインディングの世界に足を踏み入れることになりました。

そもそもデータバインディングって？

Reactの話をする前にデータバインディングについてさくっと触れておきます。

jQueryは基本的にDOMを直接操作していくような実装をしますよね。それに対してデータバインディングでは、DOMがデータ（モデル）に紐付けられていて、データが更新されるとそれに同期してDOMも更新されます。

イメージ的にはこんな感じです。

APIとデータをやりとりしてその結果をUIに反映させるような一般的なWebアプリケーションの場合、いちいち取得したデータを元に直接DOMを操作するのは面倒です。なので予めルールを決めておいて、データが更新されたらそのルールに応じて自動的にDOMが更新されるといった仕組みのほうが賢いわけですね。それまではjQueryで.detach()して.clone()して.text()して.appendTo()みたいなことを、データを受け取るたびにやってました。

デザイナーに関わるReactの特長

React全般の解説はエンジニアの方々の優れた記事がたくさんありますのでそちらに委ねるとして、デザイナー側で抑えておくべき特長は以下の2つかなと思っています。

コンポーネント指向

Reactでは、UIをコンポーネントの組み合わせで構築していきます。

各コンポーネントは親コンポーネントから受け継いだprop(s)と、自身の状態としてのstateを持っていて、それらの値をテンプレートに渡して画面を描画します。

propとかstateとかいきなり新しい用語が出てきましたが、「渡された値を使って動的にHTMLを生成する」という部分だけ見れば、従来のHTMLテンプレートでやってきたことと同じですね。

実際にはコンポーネントはテンプレートまわりだけではなく、イベントを感知して自身のstateや親のpropを更新するメソッドを持っていたりするのですが、少なくともテンプレート部分に絞ればそんなに敷居は高くないのではないかという印象です。

JSX

そんなReactのテンプレート部分ですが、コンポーネントのJSファイルのrenderメソッドにJSXという記法で記述します。

var MyComponent = React.createClass({
  render : function() {
    return (
      <div className="user">
        <h1>{this.props.username}</h1>
        <p>{this.props.description}</p>
      </div>
    );
  }
});

JSである都合上、予約語であるclassやforといった属性がclassNameやhtmlForになっていたりはしますが、ほとんどHTMLです。JSの中にHTMLを書くのが気持ち悪いという向きもありますが、個人的にはわかりやすかったですね。

子コンポーネントは独自タグのような感じで挿入できます。親側から属性でpropやstateを渡して、子はそれらをprop(s)として受け取ります。

var ChildComponent = React.createClass({
  render : function() {
    return (
      <div className="child">
        <h2>{this.props.name}</h2>
        <p>{this.props.age}</p>
      </div>
    );
  }
});

var ParentComponent = React.createClass({
  render : function() {
    return (
      <div className="parent">
        <ChildComponent name="Taro" age="10" />
        <ChildComponent name="Jiro" age="7" />
      </div>
    );
  }
});

だいぶ単純化して紹介しているので、これだけで「簡単でしょ？」とはとても言えないのですが、逆にデザイナーが全く触れない感じでもなさそうな気がしませんか？

ちなみにJSXの代わりにjadeでも書けるっぽいです。

どこまでデザイナーが関わるか

Reactが良いなと思っているのは、デザイナー側のJS力に応じて関わり方に段階を踏めそうだからです。

コンポーネントのテンプレート部分だけ触る

上記の通り、これに関してはそんなに難しくないのではないかと思っています。テンプレート部分（renderメソッド）だけ別ファイルに切り出せば、見える範囲はちょっと記法が変わったHTMLテンプレートというだけです。

JS的にはmapで配列を回すとか、if-elseの代わりに論理演算子／三項演算子を使うといったあたりが理解できていればひとまず良さそうです。

2. コンポーネントをひと通り触る

実際にはAPI等から渡されるデータとは別に、描画の切り替えだけに使いたい値があったりするので（要素を開閉するためのフラグなど）、そういうのはデザイナー側で扱いたいですよね。となるとテンプレート以外にもコンポーネントにメソッドを加えたりということが必要になってきます。

とはいえ、最初のうちは1.の延長線でコンポーネントのベースをエンジニアさんに用意していただいて、そこに加えていく感じでよいと思います。慣れてきてpropやstateの概念が理解できてきたら、親コンポーネントとの値のやり取りや、複雑になっている箇所を子コンポーネントに切り出すといったこともできるようになります。

3. Routerまわりも触る

URLとコンポーネントを紐付けます。react-routerというのを使うのがデファクトっぽいです。このあたりからは全体的な設計とも関わるので、エンジニアさんと相談して役割分担を決めた方が良さそうです。

もしデザイナー主導である程度動くプロトタイプを作っちゃいたいなんて時は扱えてた方が良いですね。

4. Fluxまわりも触る

FluxというのはFacebookが提唱したアーキテクチャーなんですが、やってることは理解したものの未だにこれに関する説明については何を言ってるかわかってません。Reactはこのアーキテクチャーの一部（View）として存在します。

これに関しては僕自身手を出してはみたのですが、正直エンジニアに任せてしまった方が良いという感想でした。なにやらフレームワークが戦国時代って話もありますし（ちなみにRefluxというのを使いました）、コンポーネントと違ってあまりデザイナーが関わる積極的なメリットもない気がします。

個人的にはReactのコンポーネントまでをデザイナーが扱えるようになっているのが、エンジニアの方々と協業する上で程よいバランスなのかなという結論です。

やってみるメリット

デザインもコンポーネント指向になってくる

予めどの要素をコンポーネントとしてまとめられるかを意識しながらデザインしていくと、実際にそれを実装していく際に無理のない設計になります。

UI/UXを考える上でも、1つのコンポーネントがあまりに過剰な役割を担っていたら、それは使う側にとっても複雑すぎるものになっていないかという指標になったりしました。

いつのまにかモダンなJSerっぽくなっている

上記のコード例では従来のJSの記法（ES5）で書いていましたが、Reactを使う時はES2015（ES6）で書かれることが多いと思います。なぜならES2015をES5にトランスパイルするbabelが早い段階でJSXをサポートしていたため、本家からもコンパイラとして推奨されるようになったからです。

コンパイルするにはターミナルでコマンドを叩いたり、BrowserifyやWebpackといったビルドツールを使います。さあ、デザイナ脳にはわけわかんなくなってきました！

このあたりは学習コストという面でデメリットかもしれませんが、言って見れば開発環境の構築なのでエンジニアさんにお願いしちゃいましょう。後から少しずつ仕組みを理解すればOKです。唯一気にする必要があるのは記法がES2015になるというところですが、これもCSSをLESSやSASSで書くようになったのと似たような話なので、一度慣れたら便利で戻れなくなってると思います。

Learn ES2015

おわりに

今回こういう話を書いてみようと思ったのは、エンジニアの方がReactを採用するにあたって、デザイナーにどこまで任せていいのかわからないというような話をちらほら耳にするようになったからでした。

数年前まではサーバーサイドはエンジニア、フロントエンドはデザイナーといった棲み分けがあって、デザイナーはjQueryをベースにプラグインを使ったりして求める表現を実現してきました。そういう意味ではjQueryはデザイナーフレンドリーなツールだと思います。とにかく動くものが簡単に作れるので、今でも黙って漢になりたくなったりします。

それがだんだんJSがエンジニア文脈の言語として扱われるようになってきて、「テスタブルである」とか「イミュータブルである」とか今まで考えたこともなかった話が出てくるようになりました。こうなると非エンジニアとしては独学しようにも手の付けどころがよくわからないのですよね。移り変わりも早いので追っていくのが大変です。

というわけで、しばらくはエンジニアに巻き込まれてるうちに気が付いたら身についてたという戦略で行こうかなと思っています。

エンジニアのみなさん、何卒お手柔らかに…！