読者です 読者をやめる 読者になる 読者になる

React/Redux/ES6をしばらく使ってみての所感

React JavaScript プログラミング

ここ数ヶ月、お仕事で以下構成での開発をしています

  • React
  • Redux
  • ES6

徐々に解ってきたと思う(たぶん)ので、感覚がホットなうちに備忘も兼ねて整理。

※個人的な感想も含みます。

良かったところ

React : コンポーネント再利用時の安心感

いままで → なんか心配

従来は、フロントエンドはjQueryをメインに開発をしていました。

jQueryプラグインするなど、後々再利用可能な形で部品化することは従来も行っていましたが、いざ使う時に「これ本当に大丈夫か?」という気持ちになることも多々。

  • 他のプラグインとの相性は?
  • 名前空間の汚染がないか?
  • 依存するHTML上のid/class/attributeで悪影響がないか?

ルールを徹底したり、ドキュメントとして注意点をちゃんと残しておいたりすればある程度は回避できますが、最後は「ある程度覚悟して信頼する」という工程を通っていたと思います。

React : あんしん

Reactでお約束に則ってコンポーネントを作成していくと、propsベースとなり内部には状態保持せず、かつコンポーネント外のDOMには影響を与えない作りとなります。

直接DOM操作もやろうと思えばできるため、100%安心!というわけではありませんが、ポイントなのは「基本的に作ってれば大丈夫」というところだと思っています。

  1. 気をつけていれば安全なコンポーネントにできる
  2. 特殊なコードを書いたときだけ安全ではないコンポーネントになる

では大きな差があると思っていて、後者のほうが圧倒的に信頼できます。

React : パフォーマンスの改善がしやすい

無心でひたすらコードを書いていくと、徐々にパフォーマンスの劣化が気になってきます。 その時に、パフォーマンス改善のためのツールが用意されているのは大きかったです。

今のところほとんどのケースにおいては

  1. Perfomance Toolsボトルネックになってるコンポーネントを探す
  2. shouldComponentUpdateでがんばる

でだいたい問題とならないレベルまで改善が可能でした。 パフォーマンス劣化時に、問題となる範囲が想定しやすいのも良いですね。

jQueryをdisっているわけではありませんが、 効率の悪いセレクタを探したりDOMの操作回数をできるだけ減らす努力をしたりして地道に頑張っていたのはなんだったのかと。

(とはいえ、対応できないレベルのパフォーマンス問題にぶつかったら考えは変わるかもしれません・・

ES6 : たくさんの幸せ

ES6が便利すぎて半端じゃないです。ES6なしではjs書けない体になりました。

アロー関数
  • コールバック系が書きやすいし読みやすい
  • self = this がいらない幸せ
spread operator
  • argumentsって書く頻度が激減
スコープまわりのあれこれ
  • ブロックスコープとか
  • const/let とか
  • 即時関数もあまり使わなくなった気がする

これだけじゃないですが、本当に痒いところに手が届くようになった感じ。もう戻れない。

つらかったところ

記述が超増える!!

React/Reduxともにですが、どうしてもコード量が大幅に増えます。

Reactの場合、Reduxのところでも少し触れましたが、propsが怒涛のリレーになることが多いです。 階層が深くなればなるほど propsが増えていき、コードの記述量が増えて行くのはなかなか大変。

Reduxについては、ビジネスロジックとデータ(store)の管理を綺麗に分離することができますが、確実に大幅にコードが増えます。

レイヤーが増えるから仕方ないとは思うのですが、簡単な画面の作成時でも

  • view
  • container
  • component
  • action
  • reducer

などと、多岐に渡る修正が必要となり、新規ファイル作成量も多いです。 「1つボタンを増やして、押したらAPIを読んで結果を別のとこにレンダリング」というだけでも、結構なコードを書く必要があります。

おまじない的にコードを書かないといけない感じもあり、java/strutsを使ってweb開発していたころを思い出しました。

役割を分離できることで粒度の細かいテストを書けるなど、 恩恵が大きいのも理解はできるのですが、恩恵以上にすごい勢いでコードが増えていくな〜と。

実際には作業スケジュールも加味しないといけないので、 全コードに対してテストを書いている余裕がないのが現実だったりもします。 その時に、コードが多ければ多いほどネガティブな影響を受けやすいのではないかと。

とはいえ、Fluxのデータフローを1方向にするという思想自体はとても良いものだなと思います。 コードが増えるは増えるのですが、実際に読む際には流れを追いやすい。

このあたりは実装側の問題もあるかもしれませんが、 同じような問題に悩んでいる人は多いのかな〜・・?

ES6 : 使う準備が大変

ES6が、というわけではありませんが、ビルド環境の整理が大変です。 このあたりは私の先輩がゴリゴリに組み込んでいましたが、それでも大変そうでした。

あとは使っているとあれもこれも入れたくなってくるので、 どんどんカオスになっていくpackages.json

ある程度自重するのも大事なのかもしれません。


まだまだ解ったような解っていないような感じですが、トータルでまとめると

  • React : 良い
  • Redux : つらい
  • ES6 : 良い

といった感じです。

React/Reduxについては、ベストプラクティスと言うのはおこがましいですが、 円滑に開発を進めるための勘所みたいなところも多々あると思います。

そのあたりについてはまた別の記事でまとめてみます。