angular.js - Adakah AngularJS tidak sesuai untuk aplikasi peta?

Question

Selepas membaca beberapa contoh di tapak web rasmi AngularJS, saya rasa ia sangat berkuasa Ia mengalihkan perhatian pembangun daripada operasi DOM skrin penuh kepada perniagaan tradisional, memfokuskan pada data, mengikat View dan merealisasikan pengikatan kedua-duanya. dan kemas kini.

Saya biasanya bekerja pada aplikasi peta, seperti versi PC Peta Baidu dan Peta Tencent, saya telah mempertimbangkan untuk menggunakan AngularJS, tetapi selepas banyak pertimbangan, saya rasa ia tidak sesuai kerana aplikasi peta biasanya bergantung pada pihak ketiga. API Peta, contohnya, berdasarkan Peta Baidu, API Javascript Peta Baidu Tencent juga mempunyai API JS sendiri Konsep umum API ini adalah untuk menyediakan elemen halaman dan kemudian mencipta antara muka peta interaktif dalam elemen ini.

1 Permulaan Peta

Jika kita ingin membuat peta di halaman p#map-p, kod biasa adalah seperti berikut:

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

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

Objek peta ini mengandungi banyak kaedah, seperti menambah tindanan, lukisan peta, dsb. Kebanyakan kaedah ini akan menyebabkan kemas kini pada antara muka peta Sebagai contoh, kod berikut akan muncul tetingkap pada antara muka peta:

map.addInfoWindow();

Jika kami mengikuti AngularJS, kami harus mengisytiharkan Paparan peta pada halaman, serupa dengan ini

Dalam kes ini, kita perlu mencipta bd-map daripada directive, yang bermaksud bahawa kita perlu mewujudkan arahan yang berbeza untuk SDK peta yang berbeza Walaupun ini adalah kerja sekali sahaja, ia tidak masalah besar.

2 Interaksi peta

Saya fikir jika kawasan ini dirangkumkan sepenuhnya melalui AngularJS, ia akan merumitkan masalah mudah Sebagai contoh, saya meminta data 10 hotel dari latar belakang markers Setiap hotel mempunyai maklumat lokasi lakukan ini Kering:

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

Tetapi menurut konsep AngularJS, markers jelas sekali harus menjadi data dalam scope tertentu Perniagaan kami harus menumpukan pada pemerolehan dan kemas kini data ini, dan kemas kini antara muka harus diselesaikan sebelum directive, jadi Nampaknya saya masih perlu mencipta arahan yang sepadan dengan marker Pada ketika ini, saya sudah merasakan ia agak rumit dan berasa seperti tidak perlu.

3 Acara

Peta itu sendiri dan tindanan pada peta mempunyai beberapa peristiwa, seperti anda mengklik pada peta, mengklik pada ikon, dll. Ini adalah perkara biasa dalam aplikasi peta Jika anda menggunakan AngularjS, nampaknya anda perlu melakukannya membungkus mereka.

Perasaan saya ialah SDK peta itu sendiri boleh dianggap sebagai pelaksanaan MVC Contohnya, anda menetapkan pelbagai parameter (data) peta, dan kemudian menggunakan antara muka yang disediakan oleh SDK untuk mencipta antara muka peta (Lihat. ) Ia dicipta Dengan mengubah suai titik tengah peta dan antara muka lain, paparan peta juga berubah mengikut kes ini, ia serupa dengan Angular. Menggabungkan JS secara paksa nampaknya tidak produktif Dalam kes ini, saya rasa Backbone lebih sesuai, pandangan Backbone adalah agak fleksibel. Anda boleh mengendalikan DOM secara manual memanggilnya melalui SDK peta, dan Tidak berganding rapat, tiada kerja tambahan diperlukan.

---

Masa untuk belajar AngularJS agak singkat, kira-kira 1 minggu saya ada idea ini.

---

Selain itu, saya rasa senario yang paling sesuai untuk AngularJS ialah apabila aplikasi hanya memerlukan gabungan elemen halaman asli Contohnya, pandangan yang berbeza hanya menyuntik data ke dalam templat yang berbeza, seperti todolist, gmail, dll., iaitu elemen html asli disatukan.

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