2018 年 5 月 24 日更新:元の投稿から +3 バージョンの Angular になりましたが、最終的に実行可能な解決策はまだありません。Lars Meijdam (@LarsMeijdam) は興味深いアプローチを思いつきました。これは一見の価値があります。(所有権の問題により、彼は最初にサンプルを投稿した GitHub リポジトリを一時的に削除する必要がありました。ただし、コピーが必要な場合は、彼に直接メッセージを送ることができます。詳細については、以下のコメントを参照してください。)
Angular 6 の最近のアーキテクチャの変更により、ソリューションに近づいています。さらに、Angular Elements ( https://angular.io/guide/elements ) はいくつかのコンポーネント機能を提供しますが、この投稿で最初に説明したものとはまったく異なります。
すばらしい Angular チームの誰かがたまたまこれに遭遇した場合は、この機能に非常に興味を持っている人が他にもたくさんいるように思われることに注意してください。バックログを検討する価値があるかもしれません。
Angular 2、Angular 4、Angular 5、またはAngular 6アプリケーションにプラグ可能な (プラグイン) フレームワークを実装したいと考えています。
(このプラガブル フレームワークを開発するための私の具体的な使用例は、小型のコンテンツ管理システムを開発する必要がある場合です。ここでAngular 2/4/5/6は必ずしも詳細に説明されていない多くの理由により、システムのほとんどのニーズにほぼ完全に適合します。)
プラグ可能なフレームワーク (またはプラグイン アーキテクチャ) とは、サード パーティの開発者が、プライマリ アプリケーションのソース コードに直接アクセスしたり、そのソース コードを知らなくても、プラグ可能なコンポーネントを使用してプライマリ アプリケーションの機能を作成または拡張できるようにするシステムを意味します。または内部の仕組み。
(「アプリケーションのソースコードや内部の仕組みに直接アクセスしたり、知識を持ったりすることなく」という言い回しは、中心的な目的です。)
プラグ可能なフレームワークの例には、 や などの一般的なコンテンツ管理システムが含まれWordPressますDrupal。
理想的な状況 (Drupal の場合と同様) は、これらのプラグ可能なコンポーネント (またはプラグイン) をフォルダーに配置し、アプリケーションにそれらを自動検出または検出させ、それらを魔法のように「機能させる」ことができるようにすることです。これを何らかのホットプラグ可能な方法で、つまりアプリの実行中に発生させるのが最適です。
私は現在、次の 5 つの質問に対する答えを (あなたの助けを借りて) 見つけようとしています。
- 実用性:アプリケーションのプラグイン フレームワークは
Angular 2/4/5/6実用的ですか? (これまでのところ、本当にプラグイン可能なフレームワークを で作成する実用的な方法は見つかりませんでしたAngular2/4/5/6。) - 予想される課題:
Angular 2/4/5/6アプリケーションのプラグイン フレームワークを実装する際に遭遇する可能性のある課題は何ですか? - 実装戦略:
Angular 2/4/5/6アプリケーションのプラグイン フレームワークを実装するために採用できる具体的な手法や戦略は何ですか? - ベスト プラクティス:
Angular 2/4/5/6アプリケーションにプラグイン システムを実装するためのベスト プラクティスは何ですか? - 代替テクノロジ: プラグイン フレームワークがアプリケーションで実用的でない場合、どの比較的同等のテクノロジ (たとえば) が最新の高度にリアクティブな Web アプリケーションに適しているでしょうか?
Angular 2/4/5/6React
一般に、次のAngular 2/4/5/6理由により、 の使用が非常に望ましいです。
- 当然のことながら、非常に高速です。
- 帯域幅をほとんど消費しません (初期ロード後)。
- フットプリントは比較的小さく (
AOTおよびの後tree shaking)、そのフットプリントは縮小し続けています。 - それは非常に機能的であり、Angular チームとコミュニティはエコシステムの急速な成長を続けています。
TypeScriptや_Observables- Angular 5 はサービス ワーカーをサポートするようになりました ( https://medium.com/@webmaxru/a-new-angular-service-worker-creating-automatic-progressive-web-apps-part-1-theory-37d7d7647cc7 )
- によって
Googleサポートされているため、将来にわたってサポートおよび拡張される可能性があります。
Angular 2/4/5/6現在のプロジェクトに使用したいと思います。を使用できる場合は、おそらく(サーバー側のレンダリング用に)Angular 2/4/5/6も使用します。Angular-CLIAngular Universal
上記の質問に関して、これまでのところ、私の考えは次のとおりです。見直して、フィードバックと啓発を提供してください。
Angular 2/4/5/6アプリはパッケージを消費しますが、これは必ずしもアプリケーション内でプラグインを許可することと同じではありません。他のシステム (例:Drupal) のプラグインは、システムによって自動的に「ピックアップ」される共通のモジュール ディレクトリにプラグイン フォルダをドロップすることで基本的に追加できます。ではAngular 2/4/5/6、パッケージ (プラグインの場合もあります) は通常、 を介してインストールされnpm、 に追加されてから、package.jsonのようにアプリに手動でインポートされapp.moduleます。Drupalこれは、フォルダーをドロップしてシステムにパッケージを自動的に検出させる方法よりもはるかに複雑です。プラグインのインストールが複雑になればなるほど、プラグインを使用する可能性は低くなります。方法があればもっといいのにAngular 2/4/5/6プラグインを自動的に検出してインストールします。Angular 2/4/5/6アプリケーションのアーキテクチャをすべて理解する必要なく、非開発者がアプリケーションをインストールし、選択したプラグインをインストールできる方法を見つけることに非常に興味があります。一般に、プラグ可能なアーキテクチャを提供する利点の 1 つは、サードパーティの開発者がシステムの機能を非常に簡単に拡張できることです。明らかに、これらの開発者は、プラグインするアプリケーションの複雑なコードのすべてに精通しているわけではありません。プラグインが開発されると、技術にあまり詳しくない他のユーザーは、アプリケーションと選択したプラグインを簡単にインストールできます。ただし、
Angular 2/4/5/6比較的複雑で、学習曲線が非常に長くなります。さらに複雑なことに、ほとんどの本番Angular 2/4/5/6アプリケーションはAngular-CLI、Angular Universal、およびも使用しWebPackます。プラグインを実装する人は、おそらく、これらすべてがどのように組み合わされるかについて、少なくともいくつかの基本的な知識を持っている必要があります。TypeScriptと合理的な知識NodeJS。サードパーティがプラグインを開発したくないほど、知識の要件は厳しいですか?ほとんどのプラグインには、クライアント側の出力だけでなく、サーバー側のコンポーネント (プラグイン関連データの保存/取得など) が含まれている可能性があります。
Angular 2/4/5特に、開発者が実行時に独自のテンプレートを注入することを (そして強く) 思いとどまらせます。これは重大なセキュリティ リスクをもたらすからです。プラグインが対応できる多くのタイプの出力 (例: グラフの表示) を処理するために、ある形式で別の形式で応答ストリームに挿入されるコンテンツをユーザーが作成できるようにする必要があるようです。Angular 2/4/5/6のセキュリティメカニズムを比喩的に細断することなく、このニーズにどのように対応できるのでしょうか。ほとんどの本番アプリケーションは、 ( ) コンパイル
Angular 2/4/5/6を使用してプリコンパイルされています。(おそらくすべてそうあるべきです。) コンパイル済みのアプリケーションにプラグインを追加 (または統合) する方法がわかりません。最良のシナリオは、メイン アプリケーションとは別にプラグインをコンパイルすることです。ただし、これを機能させる方法がわかりません。フォールバックは、含まれているプラグインを使用してアプリケーション全体を再コンパイルすることかもしれませんが、選択したプラグインとともにアプリケーションを (自分のサーバーに) インストールしたいだけの管理ユーザーにとっては、少し複雑になります。Ahead of TimeAOTアプリケーション、特にコンパイル済みの
Angular 2/4/5/6アプリケーションでは、1 つのコードの誤りや競合によってアプリケーション全体が機能しなくなる可能性があります。Angular 2/4/5/6アプリケーションは、常にデバッグが最も簡単であるとは限りません。不適切なプラグインを適用すると、非常に不快な体験が生じる可能性があります。私は現在、行儀の悪いプラグインを適切に処理するメカニズムを知りません。