Backbone: バックボーンカスタムビルド

それは素晴らしいことだ。

Backbone.jsコードベースをモジュール化する方法に興味がある場合は、バックボーンフォーク内のcustomBuildフォルダーを確認してください。 すべてのバックボーン単体テストは引き続き正常に合格することに注意してください。
https://github.com/gfranko/backbone/tree/modularBuilds

また、カスタムビルドUIがどのように機能するかの例を次に示します。
http://gregfranko.com/backbone/customBuild/

最後に、Backboneの一部のみを使用する可能性について説明するために私が書いたブログ投稿を次に示します。
http://gregfranko.com/blog/backbone-dot-js-convincing-the-boss-guide/

私はこのアイデア、特にルビーの依存関係がなくなり、うなり声が出てくる部分に本当に感謝しています。

また、Backbone.Routerが必要ない状況もあります（ルーティングするためのsmthがないためですが、JavaScriptを整理するためにBackboneを使用したいためです）。

さらに、これはLoDash（ええと、誰もがっかりしていると感じないことを願っています）カスタムビルドと非常によく合います。

@asciidiscoカスタムビルドをGruntと統合する作業はまだ行っていません。 どのようにアプローチするか考えていますか？

@gfranko jQueryのような実装を見たいです（1.8以降、カスタムビルドもあります）。
たぶん私はあなたのプロジェクトをフォークして今週末にスピンさせますが、十分な時間があるかどうかは完全にはわかりません:(

@asciidisco心配しないでください。 今週末、jQuery gruntファイルを見て、彼らがどのようにそれを行っているかを確認します。

：+1：コードベースをモジュール化するため

複数のファイルが役立つことがよくありますが、Backboneがソースを分割することでメリットが得られるとは思いません。 ライブラリはかなり小さいので、カスタムビルドでは、せいぜい数キロバイトしか節約できませんが、複雑さが増すとかなりの量になります。

価値があることについては、これは少なくとも以前に＃65で一度議論されました。

たとえば、ユーザーがBackbone.jsでjQuery Mobileを使用していて、バックボーンルートを含めたくない場合のユースケースはどうでしょうか。

デフォルトのバックボーンソースを1つのファイルのままにすることに同意しますが、ユーザーが特定の機能を望まない場合は、ソースを複数のファイルに分割することも追加できることを提案しました（これは維持するのにより多くの作業です）。

また、ブログ投稿で、ユーザーがBackboneのすべての機能を含めないようにすると、Backboneが企業環境でさらに使いやすくなることを提案しました。

そして、ちょうど好奇心が強い、追加された複雑さは何でしょうか？

たとえば、ユーザーがBackbone.jsでjQuery Mobileを使用していて、バックボーンルートを含めたくない場合のユースケースはどうでしょうか。

ソースから削除するだけです。 かなり明確にラベル付けされており、非常に簡単に実行できます。

そして、ちょうど好奇心が強い、追加された複雑さは何でしょうか？

私は、新規および既存の貢献者の複雑さについて言及しています。 新しいプロジェクトのコードを書くことは常に困難であり、私たちはそれを可能な限り奨励したいと思っています。 現在、Backboneには、ローカルファイルを提供するブラウザとテキストエディタのみが必要です。 ビルドシステム/ツールを必要とすることは大きなステップです。

そうは言っても、私は一般的にカスタムビルドに反対しているわけではなく、ブログ投稿で紹介するツールが好きです。 :)

そうです、各Backboneクラスオブジェクトには明確なラベルが付けられています（これが、コードベースを分割するのがとても簡単だった理由です）。 そうは言っても、ほとんどの開発者は、使用しているライブラリのソースに触れたくないと思います。

例として、Require.jsおよびAMDと互換性のないスクリプトを見てください。 定義メソッド内にlibをラップするのは簡単ですが、誰がそれをしたいですか？

しかし、はい、私はあなたがあまりにも多くの依存関係/複雑さを導入しようとしないことについてあなたが言っていることを聞きます。 これを別のプロジェクトとして保持し、バックボーンソースでコードを最新の状態に保つと思います。

うん-それは本当に素晴らしいプロジェクトだと思う...しかし、Backboneは、単純な単一のスクリプトであるという利点があります。 Backboneがインストールされている場合は、それがあり、期間があり、Backboneが提供するすべてのものが利用可能であると信頼できます。

braddunbar：ソースから削除するだけです。 かなり明確にラベル付けされており、非常に簡単に実行できます。

ああ、それは罠だ！ 品質、互換性、機能性を確保するための公式のビルドシステムを持つことはより良いことです。

jashkenas：うん-それは本当に素晴らしいプロジェクトだと思う...しかし、Backboneは、単純な単一のスクリプトであるという利点があります。

ええ、私も単一のファイルを掘ります。そのため、Lo-Dashは単一のファイルですが、カスタムビルドをサポートしています（ただし、jQueryはリポジトリ内の個々のファイルで機能します）。

カスタムビルドは素晴らしく、開発者がより細かく制御できるようになります。 Lo-DashとjQueryがカスタムビルドをサポートしている場合、不足しているのはBackbone; Dだけです。

おい、
興味のある方がいらっしゃいましたら、カスタムバックボーンビルドを生成するためのgruntプラグインを作成しました
「通常の」バックボーンソースファイル： https ：

今のところ実際にはテストされていません（ただし、ルーターと履歴のすべてを省略したバックボーンバージョンを実行しています）。
良い。 フィードバックを歓迎します。

@asciidiscoありがとう、あなたはロック！

browserifyまたはwebpackに切り替えると、両方の長所（複数のファイルと1つのファイル）を簡単に利用できるようになると便利です。

Eventsを個別のモジュールとして使用すると便利です。 オプションのModelとCollectionの依存関係を持つカスタムモジュールを構築する場合に非常に便利です。

AngularプロジェクトとAngularJSプロジェクトでバックボーンモデルとコレクションを使用しています。 コンセプトが素晴らしいので、モデルとコレクションだけが必要です。 私が使用しているのは、データアクセス層です。 AngularはUIレイヤーを提供しています。

最近、AngularアプリでBackboneJSを使用することでどのようにメリットが得られるかについての記事を書きました： https ：

BackboneJSをいくつかのコンポーネントに分割して、必要なものだけを含めることができるのは本当に素晴らしいことです。

@jashkenas srcファイルを複数のファイルに分割し、ビルドタスクでそれらを1つのファイルに連結して、両方を使用できるようにするのはどうでしょうか。

• 単純な単一ファイル
• ソースファイルを分割します
  ？