看了AngularJS官网的一些例子，觉得很给力，将开发人员的注意力从满屏的DOM操作中转移到传统的业务中，以数据为中心，绑定View，实现二者的绑定和更新。
自己平时做的较多的是地图类应用，类似百度地图PC版和腾讯地图那种，考虑过用AngularJS，可是想来想去觉得不大合适,主要原因是地图类应用一般依赖第三方地图API，比如基于百度地图需要百度地图Javascript API，腾讯也有自己的JS API，这些API的普遍概念是提供一个页面元素，然后在这个元素里创建一个可交互的地图界面。
1 地图初始化
假如我们希望在页面p#map-p这个位置创建一个地图，通常代码如下：
<p id="map-p"></p>
var map=new BMap.Map("map-p",{});
这个map对象有包含了许多方法比如添加叠加物、地图绘制等，这些方法大多数又会引起地图界面的更新，比如下面的代码会在地图界面上弹出一个窗口：
map.addInfoWindow();
如果按照AngularJS的里面，我们应该在页面里声明一个地图的View,类似这样
这样的话，我们需要创建一个bd-map的directive，意味着需要针对不同的地图SDK建立不同的directive，虽然这个是一劳永逸的工作，算起来这个不算啥。
2 地图交互
这一块我觉得如果完全通过AngularJS封装会导致把简单问题复杂化，比如我从后台请求了10个酒店的数据markers，每个酒店有一个位置信息，一般情况下，我会这么干：
for(var i......){
var item=...
var marker=new BMap.Marker(...);
map.addOverlay(marker);
}
但是按照AngularJS的理念，markers明显应该是某个scope里面的数据，我们的业务应该关注在这个数据的获取和更新上，界面的更新应该交由directive完成，于是我好像还需要创建marker对应的directive，到这一步我已经觉得有点复杂了，有一种多此一举的感觉。
3 事件
地图本身，以及地图上面的叠加物多少都有一些事件的，比如你点击了地图，点击了一个图标等等，这些在地图类应用里面很常见，如果使用AngularjS的话好像又要封装一下。
我的感觉是，地图类SDK本身已经可以看作是一个MVC的实现，比如你把地图的各种参数（数据）设置好，然后通过一句SDK提供的接口，一个地图界面（View）就创建了，通过修改地图中心点等接口，地图视图也跟着变化，这种情况下跟AngularJS强行结合好像会适得其反，这种情况我觉得还是Backbone更合适一点，毕竟Backbone的view还是比较灵活的，Model的渲染完全在自己手里，可以手工操作dom，也可以调用通过地图SDK完成，并没有耦合的很紧密，不需要额外的工作。
学AngularJS时间比较短，大概1周，有这种想法，不知道有没有哪里理解不到位的地方？
补充，我觉得AngularJS最适合的场景是应用只需要原生的页面元素的组合，比如不同的view只是将数据注入到不同的template的中，比如todolist，gmail这种，就是原生html元素的拼凑。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
まず、たった 1 週間で Angular を学び、深く考えるのは簡単ではありません。最初はあなたが Angular をうまく使えると思います。
第二に、残念ながら、私は地図アプリケーションにあまり触れたことがなく、特にそれらの SDK がどれほど複雑であるか知らないため、Angular に切り替えることで状況が改善されるかどうかを言うのは難しいです。
最初に余談ですが、特に Web アプリの場合、API と SDK は異なると思います。 API は通常、データ交換に使用され、DOM オブジェクトは関係しません。SDK は、独自のカプセル化されたロジックのセットを持ち、通常は DOM と緊密に結合されたインターフェイス呼び出しを提供します。
API は Angular で非常にうまく処理でき、組み込みのリソースは API サービスのカプセル化に特に適しています。ただし、Angular の世界では、SDK 自体は比較的完全にカプセル化されているため、DOM を直接操作しないことに重点が置かれているため、SDK の統合はより複雑で困難になります。この現象は実際に存在しており、その解決策は、ディレクティブを使用して DOM インタラクションを抽象化し、サービスを使用して論理部分を抽象化するというものと実際に似ています。たとえば、Highcharts のようなものについて考えてみましょう。これは地図 SDK ではありませんが、同様に複雑でよくカプセル化されたサードパーティ ライブラリです。Angular との統合は簡単ではなく、多くの落とし穴があるため、多くのユーザーが存在します。再利用のために Angular + Highcharts モジュールを個別に作成しました。この領域の例を検索して実装がどのようになっているのかを確認し、それが適切かどうかを推定することができます。
Angular のカプセル化は単純な問題を複雑にしますか?時々そうです。それは実際には問題そのものに依存します。Angular は万能薬ではなく、あらゆるタイプのアプリケーションに適しているわけではありません。バックボーンは現在の仕事をこなせると思いますか?その後は「トレンド」を無視して使い続けます。一方で、実際に Angular には Backbone に対応できない部分があることがわかった場合は、思い切って Angular を使い始めてください。とにかく、解決すべき問題に触れている限り、完璧なフレームワークはありません。触れなければ心配する必要はありません。
さらに、この議論を拡張したいと思います。
テクノロジーを大きく 3 つの部分に分けてみましょう。過去のテクノロジー (または成熟したテクノロジー)、現在のテクノロジー (または人気のあるテクノロジー)、未来のテクノロジー (またはトレンドを表すテクノロジー) です。
私たちは、「過去の技術」を「現在の技術」に置き換えることを衝動的に決断しがちですが、一般的にコストはかかりますが、メリットがないわけではなく、適切に対処すればメリットは必ずあります。常にコストを上回ります。
問題は、「現在のテクノロジー」には常に多くの選択肢があることであり、私たちはその選択に陥りやすく、決断することが大したことではないとさえ感じるかもしれません。過去の技術に戻ると、少なくとも安全です。
私はこの1年間に何度もこの質問に答えてきましたが、私は自分自身の判断を表明することしかできません。
私は「将来のテクノロジー」を学び理解することで「現在のテクノロジー」を選択し、「過去のテクノロジー」を断固として置き換える傾向があります。
「過去の技術」は遅かれ早かれ時間の問題です。たとえコストが高くても、私は「流れに逆らって前進しなければ撤退する」タイプです。 。
「現在のテクノロジー」が「将来のテクノロジー」と一致しているかどうかは、実際には、作者/チームのテクノロジートレンドの理解と判断、そしてあなたの個人的な理解と判断を反映しています。自信も意思決定能力もありません。自分自身を見つめなければなりません。
なぜ私が「未来のテクノロジー」について話すのですか?あなたが作成した地図アプリケーションを例に挙げると、現在の SDK はどれくらいの期間使用できると思いますか?コード自体だけでなく、テクノロジー スタックも含めて、SDK ベースの DOM 指向のマップ アプリケーション開発モデルはどれくらい続くのでしょうか?
この質問に答えるのが難しい場合は、まず Google マップなどの業界リーダーの開発履歴を確認し、次に業界のリーダーの技術アーキテクチャについて学ぶことができます。
WebComponents が Web アプリの次の大きなものになることはほとんどの人が知っており、WebComponents が「現在のテクノロジー」になるとき (おそらくそう長くはかからない)、現在のセットは SDK に基づいています。 DOM 指向のマップ アプリケーション開発モデルには進歩と存続の余地はありますか?
私には答えがわかりませんし、あなたに「価値観」を教え込むつもりもありません。私がどのように考え、どのように決定するかを説明するだけです。問題の説明からすると、あなたは単なるプログラマーではなく、チーム内で「アーキテクト」の役割も担っているのではないかと思われます。そのため、これについてさらに詳しく説明します。つまり、意味はたったの 4 つの言葉です。 。
マップ部分はangularとは何の関係もないように感じます。マップをangularの外に置くことも、angularでマップ部分をコンパイルしないようにすることもできます。ただし、法線マップの使用には影響しません (結局のところ、法線マップを処理するために angular が必要な場合は、angular に処理させます)。
Angular を使用していますが、ページ上のすべての要素が Angular に関連している必要はありません。必要な場合には Angular を使用してください。 Angular を使用するためだけに、すべてを Angular に接続しないでください。
私は以前に一定期間 Openlayers 開発を行ったことがあり、Angularjs についてもある程度の予備知識があります
これらは 2 つの異なる分野に属するフレームワークです
Map API は G の表示に重点を置き、AngularJS は IS の表示に重点を置いています。たとえば、この 2 つは矛盾しません。 クエリを作成すると、サーバーは一連の要素情報を返します。一般的なアプローチは、要素を処理し、情報を取得し、テンプレートを介して HTML を結合して結果リストを表示することです。これらの要素情報をレイヤーに追加し、地図上に描画します。
地図 API は地理要素の描画を完了するのに役立ちますが、情報データは自分たちで制御する必要があります。
マウスと要素の相互作用の例をシミュレートしてみましょうリーリー
//疑似コード (オリジナル)、またはその他のフロントエンド テンプレートリーリー
//AngularJSリーリー
もちろん、MVC は他の js テンプレートを使用して実行することもできますが、AngularJS を使用する利点は、単一ページのアプリケーションであることと、中間の実装プロセスがすべての道はローマに通ずであることです。ただし、要素を強調表示するときに、現在の li 要素またはその他の新しい要件を強調表示できます。この時点で、コードを変更した箇所が同じ場所にないことがわかります。
元の方法では、イベントバインディングプロセス中にスタイルの切り替えを追加する必要があります
//AngularJSリーリー
簡単に言うと、メンテナンスが早くなり、本来の業務には影響がありません実際、マップ SDK はすでに DOM 管理を完了するのに役立ちます。作業のこの部分は ng で繰り返されるため、それに ng を課すと奇妙に感じられます。マップ SDK 自体が ng モードで提供されている場合は、異なる開発エクスペリエンスがもたらされる可能性があります。
最初は少し面倒だと思いましたが、徐々にAngularを理解するにつれて簡単になりました。
どのような JS フレームワークであっても、オブジェクトには参照が渡されることを知っておく必要があります。
次に、SDK については、実際に SDK オブジェクトをサービスに結び付けます。コールバック内の $apply に注意してください