it-source

각도에서의 DOM 조작JS 서비스

criticalcode 2023. 3. 2. 22:18
반응형

각도에서의 DOM 조작JS 서비스

Angular를 사용할 때 지시어 내부의 DOM 요소를 조작해야 한다는 것은 잘 알려져 있습니다.JS.

다만, 사용 예에 따라서는, 서비스내에서 DOM 를 조작할 수 있는 경우가 있습니다.Misko Hebery는 여기서 이것에 대해 이야기하고 있다.부트스트랩 UI 대화상자에서도 예를 찾을 수 있습니다.

Misko의 설명은 다소 애매하기 때문에 DOM을 지시가 아닌 서비스에 넣어야 할 시기를 어떻게 판단해야 하는지 궁금했습니다.

디렉티브는 정의된 방법으로 항상 DOM 노드에 부가됩니다.따라서 디렉티브를 정의하면 디렉티브가 접속되어 있는DOM 노드가 "확장" 또는 치환원됩니다.

특정 상황(대화상자 등)에서는 DOM 노드를 특정 부모에 연결할 수 없습니다.이러한 경우 서비스를 사용하는 것이 타당하며 DOM 조작은 서비스 내에서 캡슐화되기 때문에 컨트롤러는 여전히 DOM 비트에서 벗어날 수 있습니다.

팝업은 서비스를 사용할 수 있는 또 다른 상황일 수 있지만 대화 상자와는 달리 팝업 IS가 DOM 노드에 연결되어 있습니다.그마저도 약간 흐릿한 영역입니다.

따라서 기본적이고 간단한 테스트는 "이 DOM 조작 코드 비트를 DOM 노드에 연결할 수 있습니까?"입니다.'네'인 경우 지시합니다.[아니오]의 경우는, 서비스를 실시.

서비스를 사용하는 일반적인 예로는 대화상자와 사용자 지정 확인 상자가 있습니다.

Ganaraj가 Misko가 말한 것을 잘 기술했다고 생각합니다만, (예를 들면) 모달 다이얼로그의 DOM 조작 코드를 DOM 노드에 넣을 수 있다고 주장할 수 있습니다.

DOM 에, 「DOM」을 사용하는 입니다.ng-show이치노 다음 할 수 .$rootScope또또그 : 비스스스 。

사실 저는 이 접근방식이 '적절하다'고 느껴지기 때문에 선호합니다. 즉, 서비스는 데이터 전송을 처리하고 지시사항은 서비스와 상호 작용하여 사용자에게 의미 있는 방식으로 표시되도록 합니다.

하지만 미스코가 특별히 명확하지 않다는 것은 상당히 주관적이라는 것을 보여준다고 생각합니다.당신에게 가장 의미 있는 일을 하세요.

이 토픽을 검색해, 이것에 대한 내면의 감정을 강화합니다.왜냐하면 저는 지금 어떤 논리를 서비스에 배치하고 싶은 문제를 다루고 있기 때문입니다.다음은 제 사례입니다. 돔 기반 핸들링을 서비스하는 데 충분한 이유가 있다고 생각합니다.

마우스 위치에 전체적으로 반응하는 지시 기반 요소가 있습니다(예: 마우스 위치에 따라 이동하거나 변경됨).이러한 요소의 수는 정해져 있지 않으며 애플리케이션 내의 특정 위치에 관련되지 않습니다(GUI 요소이며 모든 컨테이너에 관련될 수 있기 때문입니다).엄밀한 각도 "dom logic in the directives only" 규칙을 고수하면 모든 요소가 마우스 위치 해석과 관련된 논리를 공유하기 때문에 효율이 떨어집니다.이것은 창을 중심으로 회전합니다.Request Animation Frame 틱s

이 논리를 디렉티브에 포함시키면 리스너/raf 루프가 모든 인스턴스에 연결되어 있을 것입니다.마우스가 움직일 때마다 동일한 청취자를 호출하고 모든 요소에 대해 동일한 결과를 반환하기 때문에 여전히 DRY 상태이긴 하지만 효율적이지 않습니다.

이 경우 dom 기반 로직임에도 불구하고 이를 서비스로 이동하고 각 다이렉트인스턴스를 서비스에 등록하여 각 인스턴스에서 중복되는 로직과 동일한 인스턴스 기반 로직을 호출하는 것이 가장 좋습니다.

Angular는 코드를 구조화하는 방법에 대해 몇 가지 매우 좋은 조언을 제공하지만, 모든 사용 사례를 커버할 수는 없기 때문에 그렇다고 해서 그것이 어렵고 빠른 규칙이 되는 것은 아닙니다.「베스트 프랙티스」가 실패한다고 생각되는 구멍이 있는 경우는, 실제로는 베스트 프랙티스를 올바르게 이해하고 있기 때문에, 룰을 일부러 어길 필요가 있는 이유를 발견했기 때문입니다.

그건 내 2센트야!!

@dudewad에 동의합니다.결국 서비스(공장, 공급자, 값)는 각도의 모듈 패턴일 뿐이며 싱글톤으로 구현되는 것은 제한됩니다.문서나 다른 글로벌 어프로치가 아닌 디렉티브의 링크 기능에 전달되는 요소를 통해 DOM에 액세스 하는 것이 중요하다고 생각합니다.단, 디렉티브에서 얻은 dom 요소에 적용하는 논리가 같은 모듈에 존재하는 것은 중요하지 않다고 생각합니다.SRP의 이유로 서비스를 사용하여 코드를 약간 분할하는 것이 유리할 수 있습니다.이는 테스트에 초점을 맞추는 것이 보다 복잡한 논리일 수도 있고 @dudewad가 지적한 대로 여러 디렉티브로 논리를 사용하는 것이 바람직할 수도 있기 때문입니다.

변수 변경에 기초한 DOM 조작 방법을 사용하는 데 있어 하나의 단점(즉,ng-show="isVisible"DOM 조작은 다음 "Javascript turn" 루프 후에 발생합니다(다음의 경우).isVisible갱신되었습니다).DOM 를 즉시 갱신할 필요가 있는 경우가 있습니다.

예를 들어, 일반적인 시나리오는 새로운 루트/상태로의 이행 중에 "spinner"를 표시하는 것입니다.를 설정했을 경우$scope.isVisible = true에서$routeChangeStart/$stateChangeStart이벤트, 그 다음에$scope.isVisible = false에서$routeChangeSuccess/$stateChangeSuccess이벤트, 당신은 결코 볼 수 없을 것입니다.ng-show전체 경로/상태 변경이 javascript 1회 턴 내에 이루어지기 때문입니다.사용하는 것이 좋을 것 같습니다..show()그리고..hide()스피너를 실제로 볼 수 있도록 말이죠.

이 모든 것을 되돌려 OP의 질문에 관련짓습니다.DOM 조작이 「스피너」모달로 표시되는 상황에서는, 서비스중에 실시해, 모델 변경에 의존하지 않고 직접 DOM 조작 방법으로 실시합니다.

언급URL : https://stackoverflow.com/questions/17925547/dom-manipulation-in-angularjs-services

반응형