2023년 4월 3주차 개발 뉴우스

안녕하세요. 구독자님 이번주 뉴스도 봐주셔서 감사합니다 😄

1.  Everyone's talking about HOTScript

스피커는 HOTScript가 고차 유형을 사용하여 어떤 원하는 방식으로 유형을 변환하기 위한 선언적 설정을 만든다고 설명합니다. 다른 고차 유형에 전달할 수있는 고차 유형을 만들어 HOTScript는 TypeScript 마법사가 복잡한 변환을보다 직관적이고 효율적인 방식으로 만들 수 있도록합니다.

문서에는 스피커가 숫자와 문자열의 튜플을 변환하는 방법을 설명하는 HOTScript 사용 예제가 포함되어 있습니다. 예제는 입력으로 임의의 입력을 가져 오는 'pipe' 함수를 사용하는 것을 포함합니다. 'pipe'에 전달 된 두 번째 인수는 입력에 수행 할 명령어 목록입니다. 이 예제에서는 각 숫자에 3을 더하고, 마침표로 결합하고, 다시 문자열의 튜플로 분할하고, 각 문자열을 숫자로 매핑하고, 각 숫자에 10을 더한 다음, 결과를 얻기 위해 합산합니다.

스피커는 HOTScript의 가능성과 TypeScript 커뮤니티에서의 고차 유형 패턴에 대한 열광을 표현합니다. HOTScript가 제공하는 선언적 설정은 개발자가 유지 관리 및 확장이 쉬운 깨끗하고 간결한 코드를 작성할 수 있도록합니다. 스피커는 TypeScript 마법사가 HOTScript를 탐색하고 실험하여 커뮤니티가 무엇을 구축할 수 있는지 살펴보도록 권장합니다.

2. The best TypeScript library just got better

스피커는 파이프 메서드를 통한 연쇄 유효성 스키마, 데이터 유형 변환을 위한 coerce 메서드, 폴백 값에 대한 catch 메서드 및 날짜-시간 유효성 검사 지원과 같은 릴리스에 포함된 새로운 기능을 강조합니다. 스피커는 TypeScript의 데이터 유효성 검사에 대한 유용성을 강조하며 라이브러리에 대한 감탄을 표합니다.

스피커는 API에서 알 수없는 데이터를 반환하는 경우 또는 추가 할 데이터가 불확실한 API를 빌드하는 경우 Zod가 사용하기에 좋은 라이브러리라고 언급합니다. Zod는 TypeScript에 런타임 유효성 검사를 추가하여 런타임 전에 검증 오류를 쉽게 잡을 수 있습니다.

스피커는 Zod의 검증 스키마의 최소 구문을 감사한다는 것도 언급하며 이는 쉽게 읽고 이해할 수 있도록 만듭니다. 파이프 메서드는 데이터를 더 이디오매틱 한 방식으로 변환하는 데 특히 유용하며 coerce 메서드는 문자열을 숫자로 변환하는 등 데이터 유형을 변환하는 데 큰 도움이 됩니다.

또한 스피커는 일반적인 날짜-시간 유효성 검사뿐만 아니라 정밀도 및 시간대를 사용자 정의할 수 있는 Zod의 날짜-시간 유효성 검사 지원을 칭찬합니다. 이전 버전에서 누락 된 기능이었지만 이번 추가로 매우 환영합니다.

마지막으로, 스피커는 TotalTouchGroup.com에서 무료로 이용 가능한 Zod 코스를 확인하도록 시청자들에게 권장합니다. 그리고 Zod의 창시자인 Colin의 관리를 칭찬하며 라이브러리가 미래에도 계속 사용될 것으로 예측합니다.

3. TypeScript: Should you use Types or Interfaces?

발언자는 타입 및 인터페이스의 성능과 기능에 대한 유용한 인사이트를 제공하며 이에 대한 자신의 의견을 세 가지 단계로 제시한다.

최초에 발언자는 TypeScript 성능 위키와 마찬가지로 인터페이스가 타입보다 우수하다고 믿었다. 위키는 인터페이스가 더 빠르기 때문에 속도가 관심사인 경우 더 좋은 선택이라고 주장한다. 그러나 발언자는 곧 인터페이스는 객체와 함수와 같은 특정 항목에만 사용할 수 있으며 타입은 모든 것에 사용할 수 있다는 것을 발견했다. 또한 인터페이스의 속도 이점은 실제 코드가 아닌 타입 체크기의 속도에만 적용되며 이 이점은 예전만큼 중요하지 않다.

그 다음, 발언자는 두 번째 단계로 넘어갔는데, 이는 일관성만 지킨다면 어떤 것을 사용하더라도 상관없다는 것이다. 발언자는 모든 객체는 인터페이스로 유형 지정하고, 나머지는 타입으로 유형 지정하는 것이 좋다고 제안했다. 또는 모든 것에 대해 타입을 사용할 수도 있다. 발언자는 인터페이스가 상속 등 고유한 속성을 가지고 있다는 것이 흥미롭다고 생각했다.

그러나 발언자는 곧 인터페이스가 일부 사용하지 않는 기능을 번들로 제공한다는 것을 깨달았다. 특히 기본 객체 유형을 정의하는 것만 필요한 경우에는 이러한 기능이 중요하지 않을 수 있다. 예를 들어, 인터페이스의 중요한 기능 중 하나는 동일한 스코프 내에서 동일한 이름을 가진 두 인터페이스를 병합할 수 있는 선언 병합이다. 이는 일부 목적에는 유용하지만 인터페이스에 대한 생각 방식을 변경하는 방식 때문에 처리하기 까다롭다. 또한이 기능은 타입을 확장하는 유형을 정의하려는 경우 문제가 발생할 수 있으며 이는 타입으로는 가능하지만 인터페이스로는 불가능하다.

따라서 발언자는 세 번째 단계로 들어가서 특정 인터페이스 기능이 필요하지 않은 경우 타입을 사용해야한다는 결론을 내렸다. 다른 유형을 확장하는 타입이 필요한 경우 인터페이스를 사용하라. 클래스가 인터페이스를 확장한다는 것을 나타내려면 인터페이스를 사용하라. 객체지향 프로그래밍에서 인터페이스라는 단어를 좋아한다면 인터페이스를 사용하라. 그러나 특정 상황에서 이상하거나 이상한 일을하지 않을 예측 가능한 것이 필요하다면 대개 타입을 사용해야한다. 발언자는 또한 타입과 인터페이스 간에 성능 차이가 없으므로 두 가지 중 선택은 기능과 일관성에 기반해야한다고 지적했다.

4. Enums considered harmful

스피커는 TypeScript enums이 JavaScript의 기본 기능이 아니며, 언어에 C# 객체 지향적인 느낌을 제공하기 위해 TypeScript에서 도입되었다고 설명합니다. 그러나 스피커는 enums가 런타임에서 예측할 수 없으며, 예상과 다르게 동작한다고 주장합니다. 예를 들어 "로그 레벨"이라는 enum을 만들면 기본값으로 debug, warning 및 error가 멤버로 설정됩니다. 그러나 스피커가 변환된 JavaScript를 확인하면, log level은 약간 다른 객체로 나타나며, debug가 0으로 할당되고, 그 결과 (0)이 log level 0에 할당되고, 그렇게 이어집니다. 이는 사용자가 log level에서 object.values를 수행하면, 예상과 다르게 0 debug, 1 warning 및 2 error를 얻게 됩니다.

스피커는 또한 TypeScript의 규칙 중 enums에 대한 규칙을 깨는데, 이는 TypeScript가 enums의 이름에 관심을 가진다는 것입니다. 이것은 TypeScript가 명명된 형(type) 시스템(nominal type system)이 되어, "로그 레벨" enum인지 "로그 레벨 2" enum인지에 따라 다르게 취급됩니다. 이것은 리팩토링을 쉽게 만드는 장점도 있지만, 어떤 개발자들에게는 문제가 될 수 있습니다.

이 문제를 해결하기 위해, 스피커는 enums 대신 "as const" 어노테이션이 지정된 일반적인 JavaScript 객체를 사용하는 것을 권장합니다. "as const" 어노테이션은 객체를 조작하거나 변경할 수 없음을 의미합니다. 이 방법을 사용하면 사용자는 객체에서 형(type)을 추출하고 변수의 형(type)을 지정하는 데 사용할 수 있습니다. 스피커는 이 방법이 enums보다 TypeScript의 구조적 형(type) 시스템에 더 잘 어울리며, 더 자연스럽고 직관적이라고 설명합니다. 또한 enums보다 훨씬 깨끗하고 읽고 쓰기 쉽습니다.

마지막으로, 스피커는 JavaScript에 enums을 기본 기능으로 가져오기 위한 제안을 언급합니다. 이 제안이 현실이 되면, 모든 사람들이 더 잘 문서화하고 이해할 수 있기 때문에 사용자는 enums을 더 예측 가능하게 사용할 수 있게 됩니다.

결론적으로, 스피커는 TypeScript로 작업할 때 enums은 최선의 선택이 아니며, 대신 "as const" 어노테이션이 지정된 일반적인 JavaScript 객체를 사용하는 것을 제안합니다.

5. How to Name your Types

연사가 제안하는 첫 번째 지침은 배열 타입을 제외하고 단수 이름을 사용하는 것입니다. 예를 들어, 유니온 타입이 여러 루트를 포함하는 경우 "roots"가 아니라 "root"로 이름을 지정해야 합니다. 이는 유니온 타입이 여러 루트가 아닌 단일 루트의 가능성만을 나타내기 때문입니다. 마찬가지로, 루트 배열이 필요한 경우 일관성을 유지하기 위해 "roots array"가 아니라 "root array"로 이름을 지정해야 합니다.

두 번째 지침은 변수와 유형에 대해 다른 케이싱을 사용하여 혼동을 피하는 것입니다. 연사는 유형과 변수에 대해 다른 케이싱을 사용하면 런타임 변수와 타입 수준 변수를 구분하는 데 도움이 된다고 설명합니다. 예를 들어, "route"라는 변수가 "Route"라는 유형과 동일한 범위에서 선언된 경우 구문 강조 표시가 혼동될 수 있습니다. 이를 피하기 위해 연사는 유형에 대해 Pascal case를 사용하고 변수에 대해 camel case를 사용하는 것을 제안합니다.

세 번째 지침은 일반적인 유형임을 나타내기 위해 유형 인수를 "t"로 접두사로 붙이는 것입니다. 연사는 "t" 또는 "t data"를 접두사로 사용하는 것이 허용된다고 제안하지만, "t u v w x y z"를 사용하는 것은 혼란스러울 수 있으므로 경고합니다.

마지막으로, 연사는 인터페이스에 대해 "T"를 사용하는 등 불필요한 규칙을 피하는 것을 제안합니다. 연사는 유형이 인터페이스인지 클래스인지를 결정하는 것은 이름 위에 마우스를 올리면 쉽게 확인할 수 있으므로 접두사나 접미사를 추가하는 것은 필요하지 않다고 주장합니다. 대신, 유형의 목적을 정확하게 전달하는 기술적인 이름을 사용하는 것이 좋다고 제안합니다.

6. Don't use return types, unless...

반환 유형을 사용하면 개발자가 함수가 반환해야 하는 것을 명시할 수 있습니다. 예로 들어 makeID라는 함수는 ID 문자열과 길이가 16인 무작위 숫자를 끝에 추가하여 반환하는 함수입니다. 반환 유형에 string을 추가하면 함수가 문자열을 반환하도록 보장할 수 있습니다. 반대로 반환 유형을 number로 변경하면 string 형식은 number 형식에 할당할 수 없다는 오류가 발생합니다.

비디오는 반환 유형이 함수가 특정 유형을 반환하도록 강제하는 데 도움이 될 수 있지만, 유지 관리해야 하는 추가 코드가 될 수도 있다고 설명합니다. 따라서 규칙은 TypeScript가 이미 반환하는 것을 알고 있는 makeID와 같은 간단한 함수에서는 반환 유형을 사용하지 않는 것입니다. 대신 개발자는 TypeScript가 스스로 결과를 추론하도록 해야 합니다.

그러나 함수에 여러 가지 분기가 있거나 라이브러리 코드를 작성하는 경우 반환 유형이 유용합니다. 이러한 경우 반환 유형을 사용하여 함수가 반환하는 것이 의도한 대로인지 보장하고 코드를 확장하기 쉽게 만들 수 있습니다. 예를 들어, handleNewState라는 함수는 창에 초점을 맞춘 이벤트와 창에 초점을 잃은 이벤트 두 가지 유형의 이벤트를 받아들이고 전달된 이벤트에 기반하여 새 상태를 반환합니다. 함수가 반환해야 하는 것을 설명하는 새 유형을 만들고 반환 유형을 state로 표시함으로써 handleNewState가 의도한 대로 반환되도록 보장할 수 있습니다.

비디오는 또한 대형 객체가 코드를 통해 전달되고 추론될 때 반환 유형이 도움이 될 수 있는 특정 성능 문제가 있을 수 있다고 언급합니다. 그러나 대부분의 응용 프로그램 코드에서는 반환 유형을 기본적으로 사용하지 않아야 합니다. 개발자는 응용 프로그램 코드에 반환 유형을 강제하는 eslint 규칙을 끌 수 있지만 필요한 경우 반환 유형을 사용해야 합니다.

요약하면, 반환 유형은 TypeScript에서 함수가 의도한 대로 반환되도록 보장하는 데 유용한 도구입니다. 그러나 개발자는 특히 간단한 함수에서는 조심스럽게 사용해야 하며 TypeScript가 스스로 결과를 추론하도록 해야 합니다. 그러나 함수에 여러 가지 분기가 있거나 라이브러리 코드를 작성하는 경우 반환 유형이 코드를 확장하기 쉽고 의도한 것을 반환하도록 하는 유용한 방법입니다.

7.   Announcing TypeScript 5.1 Beta - TypeScript

https://devblogs.microsoft.com/typescript/announcing-typescript-5-1-beta/

타입스크립트 5.1 베타에서는 반환문이 없는 함수도 undefined를 반환할 수 있도록 허용하는 등 새로운 기능과 최적화가 소개됩니다.
JSX 요소와 태그 유형 간의 타입 체크를 분리하고 불필요한 타입 인스턴스화를 방지하는 등의 변화가 있습니다. 그러나 typeRoots가 명시적으로 지정될 때 node_modules/@types에 대한 상위 경로 탐색이 비활성화되며, get 및 set 접근자 속성의 관련 없는 타입에 대해서는 명시적인 타입 어노테이션이 필요합니다.
TypeScript의 최소 런타임 요구 사항은 ECMAScript 2020 및 Node.js 14.17로 업데이트되었습니다. TypeScript 블로그에서 자세한 정보를 확인할 수 있습니다.

8. Junior to senior: An action plan for engineering career success

https://github.com/readme/guides/engineering-career-success

문서는 주니어 엔지니어에서 시니어 엔지니어로 전환하려는 소프트웨어 엔지니어들을 위한 포괄적인 가이드를 제공합니다. 기술 역량, 커뮤니케이션 스킬, 비즈니스 도메인 이해 및 계속적인 학습과 같은 경력 성장에 필수적인 여러 가지 분야에 대한 통찰력을 제공합니다.

Microsoft의 시니어 소프트웨어 엔지니어이자 Vets Who Code의 이사인 Jerome Hardaway는 광범위한 경험을 바탕으로 경력을 끌어올리고자 하는 엔지니어들에게 유용한 조언을 제공합니다. 이 가이드는 프로그래밍, 데이터 구조, 알고리즘 및 소프트웨어 개발 관행의 기본을 숙달하는 것의 중요성과 테스트, 성능 최적화 및 확장성에 대한 최고의 실천 방법을 따르는 깨끗하고 유지보수 가능한 코드 작성에 집중하는 것을 강조합니다.

또한 이 가이드는 비즈니스 도메인을 이해하고 문제를 맥락화하며 진로 목표와 일치하는 과제를 식별하도록 하는 중요성을 강조합니다. 그리고 리더십 능력을 증명하고 교차 기능 팀과 협업하며 프로젝트를 관리하고 비기술 이해 관계자에게 기술적인 해결책을 전달하는 것의 중요성도 강조합니다.

저자는 또한 점진적인 개선 기회를 식별하고 사용자 스토리를 만들며 코드 검토에서 협력하며 기술적인 도전에 대처하기 위해 다른 팀과 연합하고 필요한 경우 일을 떠맡는 등 비즈니스 도메인 이해와 리더십 잠재력을 증명하는 몇 가지 방법을 제안합니다.

또한 이 가이드는 당신의 전문성을 증명하고 성취를 쇼케이스하는 "자랑 문서"를 작성하는 것도 추천합니다. 이 문서에는 완료된 프로젝트, 기술 스킬, 전문 개발, 성과 및 이정표, 피드백 및 인정, 그리고 오픈 소스 기여 등이 포함되어야 합니다.

마지막으로, 이 가이드는 계속해서 업계에 대해 최신 정보를 알아가며 기술을 개발하고 학습하는 것의 중요성을 강조합니다. 업계 이벤트에 참여하고 기술 커뮤니티에 참여하며 동료 전문가들과 연결하는 것도 중요하다는 것을 강조하며, 주니어 엔지니어에서 시니어 엔지니어로 진행하는 데 필요한 작업을 인내심 있게, 끈기 있게 수행하는 것의 중요성도 강조합니다.

9. Rich Harris: Hot takes on the web

개발자는 성능 지표보다 사용자 요구를 우선으로 놓고, JavaScript 프레임워크가 모든 웹 문제의 근본이 아니라는 사실을 인식해야 합니다. 동시에 새로운 기술과 도구를 신중하게 받아들이면서 잠재적인 단점을 고려해야 합니다.

10. Say no to "flickering" UI: useLayoutEffect, painting and browsers story

https://www.developerway.com/posts/no-more-flickering-ui

이 문서는 useEffect 대신 useLayoutEffect를 사용하여 React에서 "깜빡임" UI를 방지하는 방법에 대해 포괄적으로 설명합니다. 브라우저에서 렌더링과 페인팅의 차이와 현대 브라우저가 60FPS를 유지하려고 하는 방법에 대해 논하며, React가 렌더링 작업을 작은 청크로 분할하여 렌더링 또는 페인팅 코드가 차단되지 않도록하는 방법도 설명합니다.

이 문서는 SSR 문제가 useLayoutEffect 사용에 영향을 미치는 방식에 대해서도 다룹니다. React 구성 요소를 초기에 렌더링할 때, 브라우저에 도달하기 전에 모든 라이프사이클 이벤트가 서버에서 실행됩니다. 이 단계에서 useLayoutEffect를 사용하면 아직 요소가 크기를 가지지 않으므로 작동하지 않습니다. 결과적으로, 이 문서는 "shouldRender" 상태 변수를 도입하고 useEffect에서 "true"로 뒤집는 것과 같은 이 문제를 처리하는 가능한 솔루션을 제공합니다.

전반적으로, 이 문서는 React에서 useLayoutEffect를 사용하여 UI 깜빡임을 방지하고 useLayoutEffect를 사용할 때 SSR 문제를 처리하는 기술적 세부 정보를 제공합니다. 이 개념을 이해하고 React 애플리케이션의 성능을 향상시키고자하는 개발자들에게 유용한 자료입니다.

이번주 준비한 것은 여기까지입니다 😄

읽어주셔서 감사합니다 😉