각도 응용 프로그램의 문제를 해결하는 것은 진정한 도전일 수 있다.우리의 응용 프로그램이 실행되지 않을 때, 모든 것이 더욱 어려워진다. 이것은 우리에게 컨트롤러의 일부'관건'레드라인만 줄 뿐이다.
하지만 나를 믿어라, 결국 그렇게 고통스럽지는 않을 것이다.네가 해야 할 일은 흔히 볼 수 있는 오류를 피하는 것이다. 이 오류들은 거의 모든 Angular 개발자들이 직면해야 하며, 적어도 한 번은 범해야 한다.
가장 흔한 오류 7개를 분석한 이 글을 읽으면 더 적은 문제가 생길 수 있습니다.
나는 왜 이것이 나쁜 방법이거나 단지 잘못된 것인지 모든 것을 설명할 것이다. 나는 당신이 정확한 방향, 적어도 가능한 해결 방안을 가지고 있도록 인도할 것이다.

1. 필요한 각도 모듈 가져오기

초보자들이 가장 흔히 볼 수 있는 오류는 가져오는 데 필요한 모듈이 없다는 것이다.왜?너는 이 틀에 대한 이해가 부족하기 때문이다.
각도를 전면적으로 이해하는 데는 시간이 좀 걸린다.
오류는 다음과 같습니다.

Can't bind to 'ngModel' since it isn't a known property of 'input'

이 오류는 각도 모양 모듈이 우리 모듈로 가져오지 않았음을 나타냅니다.
만약 우리가 다음과 같은 오류를 얻게 된다면:

Unhandled Promise rejection: No provider for HttpClient!

이것은 HttpClient 모듈이 우리 루트 모듈로 가져오지 않았다는 것을 의미합니다.
솔루션
해결 방안은 매우 간단하다. 우리는 메인 모듈에서 부족한 모듈을 가져와야 한다.대부분의 경우 이 모듈은 응용 프로그램의 AppModule로 가져와야 합니다.

주의: 응용 프로그램의 크기가 현저하게 증가하는 것을 피하기 위해서 우리는 반드시 필요한 모듈만 가져와야 한다.이 모범 사례는 프레임워크 모듈뿐만 아니라 사용자가 사용하고 싶은 모든 사용자 정의 모듈에도 적용됩니다.
각도 재료 라이브러리를 예로 들자. Sidenav 모듈을 사용하려면 특수한 MatSidenav 모듈 등이 있다.
따라서 모듈의 필요에 따라 일부 모듈을 가져오지 않을 수도 있습니다.

...
MatSidenavModule
MatCheckboxModule
...

2. 존재하지 않는 항목에 DOM 참조를 사용하지 마십시오(@ViewChild)

@ViewChild 데코더의 도움말로 Angular는 참조 구성 요소의 특정 하위 요소 (노드 또는 HTML 구성 요소) 를 쉽게 만듭니다.
#, 뒷부분 이름만 추가하면 됩니다.예:

<div #myFirstDiv></div>

우리는 현재 구성 요소에서 이 요소를 인용할 수 있다.만약 그것이 구성 요소라면, 우리는 그 공공 방법을 호출하여 그 속성에 접근할 수 있다.간단한 HTML 요소인 경우 스타일, 속성 또는 하위 요소를 변경할 수 있습니다.
@ViewChild 데코더를 사용하여 속성을 꾸미면 Angular는 자동으로 어셈블리에 지정된 속성을 참조합니다.
인용 이름을 장식기에 전달해야 합니다.예를 들어 @ViewChild("myFirstDiv")입니다.

문제
@ViewChild 명령은 매우 유용하지만, 참조된 요소가 실제로 존재하는지 주의해야 합니다.
문제는 왜 그것이 존재하지 말아야 하는가?
인용된 항목이 실제로 존재하지 않는 이유를 설명할 수 있는 몇 가지 이유가 있다.가장 일반적인 이유는 브라우저가 업로드를 완료하지 않았기 때문에 DOM에 이 요소를 추가하지 않았기 때문입니다.
분명히 이 단계에서 이 요소에 접근하려고 시도한다면, 그것은 정의되지 않거나 비어 있을 것이다.
DOM 액세스가 존재하지 않을 때의 예는 ngOnInit 라이프 사이클 리셋의 구성 요소 구조 함수에 있습니다.
예를 들어 보겠습니다.

솔루션
DOMContentLoader 이벤트나 하이퍼클래식 jQuery에서 $(document) 콜백을 기억하십시오.준비 ()?!여기서 Angular가 사용하는 메커니즘은 동일합니다:ngAfterViewInit.
토론의 리셋은 Angular Lifecycle 연결의 일부분이다.ngAfterViewInit는 모든 구성 요소와 하위 보기를 초기화할 때 호출되는 리셋입니다.
이전 예제로 돌아가면 코드를 이렇게 변경할 수 있습니다.

너무 좋아요.우리는 이미 우리의 문제를 해결했다.하지만 조심해야 한다. 다른 함정도 고려해야 한다.
앞에서 설명한 대로 DOM의 요소를 실제로 추가할 때 액세스할 수 있습니다.
만약 우리가 이런 장면이 있다면:
*ngIf 명령이 있는 요소는 DOM에서 완전히 제거됩니다.
그래서 이런 상황에서 우리는 그것을 방문할 수 없다.
응용 프로그램의 붕괴를 방지하기 위해서, 인용이null인지 확인해야 합니다.실제로 우리의 준칙은 다음과 같다.

3. DOM을 직접 조작하지 마십시오.

참고 DOM을 직접 각도로 조작하는 것은 나쁜 방법으로 여겨지지 않습니다.
아마도 우리 프로그램은 브라우저에서 정상적으로 작동할 수 있을 것이다. 그러나 다른 환경에서, 예를 들어 Angular Universal 등은 발생하지 않을 것이다.어쨌든, Angular Universal은 서버에서 Angular 응용 프로그램을 렌더링할 수 있도록 합니다.
예를 들어 보겠습니다.

솔루션
Angular는 DOM 작업을 위한 특수 API: Render2를 제공합니다.이 API의 도움으로 우리는 DOM을 사용할 때 익숙해진 모든 것을 할 수 있다.
다음은 명확한 예이다.

앞에서 말한 바와 같이, 우리는 정말 어떤 일을 할 수 있기 때문에, 나는 너에게 공식 문서를 좀 보라고 건의한다.

4. 모서리 보호 장치는 (진정한) 안전 기능이 아니다

각도 보호는 인위적으로 일부 노선에 접근하는 것을 제한하는 좋은 방법이다.
고전적인 예는 로그인하지 않은 상황에서 일부 페이지에 접근하는 것을 금지하는 것이다.


문제
이것은 여전히 일부 루트에 접근하는 것을 금지하는 효과적인 해결 방안이지만, 다른 웹 해결 방안과 마찬가지로, 결코 100% 안전한 것은 아니다.
우리는 잠재적인'위험'사용자에게 완전한 원본 코드를 제공하기 때문에 어떤 방식으로든 응용 프로그램을 수정할 수 있다.우리 수비수들이 몇 마디 논평을 통해 쉽게 돌아갈 수 있다는 뜻이다.
솔루션
서버 측 솔루션을 추가하면 응용 프로그램에서 데이터가 침입될 위험을 낮출 수 있습니다.예를 들어 JWT(JSON 웹 토큰)를 사용합니다.

5, 한 번만 구성 요소 선언

어플리케이션을 모듈로 그룹화하기 시작하면 (기본적으로 모범 사례임) 다음과 같은 일반적인 문제가 발생할 수 있습니다.
하나의 구성 요소는 하나의 모듈에서만 설명할 수 있습니다!
그러나 만약 우리가 여러 모듈에서 우리의 구성 요소를 사용하고 싶다면, 우리는 어떻게 해야 합니까?
솔루션
해결 방안은 매우 간단하다. 모듈에 구성 요소를 추가하기만 하면 된다.
구성 요소마다 모듈이 너무 많을 수도 있는데, 왜 구성 요소 모듈을 만들지 않습니까?이 모듈은 다른 모듈로 가져올 수 있으며, 구성 요소를 사용할 수 있습니다.

6. 속성 최적화 및 애플리케이션 가속화 대신 Ngif 사용

숨기기 명령과 *ngIf 명령 사이에 혼동이 자주 발생합니다.
주요 차이점은 *ngIf 명령은 표시된 요소만 숨기는 것이 아니라 DOM에서 삭제하는 것입니다.성능 개선 외에 *ngif 솔루션이 더 깨끗한 것 같습니다.
따라서 이 장면들의 기준으로 삼을 것을 건의합니다.

7. 서비스 이용으로 서비스 유지 관리 문제 방지

주의: 일반적인 건의로서 업무 논리를 서비스에 미루는 것은 시종 좋은 방법이다.
이런 방식을 통해 관리는 더욱 쉽다. 왜냐하면 가능한 수정은 몇 초 안에 실현될 수 있고 현지화되기 때문에 우리는 n천행 코드를 미친 듯이 수정해서는 안 된다.
HttpClient를 사용할 때 이 제안은 당연히 정확합니다.그것은 항상 집중된 서비스에 포함되어야 한다.이렇게 하면 테스트도 쉽고 변경도 쉽다.
예를 들어 백엔드는 업데이트된 후에 모든 요청에 새로운 헤더를 전달해야 합니다.만약 집중식 서비스가 없다면, 응용 프로그램에서 여러 줄 코드를 변경해야 합니다.
나는 이 문장이 유용하길 바란다.그렇다면, 당신의 친구, 동료, 혹은 당신이 흥미를 느낄 수 있다고 생각하는 모든 사람들과 나누세요.