私はsymfony 3.0を使用しており、Symfonyに適したフロントエンドフレームワークを選択したいと考えています。symfonyフロントエンドフレームワーク
いくつかのオプションがReactJs、AngularJS、EmberJs、イオン、等...
要件
フロントエンドのフレームワークを選択するために私を導くあなたがしなければならないとき複雑さが追加されますajax経由でロードされるいくつかのフォームコンポーネントを持つネストされたコレクションを管理する（フォームを破るdom名 symfony convention）
まず「フレームワーク」は必要ありません。基本的な動的強化よりも多くのことをしたいのであれば、より多くの意見を取り入れたフロントエンドが役に立つかもしれません。あなたがやってみたいのは、若干のUXの改良点を追加することだけです.JSやマイナーライブラリを使うのは、おそらく簡単な時間でしょう。 （古典的な答えはjQueryですが、最近は通常jQueryが必要ありません。）
第2に、フロントエンド作業のための現在の "ベストツール"には、JSのビルドステップが必要です。 ReactとAngularの場合でも、ライブラリ/フレームワークコードをCDNにリンクすることで、直接作成して管理する単一のJSファイルに分割することができますが、これはおそらく最も困難な方法です。おそらく、Webpack、Babel、Typescript、または同じ仕事をする競合するツールなどのツールを使い慣れている方が良いでしょう。
私の個人的な一般的なは、WebpackとBabelを使って、Reactを使ってアプリケーションを構築することを前提としています。私は、Reactを使用することで、高度に保守可能なソフトウェアにつながると思います。
リアクションはフレームワークではなく、ajaxリクエストやフォームを送信するためのものは含まれていません。これはビューライブラリです。つまり、送信ボタンを使用して通常のHTMLフォームをレンダリングするオプションです。 Angularやその他のフレームワークでの大きな経験がなければ、あなたはおそらくそれを行うことができますが、しばしば特定のAjaxフローを提供することもあります。これはあなたのサーバーで処理するのがかなり簡単なはずです。
偉大な答え。私はReactも選択したいと思います。なぜなら、それは本当にフレームワークではないからです。私がそれを取り除くことを選択すれば、将来的には影響が少なくなります。私がフレームワークを使用したい理由は、私が純粋なJqueryで行っているこのUI操作が将来的にはもっと複雑になるのではないかと心配しています。反発するには+1ポイント？ – bsap
フレームワークを使用して操作を行う場合、そのフレームワークを使用しているときにのみ機能するため、再利用可能性は低くなります。たとえば、fetch（とpolyfillは現在）といくつかの関数ラッパーを使用すると、そのコードはReact、Riot、plain javascript、および潜在的にいくつかのフレームワークで動作します。一方、Angularの（1.x）HTTPサービス（メモリからの非現在の例）を使用する場合、そのコードはAngularでしか動作しません。 –
私は実際にSymfony固有の統合の話題に触れていないことを認識しています。 Symfony（2または3）はフロントエンドに非常に不自然です。それはそれ自身の生成されたフォームのための組み込みのハンドラを持っていますが、ヘルパーであり、要件ではありません。簡単にJSONリクエストを解析してそこから作業したり、GET/POSTパラメータを直接読むことができます。 –