[번역] 왜 타입스크립트는 당신을 구해주지 못하는가

• 실제 안전을 보장해 주지는 않습니다.
  • 그냥 약속일뿐
  • 타입이 정의되어있을뿐
  • 정말, 실제로 그 타입 그대로 존재할 것이라고 보장할 수 없기 때문이다
• 하지만 실제 API 응답은 그 어떤 형태로든 반환할 수 있고
  • 타입스크립트는 이걸 알 수 없다는 사실
  • 실제로 그 타입 그대로 왔는지 검증해야하는데
  • 이를 타입스크립트가 런타임에 해주는 것이 아니기 때문에 검증 작업은 직접 수동으로 작성해야한다
• 약속 그대로 지켜진다면 정말 좋기만한 상황
  • 타입이 있기 때문에 검증을 하지 않아도 될것이라는 막연한 믿음

(번역) 지시문(directives)과 플랫폼의 경계

• use client, use strict
  • 이러한 것들은 표준화된 자바스크립트 기능이 아니기에 런타임이 이해하지 못한다
  • 그럼에도 코드의 일부라고 생각하기 이르렀다
  • 그냥 각각 자신만의 읽기 좋은 무언가를 만들어냈을뿐
• 단순하게 시작되었다
  • 이것은 클라이언트이며 이것은 서버이다
  • 지시문으로써 시작되었지만 이제 점점 살이 붙어 다양한 형태가 되었다
  • use cache:remote, cache(...)
  • 이런저런 옵션까지 가지다보니 점점 자신만이 해석할 수 있는 형태가 되었다
• 주체를 알 수 없다
  • import 하지 않았으니 어떤 특정 API 라고 알 수 없다
  • 누가 어느 시점에 읽히기를 원하는 것인지 알 수 없다
• 지시문을 통해 무엇을 하고 싶은걸까
  • 어떠한 동작을 실행하고자 함이였다면
  • 특정 함수를 import하여 실행하도록 하는 방법이 있었을텐데
• 명세화 되어야한다
  • ecma
  • 모두가 알 수 있도록

[번역] 상태 기반 렌더링 vs 시그널 기반 렌더링

• 계속 시그널을 사용하면 좋겠다는 시그널을 보내는 중 🥺

  • 상태 업데이트에 의한 리렌더링을 막는 방법으로 메모이제이션을 열심히 했다

  • 그럼에도 리렌더링은 일어난다

  • 컨텍스트로 감싸져있기 때문이다

  • 그럼 리렌더링 자체가 안되게 하겠다는 일념으로

  • 해당 상태에 접근하는 구역에서만 상태를 구독하는 방식으로 변경한다

  • 시그널 기반 과 유사한 기능을 하고 있다

  • 그럼에도 시그널을 원하는 이유는 상태에 접근할때에 리렌더링 된다는 점

  • 지금 나의 상태는 접근할때라고 볼 수 없다

  • 구독 선언되어있는 컴포넌트 전체는 리렌더링 된다

    const Parent = () => {
    	// 리렌더가 되지 않음
      return (
        <>
          <ChildA />
          <ChildB />
          <ChildC />
        </>
      );
    };
    
    const ChildC = () => {
      const count = useQuerySelector('count');
      // count가 변하면 리렌더링 된다
      return (
        <>
          <Text>abcd</Text>
          <Text>{count}</Text>
        </>
      );
    };
    

  • 하지만 시그널은 선언한 컴포넌트가 아닌 이 상태 값을 읽는 위치에서야 리렌더링 된다

    const Parent = () => {
      const count = useSignal(0);
      return (
        <>
          {/* 리렌더가 되지 않음 */}
          <ChildA />
          <ChildB />
          {/* count 값을 읽는 경우에만 리렌더 됨 */}
          <ChildC count={count} />
        </>
      );
    };
    

  • 리렌더링 되는 부분은 ChildC로 동일하나

  • 구독 형태는 위치가 잘못된 경우에 컨텍스트와 같은 문제가 발생할 수 있지만 시그널은 애초에 발생하지 않는다

• 발상의 전환
  • 이제 우리는 리렌더링을 메모이제이션으로 ‘막는’ 것이 아니라, 필요한 곳에서만 ‘발생시키는’ 방식으로 사고해야 합니다.

연봉 값을 하는 엔지니어의 비밀: "모르는 것(Ambiguity)"을 "할 수 있는 것"으로 바꾸는 기술

• 모호함을 줄이는 능력
• "성능 개선 필요", "사용자 불만 증가", "확장성 고려"와 같이 불분명하고 추상적인 요구사항을 받았을 때
• 모호한 문제를 단순히 수행하는 것이 아니라, 이를 분석하고 해체하여 구체적인 과제로 변환
• 이 과정은 프로젝트의 리스크를 낮추고(De-risking), "무엇인지 모르는 상태"를 "실행 가능한 작은 프로젝트와 제거할 요소"로 정리함
• 사용자 정의: 구체적으로 누구의 어떤 고통을 해결하려 하는가? ("사용자"라는 포괄적 단어 지양)