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

Pertama sekali, bukan mudah untuk dapat memikirkan perkara ini secara mendalam selepas hanya satu minggu mempelajari Angular pada mulanya. Saya percaya anda boleh menggunakan Angular dengan baik.

Kedua, malangnya, saya tidak banyak terdedah kepada aplikasi peta, terutamanya kerana saya tidak tahu betapa rumitnya SDK tersebut, jadi sukar bagi saya untuk mengatakan sama ada menukar kepada Angular akan menjadikan keadaan lebih baik.

Sebagai penyimpangan, saya rasa API dan SDK adalah berbeza, terutamanya untuk aplikasi web. API biasanya digunakan untuk pertukaran data dan secara amnya tidak melibatkan objek DOM adalah perkara yang anda maksudkan. Ia mempunyai set logik terkapsul mereka sendiri dan biasanya menyediakan panggilan antara muka yang digabungkan dengan DOM.

API boleh dikendalikan dengan baik oleh Angular, dan Sumber terbina dalam amat sesuai untuk merangkum perkhidmatan API. Walau bagaimanapun, SDK itu sendiri agak lengkap dalam enkapsulasinya Dalam dunia Sudut, penekanan untuk tidak mengendalikan DOM secara langsung menjadikan penyepaduan SDK lebih rumit dan sukar. Fenomena ini memang wujud, dan penyelesaiannya memang serupa dengan apa yang anda fikirkan Gunakan arahan untuk mengabstrakkan interaksi DOM, dan menggunakan perkhidmatan untuk mengabstrak bahagian logik. Sebagai contoh, jika anda memikirkan sesuatu seperti Highcharts - walaupun ia bukan SDK peta, ia adalah perpustakaan pihak ketiga yang kompleks dan terkapsul dengan baik - penyepaduannya dengan Angular tidak mudah, dan terdapat banyak perangkap, jadi terdapat ramai Orang telah membuat modul Angular+Highcharts secara berasingan untuk digunakan semula Anda boleh mencari contoh di kawasan ini untuk melihat bagaimana pelaksanaannya, dan anda mungkin boleh menganggarkan sama ada ia sesuai.

Adakah pengkapsulan Angular merumitkan masalah mudah? Kadang-kadang ya. Ia benar-benar bergantung pada masalah itu sendiri, Angular bukan ubat penawar, ia tidak sesuai untuk semua jenis aplikasi. Adakah anda fikir Backbone boleh mengendalikan kerja semasa anda? Kemudian teruskan menggunakannya dan abaikan "trend". Sebaliknya, apabila anda benar-benar mendapati bahawa Angular mempunyai bahagian yang Backbone tidak dapat dipadankan, maka dengan tegas mula menggunakan Angular Bagaimanapun, tiada rangka kerja yang sempurna Selagi anda menyentuh masalah yang perlu diselesaikan, anda perlu menyelesaikannya mereka. Jika anda tidak menyentuhnya, anda tidak perlu risau.

Selain itu, saya ingin memanjangkan perbincangan ini.

Mari kita bahagikan secara kasar teknologi kepada tiga bahagian: teknologi masa lalu (atau teknologi matang), teknologi semasa (atau teknologi popular) dan teknologi masa depan (atau teknologi yang mewakili arah aliran) .

Adalah mudah untuk kita membuat keputusan secara impulsif untuk menggunakan "teknologi semasa" untuk menggantikan "teknologi lepas" Secara umumnya, akan ada kos, tetapi ia pastinya tidak akan ada faedah, dan jika dikendalikan dengan betul, faedahnya akan sentiasa. mengatasi kos.

Masalahnya ialah sentiasa ada banyak pilihan dalam "teknologi semasa". Lebih mudah untuk kita jatuh ke dalam pilihan ini dan tidak dapat membuat keputusan kepada teknologi masa lalu, sekurang-kurangnya ia selamat.

Saya tidak boleh mengatakan apa yang betul Saya telah menjawab soalan ini berkali-kali pada tahun lalu dan saya hanya boleh menyatakan pertimbangan saya sendiri.

Saya cenderung memilih "teknologi semasa" dengan mempelajari dan memahami "teknologi masa depan" dan dengan tegas menggantikan "teknologi lepas".

"Teknologi masa lalu" akan sentiasa berlalu, lambat laun hanya tinggal masa saya adalah jenis orang yang "berlayar melawan arus, jika saya tidak maju, saya akan berundur", walaupun kosnya. adalah tinggi.

Sama ada "teknologi semasa" konsisten dengan "teknologi masa hadapan" sebenarnya mencerminkan pemahaman dan pertimbangan pengarang/pasukan tentang aliran teknologi, serta pemahaman dan pertimbangan peribadi anda, adakah terdapat sedikit perjudian? Keyakinan dan keupayaan membuat keputusan ini bergantung kepada diri sendiri.

Mengapa saya bercakap tentang "teknologi masa depan"? Ambil aplikasi peta yang anda buat sebagai contoh Berapa lama pada pendapat anda SDK semasa boleh digunakan? Bukan sahaja kod mereka sendiri, tetapi tindanan teknologi mereka Berapa lama model pembangunan aplikasi peta berorientasikan DOM berasaskan SDK boleh bertahan?

Jika anda mendapati soalan ini sukar untuk dijawab, mula-mula anda boleh menyemak sejarah pembangunan pemimpin industri, seperti Peta Google, kedua, anda boleh belajar tentang seni bina teknikal pemimpin dalam industri.

Kita hampir semua tahu dan boleh menjangkakan bahawa WebComponents akan menjadi perkara besar seterusnya dalam aplikasi web Jadi, apabila WebComponents menjadi "teknologi semasa" (mungkin ia tidak akan lama), set semasa adalah berdasarkan SDK dan Berapa banyak. ruang untuk kemajuan dan kelangsungan hidup adakah model pembangunan aplikasi peta berorientasikan DOM ada?

Saya tidak tahu jawapannya, dan saya tidak mahu menanam sebarang "nilai" dalam diri anda, saya hanya menerangkan cara saya berfikir dan membuat keputusan. Daripada penerangan anda tentang masalah itu, saya merasakan bahawa anda bukan hanya seorang pengaturcara Mungkin anda juga memainkan peranan "arkitek" dalam pasukan anda, jadi saya akan mengatakan lebih lanjut tentang ini .

Answer 2

Saya rasa bahagian peta tidak ada kaitan dengan sudut Anda boleh meletakkan peta di luar sudut atau biarkan sudut tidak menyusun bahagian peta. Tetapi ia tidak menjejaskan anda untuk menggunakan peta biasa (lagipun, ia telah dikapsulkan oleh mereka apabila anda memerlukan sudut untuk mengendalikannya, biarkan sudut mengendalikannya).

Walaupun anda menggunakan sudut, tidak semua elemen pada halaman mesti berkaitan dengan sudut. Hanya gunakannya di tempat yang sesuai. Jangan kaitkan semuanya dengan Angular hanya untuk menggunakan Angular.

Answer 3

Saya telah melakukan pembangunan Openlayers untuk satu tempoh masa sebelum ini dan mempunyai beberapa pemahaman awal tentang Angularjs

Ini adalah rangka kerja yang dimiliki oleh dua medan berbeza
API Peta memfokuskan pada paparan G, dan AngularJS memfokuskan pada paparan IS Tiada konflik antara kedua-duanya Apabila kami membuat pertanyaan, pelayan mengembalikan satu siri maklumat elemen Sekarang pendekatan umum adalah untuk memudahkan elemen, mendapatkan maklumat, dan kemudian menggabungkan HTML melalui templat untuk memaparkan senarai keputusan Pada masa yang sama, tambah maklumat elemen ini ke lapisan dan lukis Pergi ke peta.

API peta membantu kami melengkapkan lukisan elemen geografi, tetapi data maklumat perlu dikawal oleh kami sendiri Mari kita meniru contoh interaksi tetikus dan elemen

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

//Pseudokod (asal) atau templat bahagian hadapan yang lain

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>

Sudah tentu, MVC juga boleh dijalankan menggunakan templat js lain, tetapi kelebihan menggunakan AngularJS ialah ia adalah aplikasi satu halaman, dan proses pelaksanaan perantaraan hanyalah kerana semua jalan menuju ke Rom.

Walau bagaimanapun, keperluan telah berubah semasa menyerlahkan elemen, kami boleh menyerlahkan elemen li semasa atau keperluan baharu yang lain Pada masa ini, kami akan mendapati bahawa titik di mana kami menukar kod tidak berada di tempat yang sama

Kaedah asal memerlukan penambahan pensuisan gaya semasa proses mengikat acara

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

Ringkasnya, penyelenggaraan menjadi lebih pantas dan perniagaan asal tidak terjejas.

Answer 4

Sememangnya, SDK peta telah pun menyelesaikan pengurusan DOM untuk anda Bahagian kerja ini diulang dengan ng, jadi ia akan berasa pelik untuk mengenakan ng padanya. Jika SDK peta itu sendiri disediakan dalam mod ng, ia mungkin membawa pengalaman pembangunan yang berbeza.

Answer 5

Saya fikir ia agak menyusahkan pada mulanya, tetapi apabila saya secara beransur-ansur memahami Angular, ia menjadi lebih mudah.
Anda mesti tahu bahawa tidak kira apa rangka kerja JS, objek adalah rujukan yang diluluskan.
Kemudian untuk SDK, sebenarnya ikat objek SDK pada perkhidmatan. Hanya perhatikan $apply dalam panggilan balik