[번역] 포맷팅 규칙이 ESLint에서 사라집니다

• 개인적으로 희소식
• eslint 없이 진행하는 프로젝트는 없다
• prettier 없이 진행하는 경우도 없다
• RN 기본 프로젝트를 보면 prettierrc 에서 설정하고 있는데
• 내가 eslint를 추가하면서 eslint vs prettier 전쟁이 시작된다
  • 서로 자신의 룰이 맞다고 강하게 주장하며
  • auto fix > auto fix > auto fix…
  • 항상 나는 수정해야한다
• 이러한 고민이 eslint 팀에게 항상 예외가 요구되었으리라 생각된다
• 오히려 깔끔하게 prettier의 역할을 제외하므로써 이 고민은 해결되지 않을까 싶은데
• 그렇다면 어디까지가 lint 가 수정할 수 있는 룰이라고 볼 수 있을까?
  • eslint, prettier 모두 코드를 깔끔하게 만들어서 유지하고자함인데 🤔

[번역] 당신의 Jest 테스트는 잘못되어 있을 수도 있습니다

• jest 테스트 케이스마다 mock 설정을 주입/정리해주던 before/after* 대신 설정을 통해 각각의 테스트 케이스 컨텍스트를 독립시킬 수 있다
  • jest.clearAllMocks()를 beforeEach() 함수에 추가하면 동일한 결과를 얻을 수 있습니다. 하지만 이는 모든 테스트를 안전하게 만들기 위해 각 테스트 파일에 이를 추가해야 하는 번거로움을 야기합니다. 대신 clearMocks를 사용하여 기본적으로 모든 테스트를 안전하게 만드는 것이 좋은 아이디어입니다.
• resetMocks 을 왜 clearMocks 와 같이 사용해야하는걸까?
  • 하나의 테스트 케이스에서 설정된 mock은 전역으로 반영된다
  • 이 전역 mock을 초기화 하기 위해 resetMocks 를 설정하면 되는데
  • 값이 reset 되어 초기값으로 돌아가는 것일뿐 clear 되지는 않는다? 🤔
    • mock 인스턴스는 그대로 살아있는다 (값만 reset 되었을뿐)
  • 이 글을 참고 하니 이해가 좀 더 쉬웠다
    • reset ⇒ clear ⇒ restore
• 모든 것을 초기화하세요
  • resetMocks, clearMocks, restoreMocks 들을 설정하여 mock을 각각 테스트 케이스에서 초기화하여 독립된 환경으로 동작하도록 하는 것
• 테스트 관해서 이렇게 쓰는게 맞을까? 고민하다가
  • [좋은 소프트웨어를 만드는 데 도움이 되는 테스트를 작성하는 한 오답은 없습니다.](https://medium.com/@yujso66/번역-자바스크립트에서-테스트-어설션-스타일-314aea22faa8)
  • 도움이 되는가? 를 고민해보는 것으로

[번역] 왜 타입스크립트는 Object.keys의 타입을 적절하게 추론하지 못할까요?

• Object.keys 를 추론해주지 못한 이유
  • 키로 접근하기 위해 타입을 캐스팅하면 해결되지만
  • 타입스크립트가 갖고 있는 구조로 인한 것 😯
• 구조적 타입 시스템
  • 타입스크립트는 추가 프로퍼티가 포함되어 있어도 에러를 표시하지 않는다
  • 정의된 타입을 슈퍼셋으로 고려하기 때문
  • 이 말은 곧 Object.keys로 가져온 키값에는 정의되지 않은 프로퍼티가 들어가있을 수 있다는 것
• 이를 해결하기 위해 제시된 방법은…
  • 접근하려는 인터페이스 슈퍼셋을 정의하고 키값을 컨버팅하여 보장하는
  • 조금 마음에 들지는 않지만
  • 제네릭 타입에 접근하는 것을 생각하면 이해가 되기도 🥺

(번역) 타입스크립트에 대해 아무도 설명해주지 않은 것 한 가지

• tsconfig.json
• 타입스크립트가 컴파일 되는 환경을 독립시키기 위한 설정 파일
  • 각각의 환경에서 타입스크립트가 찾게될 타입을 생각하면
  • 분리되기를 원하는 디렉토리마다 설정파일을 두는 것이 타입스크립트에게는 좋다

[번역] 새로운 리액트 문서에서 제시하는 9가지 권장 사항

• 리액트 문서가 새로 변경되면서 전보다 많은 것을 가이드 하고 있다는 좋은 소식
• 상태에 무엇을 저장할지 결정할 때는 필요한 것을 계산하는 데 사용할 수 있는 최소한의 정보를 저장하세요
  • 하나의 상태 변경에 따라 반응하는 여러 상태가 있다면 업데이트가 누락될 가능성이 있기 때문에
  • 최소한의 상태만을 유지하도록
• 프로퍼티 변경에 따라 상태를 조정해야 하는 경우 effect가 아닌 컴포넌트 함수에(렌더링 중에) 직접 상태를 설정하세요
  • 🚨 가장 놀라웠던 것
  • useEffect 안에서 처리하도록 했는데
  • 최근에 useAnimatedRef를 보면서 느꼈던 궁금증
  • 모든 렌더타임에 항상 조건을 비교하고 ref, state를 업데이트 하고 있었다
  • 잠시 다시 생각해보면 항상 비교하더라도 상태 업데이트는 되지 않을테니 문제가 없으려나?
  • 다른 상태 업데이트로 인해 다시 조건문을 통과해 상태가 덮어씌워지는 경우가 있다면 예외적으로 useEffect을 써야겠다

리액트로 인해 잊었거나 전혀 몰랐던 것들

*익숙한 것 너머에 더 좋은 것이 있을 수 있다

자신도 모르게 더 좋은 것을 놓치고 있을지도 모른다 익숙한 경계를 넘어 더 나은 것을 찾는다 현재 만족감은, 최소한 어느 정도는 단순히 무엇을 놓치고 있는지 모르기 때문에*

• 리액트를 기본적으로 사용하는 대부분 사람은 이 프레임워크가 얼마나 낙후되어 있는지 잘 인식하지 못한다고 생각합니다
  • 안락함에 빠져버리는 것
  • 개발자 경험(DX)이 사용자 경험(UX)을 대체해서는 안 됩니다
    • DX가 주는 안락함으로 인해 UX를 포기하면 안된다
    • 리액트가 어떤 UX를 포기하게 되었을까?
    • 지금 예측할 수 있는 것은 아마 퍼포먼스? 이지 않을까
    • 또 무엇이 있을까?
• 최신 프런트엔드가 빠르게 발전하는 만큼, 리액트를 왕좌에 올려놓았던 세상이 여러 면에서 더 이상 존재하지 않는다는 사실을 깨닫는 데는 매우 느린 것 같습니다.
  • 리액트가 나온 10여년전과 다른 세상이 되었기 때문에
  • 다른 프레임워크가 나오면 얼마나 커뮤니티가 큰가? 를 확인하게 되는데
  • 단지 자바스크립트라면 실제로 자바스크립트인 모든 것에서 그냥 작동해야 합니다.
  • 리액트 환경에서만 동작하는 것이 아닌
• 중간에 시그널에 대한 내용이 나오는데
  • 전체 컴포넌트가 아니라 다시 렌더링할 필요가 있는 노드만 다시 렌더링하도록 기본값을 개선한 업데이트된 훅이라고 생각하시면 됩니다.
  • 지난번에 시그널을 쓰고자 했던 목적에 딱 적합한 설명이다
  • 내가 리렌더를 필요로한 위치까지 아무런 영향없이 지나가다가 필요한 지점에만 영향력을 주는 것