Wijmo의 첫 번째 버전은 TypeScript 1.0으로 작성되었으며 코드 품질을 향상시키기 위해 항상 타이핑에 사용되었습니다. Wijmo 2019 v3 릴리스에서는 TypeScript의 최신 개선 사항을 활용하여 타이핑 지원을 개선하기 위해 광범위한 리팩터링을 실시하여 개발자들이 더 나은 IntelliSense와 컴파일 시간 오류 검사(항상 사용하던 런타임 검사 외에도)를 받게 되었습니다. 

타이핑 향상은 다음 네 가지 주요 카테고리로 분류됩니다.

1. 콜백 타입 정보
   
   
2. Union 타입 매개 변수
   
   
3. 일반 CollectionView / ObservableArray
   
   
4. 일반적인 이벤트

콜백 타입 정보

많은 Wijmo 클래스에는 콜백 함수를 나타내는 속성이 있습니다. 이것들은 "Function"으로 선언되었었는데, 이것은 컴파일러에게 콜백의 파라미터나 리턴 타입에 대한 정보를 제공하지 않았습니다.

이러한 콜백을 사용하려면 개발자 문서를 참조해야 합니다.

예를 들면 다음과 같습니다.

이전 스타일의 콜백 (타입 정보 없음)

참고 : 이제 툴팁은 함수가 필요하다는 것을 알려줍니다. 매개 변수 또는 리턴 타입에 대한 정보가 없기 때문에 별로 도움이 되지 않습니다.

최신 빌드에서는 모든 콜백에 타입 정보를 추가했으므로 이제 다음을 얻을 수 있습니다.

새로운 스타일의 콜백 (전체 타입 정보)

이번에는 툴팁에 콜백 함수에 네 개의 매개 변수가 있을 것으로 예상되며 각 매개 변수에 대한 타입 정보와 문서가 표시됩니다.

이 변경 사항은 Wijmo의 모든 콜백 함수 및 속성에 적용되며, 이전 버전과 호환됩니다.

Union 타입 파라미터

몇몇 Wijmo 메소드는 다른 타입의 매개 변수를 지원합니다.

예를 들어, FlexGrid.select 메서드를 사용하면 (a)행 및 열 인덱스 또는 (b)CellRange 및 부울 값 을 전달할 수 있습니다.

이 두 옵션을 지원하기 위해 이 메소드는 매개변수를 any 타입으로 선언하는 데 사용되었습니다. 하지만 개발자가 문자열을 매개 변수로 사용하면 런타임에 예외가 발생합니다. 개발자는 디자인 타임에 도움을 받지 못할 것입니다.

예를 들면 다음과 같습니다.

이전 스타일 멀티-타입 매개 변수(모든 타입)

최신 버전에서는 이러한 모든 호출을 재작업하여 union 타입을 대신 사용했으며 이제 다음과 같은 결과를 얻습니다.

새로운 스타일의 멀티 타입 매개 변수 (Union 타입)

이제 팁은 첫 번째 매개 변수가 숫자 또는 CellRange이고 두 번째 매개 변수는 숫자 또는 부울임을 분명히 보여줍니다. 각 매개 변수에 대한 주석은 각 옵션의 의미를 설명합니다. 잘못된 타입을 사용하려고 하면 컴파일 타임 오류가 발생합니다.

이 변경 사항은 Wijmo의 모든 멀티타입 방법에 적용됩니다. 그리고 이전 버전과 호환됩니다.

일반 CollectionView / ObservableArray

Wijmo의 CollectionView 클래스는 모든 컨트롤을 대신하여 데이터를 처리합니다. 통화를 관리할 뿐만 아니라 항목을 저장, 필터링, 정렬, 그룹화, 추가 및 제거 할 수 있습니다.

이전 버전에서 CollectionView는 any 타입의 항목을 유지했으므로 예를 들어, 현재 항목을 검색한 경우 사용할 타입에 명시적으로 캐스팅 해야 했습니다.

예를 들면 다음과 같습니다.

이전 스타일의 CollectionView (모든 타입의 항목)

이 코드는 최신 버전에서도 작동하지만 이제 동일한 코드를 다음과 같이 작성할 수 있는 선택적 타입 매개 변수를 추가했습니다.

새로운 스타일의 CollectionView (타입 항목)

CollectionView에서 항목 타입을 선언하는 것은 선택 사항이지만 많은 경우 코드를 보다 안전하고 읽기 쉽게 만들 수 있습니다.

ObservableArray 클래스는 항목 유형에 대한 일반적인 매개 변수를 사용하도록 업데이트되었습니다.

일반 이벤트

우리가 추가한 타입 향상의 마지막 카테고리는 일반적인 이벤트입니다.

이전 버전에서 Wijmo에 이벤트 핸들러를 추가하려면 이벤트 매개 변수에 대한 지식이 필요했으며 이는 종종 문서를 보는 것을 의미했습니다.

예를 들면 다음과 같습니다.

이전 스타일 이벤트 핸들러 (인수 타입 정보 없음) 

툴팁에서 이벤트 인수가 모든 타입의 이벤트 인수에 대한 기본 클래스인 EventArgs 클래스의 인스턴스임을 알려주는 방법에 유의해야 합니다. 이것은 정확하지만 그다지 유용하지는 않습니다.

최신 버전을 사용하면 대신 다음과 같은 결과를 얻을 수 있습니다. 

새로운 스타일의 이벤트 핸들러 (발신자 및 인수 타입 정보 포함)

발신자 및 인수 타입을 자동으로 얻는 방법에 주목해보세요. 각 이벤트에 대한 인수를 파악하기 위해 문서를 참조할 필요가 없으며 잘못된 인수 타입을 사용할 위험이 없습니다.

빌드 오류

새로운 버전의 Wijmo를 사용하여 샘플을 재구축할 때, 그 중 일부가 고장 나고 컴파일되지 않을 것입니다.(정확한 수는 460개 중 20개, 즉 약 4%입니다).

처음에는 걱정했지만 샘플을 살펴보면서 미묘한 버그가 있음을 깨달았으며 컴파일러에서 찾을 수 있었습니다.

오류는 세 가지 카테고리로 분류되었습니다.

1. 잘못된 '보낸 사람' 타입의 이벤트 핸들러. 샘플을 작성한 개발자가 '보낸 사람' 매개 변수에 (잘못된) 유형을 지정했습니다. 핸들러가 매개 변수를 사용하지 않았으므로 샘플이 작동하긴 했지만, 버그가 발생했습니다. 수정은 간단했습니다. 매개 변수 유형을 수정했습니다.
   
   
2. 잘못된 리턴 타입으로 위임합니다 . 샘플 중 하나가 문자열 대신 날짜를 반환하는 IGroupConverter 함수를 사용하여 PropertyGroupDescription을 정의했습니다. JavaScript는 날짜를 문자열로 자동 변환했기 때문에 그룹화 및 샘플이 예상대로 작동했습니다. 그러나 간단한 수정(날짜로 toString 호출)으로 코드를보다 명확하고 안전하게 만들었습니다.
   
   
3. 특정 타입을 가정합니다 . CollectionView.groupDescriptions 컬렉션의 요소에 ProertyGroupDescription 개체가 포함되어 있다고 가정했기 때문에 샘플 중 하나가 중단되었습니다 . 샘플에서는 실제로 사실이지만 일반적으로 사실이 아닙니다 (컬렉션에는 PropertyGroupDescription 의 기본 클래스인 GroupDescription 객체가 포함되어 있음). 이 경우의 수정은 단순히 멤버를 PropertyGroupDescription으로 캐스팅 하여 타입 가정을 명확하게 하고 코드를 더 명확하게/유사하게 만드는 것입니다.

이러한 오류를 수정하는 데 몇 분 밖에 걸리지 않았으며, 보다 명확하고 안전한 코드를 사용하여 더 나은 샘플 세트를 얻을 수 있습니다. 무엇보다도 디자인 타임에 오류가 발견되었으므로 위치를 쉽게 찾아 수정할 수있었습니다.

타이핑이 개선된 Wijmo 앱을 구축할 때 비슷한 경험을 하게 될 수 있으므로 이 점을 언급해야한다고 생각했습니다.

코드에 버그가 없으면 좋겠지만 버그가 생길 경우, 새로운 Wijmo가 있으면 버그를 찾는 데 도움이됩니다.

결론

Wijmo의 추가 타입 정보는 다음과 같은 이점을 제공합니다.

1. 더 많은 오류 검사로 버그가 줄어듭니다.
   
   
2. 보다 쉽고 빠르며 안전한 개발을 지원하는 더 많은 IntelliSense를 지원합니다.
   
   
3. 추가 타입 정보는 당사의 문서 도구에 의해 자동으로 선택되므로 보다 우수하고 완전한 온라인 문서화가 가능합니다.
   
   
4. 타입 정보는 컴파일 타임에만 사용되기 때문에 라이브러리 크기/풋 프린트 측면에서 비용이 전혀 들지 않습니다.
    

Wijmo의 최신 버전은 몇가지 새롭고 흥미로운 기능을 제공합니다. 더 풍부한 타입 검사는 전체 라이브러리에 적용됩니다. TypeScript 컴파일러의 강력한 기능을 활용하여 개발자가 어떤 컨트롤을 사용하든 더 나은 코드를 더 빨리 작성할 수 있습니다.