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.

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.

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.

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.

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