2016年、サーバーサイドエンジニアがゼロからReact/Reduxを学習したときの方法を振り返る

こんにちは。スタジオ・アルカナのサーバーサイドエンジニアなっちゃん(@natsumican63)です。

この記事はReact Advent Calendar 2016の13日目の記事です。

それは2016年も後半へ差し掛かったある日のことでした…

上司「次の案件、この辺の技術使うから軽く勉強しておいてー」

つ React.js + Redux.js + redux-saga + Cordova + ES6 + Babel + OnsenUI + Gulp + Webpack

( ゚д゚)

(つд⊂)ゴシゴシ

(;゚ Д゚) !?!?

(; ゚д゚)「…わ、わかりました」

※「何でもやります!やらせてください!」が私の口癖なので、決して無茶振りしてくる弊社ではありませんよ!ほんとだよ!!

斯くして2016年、サーバーサイドエンジニアがはじめてフロントエンドへの門戸を開くこととなった際の学習方法を振り返ってみようと思います。

学んだ順序

  • ES2015
  • Babel
  • ビルドツール等
  • React
  • Redux(flux)
  • その他

「そもそも何から学べばいいかわからない…」という方は、とりあえず↑の順番で学ぶとよいでしょう。 因みに私は「jsはDOM弄るときちょいちょい書くし行けるやろ〜〜〜」という安易な考えでReactから入ろうとして無事死亡しました。

では解説して行きます!


ES2015

そもそもECMASctiptとJavascriptの関係って?

ECMASctipt = 現代におけるJavaScriptと考えてよいでしょう。

実際には、ECMAScriptとはEcmaインターナショナルという標準化団体が作成したJavaScriptの言語仕様書のことを指します。

どうしてこのような事になったのかというと、かつてクライアントサイドにおけるJavasctiptはブラウザベンダーによって仕様がまちまちだったりと、互換性が非常に低いものでした。 97年にECMAによる標準化がはじまってからも、なかなか仕様がまとまらず決裂したりと不憫な歴史を歩みます。

そんな諸々の紆余曲折を経た結果、2015年、今後行われる年単位リリースの起点となる、ECMAScript2015(ES6)が策定されたのでした。

(因みに、もうすぐES2017のリリース時期だったりします。毎年キャッチアップして行きましょう〜)

ES2015の特徴について

JavaScriptはプロトタイプベースのオブジェクト指向言語であり、クラスベースではありません。 故に、JavaやRuby等クラスベースのオブジェクト指向に馴染みが深いであろうサーバーサイドエンジニアにとって、少々紛らわしいイメージがあるかと思います。

…が、なんとES2015からクラス構文が使えます!やったね!!

これにより、サーバーサイドエンジニアにとっても、わりと直感的にコードが書けるようになったのではないかと思います。 しかし 、あくまでクラス構文はシンタックスシュガーですので、最低限プロトタイプについて理解しておく必要があるでしょう。

[MDN]継承とプロトタイプチェーン

何となくJavaScriptを書いていた人が一歩先に進むための本(Kindle Unlimited対象)

ES2015からはクラス構文の他にも、

  • letによるブロックスコープ
  • constによる定数宣言
  • アロー関数
  • 「…」演算子による可変長引数
  • テンプレート文字列

などの便利な構文が追加されています。

ES2015 (ES6)についてのまとめ

しかし、世の中メリットにはデメリットがつきものですね…

問題点 : ブラウザによって対応していない場合がある

そこで登場するのが、Babelというトンスパイラーです。


Babel

↑のようなブラウザでサポートされていない新しいJavaScriptの機能を、殆どのブラウザで実装されているES5の形式へトランスパイルしてくれます。 また、後述しますが、Reactでほぼ必ず使用されているJSX構文もこちらでトランスパイルすることになります。

Babelで始める!モダンJavaScript開発

コマンドラインからトランスパイルすることも出来ますが、実際の開発では以下のようなビルドツールを使用することが多いです。


ビルドツール

GulpやGrunt、Webpackなどがあげられます。 主に上記のようにJavaScriptのトランスパイルや複数のjsファイルを1つにまとめたり、Sass→CSSへのコンパイルなどフロント周りで行わなければならないタスクを一括で実行してくれます。

最近ではビルドツール不要論もあったりとイマイチどのビルドツールがベストなのかは分かりませんが、わたしはGulpを使用しています。(2016年12月現在)


React.js

やっとこの記事の本題です!

Reactは、MVCでいうところのViewのみを担当するJavaScriptライブラリです。 例えばこのように記述していきます。

class ShoppingList extends React.Component {
  render() {
    return (
      <div className=”shopping-list”>
        <h1>Shopping List for {this.props.name}</h1>
        <ul>
          <li>Instagram</li>
          <li>WhatsApp</li>
          <li>Oculus</li>
        </ul>
      </div>
    );
  }
}

引用:Reactチュートリアルより

XMLっぽいなにか(JSX記法)とちょこちょこロジックのようなものが書いてあるのですが、PHPのそれとは全く別物です。 ただのViewです。

↑のコードはComponentとよばれ、StateによってComponent内に状態を持つことが出来たり、propsで他のComponent間でのデータの受け渡しを可能にします。

Reactは今まで我々がやってきたDOM操作とは全く異なり、JavaScriptオブジェクト内にVirtual DOM(仮想DOM)として、DOMツリーのような設計図を保持することにより、変更があった場合のみ仮想DOMと実物DOMの差分をみて再構築しています。 (「Reactはやい!」と言われる所以はここにあったりします。) Vue.jsやAngularの2系からも採択されるようなので、もしかしたら今後スタンダードになっていくのかもしれません。

学習方法

まずはさらっと概念をさらっと理解しましょう。 5分で理解する React.js

そして公式チュートリアルを写経しつつ、

一通り写経してJSXの気持ち悪さに慣れたところで、Reactのライフサイクル図を頭に入れておきましょう。

React component ライフサイクル図

変なところでstateを更新するとパフォーマンスに影響するので要注意です。


Redux

ReduxはFluxの概念をさらに拡張したアーキテクチャですので、まずはじめに軽くFluxに触れておきます。

Fluxとは、データの流れが複雑な処理を一方方向にまとめるアーキテクチャです。 Observer Patternのようなもので、状態に変更があった場合インスタンスが観察者に通知するので、すべての状態を観察する必要がなくなります。

Reduxはそれらを更に派生させたもので、違いについては以下の記事がとても参考になります。

結局FluxやらReduxやらって何なのか個人的なまとめ

Redux入門【ダイジェスト版】10分で理解するReduxの基礎

先述のReactやAngular等jsフレームワークと一緒に使われることが多く、Reduxで状態管理を奪い取ることによりロジックが分離されるので、よりシンプルなアーキテクチャとなります。


その他

redux-saga

佐賀…サガと読むらしい。

Reduxで非同期処理を書きやすくしてくれるMiddlewareです。 非同期処理をタスクとして扱えるEffectsコマンドや、非同期処理を同期的に扱う手段を提供してくれます。

redux-sagaで非同期処理と戦う

Cordova

モバイルハイブリッドアプリをつくるためのクロスプラットフォームで、HTML/CSSやJavaScript実装します。 だいたいコマンド打つだけ

Electron

デスクトップアプリをつくるためのクロスプラットフォームで、HTML/CSSやJavaScript実装します。 だいたいコマンドry


効率の良い学習方法まとめ

  • 写経 & 写経 → 技術書や関連記事をひたすら読む
  • 実案件のソースコードを読ませて貰う
  • 実際に手を動かしてなんかつくってみる

↑はフロントエンド学習に限ったことではありませんが、効率の良い学習方法といえば、やはりこれらに尽きるかと思います。

感想

ほぼ知識ゼロからフロントエンド開発に参画する事は、やはりそれなりに大変でしたが、一旦情報をキャッチアップしてしまえば、あとは流れに身を任せるのみ…!な印象です。

私のように、サーバーサイドエンジニアだけど、ときどきフロントもやるよーというエンジニアも多いかと思います。 しかしこれからは、サーバーサイドエンジニアの中でも低レイヤー寄りと高レイヤー寄りへの二極化が進むのではないか、と個人的には思います。

かつてのクライアントサイドにおけるJavaScriptでしたら、とくに環境構築も特に必要なかったし、わりととっつきやすい印象があったかもしれません。 しかし、現状の実案件におけるJavaScriptは、めちゃくちゃ奥が深い、非常に専門的な分野であることを痛感しました…

よく言われるように、フロント周りの趨勢は確かにとても早いです。 しかし、それらは流れの中にいればそれなりに納得のいくパラダイムシフトであるということ、 そしてたとえその技術が枯れたとしても、キャッチアップする技術は決して無駄にはならない…と思いたい(願望)

これからもフロントエンドの行く末をあたたかく見守っていたいと思います。

余談

2015年までにWebのフロントエンドが辿ってきた道

(合掌…🙏)