angular.js - AngularJS是不是不适合地图类应用

Question

看了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元素的拼凑。

Answer 1

Tout d’abord, ce n’est pas facile de pouvoir réfléchir à cela en profondeur après seulement une semaine d’apprentissage d’Angular. C’est bien mieux que moi au début, je pense qu’on peut très bien utiliser Angular.

Deuxièmement, malheureusement, je n'ai pas été beaucoup exposé aux applications cartographiques, notamment parce que je ne sais pas à quel point ces SDK sont compliqués, il m'est donc difficile de dire si le passage à Angular améliorera les choses.

En guise de digression, je pense que l'API et le SDK sont différents, en particulier pour les applications Web. Les API sont généralement utilisées pour l'échange de données et n'impliquent généralement pas d'objets DOM ; vous parlez des SDK. Ils ont leur propre ensemble de logique encapsulée et fournissent généralement des appels d'interface étroitement couplés au DOM.

L'API peut être très bien gérée par Angular, et la ressource intégrée est particulièrement adaptée à l'encapsulation des services API. Cependant, le SDK lui-même est relativement complet dans son encapsulation. Dans le monde Angular, l'accent mis sur le fait de ne pas exploiter directement le DOM rend l'intégration du SDK plus compliquée et difficile. Ce phénomène existe et la solution est en effet similaire à ce que vous pensez. Utilisez des directives pour abstraire l'interaction DOM et utilisez des services pour abstraire la partie logique. Par exemple, si vous pensez à quelque chose comme Highcharts - bien qu'il ne s'agisse pas d'un SDK de carte, il s'agit d'une bibliothèque tierce similaire, complexe et bien encapsulée - son intégration avec Angular n'est pas facile et il existe de nombreux pièges, il y a donc de nombreuses personnes ont créé des modules Angular + Highcharts séparément pour les réutiliser. Vous pouvez rechercher des exemples dans ce domaine pour voir comment se déroule l'implémentation, et vous pouvez probablement estimer si elle est appropriée.

L’encapsulation d’Angular complique-t-elle des problèmes simples ? Parfois oui. Cela dépend vraiment du problème lui-même, Angular n’est pas une panacée, il ne convient pas à tous les types d’applications. Pensez-vous que Backbone peut gérer votre travail actuel ? Alors continuez à l’utiliser et ignorez la « tendance ». D'un autre côté, lorsque vous constatez vraiment qu'Angular a des éléments que Backbone ne peut pas correspondre, alors commencez de manière décisive à utiliser Angular. Quoi qu'il en soit, aucun framework n'est parfait tant que vous touchez aux problèmes qui doivent être résolus. Si vous ne les touchez pas, il n'y a pas lieu de s'inquiéter.

De plus, j'aimerais prolonger cette discussion.

Divisons grossièrement la technologie en trois parties : la technologie passée (ou technologie mature), la technologie actuelle (ou technologie populaire) et la technologie future (ou technologie qui représente des tendances) .

Il est facile pour nous de décider impulsivement d'utiliser la « technologie actuelle » pour remplacer la « technologie passée ». D'une manière générale, il y aura des coûts, mais cela ne sera certainement pas sans avantages, et s'ils sont gérés correctement, les avantages seront toujours. dépassent les coûts.

Le problème est qu'il y a toujours beaucoup de choix dans la « technologie actuelle ». Il est plus facile pour nous de tomber dans ce choix et d'être incapable de prendre une décision. Nous pouvons même avoir l'impression que ce n'est pas grave de revenir en arrière. à la technologie du passé, au moins elle est sûre.

Je ne peux pas dire ce qui est juste. J'ai répondu à cette question tellement de fois au cours de la dernière année que je suis un peu fatiguée.

J'ai tendance à choisir la « technologie actuelle » en apprenant et en comprenant la « technologie du futur » et à remplacer résolument la « technologie du passé ».

La « technologie passée » passera toujours, tôt ou tard, ce n'est qu'une question de temps. Je suis le genre de personne qui « navigue à contre-courant, si je n'avance pas, je reculerai », même si cela en coûte. est élevé.

La question de savoir si la « technologie actuelle » est cohérente avec la « technologie future » reflète réellement la compréhension et le jugement de l'auteur/de l'équipe sur les tendances technologiques, ainsi que votre compréhension et votre jugement personnels. Il y aura un peu de jeu, n'est-ce pas ? Cette confiance et cette capacité de prise de décision dépendent de vous.

Pourquoi est-ce que je parle de « technologies du futur » ? Prenons l'exemple de l'application cartographique que vous créez. Combien de temps pensez-vous que les SDK actuels peuvent être utilisés ? Pas seulement leur code lui-même, mais aussi leur pile technologique. Combien de temps le modèle de développement d’applications cartographiques orientées DOM basé sur un SDK peut-il durer ?

Si vous trouvez difficile de répondre à cette question, vous pouvez d'abord consulter l'historique de développement des leaders de l'industrie, tels que Google Maps, et deuxièmement, vous pouvez en apprendre davantage sur l'architecture technique des leaders de l'industrie.

Nous savons presque tous et pouvons nous attendre à ce que les WebComponents soient la prochaine grande nouveauté dans les applications Web. Ainsi, lorsque les WebComponents deviendront la « technologie actuelle » (ce ne sera peut-être pas long), l'ensemble actuel est basé sur le SDK et combien. Quelle est la marge de progrès et de survie du modèle de développement d'applications cartographiques orientées DOM ?

Je ne connais pas la réponse et je ne veux pas vous inculquer de « valeurs », je décris simplement comment je pense et prends des décisions. D'après votre description du problème, je pense que vous n'êtes pas seulement un programmeur. Peut-être que vous jouez également un rôle d'"architecte" dans votre équipe, je vais donc en dire plus à ce sujet. Le sens total n'est que de quatre mots : pensez loin. .

Answer 2

Je pense que la partie carte n'a rien à voir avec angulaire. Vous pouvez mettre la carte en dehors d'angular ou laisser angulaire ne pas compiler la partie carte. Mais cela ne vous empêche pas d'utiliser la carte normale (après tout, elle a été encapsulée par eux). Lorsque vous avez besoin d'angular pour la gérer, laissez-la gérer.

Bien que vous utilisiez angulaire, tous les éléments de la page ne doivent pas nécessairement être liés à angulaire. Utilisez-le simplement là où il est bon. Ne connectez pas tout à Angular juste pour utiliser Angular.

Answer 3

J'ai déjà développé Openlayers pendant un certain temps et j'ai une compréhension préliminaire d'Angularjs

Ce sont des frameworks appartenant à deux domaines différents
L'API Map se concentre sur l'affichage de G et AngularJS se concentre sur l'affichage d'IS. Il n'y a pas de conflit entre les deux. Par exemple
. Lorsque nous effectuons une requête, le serveur renvoie une série d'informations sur les éléments. Désormais, l'approche générale consiste à faciliter les éléments, à obtenir les informations, puis à rassembler le HTML via le modèle pour afficher la liste des résultats en même temps, à ajouter. ces informations sur les éléments à la couche et dessinez Accédez à la carte.

L'API cartographique nous aide à compléter le dessin des éléments géographiques, mais les données d'information doivent être contrôlées par nous-mêmes

.

Simulons un exemple d'interaction entre la souris et les éléments

function highlight(feature){
    map.control.select(feature)
}

//Pseudocode (original) ou autres modèles front-end

var i=0,l=arrs.length,str=[],$case,map;
for(;i<l;i++){
    str.push("<li>"+arrs[i].name+"</li>")
}
$case.on("mouseenter","li",function(){
    var index=$(this).index();
    var feature=arrs[index];
    highlight(feature);
})

//AngularJS

<li ng-repeat="item in arrs" ng-mouseenter="highlight(item)">{{item.name}}</li>

Bien sûr, MVC peut également être réalisé à l'aide d'autres modèles js, mais l'avantage d'utiliser AngularJS est qu'il s'agit d'une application d'une seule page, et le processus de mise en œuvre intermédiaire consiste simplement à ce que tous les chemins mènent à Rome.

Cependant, les exigences ont changé. Lors de la mise en évidence des éléments, nous pouvons mettre en évidence l'élément li actuel ou d'autres nouvelles exigences. À ce moment, nous constaterons que le point où nous modifions le code n'est pas au même endroit<🎜. >

La méthode originale nécessite l'ajout d'un changement de style pendant le processus de liaison d'événement

//AngularJS

<li ng-repeat="item in arrs" 
    ng-mouseenter="highlight(item);item.active=true"
    ng-mouseleave="item.active=false"
    ng-class="{'highlight':item.active}"
    >{{item.name}}</li>

Pour faire simple, la maintenance devient plus rapide et l'activité d'origine n'est pas affectée.

Answer 4

En effet, le SDK map a déjà terminé la gestion du DOM pour vous. Cette partie du travail est répétée avec ng, cela semblera donc étrange de lui imposer ng. Si le SDK cartographique lui-même est fourni en mode ng, il peut apporter une expérience de développement différente.

Answer 5

Je pensais que c'était un peu gênant au début, mais au fur et à mesure que j'ai compris Angular, c'est devenu plus facile.
Vous devez savoir que quel que soit le framework JS, les objets reçoivent des références.
Ensuite, pour le SDK, liez l'objet SDK à un service. Faites simplement attention à $apply dans le rappel

.