Angular Framework_AngularJS를 처음 알게 된 후의 생각

직장에서 실제 개발이 필요했기 때문에 저는 Angle 프레임워크를 접하기 시작했습니다. 초기 비교부터 다양한 문제와 개념으로 인해 괴로움과 황폐화를 겪은 후 이제 어느 정도 이해가 되었으며 이해를 간략하게 요약해야 할 필요성을 느낍니다. 부족한 점이라도 용서해주세요.

1. 양방향 데이터 바인딩
현재 업계에서는 다양한 MV** 프레임워크가 인기를 끌고 있으며, 관련 프레임워크도 꾸준히 등장하고 있는데, 그중 하나가 Angular(MVVM)입니다. 실제로 MV** 프레임워크의 핵심 문제는 뷰 계층을 모델에서 분리하고, 코드의 결합을 줄이고, 데이터와 성능의 분리를 달성하는 것입니다. MVC, MVP, MVVM은 모두 동일한 목표를 가지고 있습니다. 하지만 그들 사이의 차이점은 모델 레이어를 뷰와 연결하는 방법에 있습니다.

모델 및 뷰 레이어에서 데이터가 흐르는 방식이 문제의 핵심이 되었습니다. Angular는 더티 체크를 통해 양방향 데이터 바인딩을 구현합니다. 소위 양방향 바인딩은 뷰의 변경 사항이 모델 레이어에 반영되고, 모델 데이터의 변경 사항이 뷰에 반영될 수 있음을 의미합니다. 그러면 Angular는 어떻게 양방향 바인딩을 달성합니까? 더티 체크가 되는 이유는 무엇입니까? 프런트 엔드에 대한 독창적인 질문부터 시작해 보겠습니다.

html:

 <input type="button" value="increase 1" id="J-increase" />
 <span id="J-count"></span>

js:

 <script>
 var bindDate = {
  count: 1,
  appy: function () {
   document.querySelector('#J-count').innerHTML = this.count;
  },
  increase: function () {
   var _this = this;
   document.querySelector('#J-increase').addEventListener('click', function () {
    _this.count++;
    appy();
   }, true);
  },
  initialize: function () {
    // 初始化
   this.appy();
    //
   this.increase();
   }
  };
  bindDate.initialize();
 </script>

위의 예에는 두 가지 프로세스가 있습니다.

뷰 레이어는 모델 레이어에 영향을 미칩니다. 페이지의 버튼을 클릭하면 데이터 수가 1씩 증가합니다
모델 레이어는 뷰 레이어를 반영합니다: 개수가 변경된 후 적용 기능을 통해 뷰 레이어에 반영됩니다
이는 이전에 jquery 및 YUI와 같은 라이브러리를 사용하여 구현된 데이터 처리입니다. 여기서 문제는 분명합니다.

• 많은 DOM 작업이 필요합니다.
• 과정이 번거롭습니다.
• 코드 결합도가 너무 높아 단위 테스트 작성이 어렵습니다.

Angular가 데이터를 처리하는 방법을 살펴보겠습니다.

첫 번째 단계: 감시자 추가: 데이터가 변경되면 감지해야 할 개체를 먼저 등록해야 합니다

// 对angular里面的源码进行了精简 
 $watch: function(watchExp, listener, objectEquality) {
  var scope = this,
   array = scope.$$watchers,
  watcher = {
    fn: listener,
    last: initWatchVal,
   get: get,
   exp: watchExp,
    eq: !!objectEquality
  };
  if (!array) {
   array = scope.$$watchers = [];
 }
  array.unshift(watcher);
 }

두 번째 단계. 더티 확인: 특정 범위의 데이터가 변경되면 등록된 $$watchers = [...]

를 탐색하고 감지해야 합니다.

 $digest: function() {
 while (length--) {
   watch = watchers[length];
  watch.fn(value, lastValue, scope);
 }
 }

이것은 양방향 데이터 바인딩을 달성합니다. 위의 구현은 사용자 정의 이벤트와 유사합니까? 관찰자 디자인 패턴 또는 (publisher-subscriber)이 사용되는 것을 볼 수 있습니다.

2. 의존성 주입
Spring 프레임워크를 사용해 본 학생들은 Ioc와 AOP가 Spring에서 가장 중요한 두 가지 개념이라는 것을 알고 있으며 Ioc를 사용하여 종속성(DI)을 주입할 수 있다는 것은 분명합니다. Angle이 매우 강력한 백엔드 색상을 가지고 있다는 것은 분명합니다.

마찬가지로 먼저 DI를 사용하지 않고 객체 상호의존성을 해결하는 방법을 살펴보겠습니다.

 function Car() {
 ...
}
 Car.prototype = {
 run: function () {...}
}
 
function Benz() {
 var cat = new Car();
 }
Benz.prototype = {
  ...
}

위의 예에서 Benz 클래스는 Car 클래스에 종속되며 이 종속성은 내부 New를 통해 직접 해결됩니다. 이것의 단점은 매우 명백하며, 코드 결합도가 높아져 유지 관리에 도움이 되지 않습니다. 백엔드 프레임워크는 오랫동안 이 문제를 인식해 왔습니다. 초기에는 Spring이 xml 파일에 객체 간의 종속성을 등록했지만 나중에는 COS 측의 학생들이 사용할 수 있는 DI 문제를 더 편리하게 해결했습니다. 백엔드 코드를 살펴보세요.

js 언어 자체에는 주석 메커니즘이 없는데 각도에서는 이를 어떻게 구현하나요?

1. 시뮬레이션 주석

 // 注解的模拟
 function annotate(fn, strictDi, name) {
 var $inject;
 if (!($inject = fn.$inject)) {
  $inject = [];
  $inject.push(name);
 }else if (isArray(fn)) {
  $inject = fn.slice(0, last);
 }
  return $inject;
 }
 createInjector.$$annotate = annotate;

2. 주입 객체 생성

 function createInjector(modulesToLoad, strictDi) {
  //通过singleton模式创建对象
  var providerCache = {
    $provide: {
      provider: supportObject(provider),
      factory: supportObject(factory),
      service: supportObject(service),
      value: supportObject(value),
      constant: supportObject(constant),
     decorator: decorator
   }
   },
  instanceCache = {},
  instanceInjector = (instanceCache.$injector =
  createInternalInjector(instanceCache, function(serviceName, caller) {
  var provider = providerInjector.get(serviceName + providerSuffix, caller);
     return instanceInjector.invoke(provider.$get, provider, undefined, serviceName);
    }));
 return instanceInjector;
 }

3. 주입 개체 가져오기

function invoke(fn, self, locals, serviceName) {
 var args = [],
  $inject = annotate(fn, strictDi, serviceName);

 for (...) {
  key = $inject[i];
   // 替换成依赖的对象
   args.push(
   locals && locals.hasOwnProperty(key)
     ? locals[key]
    : getService(key, serviceName)
   );
 }
  if (isArray(fn)) {
  fn = fn[length];
  }   
  return fn.apply(self, args);
}

이 시점에서 백엔드 프레임워크 디자인 아이디어를 많이 보셨나요? 주석 없이 그냥 시뮬레이션해 보세요. PPK에서 Angle이 "프론트엔더가 아닌 사용자를 위한 프론트엔드 프레임워크"라고 말하는 것은 당연합니다. 엔더"

3.컨트롤러 통신
실제 개발에서는 애플리케이션 시스템이 매우 커집니다. 애플리케이션 앱에 컨트롤러가 하나만 있는 것은 불가능하므로 서로 다른 컨트롤러 간에 통신할 가능성이 있습니다. 이 일반적인 문제를 해결하는 방법은 두 가지입니다.

1. 이벤트 메커니즘: $rootScope에 이벤트를 등록합니다. 이 문제는 $rootScope에 너무 많은 이벤트가 등록되어 일련의 문제가 발생한다는 것입니다.

 //controller1
app.controller('controller1', function ($rootScope) {
 $rootScope.$on('eventType', function (arg) {
    ......
  })
 })

// controller2
app.controller('controller2', function ($rootScope) {
   $rootScope.$emit('eventType',arg);
 or
  $rootScope.$broadcast('eventType',arg);
 })

2. 서비스를 통해 각도의 DI 기능을 최대한 활용: 서비스가 싱글톤이라는 기능을 사용하여 서로 다른 컨트롤러 간의 브리지 역할을 수행

// 注册service
app.service('Message', function () {
 return {
  count: void(0);
 }
 })
 // controller1,修改service的count值
app.controller('controller1', function ($scope, Message) {
  $scope.count = 1;
 Message.count = $scope.count;
});
 // controller2, 获取service的count值
app.controller('controller2', function ($scope, Message) {
$scope.num = Message.count;
 });

4.서비스 특징

1. 싱글톤: Angular의 서비스만 컨트롤러 및 지시어와 같은 DI를 수행할 수 있습니다. 서비스는 말 그대로 일부 기본 기능을 제공하지 않습니다. 특정 사업과 관련이 없는 반면, 컨트롤러와 지침은 특정 사업과 밀접하게 관련되어 있으므로 서비스의 고유성이 보장되어야 합니다.

2. 게으른 신규: angular는 먼저 서비스 제공자를 생성하지만 해당 서비스를 즉시 생성하지는 않습니다. 필요할 때만 이러한 서비스를 인스턴스화합니다. .

3. 제공자) 분류: provider(), 팩토리, 서비스, 값, 상수, 여기서 제공자는 최하위 구현이고 다른 메소드는 이를 기반으로 합니다. sugar), 특정 서비스는 $get 메소드를 실행하여 생성되기 때문에 이러한 서비스는 결국 $get 메소드를 추가하게 된다는 점에 유의해야 합니다.

5. 지침 시행
지시어 컴파일에는 컴파일과 링크의 두 단계가 포함됩니다. 간단히 말해서 컴파일 단계에서는 주로 템플릿 DOM을 처리합니다. 즉, 데이터 렌더링이 수행되지 않습니다. 예를 들어 ngRepeate 명령은 컴파일을 통해 템플릿을 수정합니다. , 링크 함수는 나중에 정의된 링크를 덮어쓰며 반환됩니다. 링크는 주로 데이터 렌더링에 사용되며, 이 두 링크의 구문 분석 순서는 반대입니다. 사후 링크는 내부 부분을 먼저 구문 분석한 다음 외부 부분을 구문 분석합니다. 이는 지시문에 지시문이 포함될 수 있으므로 동시에 링크가 성능 문제를 포함할 수 있으므로 구문 분석은 안전합니다. DOM 작업에서.

이 기사에서 다루는 내용은 그다지 보편적이지 않으며 나중에 해당 보충 자료가 있을 예정입니다. 모든 사람이 Angle Framework에 대해 배우고 토론할 수 있기를 바랍니다.