각도 형식을 검증하는 새로운 방법

트위터에서 저를 주목하세요. 최초로 Newsletter에 발표된 timdeschryver.dev을 구독하세요.
지난 1년 동안 우리 팀은 폼이 밀집된 응용 프로그램을 위해 다양한 폼을 만들었다.
우리가 겪는 어려움 중 하나는 표의 다른 필드에 의존하는 필드를 검증하는 것이다.
예를 들어 조건 검증이나 컨트롤의 검증을 검증하기 위해 여러 필드가 필요합니다.
현재, 우리가 이 표들을 돌이켜 볼 때, 우리는 대부분의 표의 구축 방식이 다르다는 것을 알아차렸다.
우리는 결코 유일하게 이와 항쟁하는 사람이 아니다.트위터에서 조건 검증을 각도로 어떻게 실현하는지 물어봤는데, 이 문제를 어떻게 해결하는지에 대한 여러 가지 답이다.이 모든 것은 다르지만, 공통된 인식이 하나 있는데, 이것은 항상 단도직입적이지도, 쉽지 않다.
표를 간소화하고 검증을 간소화하기 위해 저는 개념 검증을 시작하여 서로 다른 방식으로 표를 검증했습니다.

목표

우리의 목표는 더욱 복잡한 표를 위해 해결 방안을 제공하는 것이지만, 간단한 표에도 사용할 수 있다.
이런 새로운 인증 API를 사용하는 개발자로서 미세한 오류를 도입한 코드를 너무 많이 작성하고 싶지 않다.반대로 나는 검증 규칙을 성명하고 싶을 뿐이다.
이 검증 규칙들은 반드시 다시 사용할 수 있어야 한다.만약 일반적인 규칙이 내장되어 있다면, 우리는 각도 검증기와 유사한 추가 점수를 얻을 수 있을 것이다.
나도 이 해결 방안이 파괴적이기를 원하지 않는다. 왜냐하면 나는 기존의 표를 다시 쓰고 싶지 않기 때문이다.
따라서 솔루션은 기존 Angular Forms API 위에 레이어를 구축해야 합니다.

제안

Angular Forms API는 이러한 목표를 달성하기 위한 기본 빌드 블록을 제공합니다.
AbstractControl 은 방법 setError 을 가지고 있습니다. 이것은 폼(컨트롤)을 유효하거나 무효화시키는 데 필요한 모든 내용입니다.
이러한 폼 컨트롤의 유효성을 바탕으로 폼의 유효성 상태를 내보냅니다.
비동기 검증기에 대해 검증기가 그 값을 검증할 때 우리는 markAsPending 이 컨트롤러의 상태를 pending으로 설정해야 한다.
이 새 검증층의 목적은 폼 값을 검증하고 기존의 폼 API를 이용하여 폼 컨트롤의 오류를 설정하고 제거하는 것입니다. 또한 폼 자체에도 사용됩니다.

검증층을 구축하기 위해 우리는 createValidator<T>() 패키지를 사용하고 검증 규칙을 폼 속성에 분배합니다.검증 규칙에는 검증 실패 원인에 대한 상세한 정보가 포함되어 있습니다.인증 규칙에는 이러한 세부 정보를 포함할 수 있는 사용자에 대한 메시지도 포함되어 있습니다.
인증서를 활성화하려면 구독을 해야 합니다. 인증서는 모든 메시지를 포함하는 관찰 대상을 되돌려줍니다.
이 점을 이해하려면 아래의 예를 보십시오.

차이점

양자를 비교함으로써 묵인 행위와 비교되는 차이와 장점을 강조합시다.

조건 검증

컨트롤 값을 기반으로 폼 검증을 비활성화하고 사용하기 위해서, 우리는 when을 사용합니다.
예를 들어 검증 프로그램에서 name이 진짜일 때 아래의 strict은 필수가 된다.

formValidator = createValidator<FormValue>(this.form, {
  name: {
    validator: required(),
    when: (_, form) => form.strict,
  },
})

만약 createValidator 패키지가 없다면, 우리는 컨트롤러를 추가하거나 삭제하는 검증 프로그램을 통해 검증 프로그램을 처리해야 합니다.
Taiga UI 키트를 사용하는 경우 tuiValidator 명령을 사용할 수 있습니다.

this.form.get('strict')!.valueChanges.subscribe((strict) => {
  if (strict) {
    this.form.get('string')!.setValidators(Validators.required)
    this.form.get('string')!.updateValueAndValidity()
  } else {
    this.form.get('string')!.setValidators(null)
    this.form.get('string')!.updateValueAndValidity()
  }
})

서로 다른 컨트롤 사이에 내부 집합이 존재할 때, 이렇게 하면 곧 비대해지고 대형 폼에 해로울 수 있다.
우리의 사례에서, 우리는 다른 검증기로 이전의 검증기를 뒤집었다.몇 차례의 디버깅을 거쳐서야 우리는 이 숨겨진 버그를 재현할 수 있었다.when 문법을 사용하면 컨트롤과 검증기 간의 일치성을 쉽게 볼 수 있습니다.

액세스 양식 값

모든 검증기에서, 우리는 전체 표의 값에 접근할 수 있다.
폼 속성(예를 들어 equal 규칙과)을 비교하거나 여러 폼 값을 기반으로 하는 것을 검증할 때 방문 폼 값이 매우 유용하다.
다음 코드 세그먼트에서 passwordConfirmation은 password의 값을 필요로 한다.

formValidator = createValidator<User>(this.form, {
  password: [required(), minLength(7)],
  passwordConfirmation: equal((user) => user.password),
})

Forms API로 이 장면을 실현하기 위해서는 두 가지 옵션이 있습니다.
우선, 우리는 이 두 컨트롤을 그룹으로 나누고, 폼 그룹에 인증서를 만들 수 있습니다.이렇게 하는 것은 메시지가 특정한 컨트롤에 연결되지 않았음을 검증하는 것이 단점이다.Google의 일반적인 컨트롤러는 사용자에게 검증 메시지를 보여주기 위해 그룹에 귀속되지 않고 검증 메시지를 컨트롤러에 귀속시키기를 원하기 때문에 문제가 있습니다.
두 번째 옵션은 값이 바뀔 때 인증서를 다시 만드는 것입니다.

this.form.get('password')!.valueChanges.subscribe((password) => {
    this.form.get('passwordConfirmation')!.setValidators(CustomValidators.equal(password))
    this.form.get('passwordConfirmation')!.updateValueAndValidity()
  }
})

Conditional Validation처럼 더 큰 리스트는 까다롭다.

정적 유형

하나의 유형을 createValidator<T>에 전달할 때 나머지 검증은 정적 형식입니다.
검증기를 구축할 때, 폼 모델의 속성은 자동으로 완성되고, 폼 컨트롤과 폼의 값은 모든 검증기 규칙에 입력됩니다.내장된 검증기도 타자를 치는 것이기 때문에 우리는 오류 검증기를 사용하는 오류를 범해서는 안 된다.
예를 들어 문자열 값을 포함하는 속성에 대해 숫자 검증을 사용할 수 없습니다. (예: greaterThan)

주요 차이점

상술한 용례를 가능하게 하기 위해서, 매번 변경할 때마다 전체 표를 검증한다.
동기화 검증기에 있어서 이런 영향은 무시할 수 없다. 왜냐하면 그것들은 호출된 방법일 뿐이기 때문에 신속하고 성능에 대한 영향은 매우 적기 때문이다.
비동기 검증기에 있어서는 또 다른 상황으로 이런 행위가 영향을 미칠 수 있다.

영향

개발자로서 createValidator 패키지는 폼을 작성하고 읽는 검증 논리를 더욱 쉽게 하기 위한 것이다.
그것의 최소 API(흔한 검증 규칙도 포함)도 createValidator 패키지로 빠르게 넘어갈 수 있도록 허용해야 한다.
기존 폼을 재구성하는 것은 폼의 상태와 값이 이전과 같기 때문에 가장 작은 영향을 미칠 것이다.

마지막 생각

단순한 개념 증명일 뿐이지만 Angular Forms API에 추가 레이어를 추가하여 빌드 블록의 이점으로 사용할 수 있습니다.그렇기 때문에, 흔히 볼 수 있는 검증 규칙은 내장된 각도 검증기의 행위와 같기 때문에, 만약 우리가 촉발하기로 결정한다면, 그것은 작고 빠른 변화가 될 것이다.
표 검증은 더욱 표현력이 있어 개발에 도움이 되고 유지 보수 원가를 높일 수 있다.
예전과 같이 언제든지 당신의 생각을 저에게 알려주세요.
트위터에서 저를 주목하세요. 최초로 Newsletter에 발표된 timdeschryver.dev을 구독하세요.