貢献

• チュートリアル
  • インストール
  • イントロダクション
  • チュートリアル
• リソース
  • JSX
  • ES6
  • CSS
  • アニメーション
  • テスト
  • サンプル
• 重要なコンセプト
  • Vノード
  • コンポーネント
  • ライフサイクルメソッド
  • キー
  • 自動再描画システム
• ソーシャル
  • Mithrilの求人
  • 貢献の仕方
  • クレジット
• その他
  • フレームワークの比較
  • 変更履歴/移行

FAQ

アイディアや新機能を投稿するにはどうすればいいでしょうか？

GitHubに提案したい内容のissueスレッドを立てるとコミュニティ内で議論することができます。

もし、そのアイディアががすばらしいものであるとコンセンサスが取れたら、Pull Requestを投げるのがリリースへの近道です。もしPull Requestがなければ、開発にかかる期間は開発チームの余裕と、開発の優先度により決定されます。

どのようにバグを報告すればいいでしょうか？

理想的には、jsfiddle、jsbin、gistなどにバグを再現させる小さなコードを作成して報告するのが最良の方法です。もちろん、バグの修正と再現テストをPull Requestで送るのが最良の方法です。もしどのように修正コードをテストしたり、コードのスタイルの修正をすればいいのかわからないのであれば、まずは送信してください。私達がサポートします。

どのようにPull Requestを送信すればいいでしょうか？

Pull Requestを送信するには:

• リポジトリをフォークします（GitHubの右上のボタンを押します）
• フォークしたリポジトリを自分のコンピュータにcloneします（GitHubの右上のボタンです）
• フィーチャーブランチを作成します（git checkout -b the-feature-branch-nameを実行します）
• 変更を行います
• テストを行います（npm tを実行します）
• Pull Requestを送信します（GitHubのPull Requestタブに行き、緑のボタンを押して、フィーチャーブランチを選択します）

Pull Requestを送ろうとしています。どのようにテストを実行すればいいでしょうか？

このリポジトリをフォークしているものとして説明します。testsフォルダの中のindex.htmlファイルを開き、コンソール出力を見るとテスト結果を見ることができます。また、コマンドラインからospec/bin/ospecを実行すると、すべてのテストが実行できます。

テスト中は、テストを変更してo(description, test)の代わりにo.only(description, test)を使うと、特定のテストだけが実行されるのでデバッグ作業が高速になります。ただし、修正が終わったら.onlyを忘れずに削除してください。

テストの実行にあたってnpm installを実行する必要はありませんが、コマンドラインからテストを実行するにはNode.jsが必要となります。ただし、コードのlintやコードカバレッジのレポートを取得するには、npm installの実行する必要があります。

どのようにMithrilをビルドするのでしょうか？

コードベースの中でサンプルを実行するには、ビルドする必要はありません。さまざまなHTMLファイルを開いて動作させるだけです。

テストのためにバンドルされたファイルを生成するときは、コマンドラインからnpm run devを実行します。ミニファイされたファイルを作成するには、npm run buildを実行します。npm installを実行する必要はありませんが、ビルドスクリプトの実行のためにはNode.jsが必要となります。

スタイルガイドはありますか？

eslintの設定ファイルがありますが、フォーマッティングに関しては厳しくしていません。もし、変更したコードがnpm run lintにパスすれば、Pull Requestしては十分です。なお、パスしなくてもPull Requestは受け入れます。

スペースやフォーマットの不一致はそのうち修正されますが、そのような修正だけの貢献は余り歓迎しません。

なぜテストではブラウザAPIのモックをしているのですか？

もっとも大きな理由は、ラウターとその副作用のテストがただしく行えないからです。また、モックがあるおかげで、Node.jsを使ってテストするときも、PhantomJS/ChromeDriver/JSDOMなどの重い依存が不要になります。

モックのテストコードにより、ブラウザAPIの癖を文書化することができるのも大切な理由です。

なぜMithrilはMocha/Jasmine/Tapeを使わずに、自前のテスティングフレームワークを使っているのでしょうか？

主な理由は必要な依存をなくすためです。ospecは一般的なテストのワークフローで必要なもののみに特化しています。通ったテストに対してはなにも表示せず、エラーと失敗だけをノイズなく表示します。

なぜmodule/module.jsを使ってテストしていますか？なぜBrowserify, Webpack, Rollupを使わないのですか？

これも必要な依存をなくすためです。Mithrilコードベースは、（ES6 modulesではなく）CommonJSのモジュール定義のサブセットを使って書かれています。この文法はES5と後方互換性があり、静的に解析可能な構文を使っています。そのため、ビルドツールやファイル監視ツールなどを使わずに、何も変更せずにブラウザで動作させることができます。

これにより、バグ修正のワークフローが簡単になり、バグ修正が高速で行なえます。

なぜMithrilのコードベースはBabelを利用してES6を使わないのですか？アップグレードのためのPull Requestは歓迎されますか？

リポジトリに含まれるすべてのブラウザ関連のモジュールが、変更せずにそのままIEで動作するのが必要条件です。

また、ES6の機能を使ったコードは、同等のES5 のコードと比べるとパフォーマンスがやや劣り、トランスパイルされたコードのサイズはやや大きくなります。

なぜMithrilのコードベースは末尾のセミコロンを使わないのですか？それらを使うためのPull Requestは歓迎されますか？

私はそれを使いません。それらを追加していくと、コードベースの一貫性が崩れます。

なぜMithrilのコードベースはObject.prototype.toString.callとArray.isArrayを使わないで、instanceofとtypeofによるチェックを行っていますか？それらのチェックコードをリファクタリングするPull Requestは歓迎されますか？

Mithrilはパフォーマンス上の理由から、オブジェクトの [[class]]文字列の取得を避けています。多くの型チェックは、ベンチマーク上では、他の手法と較べて、自分のコードがベストに見せるような構成で行っているため、奇妙な結果に見えます。

型チェックは一般的にはこれ以上簡単にできない式であり、型チェックをサブルーチン化したマイクロモジュールを作るとメンテナンス上のオーバーヘッドが発生します。

パフォーマンスに関連する貢献をしようとする時に、事前に知っておくべきことは何ですか？

DOM操作の数を減らすか、ホットスポットとなっているアルゴリズムの複雑さを軽減すべきです。それ以外は時間の無駄です。具体的に挙げると、配列の長さを変数にキャッシュするとか、オブジェクトのプロパティ値のキャッシュ、関数のインライン化などのミクロな最適化は、現代のjavaScriptエンジンで効果がありません。

オブジェクトのプロパティの一貫性を保つと、JSエンジンはハッシュマップではなく、JIT化された構造体（hidden class）を使い、高速化できます。同じプロパティを持つ構造体は常に順序が同じになり、アクセスが高速になります。複合型のチェックでは、nullチェックを常に先頭に置くことで、JavaScriptエンジンが型に固有のコードパスの最適化が行えるようになります。Arrayのメソッドよりもforループを使ったり、ループの条件式をなるべくループの外に出します。