Angular JS - "Controller as vm"을 사용하는 이유

Angular JS - "Controller as vm"을 사용하는 이유

이번 주말 내내 왜 부모 컨트롤러의 기능이 자녀 컨트롤러에 의해 인식되지 않는지 이해할 수 없어서 매우 괴로웠습니다.

컨트롤러를 VM으로 사용하는 것이 원인임을 곧 깨달았습니다.

 <div data-ng-controller="ParentCtrl as vm">
   <div data-ng-controller="Child1 as vm"></div>
   <div data-ng-controller="Child2 as vm"></div>
 </div>

물론 이제 child1과 child2 모두 ParentCtrl의 기능을 인식하지 못하고, 대신 VM 없이 작업하는 이전 패턴을 사용하고 $scope를 사용했다면 모든 것이 양호했을 것입니다.

그래서 제 질문은 "vm" 메서드를 사용하면 누구에게나 이득이 되는 것은 무엇이며, 사용하지 않는 것보다 우수하다면 어떻게 ParentCtrl을 호출할 수 있는가?"입니다.

감사해요.

컨트롤러를 구문으로서 사용하는 것의 장점 중 하나는 컨트롤러를 $scope가 아닌 인스턴스화된 객체에서 직접 나타나는 속성과 함수를 가진 단순한 javascript 컨스트럭터 함수로 정의할 수 있다는 것입니다.

예를 들어 다음과 같습니다.

function MyController() {

    var ctl = this;

    ctl.message = 'You have not clicked anything yet.';

    ctl.onClick = function() {
        ctl.message = 'You clicked something.';
    };

    return ctl;
}

...

myModule.controller('MyController', MyController);

...

<div ng-controller="MyController as vm">
    <span>{{vm.message}}</span>
    <button ng-click="vm.onClick()">Click Me</button>
</div>

angular에 얽매이지 않고 밋밋한 javascript 컨트롤러를 사용할 수 있습니다.$scope나 기타 서비스 등 추가 의존관계가 필요한 시나리오에서도 쉽게 컨스트럭터에 전달할 수 있지만 이 패턴은 $scope에 직접 대한 혼란을 줄여주고 변수를 직접 설정할 때 변수가 숨겨지는 문제를 해결합니다.

결국 선호도에 따라 다르지만, 저는 스코프에서 모든 것을 직접 정의하지 않고 컨트롤러를 가능한 한 오래된 Javascript 객체로 취급하는 것을 매우 좋아합니다.

다음은 컨트롤러 사용에 관한 훌륭한 기사입니다.http://www.johnpapa.net/angularjss-controller-as-and-the-vm-variable/

예전에는 컨트롤러를 VM 구문으로 사용했지만 최근에는 컨트롤러를 사용하지 않게 되었습니다.스코프 분리를 사용하여 네스트된 디렉티브로 복잡한 페이지를 작성할 경우 기존의 $scope 접근방식을 사용하는 것이 훨씬 쉬워집니다.

당신의 질문은 한동안 궁금했던 질문입니다.페이지 내에서 네스트된 컨트롤러를 사용하면 각 스코프에 대한 의미 참조를 얻을 수 있기 때문에 마크업이 읽기 쉬워집니다.예를 들어 다음과 같습니다.

<div ng-controller="CustomersCtrl as customers">
    <div ng-controller="OrdersCtrl as orders">
         <p>Showing{{customers.model.length}} customers with a total of {{orders.model.length}} orders</p>
    </div>
</div>

그 외에는 값을 잘 모르기 때문에 저처럼 디렉티브로 네스트 하는 것을 선호하면 값은 금방 무효가 됩니다.

이 예에서 볼 수 있는 것은 컨트롤러가 구문으로 사용되었기 때문이 아니라 이름 지정에 의해 부모를 숨긴 중첩된 오브젝트 때문입니다.

controller as 옵션은 CoffeeScript나 TypeScript와 같은 JavaScript로 컴파일되는 다른 언어를 광범위하게 사용할 때 매우 유용합니다.또한 $scope 주입이 필요 없기 때문에 비각형 컴포넌트와 교환할 수 있는 훨씬 더 가벼운 컨트롤러를 만들 수 있습니다.이것은 단순히 대체 구문이지만, $scope를 사용할 수 있습니다.

여기서 진짜 문제는 컨트롤러의 예를 구문으로 작성한 사람들이 왜 "VM"을 사용하기로 결정했는지입니다.기술적으로 이 구문은 MVVM 스타일의 코딩 경험을 제공하도록 설계되었기 때문에 "VM"으로 사용하는 것이 타당할 수 있지만, 이 경우 발생하는 문제가 노출됩니다.상위 컨트롤러가 다음 개체입니다.vm도 '아이 오브젝트'입니다vm따라서 하위 개체는 부모 개체를 보기에서 숨깁니다.대신 개체 이름을 다르게 지정하면 하위 개체는 상위 개체에 액세스하는 데 문제가 없으며 작업 중인 속성이 어떤 개체에서 왔는지 코드로 매우 명확해집니다.

가장 큰 장점 중 하나는 이 기능이 자동으로 작동하게 된다는 것입니다.. 은 Angular가 없으면 Angular가 것입니다..결박할 때 발에 총을 쏠 수도 있어요

다음과 같이 생각하십시오.

<input ng-model="foo" />

이것은 의도한 대로 동작하지 않을 수 있습니다. 「」를 는, 「」를 합니다.SomeController as vm구문은 자동으로 다음과 같이 됩니다.

<input ng-model="vm.foo" />

이렇게 하면 데이터 바인딩이 예상대로 작동하지 않는 잠재적 문제를 방지할 수 있습니다.

그 배경에는 JavaScript에서 프로토타입 상속이 작동하는 방식이 있으며, 여기에 자세히 설명되어 있습니다.AngularJS에서 스코프 프로토타입/프로토타입 상속의 뉘앙스는 무엇입니까?

"controller as vm" 구문을 사용하는 주된 이유는 angularjs의 컨트롤러가 실제로 모델(데이터를 캡슐화하고 동작을 제공) 또는 모델을 보기(데이터를 html에 표시)하는 것입니다.

대부분의 경우 잘 작동했지만, 제가 경험한 주요 폴백 중 하나는 하위 컨트롤러에서 상위 컨트롤러의 데이터에 액세스하는 것이 어렵다는 것입니다. 가능한 솔루션(모두 '컨트롤러 as VM' 표기를 사용하는 상위 컨트롤러를 하위 컨트롤러로 가져오는 것)은 우아하지 않습니다.

언급URL : https://stackoverflow.com/questions/22285597/angularjs-why-use-controller-as-vm