angular.js - Is AngularJS not suitable for map applications?

Question

After reading some examples on the AngularJS official website, I think it is very powerful. It shifts the developer's attention from full-screen DOM operations to traditional business, focusing on data, binding View, and realizing the binding of the two. and updates.

I usually work on map applications, such as Baidu Map PC version and Tencent Map. I have considered using AngularJS, but after much deliberation I feel it is not suitable. The main reason is that map applications generally rely on third parties. Map API, for example, based on Baidu Map, Baidu Map Javascript API is required. Tencent also has its own JS API. The general concept of these APIs is to provide a page element and then create an interactive map interface in this element.

1 Map initialization

If we want to create a map at the page p#map-p, the usual code is as follows:

<p id="map-p"></p>

var map=new BMap.Map("map-p",{});

This map object contains many methods, such as adding overlays, map drawing, etc. Most of these methods will cause updates to the map interface. For example, the following code will pop up a window on the map interface:

map.addInfoWindow();

If we follow AngularJS, we should declare a map View on the page, similar to this

In this case, we need to create a bd-map of directive, which means that we need to establish different directives for different map SDKs. Although this is a once-and-for-all job, it is not a big deal.

2 Map interaction

I think if this area is completely encapsulated through AngularJS, it will complicate simple problems. For example, I requested the data of 10 hotels from the background markers. Each hotel has a location information. Under normal circumstances, I will do this Dry:

for(var i......){
  var item=...
  var marker=new BMap.Marker(...);
  map.addOverlay(marker);
}

But according to the concept of AngularJS, markers should obviously be the data in a certain scope. Our business should focus on the acquisition and update of this data, and the update of the interface should be completed by directive, so It seems that I still need to create the directive corresponding to marker. At this point, I already feel that it is a bit complicated and feels like it is unnecessary.

3 Events

The map itself and the overlays on the map have some events, such as you clicked on the map, clicked on an icon, etc. These are very common in map applications. If you use AngularjS, it seems that you need to encapsulate them. .

My feeling is that the map SDK itself can be regarded as an MVC implementation. For example, you set the various parameters (data) of the map, and then use the interface provided by the SDK to create a map interface (View) It is created. By modifying the map center point and other interfaces, the map view also changes accordingly. In this case, it is similar to Angular. Forcibly combining JS seems to be counterproductive. In this case, I think Backbone is more suitable. After all, Backbone's view is relatively flexible. The rendering of the Model is completely in your own hands. You can manually operate the DOM, or you can call it through the map SDK, and Not tightly coupled, no extra work required.

---

The time to learn AngularJS is relatively short, about 1 week. I have this idea. I wonder if there is anything I don’t understand well?

---

In addition, I think the most suitable scenario for AngularJS is when the application only needs a combination of native page elements. For example, different views just inject data into different templates, such as todolist, gmail, etc., which are native html elements. put together.

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