angular.js - AngularJS는 지도 애플리케이션에 적합하지 않습니까?

Question

AngularJS 공식 웹사이트에서 몇 가지 예제를 읽은 후에는 개발자의 관심을 전체 화면 DOM 작업에서 기존 비즈니스로 전환하여 데이터에 초점을 맞추고 뷰를 바인딩하고 두 가지의 바인딩 및 업데이트를 실현하는 것이 매우 강력하다고 생각합니다. 제가 평소에 가장 많이 하는 일은 바이두맵 PC버전, 텐센트 등 지도어플입니다...

大家讲道理 · Answer

일단 Angular를 일주일만 배운 후에는 이 부분에 대해 깊이 생각하기가 쉽지 않습니다. 처음에 저보다 훨씬 잘 사용하실 수 있을 거라 믿습니다.

두 번째로, 안타깝게도 저는 지도 애플리케이션을 많이 접해본 적이 없습니다. 특히 SDK가 얼마나 복잡한지 이해하지 못하기 때문에 Angular로 전환하면 상황이 좋아질지 여부를 말하기가 어렵습니다.

우선 다른 이야기로 넘어가겠습니다. 특히 웹앱의 경우 API와 SDK가 다르다고 생각합니다. API는 일반적으로 데이터 교환에 사용되며 일반적으로 DOM 객체를 포함하지 않습니다. SDK는 자체 캡슐화된 논리 세트를 가지며 일반적으로 DOM과 긴밀하게 결합된 인터페이스 호출을 제공합니다.

API는 Angular에서 매우 잘 처리할 수 있으며 내장된 리소스는 특히 API 서비스를 캡슐화하는 데 적합합니다. 그러나 SDK 자체는 캡슐화 측면에서 비교적 완벽합니다. Angular 세계에서는 DOM을 직접 작동하지 않는다는 점을 강조하므로 SDK 통합이 더욱 복잡하고 어려워집니다. 이러한 현상은 실제로 존재하며 솔루션은 실제로 여러분이 생각하는 것과 유사합니다. 지시문을 사용하여 DOM 상호 작용을 추상화하고 서비스를 사용하여 논리 부분을 추상화합니다. 예를 들어, Highcharts와 같은 것을 생각해보면 - 비록 지도 SDK는 아니지만 비슷하고 복잡하고 잘 캡슐화된 타사 라이브러리입니다. - Angular와의 통합이 쉽지 않고 함정이 많기 때문에 많은 사람들이 재사용을 위해 Angular + Highcharts 모듈을 별도로 만들었습니다. 이 영역에서 예제를 검색하여 구현 방법을 확인하고 적합한지 추정할 수 있습니다.

Angular의 캡슐화는 간단한 문제를 복잡하게 만드나요? 때로는 그렇습니다. 실제로는 문제 자체에 따라 다릅니다. Angular는 만병통치약이 아니며 모든 유형의 애플리케이션에 적합하지 않습니다. Backbone이 귀하의 현재 업무를 처리할 수 있다고 생각하십니까? 그런 다음 계속 사용하고 "추세"를 무시하십시오. 반면에 Angular가 Backbone과 일치하지 않는 부분이 있다는 것을 알게 되면 과감하게 Angular를 사용하기 시작하세요. 어쨌든, 해결해야 할 문제만 건드리면 완벽한 프레임워크는 없습니다. 만지지 않으면 걱정할 필요가 없습니다.

추가로 이 논의를 확장하고 싶습니다.

기술을 과거 기술(또는 성숙 기술), 현재 기술(또는 대중 기술), 미래 기술(또는 트렌드를 대표하는 기술)의 세 부분으로 크게 나누어 보겠습니다.

"과거의 기술"을 "현재의 기술"로 대체하기로 충동적으로 결정하기 쉽습니다. 일반적으로 비용이 들지만 확실히 이점이 없을 수 없으며, 제대로 처리하면 항상 비용보다 이점이 더 큽니다. .

문제는 '현재 기술'에는 항상 선택의 여지가 많다는 것입니다. 우리는 이 선택에 빠져 결정을 내리지 못하는 것이 더 쉽습니다. 과거의 기술은 적어도 안전합니다.

지난 1년 동안 이 질문에 여러 번 답변을 드렸는데 무엇이 옳다고 말씀드릴 수가 없네요.

나는 "미래 기술"을 학습하고 이해하여 "현재 기술"을 선택하고 "과거 기술"을 과감하게 대체하는 경향이 있습니다.

"과거의 기술"은 언젠가는 시간 문제일 뿐입니다. 나는 비용이 많이 들더라도 "전진하지 않으면 퇴보하는" 유형입니다.

'현재 기술'이 '미래 기술'과 일치하는지 여부는 실제로 기술 동향에 대한 작성자/팀의 이해 및 판단뿐만 아니라 귀하의 개인적인 이해 및 판단을 반영합니다. 자신감과 의사결정 능력은 본인에게 달려있습니다.

내가 '미래기술'을 얘기한 이유는 무엇인가요? 당신이 만드는 지도 애플리케이션을 예로 들어보겠습니다. 현재 SDK를 얼마나 오랫동안 사용할 수 있다고 생각하시나요? 코드 자체뿐만 아니라 기술 스택도 SDK 기반 DOM 기반 지도 애플리케이션 개발 모델이 얼마나 오래 지속될 수 있습니까?

이 질문에 대답하기 어렵다면 먼저 Google 지도와 같은 업계 리더의 개발 이력을 검토하고 두 번째로 업계 리더의 기술 아키텍처에 대해 알아볼 수 있습니다.

우리는 WebComponents가 웹앱의 차세대 기술이 될 것이라는 것을 거의 모두 알고 있고 예상할 수 있습니다. 따라서 WebComponents가 "현재 기술"이 되면(아마도 그리 오래 걸리지는 않을 것입니다) 현재 세트는 SDK를 기반으로 하며 DOM을 지향적인 지도 응용 프로그램 개발 모델에는 발전과 생존의 여지가 얼마나 있습니까?

나는 답을 모르고, 당신에게 어떤 "가치"를 심어주고 싶지도 않습니다. 나는 단지 내가 어떻게 생각하고 결정하는지 설명할 뿐입니다. 문제에 대한 귀하의 설명을 보면 귀하는 단순한 프로그래머가 아닐 수도 있으며 팀에서 "설계자" 역할도 수행할 수도 있으므로 이에 대해 더 자세히 설명하겠습니다. 즉, 광범위하게 생각하십시오. .

phpcn_u1582 · Answer

지도 부분은 각도와 아무 관련이 없다고 생각합니다. 지도를 각도 외부에 배치하거나 각도가 지도 부분을 컴파일하지 않도록 할 수 있습니다. 그러나 노멀 맵을 사용하는 것은 영향을 미치지 않습니다(결국 노멀 맵에 의해 캡슐화되었습니다). 이를 처리하기 위해 각도가 필요한 경우 각도가 이를 처리하도록 하십시오.

Angular를 사용하더라도 페이지의 모든 요소가 Angular와 관련되어 있어야 하는 것은 아닙니다. 단지 Angular를 사용하기 위해 모든 것을 Angular와 연결하지 마십시오.

滿天的星座 · Answer

저는 한동안 Openlayers 개발을 해왔고, Angularjs에 대해서도 어느 정도 사전 지식을 갖고 있습니다

이것은 서로 다른 두 분야에 속하는 프레임워크입니다
Map API는 G 표시에 중점을 두고, AngularJS는 IS 표시에 중점을 둡니다. 예를 들어 둘 사이에는 충돌이 없습니다. 쿼리를 수행하면 서버는 일련의 요소 정보를 반환합니다. 이제 일반적인 접근 방식은 요소를 촉진하고 정보를 얻은 다음 템플릿을 통해 HTML을 결합하여 동시에 결과 목록을 표시하는 것입니다. 이러한 요소 정보를 레이어에 추가하여 지도에 그립니다.