새 지시문을 작성할 때 사용할 범위 유형을 결정하는 데 사용할 수있는 몇 가지 지침을 찾고 있습니다. 이상적으로, 나는 많은 질문을 안내하고 새로운 새로운 범위, 새로운 자식 범위 또는 새로운 격리 범위가 아닌 올바른 대답을 보여주는 흐름도와 비슷한 것을 원하지만 너무 많이 요구하는 것 같습니다. 다음은 현재의 팰 트리 가이드 라인입니다 :

• 지시문을 사용할 요소가 ng-model을 사용하는 경우 격리 된 범위를 사용하지 마십시오. 격리 된 범위 와 함께 ng-model을 사용할 수 있습니까?를
  참조하십시오 . 그리고
  왜 포맷터는 고립 범위에서 작동하지 않는 이유는 무엇입니까?
• 지시문이 범위 / 모델 속성을 수정하지 않으면 새 범위를 만들지 마십시오.
• 지시문이 DOM 요소 세트 ( 문서 가 "복잡한 DOM 구조"라고 함)를 캡슐화하고 지시문이 요소 로 사용되거나 동일한 요소에 다른 지시문이없는 경우 격리 범위가 제대로 작동하는 것 같습니다 .

요소에 격리 범위가있는 지시문을 사용하면 동일한 요소의 다른 모든 지시문이 동일한 (하나의) 격리 범위를 사용하게되므로 격리 범위를 사용할 수있을 때 이것이 심각하게 제한되지 않습니까?

Angular-UI 팀의 일부 (또는 많은 지시문을 작성한 다른 사람들)가 자신의 경험을 공유 할 수 있기를 바랍니다.

단순히 "재사용 가능한 구성 요소에 격리 된 범위 사용"이라는 답변을 추가하지 마십시오.

정말 좋은 질문입니다! 나는 것 좋아하는 다른 사람이 무슨 말을하는지 듣고, 그러나 여기 내가 사용하는 지침입니다.

고도 전제 : 범위는 상위 컨트롤러, 지시문 및 지시문 템플릿간에 통신하는 데 사용되는 "접착제"로 사용됩니다.

부모 범위 : scope: false 이므로 전혀 새로운 범위가 없습니다.

나는 이것을 자주 사용하지 않지만 @MarkRajcok가 말했듯이 지시어가 범위 변수에 액세스하지 않으면 (그리고 분명히 설정되지 않았습니다!), 이것은 내가 걱정하는 한 괜찮습니다. 이것은 부모 지시문의 컨텍스트 에서만 사용되며 (항상 예외는 있지만) 템플릿이없는 자식 지시문에도 유용합니다 . 기본적으로 템플릿이있는 것은 범위를 공유하는 것이 아닙니다. 왜냐하면 본질적으로 액세스 및 조작을 위해 해당 범위를 노출하기 때문입니다 (그러나이 규칙에는 예외가 있다고 확신합니다).

예를 들어, 최근에는 작성중인 SVG 라이브러리를 사용하여 (정적) 벡터 그래픽을 그리는 지시문을 만들었습니다. 이 $observe두 가지 특성 (들 width과 height그 어느 세트) 및 용도의 계산에 해당하지만,이 범위도 임의의 변수를 판독하고, 어떤 템플릿이 없다. 다른 범위를 만들지 않는 좋은 사용 사례입니다. 우리는 필요하지 않으므로 왜 귀찮게합니까?

그러나 다른 SVG 지시문에서 사용할 데이터 세트가 필요했으며 추가로 약간의 상태를 저장해야했습니다. 이 경우 부모 범위를 사용하는 것은 무책임합니다 (다시 말해서). 그래서 대신에...

아동 범위 : scope: true

자식 범위가있는 지시문은 상황을 인식하며 현재 범위와 상호 작용하기위한 것입니다.

분명히, 격리 범위에 비해 이것의 주요 장점은 사용자가 원하는 속성에 대해 보간을 자유롭게 사용할 수 있다는 것입니다. 예를 들어 class="item-type-{{item.type}}"격리 범위와 함께 지시문을 사용하면 기본적으로 작동하지 않지만 보간 된 항목은 여전히 ​​기본적으로 부모 범위에서 찾을 수 있기 때문에 자식 범위가있는 지시문에서는 제대로 작동합니다. 또한 지시문 자체는 부모의 오염이나 손상에 대한 걱정없이 자체 범위의 맥락에서 속성과 표현을 안전하게 평가할 수 있습니다.

예를 들어 툴팁은 추가 된 것입니다. 격리 범위는 작동하지 않습니다 (기본적으로 아래 참조). 여기서 다른 지시문이나 보간 된 속성을 사용할 것으로 예상되기 때문입니다. 툴팁은 개선 된 기능입니다. 그러나 툴팁은 하위 지시문 및 / 또는 템플릿과 함께 사용하고 분명히 자체 상태를 관리하기 위해 범위에 몇 가지 사항을 설정해야하므로 실제로 부모 범위를 사용하는 것은 매우 나쁩니다. 우리는 그것을 오염 시키거나 손상시키고 있으며 부에노도 아닙니다.

독립 또는 부모 범위보다 자식 범위를 더 자주 사용합니다.

범위를 분리하십시오. scope: {}

재사용 가능한 구성 요소를위한 것입니다. :-)

그러나 심각하게도 "재사용 가능한 구성 요소"는 "자체 포함 된 구성 요소"라고 생각합니다. 의도는 특정 목적으로 사용되어야하기 때문에 다른 지시문과 결합하거나 다른 보간 속성을 DOM 노드에 추가하는 것은 본질적으로 의미가 없습니다.

보다 구체적으로,이 독립형 기능에 필요한 모든 것은 상위 범위의 컨텍스트에서 평가 된 지정된 속성을 통해 제공됩니다. 단방향 문자열 ( '@'), 단방향 표현식 ( '&') 또는 양방향 변수 바인딩 ( '=')입니다.

자체 포함 된 구성 요소에서는 다른 지시문이나 속성이 자체적으로 존재하기 때문에 적용 할 필요가 없습니다. 스타일은 자체 템플릿 (필요한 경우)에 따라 결정되며 필요한 경우 적절한 내용을 포함 할 수 있습니다. 독립형이므로 격리 범위에 배치하여 "이 문제를 해결하지 마십시오. 몇 가지 속성을 통해 정의 된 API를 제공합니다."

가장 좋은 방법은 지시문 링크 및 컨트롤러 기능에서 가능한 많은 템플릿 기반 항목을 제외하는 것입니다. 이는 또 다른 "API와 같은"구성 지점을 제공합니다. 지시문의 사용자는 단순히 템플릿을 바꿀 수 있습니다! 기능은 모두 동일하게 유지되었으며 내부 API는 절대 손대지 않았지만 필요한만큼 스타일과 DOM 구현을 망칠 수 있습니다. ui / bootstrap은 Peter & Pawel이 훌륭하기 때문에 이것을 잘하는 좋은 예입니다.

격리 범위도 변환과 함께 사용하기에 좋습니다. 탭을 가지고; 그것들은 전체 기능 일뿐만 아니라 그 안에 있는 모든 것을 부모 범위 내에서 자유롭게 평가할 수 있으며 원하는대로 탭과 창을 남겨 둡니다. 탭은 분명히 자신의 상태 를 가지고 있으며, 이는 템플릿과 상호 작용하기 위해 범위에 속하지만 해당 상태는 사용 된 컨텍스트와 아무런 관련이 없습니다. 탭 지시문을 탭 지시문으로 만드는 것은 전적으로 내부적입니다. 또한 탭과 함께 다른 지시문을 사용하는 것은 의미가 없습니다. 그것들은 탭입니다-우리는 이미 그 기능을 가지고 있습니다!

더 많은 기능으로 둘러싸거나 더 많은 기능을 포함 시키지만 지시문은 이미 그 기능입니다.

그러나 @ProLoser가 그의 대답에서 암시 한 것처럼 격리 범위의 일부 제한 (예 : 기능)을 둘러싼 방법이 있음에 유의해야합니다. 예를 들어 자식 범위 섹션에서 격리 범위를 사용할 때 비 기본 속성 파괴에 대한 보간에 대해 언급했습니다 (기본적으로). 그러나 사용자는 예를 들어 간단하게 사용할 수 class="item-type-{{$parent.item.type}}"있으며 다시 작동합니다. 따라서 하위 범위에 대해 격리 범위를 사용해야하는 강력한 이유가 있지만 이러한 제한 중 일부에 대해 걱정이되는 경우 필요한 경우 거의 모든 문제를 해결할 수 있습니다.

요약

새로운 범위가없는 지시문은 읽기 전용입니다. 그들은 완전히 신뢰할 수 있으며 (즉, 앱 내부) 잭을 만지지 않습니다. 자식 범위가있는 지시문은 기능을 추가 하지만 유일한 기능 은 아닙니다 . 마지막으로 격리 범위는 전체 목표 인 지시문에 대한 것입니다. 그것들은 독립형이기 때문에, 그들이 도둑질을하는 것은 괜찮습니다.

나는 초기 생각을 꺼내고 싶었지만 더 많은 것을 생각할 때 이것을 업데이트 할 것입니다. 그러나 거룩한 쓰레기-이것은 SO 답변을 기다리는 데 오래입니다 ...

추신 : 완전히 접선이지만 범위에 대해 이야기하고 있기 때문에 나는 "프로토 타입"이라고 말하고 다른 사람들은 "프로토 타입"을 선호합니다. :-)

나의 개인적인 정책과 경험 :

절연 : 개인 샌드 박스

내 지시어에서만 사용되며 사용자가 직접 보거나 직접 액세스하지 않는 많은 범위 메서드와 변수를 만들고 싶습니다. 사용 가능한 스코프 데이터를 허용하고 싶습니다. transclusion을 사용하여 사용자가 부모 범위에서 영향을받지 않도록 할 수 있습니다 (영향 없음) . 나는 포함 된 자식에서 변수와 메소드에 접근하기를 원하지 않습니다 .

아동 : 콘텐츠의 하위 섹션

사용자가 액세스 할 수 있는 스코프 메소드와 변수를 만들고 싶지만 내 지시문의 맥락 밖에서 주변 스코프 (형제 및 부모)와 관련이 없습니다. 또한 모든 부모 범위 데이터가 투명하게 세분화되도록하고 싶습니다.

없음 : 단순 읽기 전용 지시문

스코프 메소드 또는 변수를 엉망으로 만들 필요가 없습니다. 아마도 범위와 관련이없는 작업 (예 : 간단한 jQuery 플러그인 표시, 유효성 검사 등)을하고있을 것입니다.

노트

• ngModel 또는 기타 사항이 결정에 직접 영향을 미치지 않도록하십시오. ng-model=$parent.myVal(자식) 또는 ngModel: '='(격리) 와 같은 일을 수행하여 이상한 행동을 피할 수 있습니다 .
• Isolate + transclude 는 모든 정상적인 동작을 형제 지시문으로 복원하고 부모 범위로 돌아갑니다. 따라서 판단에 영향을 미치지 않도록하십시오.
• 의 범위를 함께 엉망를 수행 없음 이 바닥은 DOM의 절반이 아닌 0 의미가 상단의 절반 범위에 데이터를 넣어처럼 때문이다.
• 지시 우선 순위에주의를 기울이십시오 (이것이 어떻게 영향을 미칠 수 있는지에 대한 구체적인 예는 없습니다)
• 서비스를 주입하거나 컨트롤러를 사용하여 모든 범위 유형의 지시문간에 통신하십시오. require: '^ngModel'부모 요소를 살펴볼 수도 있습니다 .

많은 지시문을 작성한 후, 나는 더 적은 isolated범위 를 사용하기로 결정했습니다 . 시원하고 데이터를 캡슐화하고 부모 범위로 데이터를 유출하지 않더라도 함께 사용할 수있는 지시문의 양을 심각하게 제한합니다. 그래서,

작성하려는 지시문이 완전히 자체적 으로 작동 하고 다른 지시문과 공유하지 않으려면 격리 범위 로 이동하십시오 . (구성 요소와 같이 최종 개발자를 위해 많은 사용자 정의를하지 않고도 플러그인 할 수 있음) (지시문이있는 하위 요소를 작성하려고하면 매우 까다로워집니다)

당신이 쓰기에 가고있는 지시어에가는 경우 단지 어떤 범위의 내부 상태, 또는 명시 적 범위 변경 (대부분 매우 간단한 일)가 필요 없다 DOM 조작을 할; 새로운 범위 를 찾지 마십시오 . (예를 들면 ngShow, ngMouseHover, ngClick, ngRepeat)

작성하려는 지시문이 부모 범위의 일부 요소를 변경해야하지만 일부 내부 상태도 처리 해야하는 경우 new child scope 로 이동하십시오 . (예 ngController)

지침에 대한 소스 코드를 확인하십시오 : https://github.com/angular/angular.js/tree/master/src/ng/directive
이 크게 그들에 대해 생각하는 방법에 대한 도움

방금 내 이해와 다른 JS 개념과의 관련성을 추가한다고 생각했습니다.

기본값 (예 : 선언되지 않거나 범위 : false)

이것은 전역 변수를 사용하는 것과 철학적으로 동일합니다. 지시어는 상위 컨트롤러의 모든 것에 액세스 할 수 있지만 동시에 영향을 미치며 영향을받습니다.

범위:{}

이것은 모듈과 같으므로 사용하려는 모든 것이 명시 적으로 전달되어야합니다. 사용하는 모든 지시문이 격리 범위이면 모든 종속 파일을 주입하는 데 많은 오버 헤드가있는 자체 모듈을 작성하는 모든 JS 파일을 만드는 것과 같습니다.

범위 : 아이

이것이 전역 변수와 명시 적 통과 사이의 중간 지점입니다. 그것은 자바 스크립트의 프로토 타입 체인과 유사하며 부모 범위의 사본을 확장합니다. 분리 범위를 작성하고 상위 범위의 모든 속성과 기능을 전달하면 기능적으로 이것과 같습니다.

핵심은 모든 지시문은 어떤 방식 으로든 작성할 수 있다는 것입니다. 다른 범위 선언은 구성에 도움이됩니다. 모든 것을 모듈로 만들거나 모든 전역 변수를 사용하고 매우 조심할 수 있습니다. 유지 관리의 편의성을 위해 논리를 논리적으로 일관된 부분으로 모듈화하는 것이 바람직합니다. 열린 초원과 닫힌 감옥 사이에는 균형이 있습니다. 이것이 까다로운 이유는 사람들이 이것에 대해 배울 때 지시어의 작동 방식에 대해 배우고 있지만 실제로 코드 / 논리 조직에 대해 배우고 있다고 생각하기 때문입니다.

지시문이 어떻게 작동하는지 알아내는 데 도움이 된 또 다른 것은 ngInclude에 대해 배우고 있습니다. ngInclude는 HTML 부분을 포함하는 데 도움이됩니다. 지시문을 처음 사용하기 시작했을 때 템플릿 옵션을 사용하여 코드를 줄일 수는 있지만 실제로 논리를 첨부하지는 않았습니다.

물론 angular의 지시문과 angular-ui 팀 의 작업 사이에 나는 실질적인 것을 수행하는 내 지시문을 아직 만들지 않았으므로 이것에 대한 나의 견해가 완전히 잘못 될 수 있습니다.

나는 Umur와 동의합니다. 이론적으로 격리 된 스코프는 훌륭하고 "휴대용"으로 들리지만, 사소한 기능을 포함하도록 내 앱을 구축 할 때 내 전체를 완전히 작성하기 위해 여러 가지 지시문 (다른 일부에 중첩되거나 속성을 추가)을 통합 해야하는 필요성에 직면했습니다. 도메인 고유 언어의 목적인 자체 HTML.

결국, 격리 범위에 필요한대로 지시문의 각 DOM 호출에서 여러 속성으로 체인에 모든 전역 또는 공유 값을 전달해야하는 것은 너무 이상합니다. DOM에서 모든 것을 반복적으로 쓰는 것은 바보 같고 공유 객체 인 경우에도 비효율적이라고 느낍니다. 또한 지시문 선언을 불필요하게 복잡하게 만듭니다. 지시어 HTML에서 "도달"하고 값을 가져 오기 위해 $ parent를 사용하는 해결 방법은 매우 잘못된 형식 인 것 같습니다.

나도 아주 적은 수의 분리 물을 가진 대부분의 자식 범위 지시문을 갖도록 앱을 변경했습니다. 단순하고 반복되지 않는 속성을 통해 전달 될 수있는 것 이외의 부모로부터 모든 것에 액세스 할 필요가없는 지시자 만 있습니다.

그러한 일이 있기 전에 수십 년 동안 Domain Specific Languages의 꿈을 꿈꿔 왔던 AngularJS 가이 옵션을 제공 하고이 분야에서 더 많은 개발자가 작업함에 따라 우리는 매우 멋진 앱을 보게 될 것을 알고 있습니다 또한 건축가가 작성, 확장 및 디버깅하기가 쉽습니다.

-D