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

First of all, it’s not easy to be able to think about this in depth after only one week of learning Angular. It’s much better than me at the beginning. I believe you can use Angular very well.

Secondly, unfortunately, I haven’t had much exposure to map applications, especially because I don’t understand how complicated those SDKs are, so it’s hard for me to say whether switching to Angular will make things better.

Let me digress first, I think API and SDK are different, especially for webapps. APIs are usually used for data exchange and generally do not involve DOM objects; SDKs are what you are talking about. They have their own set of encapsulated logic and usually provide interface calls that are tightly coupled with the DOM.

API can be handled very well by Angular, and the built-in Resource is particularly suitable for encapsulating API services. However, the SDK itself is relatively complete in its encapsulation. In the Angular world, the emphasis on not directly operating the DOM makes the integration of the SDK more complicated and difficult. This phenomenon does exist, and the solution is indeed similar to what you think. Use directives to abstract DOM interaction, and use services to abstract the logic part. For example, think about something like Highcharts - although it is not a map SDK, it is a similar complex and well-encapsulated third-party library - its integration with Angular is not easy, and there are many pitfalls, so there are many People have made Angular+Highcharts modules separately for reuse. You can search for examples in this area to see how the implementation is, and you can probably estimate whether it is suitable.

Does Angular’s ​​encapsulation complicate simple problems? Sometimes yes. It really depends on the problem itself, Angular is not a panacea, it is not suitable for all types of applications. Do you think Backbone can handle your current job? Then keep using it and ignore the "trend". On the other hand, when you really find that Angular has parts that Backbone can't match, then decisively start using Angular. Anyway, no framework is perfect. As long as you touch the problems that need to be solved, you have to solve them. If you don't touch them, there is no need to worry.

In addition, I would like to extend this discussion.

Let us roughly divide technology into three parts: past technology (or mature technology), current technology (or popular technology), and future technology (or technology that represents trends).

It is easy for us to impulsively decide to replace "past technology" with "current technology". Generally speaking, there will be costs, but it will definitely not be without benefits, and if handled properly, the benefits will always outweigh the costs.

The problem is that there are always many choices in "current technology". It is easier for us to fall into this choice and be unable to make a decision. We may even feel that it is not a big deal to go back to the technology of the past, at least it is safe.

I can't say what is right. I have answered this question many times in the past year and I am a little tired. I can only express my own judgment.

I tend to choose "current technology" by learning and understanding "future technology" and resolutely replace "past technology".

"Past technology" will always pass. Sooner or later is just a matter of time. I am the type of person who "sails against the current and retreats if I don't advance", even if the cost is high.

Whether "current technology" is in line with "future technology" actually reflects the author/team's understanding and judgment of technology trends, and also reflects your personal understanding and judgment. There will be a bit of gambling involved. Do you have this? Confidence and decision-making ability depend on yourself.

Why do I talk about "future technology"? Take the map application you make as an example. How long do you think the current SDKs can be used? Not just their code itself, but their technology stack. How long can the SDK-based DOM-oriented map application development model last?

If you find this question difficult to answer, then first you can review the development history of industry leaders, such as Google Maps; secondly, you can learn about the technical architecture of the leaders in the industry.

We almost all know and can expect that WebComponents will be the next big thing in webapps. So, when WebComponents becomes "current technology" (maybe it won't be long), the current set is based on SDK and uses DOM as the How much room for progress and survival does the oriented map application development model have?

I don’t know the answer, and I don’t want to instill any “values” in you. I just describe how I think and make decisions. From your description of the problem, I feel that you are not just a programmer. Maybe you also play an "architect" role in your team, so I will say more about this. The total meaning is just four words: Think far and wide.

Answer 2

I feel that the map part does not have to have anything to do with angular. You can put the map outside of angular or let angular not compile the map part. But it does not affect you to use normal map (after all, it has been encapsulated by them). When you need angular to handle it, let angular handle it.

Although you use Angular, not all elements on the page must be related to Angular. Just use it where it is good at. Don't hook everything up with Angular just to use Angular.

Answer 3

I have done Openlayers development for a period of time before, and I also have some preliminary understanding of Angularjs

These are frameworks belonging to two different fields
Map API focuses on the display of G, and AngularJS focuses on the display of IS. There is no conflict between the two. For example
When we make a query, the server returns a series of element information. Now the general approach is to facilitate the elements, obtain the information, and then piece together the HTML through the template to display the result list. At the same time, add these element information to the layer and draw onto the map.

The map API helps us complete the drawing of geographical elements, but the information data needs to be controlled by ourselves.

Let’s simulate an example of mouse and element interaction

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

//Pseudocode (original), or other front-end templates

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>

Of course, MVC can also be carried out using other js templates, but the advantage of using AngularJS is that it is a single-page application, and the intermediate implementation process is just that all roads lead to Rome.

However, the requirements have changed. While highlighting the elements, we can highlight the current li element or other new requirements. At this time, we will find that the point where we changed the code is not in the same place

The original method requires adding style switching during the event binding process

//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>

To put it simply, maintenance becomes faster and the original business is not affected.

Answer 4

Indeed, the map SDK has already completed the DOM management for you. This part of the work is repeated with ng, so it will feel weird if you impose ng on it. If the map SDK itself is provided in ng mode, it may bring a different development experience.

Answer 5

I thought it was a bit troublesome at first, but as I gradually understood Angular, it became easier.
You must know that no matter what JS framework, objects are passed references.
Then for the SDK, actually tie the SDK object to a service. Just pay attention to $apply in the callback