Evolving Complex Systems Incrementally

by cpojer

FacebookでReactやReactNative, Relay, Jestなどの開発をしているエンジニアのChristoph Pojerさんによる発表。

注：全部英語だったので理解が間違っている可能性あり。

JSCodeshiftの話。

規模の大きいプロダクトではJavaScriptの言語仕様や依存しているモジュールの仕様が変更になった時に、数百~数万単位でJSファイルを更新する必要がでてくるが、これは普通に考えて辛すぎる。

それらの変更を簡単にするためにFacebookはJSCodeshiftというツールを作ったから紹介するよという話。Facebookには何でも作っちゃう文化があるんだ的な事を言っていた。

JSCodeshiftはコードをインクリメンタルにアップデートするためのツールでATSベースのcodemods。

処理の流れとしては、JSのコードをParse->Find->Create->Update->Printの順序で処理して最終的にリファクタリングされたコードを生成する。Find（探索）とUpdate（更新）の話は時間の関係上スキップされた。

Parse：JSのコードをATSに変換する処理。AST explorerを見るとJSのコードがどのようにASTに変換されるかがわかる。

Create：変換されたASTを更に独自のDSLで記述されたASTに変換する処理。変換処理はast-typesで行っている。

ast-typeに関しては良くわかっていないのだけどググったらazuさんの記事に少し説明が書いてあった。通常のASTはただのJavaScriptオブジェクトだけど、ast-typeでは型を持ったDSLで記述されるので良いという話なのかな。

Print：AST変換後にリファクタリングされたものをJSコードとして吐き出す処理。コードの出力はrecastで行っている。

JSCodeshiftを使うと結局どんなことが出来るの？っていう話だけど、var使ってるコードを全てconstやletに変換したり、ES2015で新しく置き換える事ができる関数に全部変換する等といったことができる。

実際にデモとしてReact.js本体のコードに含まれているvarを全てconstとletに変更するという処理を実行し、そのままプルリクまで出していた。凄い。

最近はASTを使ってコードを解析したり弄ったりするツールが増えてきているのでこの辺はもう少し勉強しとかないと時代の流れに追いつけなくて不味いなぁと思った次第。

Q&A with cpojer. About React, Relay or anything else

by cpojer

cpojerに色々質問するセッション。

別の作業してて半分くらい聞き取れなかったので聞けたところだけ書く。

Q：Facebook/Fluxのdispatcherを今後どうしていくつもりなのか（Reduxと比較して）

A：特にどうするかとかは決まってないが、Facebookはやると決めたことはドラスティックな変更でもしちゃうので、そのような変更はいつかあるかもしれない。（前半部分があまり聞き取れなかった）

Q：なにか今後大きな発表はあるのか？

A：draft.jsをちょうど今日リリースしたよ。

Q：ReactNativeを使ってアプリを作った際にUIのパフォーマンスがあまり良くないと思うが、ネイティブアプリ並にパフォーマンスを良くするにはどうすればよいか。

A：速くしたいなら細かなチューニングは必要かもしれないが、既にリリースされている最新バージョンのReactNativeでも十分なパフォーマンスが出ていると思っている。もしパフォーマンスを更に良くしたいと考えているなら、ちょうど現在開催されているReact ConfでReactNativeのパフォーマンスに関するセッションがあるので見てみると良いかもしれない。（たぶんこの辺の話だと思う。 React: What Lies Ahead、Optimising React Native: Tools and Tips）

React/Flux/Relay/GraphQL

by neth_6

GraphQLとRelay.jsの基本的な説明とそれらを使う利点に関する内容。（Fluxの話は無しになった）

GraphQL

Facebookが開発したクライアントとサーバー間のデータのやり取りをするためのクエリ言語。

GraphQLサーバーはシングルエンドポイントのAPIを提供し、リクエストパラメータとしてqueryを渡すことで任意のデータを取得できるという仕組みで、クライアントサイドでのデータ取得処理を簡略化する。

GraphQLサーバーは特定の言語に依存せず、RubyやScalaなど様々な言語で実装可能。

下記記事が分かりやすかった。

Relay.js

データ駆動でReactアプリケーションを開発するためのフレームワークで、GraphQLの利用が前提となっている。GraphQLサーバーとReactコンポーネント間のデータのやり取りを簡単にしてくれる。

下記記事が分かりやすかった。

GraphQLやRelay.jsは完全ノータッチだったので何となく概要を把握できたのは良かったが、細かな特徴や実装などに関しては英語がうまく聞き取れなかったので、発表資料や公式のドキュメントを今週中に改めて見ておこうと思う。

GraphQLやRelayを使うとReactを使ったクライアントサイドの実装は楽になりそうだけど、サーバーサイドの実装はGraphQLやRelayにロックされてる感があって辛そう。

この仕様が流行るかどうか分からないという現状でプロダクション環境に導入するのは、学習コストの割にそこまで利点が無さそうかなという印象を受けた。

React.jsユーザーのためのElm

by jinjor

Elmとは関数型言語のAltJSでHaskelに近い。

なぜElmなのか：Reactと言えばRedux->ReduxはElmを参考にして作られている->Redux好きならElm知っておいても良い的は話。

Elmは2015年にフロントエンド界隈で人気が急上昇してきた。理由としてはVirtualDOMの導入とElmArchitectureというFRPに関する独自のアーキテクチャを提供しているから。

VirtualDOMの導入

VDOMの差分比較をする場合はObjectがImmutableである必要がある。そのためにReactではImmutable.jsを使っている。Elmは言語仕様からしてImmutableなので、パフォーマンス的にReactよりも優れている。

ElmArchitecture

ElmはいわゆるFRP言語。FRPは明確な設計方針が無いとカオスになってしまう。各開発者が思うままにシグナルを合成・量産してしまい何が何処に存在するのかがわからなくなる。

ElmArchitectureはそれらを解決するための設計方針を示したもので、これがRedux開発に影響を与えた。

ElmArchitectureに従うと開発者はAction->Model->Viewの3つのシグナルを作るだけでよい。しかも開発者はシグナルを殆ど意識する必要がない。（そもそもFPRに対する理解が足りないので、この辺よくわからなかった）

改めてElmの良さとは何か

• 膨大なスタックを必要としない（elm-html・start-app・ Gulpがあれば良い）
• 静的型付け言語である（ランタイムエラーが起きない・リファクタリングしてもバグらない・アーキテクチャをきちんと守れる）

（静的型付けを求めるのであればTypeScriptでも良いかなぁと思ったり）

もし気になるならElmアドベントカレンダーがあるからそっちをチェックしてみても良いかもしれない。