유형 안전성을 넘어서: 런타임 선택기를 구축하여 TypeScript를 더욱 스마트하게 만들기-JS 튜토리얼-php.cn

Beyond Type Safety: making TypeScript smarter by Building a Runtime Picker

면책조항

시작하기 전에 한 가지 분명히 짚고 넘어가겠습니다. 제 패키지인 ts-runtime-picker에 대해 많이 이야기하겠지만 이 글은 홍보 기사가 아닙니다. 나는 단지 내 경험과 그것을 만들기 전에 겪었던 여정을 공유하고 있을 뿐입니다. (그런데 궁금하신 분들은 패키지 링크를 참고해주세요 ?)

TypeScript가 나를 새로운 아이디어(그리고 패키지)로 이끌었던 방법

조금 되감아 보겠습니다. 그래서 저는 한동안 TypeScript로 작업해 왔습니다. 저는 제 자신을 TypeScript 전문가라고 부르지는 않지만 몇 가지 큰 프로젝트를 구축하고 회사에서 함께 작업했습니다. 아시다시피 일반적인 일부 "hello world" 프로젝트, 약간 더 복잡한 프로젝트, 그리고 물론 "이 오류가 도대체 무엇을 의미하는지"를 파악하기 위해 Google을 방문하는 경우도 꽤 있습니다. 또는 "인터페이스에서 필드를 다시 선택하려면 어떻게 해야 하나요?" (이점을 알겠습니다. ?)

어느 날 Firebase 클라우드 기능을 사용하던 중 문제가 발생했습니다. 저는 createUser 엔드포인트에서 유효성 검사 논리를 작성하고, 데이터를 다듬고, 일반적인 CRUD 요청을 처리하고 있었습니다. 이전 개발자의 다음 코드를 접하기 전까지는 모든 것이 순조롭게 진행되었습니다.

firebase.collection("users").add(request.data.user);

로그인 후 복사

...그리고 내 내면의 TypeScript 전문가는 비명을 지르고 있었습니다. ?

어서, 이것은 엄청난 위험 신호였습니다. 오른쪽? 필터링되지 않은 사용자 데이터를 이렇게 직접 삽입하는 것은 위험했습니다. 요청 데이터에 일부 유효성 검사가 누락되어 원하지 않는 필드를 데이터베이스에 삽입하게 된다면 어떻게 될까요? 좋지 않아요.

코드를 재빨리 제거했지만 잠시 멈췄습니다. ? 저는 화면을 바라보며 다음과 같이 생각했습니다. "잠깐만요. request.data를 사용자 인터페이스 유형에 할당하면 TypeScript가 제가 이런 일을 하는 것을 막지 않을까요? 이렇게 하면 문제가 해결되지 않을까요?" (빨간 구불구불한 선이 나타날 때까지 기다리면서 내 IDE를 희망적으로 바라봅니다.)

하지만 잠깐만요… ?‍♂️ TypeScript는 마법이 아닙니다. 단지 컴파일 시간 확인일 뿐입니다. 그렇죠? 런타임에는 존재하지 않습니다. TypeScript는 유형 안전을 위한 마스크이지만 코드가 실행될 때 실제로 아무것도 적용하지 않습니다. 런타임에 추가 필드가 삽입되는 것을 실제로 막지는 않습니다.

그래서 저는 팀원 중 한 명에게 전화를 걸어 "안녕 형제님, 알파벳의 모든 글자가 포함된 Alphabets라는 개체가 있고 'a'와 ''만 허용하는 OnlyTwoLetters 인터페이스를 만든다면 b', 알파벳 객체를 해당 인터페이스에 캐스팅하면 어떻게 되나요?”

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

로그인 후 복사

제 팀원은 한 순간도 놓치지 않고 "하하, 음, TypeScript가 런타임에 이를 막을 수 없기 때문에 여전히 모든 알파벳 문자를 얻을 수 있을 것입니다."라고 말했습니다.

젠장. 나는 그것을 알고 있었다. 저는 TypeScript가 마술처럼 런타임 시 실수를 방지할 수 있다는 희망에 휩싸였습니다. 희망. ?

그런데 문득 떠오른 생각이 있었습니다. TypeScript가 런타임에 이를 적용할 수 있다면 어떨까요? 객체를 특정 인터페이스로 캐스팅하고 TypeScript가 인터페이스에 정의되지 않은 모든 속성을 자동으로 제거하도록 할 수 있다면 어떨까요?

그러면 내 문제가 해결될 거예요.

ts-runtime-picker의 탄생

그래서 저는 전구가 켜지는 순간 "이것을 현실로 만들어보면 어떨까?"라고 생각했습니다. request.data를 사용자 인터페이스로 전송할 수 있다면 TypeScript를 사용하여 추가 속성을 자동으로 제거하여 객체를 Firebase에 안전하게 삽입할 수 있습니다. ?

그래서 ts-runtime-picker에 대한 아이디어가 탄생했습니다. 목표는 간단했습니다. TypeScript 사용자가 특정 인터페이스에 정의된 필드를 기반으로 객체에서 원하지 않는 속성을 필터링할 수 있는 패키지를 만드는 것입니다.

가장 좋은 점은 무엇인가요? 필드를 수동으로 검증하고 필터링하지 않아도 됩니다. 다음과 같은 시대는 지나갔습니다:

firebase.collection("users").add(request.data.user);

로그인 후 복사

작동 방식: TypeScript가 작업을 수행하게 하세요

ts-runtime-picker를 사용하면 전체 프로세스가 자동화됩니다. 개체를 인터페이스로 캐스팅할 수 있으며 패키지는 인터페이스에 정의된 속성만 유지되도록 합니다. 실제 작동 방식은 다음과 같습니다.

이전: 수동 검증

// Object with all alphabet letters
const alphabets = {
  a: 'Apple',
  b: 'Banana',
  c: 'Cherry',
  d: 'Date',
  e: 'Eggplant',
  f: 'Fig',
  // ... all the way to z
};

// Interface that only allows 'a' and 'b'
interface OnlyTwoLetters {
  a: string;
  b: string;
}

// Casting alphabets to OnlyTwoLetters
const filteredAlphabets = alphabets as OnlyTwoLetters;

console.log(filteredAlphabets);

로그인 후 복사

이후: ts-runtime-picker 사용

const filteredData = {
  name: requestData.name,
  age: requestData.age,
};

firebase.collection("users").add(filteredData);  // More work, less fun.

로그인 후 복사

가장 좋은 점은 무엇인가요? 이 코드는 기본적으로 안전합니다. 수동으로 확인하거나 객체를 조작할 필요가 없습니다. ts-runtime-picker는 사용자 인터페이스에 존재하지 않는 모든 필드를 필터링하여 자동으로 처리합니다. 실수로 필드를 삽입하는 것에 대한 걱정 없이 핵심 논리에만 집중할 수 있습니다. ?

게으름의 힘(게으름이 혁신으로 이어지는 방식)

그러면 "이게 순전히 게으름에서 나온 걸까요?"라고 궁금해하실 수도 있습니다. 이에 대해 저는 이렇게 말합니다. 그렇습니다. 그러나 또한 아닙니다. ?

물론, 제가 약간 게으른 태도로 아이디어를 처음 떠올린 것은 데이터를 삽입해야 할 때마다 필드를 수동으로 필터링하고 싶지 않았기 때문입니다. 하지만 때로는 게으름이 광채를 낳기도 합니다! 일을 더 쉽게하려는 욕구는 혁신의 원동력이 될 수 있습니다.

사실 초기의 '게으름'에도 불구하고 패키지를 만드는 데 8시간이 걸렸습니다. 응, 맞아. ?

그런데 가끔 그럴 때도 있어요. "필요는 발명을 낳는다." 지루하고 반복적인 확인을 피하려는 이러한 요구는 궁극적으로 내 삶(그리고 바라건대 다른 많은 사람들의 삶)을 훨씬 더 쉽게 만드는 새로운 솔루션으로 이어졌습니다.

따라서 게으름을 비난할 수는 있지만 ts-runtime-picker를 발생시킨 문제를 해결해야 한다는 요구가 있었습니다. 그래서 때로는 막혀 있거나 게으른 것이 반드시 나쁜 것은 아닙니다. 새롭고 유용한 것이 탄생하는 곳이기도 합니다!

결론

이것이 ts-runtime-picker 패키지 뒤에 숨겨진 이야기입니다. TypeScript의 좌절에서 실제 문제를 해결하는 도구를 만드는 여정입니다. 이 패키지는 TypeScript 사용자가 개발 중뿐만 아니라 런타임에서도 유형 안전성을 최대한 활용할 수 있도록 돕는 방법입니다.

수동으로 필드를 필터링하는 것이 지겹거나 원치 않는 데이터가 몰래 들어가는 것이 걱정된다면 ts-runtime-picker를 사용해 보세요. 걱정할 것이 하나 줄어들고 TypeScript 작업이 조금 더 똑똑해집니다. ?

위 내용은 유형 안전성을 넘어서: 런타임 선택기를 구축하여 TypeScript를 더욱 스마트하게 만들기의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!