30000 lines of client-side JavaScript. No tests. Two difficult TV deployment platforms with poor tooling. Strong dependencies on poorly documented
30000 lines of client-side JavaScript. No tests. Two difficult TV deployment platforms with poor tooling. Strong dependencies on poorly documented
Once you have installed Flow, you will want to get a feel of how to use Flow at the most basic level. For most new Flow projects, you will follow this general pattern: Initialize your project with flow init.Start the Flow background process with flow.Determine which files Flow will monitor with // @flow.Write Flow code for your project.Check your code for type errors.Initialize Your ProjectPrepar
flowtype v0.31.0がでましたね!(既にv0.32.0もでてますけど) CHANGELOG読んでみると Added a new "magic" type called $PropertyType. This utility extracts the type of the property 'x' off of the type T. magic typeなる気になる用語があるじゃありませんか!! どうやら$から始まる定義済みの型のことを指してるようなのですが、公式のドキュメントや過去のCHANGELOGを見てもそんなものは一切出てきません。 仕方ないので実際にコードを見てみると https://github.com/facebook/flow/blob/master/src/typing/type_annotation.ml type_annotation.mlの中に$から始
Having high-quality and community-driven library definitions (“libdefs”) are important for having a great experience with Flow. Today, we are introducing flow-typed: A repository and CLI tool that represent the first parts of a new workflow for building, sharing, and distributing Flow libdefs. The goal of this project is to grow an ecosystem of libdefs that allows Flow's type inference to shine an
最初に この記事はflowtype導入の手順紹介というより、自分の作業ログに近いものです。flowtypeって何?ってところも含めて以下に紹介する記事を見たほうがわかりやすいと思いますので、参照してください。 今回試すにあたって、参考にした記事。 qiita.com qiita.com joe-re.hatenablog.com qiita.com 動機 自分の観測範囲内で「flowtypeいいよ!」って話しをよく聴くようになり、試してみることにした。 自分の場合はだが、主な動機としてはReactのpropTypes頑張って書く割に得られる恩恵少ないというのがあってflowtypeであれば、それを改善しつつ、部分的に適用することができる。 新規プロジェクトで あればTypescriptを採用するなどの選択肢を取ることが可能であるが、既存プロジェクトの場合はそうはいかない。だけど、flowt
Flow is a static type checker for JavaScript. This is a list of Flow types generated from the source code in https://github.com/facebook/flow/tree/v0.111.3/ The script to generate this list is on github. Fixes welcome. See also my TypeScript cheat sheet, TypeScript React cheat sheet, and Docker cheat sheet. There are separate sections for "private" or "magic" types with a $ in the name. See the no
Type Systems for JavaScript Oliver Zeigermann / @DJCordhose http://djcordhose.github.io/flow-vs-typescript/2016_hhjs.html Most recent version including TypeScript 2.0 can be found here (might be work in progress): http://djcordhose.github.io/flow-vs-typescript/flow-typescript-2.html Part I: Introduction Why using type systems? IMHO type systems make code easier to maintain type annotations can mak
Statement Brian Terlson who is editor of ECMAScript said that Speaking as someone who proposed types for JavaScript in 2014: I do not believe types are in the cards for the near future. This is an extremely complex problem to get right from a standards perspective. Just adopting TypeScript as the standard would of course be great for TypeScript users, but there are other typed JS supersets with pr
ハウス・オブ・カードで寝不足の小飼です。 どうなるんですか、あのアレは... さて、最近個人的にGolangでアプリケーションを作ったり、Haskellを勉強したりしています。 いずれも静的型付けにより、実行前に型エラーを検出可能な言語です。 私は普段、動的型付け言語であるJavaScriptを主に書いていますので、初めこそビルド時のエラーにヤキモキしたりしましたが、慣れてくると非常に快適に感じるようになりました。 実行時に検出されるつまらない間違いや、間違った型が渡ってきた時の防御コード(if typeof variable !== 'string' console.warn('型が違う')のようなコード)が不要になること以外に、アプリケーション固有のデータ構造を型として宣言することで、何をするかよりも何であるかに注目した読みやすいコードを書くことが可能になるからです。 React.js
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く