型なき世界のためのflowtype入門 - Qiita
http://qiita.com/mizchi/items/3bbb3f466a3b5011b509 で紹介したモダンJSスタックの上に、flowtype を導入して型をボトムアップに追加していくアプローチを紹介します。 なぜflowtypeか、そのゴールは 流行っているライブラリのみを組み合わせて使う場合や、バックエンドとの連携において型が十分に提供される環境なら、正直、flowtypeよりtypescriptでいいと思っています。flowtypeが力を発揮する環境は、既存のJSが大量に存在する環境や、railsなどの動的な型のフレームワーク環境で、静的な定義が抽出できない環境だと思います。 よほど品質が低いライブラリを使わないかぎり、バグはほとんど自分が記述したコードによって発生します。なので、まずは「自分が書いたコードのIFを明確にし、その静的なチェックを行なう」、というのを最初の目
EventEmitterバケツリレースタイル/フレームワークなしで小さくFluxする - Qiita
想定しているシチュエーション 非SPA環境で個別にマウントされるコンポーネントがそれぞれで小さくFluxするような環境。 SPAガッツリ組むのでないなら、Fluxフレームワークは不要だと思っていて、とは言えオレオレ構成も行き過ぎると害になる。 その辺のバランスをとって、次のような構成がいいのではないか、と考えてみた。 考え方 コンテナがEventEmitterを1つ保持する コンテナはEventEmitterの各種イベントをListenする コンテナはpropsとstateを区別して扱い、stateを更新する コンテナはコンポーネントを一つだけ描画する コンポーネントはpropsとして渡されたEventEmitterを発火させる コンポーネントはEventEmitterをListenしない コンポーネントはpropsのみ扱う コード // src/components/header.js
app/assets/javascripts以下のJSを全てcommonjsのrequireに書き換える - Qiita
仕事でgulpを使って僕がよくいじる一部のjsを高速でビルドできるようにしてみたのだが、JSをいじらない人の手元でなにかと差分がおかしくなったり、ビルドするタイミングを伝えないことで問題起きたり、その為に呼ばれて治すのがとにかくめんどくさかったため、思い切ってすべてのビルド工程をbrowserify_railsとbrowserify-incrementalと(そのtransform)に押し込んで、gulpを排除してみた。 そんで、browserify_rails は導入しただけだと嬉しさがあまりないので、スクリプトを書いて一気にcommonjsに置き換えることにした。 browserify_rails に関してはhokacchaさんの記事が便利。 モダンJavaScript開発環境 on Rails - クックパッド開発者ブログ 脇道にそれるが、僕は最初、これをbrowserifyを模した
bower-buildでbowerで入れたファイルを一つにconcatする - Qiita
bower、普通に入れるだけだとbower_components/...に入るんだけど、index.htmlから相対パスで一個一個引いたりするのが面倒なので、だいたいconcatして一つにまとめたりする。 で、gulpやgruntのタスクを書くんだけど、毎回やるの面倒になったので、それだけのタスクをやるライブラリをさっくり作った。 mizchi/bower-build いれる。 $ bower init # なんか色々訊かれる $ bower install --save jquery codemirror # ライブラリいれる $ bower-build -o public --debug write: /Users/mizchi/proj/bower-build/public/vendor.js # include codemirror.js and jquery.js write:
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
