2013-08-10 6 views
10

Angularjsを試したかったのですが、しかし、どこのアプリケーションを配置すべきかを決めるのは難しかったです。AngularjsとRailsアプリケーションを独立したコンポーネントとして分離する

私はバックエンドにRailsフレームワークを使用しています。私はチュートリアルを見てきましたが、ここでは角型アプリケーションはassets/javascriptフォルダの下にあります。

私はassets/javascriptフォルダの中に暮らす代わりに、私がそれを私のレールディレクトリの外に完全に居住させることができるのだろうかと思っていました。そうすれば、バックエンドとフロントエンドを完全に分離することができます。 (これはお勧めですか?)

私は資産パイプラインも多くの資産をプリコンパイルすると考えています。 angularjsアセットを分離する場合、アセットをあらかじめコンパイルする必要がありますか?

おかげ

答えて

5

あなたは作男ベースのワークフローを使用できます:あなたは切り離さフロントエンドで始まる場合は、滞在することができますので、使用は最初に皮肉っ

をバックエンドとフロントエンドロジック間のフォーカス切り替えを失うことはありません。単一ページアプリケーションを構築する利点は、バックエンドAPIとは独立して開発できることです。 http応答の疑似化については、(。$ httpBackend)を参照してください。

+0

ああ、面白そうです。したがって、私が理解しているところから、angularjsをassets/javascriptアプリに追加すると、anglejsアプリをプリコンパイルする必要はありません。私が不満なワークフローを使用した場合、展開する前にanglejsを再コンパイルする必要があります。それは正しいでしょうか? – Karan

+0

ああ、一度私はアプリをgruntを使ってビルドします、これはrailsapp/publicディレクトリの下に置かれるべきですか? – Karan

4

私も同様の質問をしてきました。あなたがAngularJSをあなたのレールのアセットパイプラインに直接組み込むことを可能にする良いツールがいくつかあります.Angularをちょっとだけ欲しいと思ったら、私はよく見えます。

しかし、角型のフロントエンド、つまり1ページのウェブアプリが必要な場合、最終的には互換性とツールのいくつかによって制限されると思います。私はRailsの宝石がAngularに追いついていないように感じるので、バージョンの競合になるでしょう。私はまた、スタンドアロンとしてAngular用のツールを見てきました。私はng-boilerplateプロジェクトテンプレートに非常に似ています。私はカルマのようなテスト用ツールの多くを好んでおり、カルマとレールを統合する方法を実際に選んだわけではありません。

そのため、私は最終的に私は2つの別々のものを保つと決めました。最初は、レールアプリケーションと別の角度アプリケーション(別のディレクトリ)を作成することでそれを行いました。私は角の端のフレームワークとしてng-boilerplateを使用しました。私はtutorial on thatと書いた。これは最終的には少しイライラしていました。私はsome more thoughts on itと書いていましたが、主な煩わしさは私が2つのgitリポジトリを持っていて、同期させておくのは面倒でした。また、2つのディレクトリにまたがるIDEで作業するのも面倒です。私は同じフォルダ内のレールと角にシフトしてしまいました。そして、それらはそれぞれがそのプロジェクト内の異なるディレクトリを使用するので、うまくいくように見えます。

この現在の構造では、ng-boilerplateに付属のgrunt setupを使用して、すべてのコードを小さくし、パッケージ化し、カルマユニットテストを実行します。私はまだエンドツーエンドのテストを打ち切っていないが、それは私のリストに載っている。私はこれが比較的生産的な作業環境であることを発見しました。私のページ、コントローラー、カルマテストケースのために私が選んだ構造は、コードを繰り返しています(私は読みやすさを保つためにそれを考慮しないことを選択しています)。私は、私のためのjavascriptフレームワークを作成するためにレール足場ジェネレータを拡張する予定です - 私は人レール足場を作成するとき、それはまた私のための人angularjs足場を作成します。もし私がその仕事をしたら、私はここで更新します。

編集:私はあなたがレールを生成する際にレールが自動的にangularJS要素を生成することを可能にするだけでなく足場の作業を完了したモデル/コントローラなどのブログ記事はこちら:我々は、使用しているhttp://technpol.wordpress.com/2013/09/24/rails-generator-to-generate-angular-views/

1

私たちがRails ERBテンプレートを使用していた方法で、RailsアプリケーションでAngularJSを実行しますが、必要に応じてngディレクティブを使用するように切り替えます。

上記の設定では、bower/bower-rails gemを使用しました。これにより、bowerを使用して角度パッケージとその依存関係を管理できます。これをjavascriptディレクトリのrepoにコミットし、Railsのアセットパイプラインで処理します。

この設定は、ERBテンプレートとAngularjsの間で50〜50%以上のビューを分割していることを考慮すると、うまくいきました。

以下のリンクでは、この設定の詳細を:

0

あなたのAPIサービスを分離する多くの利点があります(この場合はレール)あなたのフロントエンドのコンポーネント。私たちがiOS/androidアプリケーションの場合と同じように、角クライアントは独立したエンティティとして独自に生きることができます。 s3または静的なWebサイトのホストに展開できる静的なWebサイトになります。それはちょうどあなたのAPIサービスと通信する必要があります。あなたはそれを可能にするためにCORSをセットアップすることができます。このワークフローの

いくつかの利点

  • あなたはRailsアプリケーションのサブセットであるrails-apiを、使用することができます。 apisをビルドするためにレールを使用するだけであれば、完全なレールアプリが提供するすべての機能を持つことは意味がありません。その軽量で、速く、MVCアーチよりもAPIの最初のアーチを構築する方向にもっと傾いています。
  • yeoman angular-generatorを使って角型アプリケーションを生成し、ビルド(concat、uglify、cdnifyなど)と依存関係(角モジュール)を管理するためにgruntを最大限に活用することができます。
  • デプロイメントは柔軟になります。もう片方を押すことに頼る必要はありません。
  • バックエンドのスタックを変更する予定がある場合(たとえば、play/revelするためのrails)、クライアントコンポーネントについて心配する必要はありません。
  • フロントエンドとRailsバックエンドの開発を分割することで、2つの開発チームで作業を配布し、アプリケーション全体を非常に拡張性のあるものに保つことができます。

このアプローチには欠点も1つあります。 2つの別々のリポジトリにアプリケーションを置くことで、簡単に完全な統合テストを行うことはできません。だからあなたは別々にアプリをテストする必要があります。あなたは角のアプリをテストするためにapisを模擬することができます。

私たちはこのアプローチを使用しており、他の人にも同じことをお勧めします。 依存性が低い&より生産性が向上します。

関連する問題