React時代におけるデザイナーとエンジニアの寄り添い方ついて #JavaScript

フロントエンド開発において，かつてのようにスタイルとロジックがきれいに分離されていた時代は終焉を迎えました．React 時代においては，それらを独立して扱うことは難しくなってきており，デザイナーとエンジニアはお互いに寄り添って歩んでいかなければなりません．

そこで今回は，エンジニアの視点から，デザイナーに寄り添うために具体的にできることを，5 つのポイントに分けて書いてみたいと思います．

1. 頻度の高い JS, JSX の記法を習得してもらう

デザイナーが React で View を実装するにあたり，相性のよい JS 記法や JSX 記法をいくつか習得してもらうだけで，生産性は大きく向上します．頻度の高い記法は限られており，かつそれぞれのハードルも高くないので，習得コスト以上のリターンが得られると思います．以下のものあたりを習得してもらうと十分でしょう．

map, 三項間演算子, Template literal

JS の基本記法としては，最低限このあたりをおさえておくと幸せになれるのではないかと思います．

{/* セレクタの出し分け (三項間演算子 + ES6 の Template literal) */}
<button className={`button ${isActive ? 'is-active' : ''}`}> Button </button>

{/* コンポーネントのループ (map) */}
{[1, 2, 3].map(n => <div> {n} </div>)}

className, htmlFor, maxLength, minLength

HTML と JSX で attribute 名が異なり，かつ JSX で頻度高く利用されるものとしてはこのあたりが挙げられます．あとは必要に応じて DOM Elements - React を参照してもらうと十分なように思います．

以前はデザイナーに書いてもらった HTML マークアップを，エンジニアである自分が JSX に変換するみたいな ~~クズみたいな~~ ことをしていましたが，デザイナーが JSX を編集できるようになることで，このような本質的でない作業が消え，かつデザイナーも直接的に UI の修正などができるようになり，メンテナンス性が向上したように思います．

{/* maxLength */}
<input type="text" maxLength="4" />

{/* className, htmlFor */}
<label className="label" htmlFor="id"> label </label>

SFC (Stateless Functional Components)

デザイナーにコンポーネント志向で開発をしてもらうために，ES6 の import/export といった基本構文に加えて，SFC を習得してもらうことをおすすめします．SFC はシンプルに JS の function として記述できるため，デザイナーにとってコンポーネント化に対するハードルが下がり，共通フッターなどのステートレスでかつ再利用可能なコンポーネントを実装しやすくなります．

export const button = ({ isActive }) => (
  <button className={`button ${isActive ? 'is-active' : ''}`}> Button </button>
)

2. 開発環境を整える

JS や JSX をエンジニアとデザイナーで共同編集していくにあたり，開発環境の整備，特にフォーマットやスタイルの統一は不可欠です．以下のような環境をエンジニアがあらかじめ用意しておくと，お互いが円滑に開発できるように思います．

ESLint を CI で走らせる

ESLint を，例えば push ごとに JSX に CI で走らせるようにしておくことで，最低限の View のクオリティ担保に役立ちます．eslint-config-airbnb をベースに，必要に応じてルールを追加/削除していくのがおすすめです．ES6 で開発している場合，最低限の設定は以下のような感じかと思います．

.eslinterc

{
  "extends": "airbnb",
  "env": {
    "browser": true,
    "node": true,
    "es6": true
  },
  "parserOptions": {
    "ecmaVersion": 6,
  },
  "rules": {
    "no-console": 1,
    ...  // ここにルールを上書きしていく
  }
}

.editorconfig を git 管理する

エンジニアは基本的にインデントにソフトタブを用いますが，デザイナーはハードタブを用いることも多く，共同編集するとそれらが混ざってしまい，秩序が乱れかねません．ESLint の no-tabs でエラーを出すことはできますが，それよりも EdirotConfig でインデントなどを統一するのが快適です．以下のような .editorconfig を git 管理しておくと，エディタの設定が共有され，エンジニアもデザイナーも環境を意識せずに開発をすることができます．

[*.{js,jsx}]
charset = utf-8
indent_style = space
indent_size = 2
...

HMR (Hot Module Replacement) などの Webpack の設定

Webpack でフロントのリソース全てを統一的にバンドルできることは，エンジニアにとってはうれしい限りですが，デザイナーからすると，gulp などと比べると学習コストが高い上にハマりどころも多く，とっつきにくい印象があるように思います．なので，sass や image などをロードする環境をエンジニアがあらかじめ用意しておくのがよいでしょう．

また，デザイナーが HTML/CSS の LiveReload と同じ感覚で JSX を編集できるために，HMR などの環境も用意しておくと幸せになれるのではないかと思います．

3. jQuery への依存をなくしてもらう

JS を書く際，jQuery に大きく依存しているデザイナーは多いと思いますが，React を用いている場合，不必要な共存は極力なくしたいという思いがあります．jQuery でやろうとしていることのほとんどは Pure な JS や React のみで事足りますし，それだけだとつらいものが一部あったとしても，その一部を実現するために，わざわざ jQuery のようなヘビーなライブラリをロードすることはパフォーマンスの低下につながります．なので，以下のようにして，デザイナーには jQuery への依存を断ち切ってもらいましょう．

「jQuery は甘えやで」と言って洗脳していく

もしレビュー時に jQuery を利用しているのを発見したら，「jQuery は甘えやで」と言って，You Don't Need jQuery へのリンクを貼りましょう．これを見ると分かるように，ほとんどのものは jQuery を使わなくても簡単に記述できます．自分の場合，これにより無事に jQuery への依存をなくすことに成功しました．

アニメーションは基本的に CSS で記述してもらう

jQuery で fade などのアニメーションを利用している場合，これらは基本的に CSS Animation で代替できます．React でもアニメーションは記述できますが，親和性は高いとは言えず，基本的には CSS で実現するのがよいと個人的には思います．アニメーションの責務を CSS に持たせることで， View からスタイルに関するものを分離することができ，メンテナンス性が高まります．

CSS だけでは難しいものは，スクラッチ or ライトなライブラリを利用する

どうしても CSS Animation だけでは実装が大変なものも中にはあります．例えば，以下のような duration を指定したスクロールは，jQuery では簡単に記述できますが，CSS だとちょっと面倒です．

$(window).animate({ scrollTop: 0 }, 500)

このようなものに関しては，エンジニアがスクラッチで書いて用意するか，その用途に特化したライトなライブラリを導入するのがよいかと思います．

4. React コンポーネントのスタイルガイドを用意する

React コンポーネントをエンジニアとデザイナーで共同編集していくと，コンポーネントのスタイルに関するガイドラインが欲しくなります．スタイルガイドジェネレータとしては，StoryBook がかなり便利なのでおすすめです．

StoryBook 自体は，React コンポーネントのサンドボックス環境なのですが，コンポーネントの状態を含めたスタイルガイド としても利用できます．例えば，以下のように 1 つのコンポーネントを 1 つのストーリーとして，複数の状態を定義することができます．

storiesOf('Button', module)
  .add('Active', () => (
    <Button
      onClick={action('click')}
      isActive
    />
  ))
  .add('Inactive', () => (
    <Button
      onClick={action('click')}
    />
  ))
  .add('Loading', () => (
    <Button
      onClick={action('click')}
      isLoading
    />
  ))

また，Storybook の環境を用意しておくことで，デザイナーがプロトタイプ段階から React でコンポーネントを実装するのが容易になります．そして，デザインもそれに引きずられてコンポーネント志向になり，メンテナンス性が高まるという副作用もあります．

5. View 以外の部分は意識させないようにする

React の View を直接デザイナーが実装するとなると，ロジックとも密接に関わってくることもあり，View 以外のところに気を取られることが多くなってしまいます．View に関する部分以外は極力エンジニアが土台を整え，UI とスタイルに集中してもらう必要があります．例えば以下のようなことを意識するといいでしょう．

SPA のひながたはあらかじめ用意する

デザイナーが新規 View を作成する際，Flux で State 管理していると，ファイル数が多くどこに作成したらいいか分からないといった状況になってしまいがちです．なので，ルーティングを含めた SPA のひながたはエンジニアが用意し，この JSX がこのページに対応している，ということが分かる状態でデザイナーに渡すのがベストでしょう．

サーバサイドの State を容易に変更できるようにしておく

React を利用している場合，SSR などのために Isomorphic な実装にしていることが多いと思いますが，サーバサイドに関しては極力デザイナーに意識させないことが重要です．1 ページに複数の State が存在する場合などは，ちょっとしたスクリプトをエンジニアが用意して，簡単に状態を変更できるようにしておくとよいように思います．

以上，React 時代におけるデザイナーとエンジニアの協業について書いてみました．プロジェクトの状況や各々のスキルセットなどにより，どこまでデザイナーが関わるか，どこまでデザイナーに求めるかは変わってくると思いますので，その状況に応じたデザイナーとエンジニアの寄り添い方を見つけ，最も生産性が高くなるポイントを見出していただければと思います．