2015/01/15時点の情報です。
v0.1.3が計画されてるけど、initial releaseのv0.1.0からはbugfixや細かな修正がほとんどで、大きな進化はしてない。 コミットもあまり活発ではない。 もしかしたら、Facebook社内でprivateブランチを育てていてまとまったところで出してくるのかも。 （JS等に比べて）開発者人口の少ないOCaml実装というのも、プルリクが集まりにくくOSS的な加速的進化が起きにくい原因かもしれない。
- Publish v0.1.3 · Issue #206 · facebook/flow
- v0.1.2からの差分: https://github.com/facebook/flow/compare/v0.1.2...HEAD
- Handle strict undefined checks.
- Add theoretical support to print tuple types properly.
- Relax the callback type in Array.prototype.forEach
- Add basic autocomplete support for React classes.
- [Hack] Kill shell.ml entirely.
- Handle spread attributes in JSX syntax.
- [Parser] Allow most keywords as types
- Add Array.from to lib file
- [#161]: String literal keys for object type aliases
- Generalize mock module handling under Haste a bit.
- Improve autocomplete type printing
- misc cleanup
- [Parser] Improve type keywords
- [Parser] Stop vendoring in ast-types
- Add an ocaml wrapper for find path1 ... pathN -name pattern
- Restart if a known lib file changes
- Add ProgressEvent definition and update two onprogress types
- [Hack] Add client time to server start time.
- Improve control flow type refinements
- [Hack] Reduce dependencies on ParserHeap.
- Exit server on config change for now rather than restart to avoid some bugs
- [Parser] ArrowFunction object & array patterns must be wrapped with parens
- Properly functorize logging code too
- [Hack] Make GC parameters configurable.
- Refinements on method calls
- [Hack] Log whether we are loading from a saved state in INIT_END.
- [Hack] Improve error handling for saved states.
- [PR #137] from sverrejoh/master
- [PR #150] from unknownexception/fix/dom.js
- [PR #146] from k-bx/master
- [PR #151] from unknownexception/feature/no_flowlib
- [PR #144] from rsolomo/node-assert
- [PR #191] from Shraymonks/HTMLBaseElement
- [PR #145] from rsolomo/node-util
- [PR #192] from Shraymonks/HTMLScriptElement
- Add ES6 String.prototype.contains
- Add Promise.prototype.done() to Flow lib
公式のチュートリアル(Flow | A Flux & React demo)等を触ってみての感想。
ReactではPropTypesという仕組みを使ってComponentのpropに型情報を持たせることができるProp Validationという仕組みがある。
var MyComponent = React.createClass({
propTypes: {
name: React.PropTypes.string.isRequired,
date: React.PropTypes.instanceOf(Date).isRequired
},
//...
});通常、Reactではこれをdevelopmentビルド時にランタイムでバリデートするため、実行して実際に処理が走らないとロジックの整合性を確認できない。
Flowtypeでは、このPropTypesを静的にチェックできる。つまり実行しなくてもflowコマンドを叩くだけで不整合が無いか確認できる。
例えば上記のMyComponentを以下のように使うと、nameが必須なのに指定されてないこと、dateがDateクラスを要求しているのに文字列であることがflowコマンドでコンパイル時に検出可能。
React.render(<MyComponent date="2015/01/15" />, document.body);これはReactとFlowtypeを組み合わせる大きな利点と言えそう。
詳細: http://flowtype.org/docs/react-example.html#property-use
現状、FlowtypeとReactを組み合わせて使う上で制限事項がある。
http://flowtype.org/docs/react-example.html#working-around-current-flow-limitations
object-assignの型チェックに非対応- 実行時のオブジェクト拡張的なクラス継承の書き方に対応してない
- Reactの一部のAPIに対する型定義ファイルがない（現行Flowtypeでは表現できない）ので、これらを参照するファイルは、ファイルまるごと型チェックの対象外にする必要がある
FlowtypeとReactを組み合わせて使うと、Flowtypeによる通常の型チェックだけでなく、ReactのpropTypesも静的に型チェックできるということで恩恵はあると言えるが、現時点ではまだ制限事項が多くこなれてない印象。 この辺がこなれてきて、さらにd.tsの扱いもうまくなると、ReactはFlowtype組み合わせるのが定番になっていきそう。
ただし、パブリックに見える範囲ではFlowtypeの進化は小幅な修正に留まっているので、対応時期とかはよくわからない。 どこかでとっておきの社内ブランチがどかんと出してくるのかな。期待して待つ。