원문 : 2021.01.18에 작성된 Tao of React - Software Design, Architecture & Best Practices

저는 React를 2016년부터 사용했지만 여전히 어플리케이션 구조와 디자인에 대한 모범적인 예시는 한 건도 없습니다. 마이크로 수준에 대한 모범 사례는 있지만 대부분의 팀들은 각자 자신만의 아키텍쳐를 구축합니다. 물론, 모든 비즈니스와 어플리케이션에 적용될 수 있는 최고의 예시는 없습니다. 그러나 생산적인 코드베이스를 만들기 위해 따라야 하는 일반적인 규칙들은 존재합니다.

소프트웨어 아키텍쳐와 디자인의 목적은 소프트웨어를 생산적이고 유연하게 유지하는 것에 있습니다. 개발자들은 소프트웨어의 핵심부분을 재작성하지 않고 효과적으로 작업하고 수정해야만 합니다. 이 글은 저와 제가 함께 일했던 팀에서 꽤 효과적이라고 증명되었던 원리와 규칙들의 모음집입니다.

컴포넌트, 어플리케이션 구조, 테스팅, 스타일링, 상태 관리와 데이터 fetching 등에 대한 사례들을 개략적으로 설명합니다. 예제의 일부는 구현보다는 원칙에 집중하고자 지나치게 단순화되어 있으니 참고하세요.

이 글의 모든 것을 절대적인 것이 아닌 하나의 의견으로서 받아들이길 바랍니다. 소프트웨어를 만드는 데에는 여러 방법이 존재합니다.

• 컴포넌트
• 상태관리
• 컴포넌트 심상 모델
• 어플리케이션 구조
• 성능
• 테스팅
• 스타일링
• 데이터 fetching

컴포넌트 (Components)

함수형 컴포넌트를 지향하라 (Favor Functional Components)

함수형 컴포넌트를 지향하라 - 간단한 표현입니다. 라이프사이클 메소드, 생성자, 보일러플레이트도 없습니다. 클래스 컴포넌트를 사용할 때보다 가독성을 잃지 않으면서 적은 표현으로 같은 로직을 표현할 수 있습니다. error boundary가 필요한 것이 아니라면 이 방식을 따라야만 합니다. 여러분의 머릿 속에 간직해야 할 정신적인 모델이 훨씬 작아질 것입니다.

// 👎 클래스 컴포넌트는 장황합니다
class Counter extends React.Component {
  state = {
    counter: 0,
  }

  constructor(props) {
    super(props)
    this.handleClick = this.handleClick.bind(this)
  }

  handleClick() {
    this.setState({ counter: this.state.counter + 1 })
  }

  render() {
    return (
      <div>
        <p>counter: {this.state.counter}</p>
        <button onClick={this.handleClick}>Increment</button>
      </div>
    )
  }
}

// 👍 함수형 컴포넌트가 읽기도 쉽고 유지하기도 좋죠
function Counter() {
  const [counter, setCounter] = useState(0)

  handleClick = () => setCounter(counter + 1)

  return (
    <div>
      <p>counter: {counter}</p>
      <button onClick={handleClick}>Increment</button>
    </div>
  )
}

일관된 컴포넌트를 작성하라 (Write Consistent Components)

여러분의 컴포넌트의 스타일을 일관되게 유지하세요. 같은 위치에 헬퍼 함수를 두고, 같은 방식으로 export하고 동일한 네이밍 패턴을 따르세요.
어떤 접근 방식이 다른 방식보다 나은 점은 없습니다. 파일 아래에서 export하든지, 컴포넌트 정의에서 바로 하든지 상관없습니다.
하나를 골라 그 방식을 고수하세요.

컴포넌트의 이름을 지어라 (Name Components)

여러분의 컴포넌트에 항상 이름을 지어주세요. 이는 나중에 여러분이 에러 스택을 추적하거나 React Dev tools를 사용할 때 도움이 됩니다.
또한 파일 내에 컴포넌트 이름이 있다면 여러분이 개발할 때 컴포넌트를 찾기가 더 쉽습니다.

헬퍼 함수를 구성하라 (Organize Helper Functions)

컴포넌트에 대해 클로져를 가질 필요 없는 헬퍼 함수는 바깥으로 옮겨야 합니다. 이상적인 위치는 컴포넌트가 정의된 곳보다 먼저 나오는 것이 좋습니다. 그래야 위에서부터 아래로 파일을 읽기가 좋기 때문입니다. 이 룰은 컴포넌트를 깨끗하게 해주며 컴포넌트 내에서 필요한 것만 남겨둡니다.

// 👎 클로져를 유지할 필요 없는 복잡한 함수를 피하세요.
function Component({ date }) {
  function parseDate(rawDate) {
    ...
  }

  return <div>Date is {parseDate(date)}</div>
}

// 👍 헬퍼함수는 컴포넌트 위에 두세요
function parseDate(date) {
  ...
}

function Component({ date }) {
  return <div>Date is {parseDate(date)}</div>
}

여러분은 정의한 함수 내에 적은 양의 헬퍼함수를 유지하고 싶을 수 있습니다. 가능한 한 헬퍼 함수는 밖으로 옮겨두고 인자로 상태값을 전달하세요.
로직을 입력값에 의존하는 순수함수로 구성하는 것이 버그를 찾기가 용이하며 확장성이 좋습니다.

// 👎 헬퍼 함수가 컴포넌트의 상태에서 읽히면 안 됩니다.
export default function Component() {
  const [value, setValue] = useState('')

  function isValid() {
    // ...
  }

  return (
    <>
      <input
        value={value}
        onChange={e => setValue(e.target.value)}
        onBlur={validateInput}
      />
      <button
        onClick={() => {
          if (isValid) {
            // ...
          }
        }}
      >
        Submit
      </button>
    </>
  )
}

// 👍 헬퍼함수는 밖으로 빼서 필요한 값만 전달하세요.
function isValid(value) {
  // ...
}

export default function Component() {
  const [value, setValue] = useState('')

  return (
    <>
      <input
        value={value}
        onChange={e => setValue(e.target.value)}
        onBlur={validateInput}
      />
      <button
        onClick={() => {
          if (isValid(value)) {
            // ...
          }
        }}
      >
        Submit
      </button>
    </>
  )
}

마크업을 하드코딩하지 마라 (Don't Hardcode Markup)

네비게이션, 필터, 목록에 대한 마크업을 하드코딩하지 마세요. 대신 객체 배열을 사용하여 아이템을 순회하세요.
즉, 한 곳에서만 마크업과 아이템을 변경하면 됩니다.

// 👎 하드코딩된 마크업은 관리하기가 어렵습니다.
function Filters({ onFilterClick }) {
  return (
    <>
      <p>Book Genres</p>
      <ul>
        <li>
          <div onClick={() => onFilterClick('fiction')}>Fiction</div>
        </li>
        <li>
          <div onClick={() => onFilterClick('classics')}>
            Classics
          </div>
        </li>
        <li>
          <div onClick={() => onFilterClick('fantasy')}>Fantasy</div>
        </li>
        <li>
          <div onClick={() => onFilterClick('romance')}>Romance</div>
        </li>
      </ul>
    </>
  )
}

// 👍 loop와 객체 배열을 사용하세요
const GENRES = [
  {
    identifier: 'fiction',
    name: Fiction,
  },
  {
    identifier: 'classics',
    name: Classics,
  },
  {
    identifier: 'fantasy',
    name: Fantasy,
  },
  {
    identifier: 'romance',
    name: Romance,
  },
]

function Filters({ onFilterClick }) {
  return (
    <>
      <p>Book Genres</p>
      <ul>
        {GENRES.map(genre => (
          <li>
            <div onClick={() => onFilterClick(genre.identifier)}>
              {genre.name}
            </div>
          </li>
        ))}
      </ul>
    </>
  )
}

컴포넌트 길이 (Component Length)

리액트 컴포넌트는 props를 받고 마크업을 리턴하는 함수일 뿐입니다. 컴포넌트도 동일한 소프트웨어 설계 원칙을 준수합니다.
함수가 너무 많은 일을 한다면, 로직의 일부를 꺼내서 다른 함수를 호출하도록 하는 것처럼 컴포넌트도 마찬가지입니다.
너무 많은 기능을 하는 컴포넌트라면 작은 컴포넌트들로 쪼개서 호출하도록 하세요.

마크업의 어느 부분이 반복문을 사용하거나 조건문을 사용하여 복잡하다면 밖으로 빼두세요.
커뮤니케이션과 데이터를 위한 props와 callback에 의존하세요. 코드의 라인은 객관적인 척도가 아닙니다.
대신에 책임감과 추상성에 대해 생각해보세요.

JSX에서 주석을 사용하라 (Write Comments in JSX)

더 명확하게 해야 할 때 코드 블록을 열고 추가적인 정보를 제공하세요. 마크업은 로직의 일부이므로 명확하게 할 때 주석을 작성하세요.

function Component(props) {
  return (
    <>
      {/* If the user is subscribed we don't want to show them any ads */}
      {user.subscribed ? null : <SubscriptionPlans />}
    </>
  )
}

Error Boundary를 사용하라 (Use Error Boundaries)

한 컴포넌트에서 에러가 발생한다고 해서 전체 UI가 깨지면 안됩니다. 심각한 오류가 발생하여 페이지를 통째로 내리거나 리다이렉트하게 되는 경우는 드문 일입니다. 대부분의 경우 스크린에서 에러가 발생한 부분만 숨기는 것이 좋습니다.

데이터를 다루는 함수에서 여러 try/catch 문을 사용할 수도 있습니다. 최상위 레벨이 아니더라도 사용하고자 하는 곳에 Error boundary를 두세요.
별개로 존재할 수 있는 스크린의 element를 감싸면 이어지는 장애를 방지할 수 있습니다.

function Component() {
  return (
    <Layout>
      <ErrorBoundary>
        <CardWidget />
      </ErrorBoundary>

      <ErrorBoundary>
        <FiltersWidget />
      </ErrorBoundary>

      <div>
        <ErrorBoundary>
          <ProductList />
        </ErrorBoundary>
      </div>
    </Layout>
  )
}

props를 비구조화하라 (Destructure Props)

대부분의 리액트 컴포넌트는 함수일 뿐입니다. props를 받아 마크업을 리턴하죠. 일반 함수에서 인수를 사용하면 인수가 직접 전달되므로 리액트 컴포넌트에도 동일한 원리를 적용하면 됩니다. 어디서나 props를 반복할 필요가 없습니다.

props를 비구조화하지 않는 이유는 아마 외부에서 온 것과 내부 상태를 구분짓기 위함일 것입니다. 그러나 일반 함수에서 인자와 변수의 구분이 따로 있지 않습니다. 불필요한 패턴을 만들지 마세요.

// 👎 컴포넌트 어디에서든지 props를 반복하지 마세요
function Input(props) {
  return <input value={props.value} onChange={props.onChange} />
}

// 👍 props를 비구조화하여 바로 사용하세요
function Component({ value, onChange }) {
  const [state, setState] = useState('')

  return <div>...</div>
}

props의 수 (Number of Props)

컴포넌트가 받는 props의 개수가 몇개여야 하는지에 대한 질문은 주관적입니다. 컴포넌트가 가지는 props의 수는 컴포넌트가 하는 것과 상관 있습니다. 더 많이 props를 전달할 수록 컴포넌트의 책임도 함께 커집니다. props가 너무 많다면 이는 컴포넌트가 너무 많은 일을 한다는 신호입니다.

저는 5개 이상의 props를 받는다면 컴포넌트를 나누어야 할지를 생각해 봅니다. 일부의 경우에서 많은 데이터가 필요할 수도 있습니다.
예를 들어 input 필드는 많은 props를 받아야 합니다. 다른 경우에서는 나누어야 한다는 신호가 되기도 합니다.

주의 : 컴포넌트가 가지는 props가 많을 수록 리렌더링되어야 할 이유도 많아집니다!

원시값 대신 객체를 전달하라 (Pass Objects Instead of Primitives)

props의 양을 줄이는 방법 중 하나는 원시값 대신에 객체를 전달하는 것입니다. 이름, 이메일, 설정 등을 바로 전달하는 것 대신에 묶어서 객체로 전달할 수 있죠. 이는 사용자가 추가적인 값을 전달할 때 변경해야 하는 부분을 줄여줍니다.

타입스크립트를 사용하면 이를 더 쉽게 해줍니다.

// 👎 관련된 값이라면 하나씩 전달하지 마세요
<UserProfile
  bio={user.bio}
  name={user.name}
  email={user.email}
  subscription={user.subscription}
/>

// 👍 대신에 객체로 묶어 보내세요
<UserProfile user={user} />

조건부 렌더링 (Conditional Rendering)

일부 상황에서 조건부 렌더링을 위해 단락 연산자(&&)를 사용하는 것은 역효과를 낳을 수 있으며 여러분의 UI에 원치않는 0이 보일 수 있습니다. 이런 상황을 피하기 위해 삼항 연산자를 사용하세요. 다만 좀 더 장황해질 수 있습니다.
단락 연산자는 코드의 양을 줄여주고 이는 아주 좋습니다. 삼항 연산자는 더 복잡하지만 잘못될 여지는 없습니다. 게다가 다른 조건을 추가하게 되더라도 변경사항이 적습니다.

// 👎 단락 연산자를 사용하는 것을 지양하세요
function Component() {
  const count = 0

  return <div>{count && <h1>Messages: {count}</h1>}</div>
}

// 👍 대신 삼항 연산자를 사용하세요
function Component() {
  const count = 0

  return <div>{count ? <h1>Messages: {count}</h1> : null}</div>
}

중첩된 삼항 연산자를 지양하라 (Avoid Nested Ternary Operators)

삼항 연산자는 한 단계를 지나가게 되면 읽기 어려워집니다. 공간을 절약하는 것처럼 보이더라도 여러분의 의도를 분명히 하는 것이 좋습니다.

// 👎 JSX에서 중첩된 삼항 연산자는 읽기 어렵습니다.
isSubscribed ? (
  <ArticleRecommendations />
) : isRegistered ? (
  <SubscribeCallToAction />
) : (
  <RegisterCallToAction />
)

// 👍 컴포넌트 내에 두세요
function CallToActionWidget({ subscribed, registered }) {
  if (subscribed) {
    return <ArticleRecommendations />
  }

  if (registered) {
    return <SubscribeCallToAction />
  }

  return <RegisterCallToAction />
}

function Component() {
  return (
    <CallToActionWidget
      subscribed={subscribed}
      registered={registered}
    />
  )
}

배열은 별개의 컴포넌트로 옮겨라 (Move Lists in a Separate Component)

map 함수를 사용하려 아이템의 배열을 순회하는 것은 흔히 사용하는 방법입니다. 그러나 여러 마크업을 가진 컴포넌트 내에서 추가적인 여백이나 map 문법은 가독성을 해칩니다. map으로 순회해야 한다면 마크업이 많지 않더라도 그 부분을 따로 빼서 컴포넌트로 분리하세요. 부모 컴포넌트는 자세한 부분을 알 필요없이 배열을 나타내기만 하면 됩니다.

컴포넌트의 주 역할이 보여주기라면 마크업에 루프를 두기만 하세요. 컴포넌트마다 하나의 매핑을 두도록 하세요. 마크업이 너무 길어지거나 복잡해진다면 따로 빼두는 것이 좋습니다.

// 👎 반복문과 다른 마크업을 같이 두지 마세요.
function Component({ topic, page, articles, onNextPage }) {
  return (
    <div>
      <h1>{topic}</h1>
      {articles.map(article => (
        <div>
          <h3>{article.title}</h3>
          <p>{article.teaser}</p>
          <img src={article.image} />
        </div>
      ))}
      <div>You are on page {page}</div>
      <button onClick={onNextPage}>Next</button>
    </div>
  )
}

// 👍 배열에 대한 컴포넌트를 따로 빼세요
function Component({ topic, page, articles, onNextPage }) {
  return (
    <div>
      <h1>{topic}</h1>
      <ArticlesList articles={articles} />
      <div>You are on page {page}</div>
      <button onClick={onNextPage}>Next</button>
    </div>
  )
}

비구조화를 할 때 기본 props를 할당하라 (Assign Default Props When Destructuring)

기본 prop 값을 설정하는 방법은 컴포넌트에 defaultProps를 두는 것입니다. 이는 컴포넌트 함수와 인자 값이 함께 있지 않다는 것을 의미하기도 합니다. props를 비구조화할 때 기본값을 바로 할당하는 것을 지향하세요. 이는 코드를 위에서부터 읽기 편하게 하며 정의와 값을 함께 둡니다.

// 👎 default props를 함수 밖에 정의하지 마세요
function Component({ title, tags, subscribed }) {
  return <div>...</div>
}

Component.defaultProps = {
  title: '',
  tags: [],
  subscribed: false,
}

// 👍 인자 목록에 함께 두세요
function Component({ title = '', tags = [], subscribed = false }) {
  return <div>...</div>
}

중첩된 렌더 함수를 지양하라 (Avoid Nested Render Functions)

컴포넌트나 로직으로부터 마크업을 분리하고 싶을 때 같은 컴포넌트 내에 마크업 함수를 두지 마세요. 컴포넌트는 함수일 뿐입니다.
이렇게 함수를 정의하게 되면 부모 함수 내에서 둥지를 트는 셈입니다. 이는 부모의 상태나 데이터를 모두 접근할 수 있다는 것을 의미하는데요.
컴포넌트 내에서 함수가 하는 일이 없음에도 내부에 있다면 코드의 가독성을 해치게 됩니다.

마크업 컴포넌트로 옮기고 이름을 짓고 클로져 대신에 props로 전달하세요.

// 👎 중첩되도록 렌더함수를 만들지 마세요
function Component() {
  function renderHeader() {
    return <header>...</header>
  }
  return <div>{renderHeader()}</div>
}

// 👍 각 컴포넌트로 분리하세요
import Header from '@modules/common/components/Header'

function Component() {
  return (
    <div>
      <Header />
    </div>
  )
}

원문 : https://www.zhenghao.io/posts/ts-never

타입스크립트의 never는 다른 타입들만큼 아주 흔하거나 무시할 수 없는 타입이 아니기 때문에 그다지 활발하게 논의되는 타입이 아닙니다. 심화된 타입을 다루거나 까다로운 타입 에러 메시지를 읽을 때나 등장하기 때문에 초급자들은 아마 never 타입을 무시하고도 타입스크립트를 쓸 수 있습니다.

never 타입은 타입스크립트에서 꽤 좋은 유즈 케이스를 가지고 있습니다. 그러나, 그만큼 여러분들이 조심해야 하는 위험들도 갖고 있습니다.
이 글에서는 다음 내용을 다룹니다.

• never 타입의 의미와 필요성
• never 타입의 응용과 위험
• 여러 말장난들 🤣

never 타입이 무엇일까?

never 타입과 이것의 목적을 완벽하게 이해하기 위해서는, 타입이란 무엇인지 그리고 타입 시스템에서 타입이 어떤 역할을 하는지 먼저 이해해야 합니다.
타입은 가능한 값들의 집합과 같습니다. 예를 들어 string 타입은 가능한 문자열의 무한집합을 나타냅니다. 우리가 변수에 string 타입이라고 붙여줄 때, 그 변수는 문자열 집합 내에서만 값을 가질 수 있게 됩니다.

let foo: string = 'foo'
foo = 3 // ❌ 숫자는 문자열 집합에 속하지 않습니다.

타입스크립트에서 never는 값들의 공집합을 의미합니다. 실제로 또다른 유명한 자바스크립트 타입 시스템인 Flow에서도 never와 동일한 타입을 empty라고 부른답니다.

집합에 값이 없기 때문에 never는 any 타입을 포함하여 절대로(never ㅋ) 어떠한 값도 가질 수 없습니다. never가 때때로 거주 불가능한 타입(uninhabitable type) 또는 바닥 타입(bottom type)이라고 불리는 이유입니다.

declare const any: any
const never: never = any // ❌ 'any' 타입은 'never'에 할당할 수 없습니다.

바닥 타입은 TypeScript Handbook에서 정의한 단어입니다. 저는 서브타이핑을 이해하는 데 사용하는 타입 계층 트리에서 never를 두지 않는 게 더 이해하기 쉽다고 생각했습니다.

다음 논리적인 질문은, '왜 never 타입이 필요한가?' 입니다.

왜 우리는 never 타입이 필요할까?

숫자 시스템에서 아무것도 가지지 않았다는 것을 나타내기 위해 우리가 0을 사용하는 것처럼, 타입 시스템도 불가능함을 나타내는 타입이 필요합니다. "불가능함"이란 단어 자체가 모호합니다. 타입스크립트에서 "불가능함"은 다양한 방식으로 나타납니다.

• 다음을 나타내기 위해 사용될 수 있는, 어떠한 값도 가지지 않는 빈 타입
  • 제네릭과 함수에서 허용되지 않는 파라미터
  • 서로 배타적인 타입들의 교칩합
  • 비어있는 합집함 (없음의 합집합)
• 실행이 완료되었을 때 호출자(caller)에게 제어를 아무것도(never) 반환하지 않는 함수의 리턴 타입 (Node에서 process.exit처럼)
  • void와 혼동하지 마세요. void는 호출자에게 유용한 무언가를 리턴하지 않는다는 의미입니다.
• 조건문에서 절대(never) 들어갈 수 없는 else 분기
• reject된 promise의 fulfilled된 값의 타입

const p = Promise.reject('foo') // const p: Promise<never>

never 타입은 합집합(union)과 교집합(intersection)에서 어떻게 동작할까?

덧셈, 곱셈에서 0이 동작하는 방식과 유사하게, never 타입은 union 타입과 intersection 타입에서 사용되는 특별한 프로퍼티를 가집니다.

• never와 합집합을 하게 되면 never는 제외됩니다. 어떤 숫자에 0을 더했을 때 그 숫자가 그대로인 것과 같은 원리입니다.
  • 예시) type Res = never | string // string
• never와 intersection 하게 되면 다른 타입을 오버라이딩합니다. 어떤 숫자에 0을 곱하면 0이 되는 것처럼 말입니다.
  • 예시) type Res = never & string // never

never 타입이 가지는 두 가지 동작/특성은 나중에 보게 될 몇몇 가장 중요한 유즈 케이스의 기반을 마련해줍니다.

어떻게 never 타입을 사용할까?

아마 여러분들은 스스로 never를 많이 사용하진 않았겠지만, 이미 꽤 잘 사용되는 유즈 케이스들이 존재합니다.

허용되지 않는 함수 매개변수를 제한하기

어떤 값에 never 타입을 할당할 수 없기 때문에 우리는 다양한 응용을 위해 함수에 제한을 가하는 방식으로 never를 사용할 수 있습니다.

switch문과 if-else문에서 완전히 일치하는지 보장

어떤 함수가 오직 never 타입인 하나의 매개변수만 받는다면 그 함수는 never가 아닌 값과 함께 호출될 수 없습니다.

function fn(input: never) {}

// `never`만 허용
declare let myNever: never
fn(myNever) // ✅

// 다른 걸 전달하면 타입 에러 발생
fn() // ❌ 'input`에 대한 인자가 주어지지 않음.
fn(1) // ❌ number 타입은 never에 할당할 수 없음
fn('foo') // ❌ string 타입은 never에 할당할 수 없음

// 심지어 any도 불가능
declare let myAny: any
fn(myAny) // ❌ any 타입은 never에 할당할 수 없음

이러한 기능을 사용하여 switch문과 if-else문에서 완전히 일치하도록 보장할 수 있습니다. 남은 타입은 반드시 never 타입이므로 default 케이스로 never 타입을 사용하면 모든 경우가 커버될 수 있기 때문입니다. 실수로 일치하는 항목을 누락하면 타입 에러가 발생합니다.

function unknownColor(x: never): never {
    throw new Error("unknown color");
}


type Color = 'red' | 'green' | 'blue'

function getColorName(c: Color): string {
    switch(c) {
        case 'red':
            return 'is red';
        case 'green':
            return 'is green';
        default:
            return unknownColor(c); // Argument of type 'string' is not assignable to parameter of type 'never'
    }
}

구조적인 타이핑을 부분적으로 비허용

VariantA 또는 VariantB를 가지는 파라미터를 받는 함수가 있다고 가정해봅시다. 그러나 사용자가 두 유형의 모든 프로퍼티를 포함하는 타입을 전달해서는 안되는 경우입니다.

파라미터로 유니온 타입인 VariantA | VariantB을 사용할 수 있습니다. 그러나 타입스크립트에서 타입 호환성은 구조적인 서브타이핑을 기반으로 하고 있기 때문에 함수의 파라미터의 타입보다 더 많은 프로퍼티를 가지는 객체를 전달하는 것은 허용되지 않습니다. (객체 리터럴을 전달하지 않는 한)

type VariantA = {
    a: string,
}

type VariantB = {
    b: number,
}

declare function fn(arg: VariantA | VariantB): void

const input = {a: 'foo', b: 123 }
fn(input) // TypeScript가 안된다고 하진 않지만 우리는 이를 허용하지 않아야 합니다.

위의 코드 스니펫에서 타입스크립트는 타입 에러를 발생시키지 않습니다.
never를 사용함으로써 부분적으로 구조적 타이핑을 불가능하게 하고 사용자들이 두 프로퍼티를 다 가지는 객체를 전달하지 못하게 할 수 있습니다.

type VariantA = {
    a: string
    b?: never
}

type VariantB = {
    b: number
    a?: never
}

declare function fn(arg: VariantA | VariantB): void

const input = {a: 'foo', b: 123 }
fn(input) // ❌ Types of property 'a' are incompatible

의도되지 않은 API 사용 방지

데이터를 읽고 저장하는 Cache 인스턴스를 생성한다고 해봅시다.

type Read = {}
type Write = {}
declare const toWrite: Write

declare class MyCache<T, R> {
  put(val: T): boolean;
  get(): R;
}

const cache = new MyCache<Write, Read>()
cache.put(toWrite) // ✅ allowed

어떠한 이유든지 간에 get 메소드를 통해 데이터를 읽기만 가능한 read-only 캐시를 가지고 싶어질 수도 있습니다. put 메소드 인자에 never 타입을 추가하게 되면 함수 내부로 어떠한 값이든 받을 수 없게 됩니다.

declare class ReadOnlyCache<R> extends MyCache<never, R> {} 
                        // Now type parameter `T` inside MyCache becomes `never`

const readonlyCache = new ReadOnlyCache<Read>()
readonlyCache.put(data) // ❌ Argument of type 'Data' is not assignable to parameter of type 'never'.

부가적으로 never 타입과는 관련없지만, 이는 파생 클래스의 좋은 예시가 아닐 수 있습니다. 저는 객체 지향 프로그래밍의 전문가가 사실 아니기 때문에 각자 알아서 판단해주시길 바랍니다.

이론적으로 닿을 수 없는 조건 분기들을 나타내기

조건 타입 내에서 추가적인 타입 변수를 생성하기 위해 infer를 사용할 때 우리는 모든 infer 키워드에 반드시 else 분기를 추가해야 합니다.

type A = 'foo';
type B = A extends infer C ? (
    C extends 'foo' ? true : false// inside this expression, C represents A
) : never // 이 분기점에 닿을 수 없겠지만 생략할 순 없습니다

왜 extends infer 콤보가 유용한가요?
이전에 작성한 글에서 "로컬 (타입) 변수"를 선언하는 방식과 함께 extends infer를 언급했었습니다. 아직 읽지 않았다면 여기를 참고하세요.

유니온 타입에서 유니온 멤버 분리하기

불가능한 분기를 나타내는 것 외에도, never는 조건 타입에서 원치않는 타입을 분리해내는 데 사용할 수 있습니다.
이전에도 얘기했듯이, 유니온 멤버로써 never를 사용하면 자동적으로 제거된다고 했습니다. 즉, 유니온 타입에서 never는 쓸모가 없는 것이죠.

어떤 기준점을 기반으로 유니온 타입에서 유니온 멤버를 선택하는 유틸리티 타입을 작성할 때 never 타입의 쓸모없음은 else 분기에 완벽한 타입을 두게끔 만들어줍니다.

foo 문자열 리터럴을 가지는 name 프로퍼티를 추출하고, 그 외에는 필터링하는 유틸리티 타입인 ExtractTypeByName을 작성한다고 해볼까요.

type Foo = {
    name: 'foo'
    id: number
}

type Bar = {
    name: 'bar'
    id: number
}

type All = Foo | Bar

type ExtractTypeByName<T, G> = T extends {name: G} ? T : never

type ExtractedType = ExtractTypeByName<All, 'foo'> // the result type is Fo

실제로 어떻게 동작하는지 자세히 살펴봅시다.
다음은 타입스크립트가 결과 타입을 평가하고 가져오는 각 단계들입니다.

• 조건부 타입은 유니온 타입에 걸쳐 분산됩니다.

type ExtractedType = ExtractTypeByName<All, Name> 
⬇️                    
type ExtractedType = ExtractTypeByName<Foo | Bar, 'foo'>
⬇️    
type ExtractedType = ExtractTypeByName<Foo, 'foo'> | ExtractTypeByName<Bar, 'foo'>

• 구현을 대체하고 개별적으로 평가됩니다.

type ExtractedType = Foo extends {name: 'foo'} ? Foo : never 
                    | Bar extends {name: 'foo'} ? Bar : never
⬇️
type ExtractedType = Foo | never

• 유니온에서 never를 제거합니다.

type ExtractedType = Foo | never
⬇️
type ExtractedType = Foo

매핑된 타입에서 key를 필터링하기

타입스크립트에서 타입은 불변입니다. 객체 타입에서 어떤 프로퍼티를 제거하고자 한다면 이미 존재하는 타입을 변형하고 필터링하여 새로운 타입을 만들어야만 합니다. 매핑된 타입의 키를 조건부로 다시 never로 매핑할 때, key는 필터링됩니다.

객체의 값 타입에 따라 객체 타입 프로퍼티를 필터링하는 Filter 타입에 대한 예시입니다.

type Filter<Obj extends Object, ValueType> = {
    [Key in keyof Obj 
        as ValueType extends Obj[Key] ? Key : never]
        : Obj[Key]
}

interface Foo {
    name: string;
    id: number;
}

type Filtered = Filter<Foo, string>; // {name: string;}

제어 흐름 분석에서 타입 좁히기

함수의 리턴 값을 never라고 타입을 지정한다는 것은, 함수가 실행이 종료되었을 때 절대 호출자에게 제어권을 리턴해주지 않는다는 것을 의미합니다. 타입을 좁히기 위한 제어 흐름 분석에서 이 점을 응용할 수 있습니다.

함수는 다음과 같은 이유로 아무것도 리턴하지 않을 수 있습니다: 모든 코드 경로마다 예외를 throw하는 경우, 무한 루프에 빠지는 경우, process.exit과 같은 프로그램에 의해 종료되는 경우

다음 코드 스니펫에서, never 타입을 리턴함수를 사용하여 foor라는 union 타입에서 undefined를 제거할 수 있습니다.

function throwError(): never {
    throw new Error();
}

let foo: string | undefined;

if (!foo) {
    throwError();
}

foo; // string

또는 ||나 ?? 연산자 이후에 throwError를 호출할 수도 있습니다.

let foo: string | undefined;

const guaranteedFoo = foo ?? throwError(); // string

공존할 수 없는 타입들의 불가능한 교집합 나타내기

never의 응용 사례보다는 타입스크립트 언어의 동작/특징에 더 가깝다고 느껴질 수도 있습니다. 그럼에도, 이 점은 여러분이 마주칠 수도 있는 몇 가지 암호 에러 메시지를 이해하는 데 아주 중요합니다.

공존할 수 없는 타입들끼리 교집합 연산을 하면 never 타입을 얻을 수 있습니다.

type Res = number & string // never

또한, 어느 타입이든지 never로 교집합 연산을 하면 never를 얻겠죠.

type Res = number & never // never

type Foo = {
    name: string,
    age: number
    }
type Bar = {
    name: number,
    age: number
}

type Baz = Foo & Bar // {name: never, age: number} 

type Foo = {
    name: boolean,
    age: number
    }
type Bar = {
    name: number,
    age: number
}

type Baz = Foo & Bar // never

(에러 메시지로부터) never 타입을 읽는 방법

여러분이 명시적으로 never라고 타입을 지정하지 않으면, 예상치 못한 never 타입과 함께 에러 메시지를 마주하게 될 수도 있습니다. 이는 기본적으로 타입스크립트 컴파일러가 타입들을 교차하기 때문입니다. 타입의 안전성을 지키고 건전성(soundness)을 보장하기 위해 암묵적으로 수행되는 작업입니다.

다음 예시는 이전에 다형적인 함수의 타입에 대해 작성한 포스팅에서 사용한 예시입니다.

type ReturnTypeByInputType = {
  int: number
  char: string
  bool: boolean
}

function getRandom<T extends 'char' | 'int' | 'bool'>(
  str: T
): ReturnTypeByInputType[T] {
  if (str === 'int') {
    // generate a random number
    return Math.floor(Math.random() * 10) // ❌ Type 'number' is not assignable to type 'never'.
  } else if (str === 'char') {
    // generate a random char
    return String.fromCharCode(
      97 + Math.floor(Math.random() * 26) // ❌ Type 'string' is not assignable to type 'never'.
    )
  } else {
    // generate a random boolean
    return Boolean(Math.round(Math.random())) // ❌ Type 'boolean' is not assignable to type 'never'.
  }
}

이 함수는 전달받는 인자에 따라 숫자, 문자열, 불리언을 리턴합니다. 리턴 값에 해당하는 타입을 가져오기 위해 ReturnTypeByInputType[T]를 사용합니다. 그러나 모든 리턴문에서 Type X is not assignable to type 'never'라는 타입 에러가 발생합니다. 분기에 따라 X는 string, number, boolean이 됩니다.

타입스크립트는 우리 프로그램이 문제를 일으킬 가능성을 줄여주기 위해 도움을 주려고 하기 때문에 발생합니다. 각 리턴 값은 ReturnTypeByInputType[T]에 할당할 수 있어야 하는데, 이 값은 런타임 때 number, string, boolean이 될 수 있습니다.

리턴 타입이 모든 가능한 ReturnTypeByInputType[T]에 할당할 수 있다고 보장할 수 있을 때 타입 안정성이 지켜집니다. 즉 number, string, boolean의 intersecion일 때가 그런 경우지만 이는 서로 공존할 수 없는 타입이기 때문에 never가 되는 것이죠. 그래서 에러 메시지에 never를 보게 되는 겁니다.

이를 해결하려면, 여러분은 타입 단언(type assertions) (또는 함수 오버로딩)을 사용해야만 합니다.

• return Math.floor(Math.random() * 10) as ReturnTypeByInputType[T]
• return Math.floor(Math.random() * 10) as never

다른 분명한 예시가 있을 수 있습니다.

function f1(obj: { a: number, b: string }, key: 'a' | 'b') {
    obj[key] = 1;    // Type 'number' is not assignable to type 'never'.
    obj[key] = 'x';  // Type 'string' is not assignable to type 'never'.
}

obj[key]는 런타임에 key의 값에 따라 string 또는 number가 됩니다. 이러한 제약조건이 더해진 타입스크립트는 타입의 안정성을 위해 string과 number 두 타입 모두 공존가능한 값만 쓰게끔 합니다. 그래서 두 타입의 교차된 타입인 never 타입이 전달되는 것입니다.

never 확인하기

어떤 타입이 never이어야 하는지 확인하는 것보다 never인지 확인하는 것이 더 어렵습니다. 다음 코드 예시를 봅시다.

type IsNever<T> = T extends never ? true : false

type Res = IsNever<never> // never 🧐

Res는 true 또는 false가 될까요? 놀랍게도 둘 다 정답이 아닙니다. 실제로는 never가 됩니다.

저도 이걸 처음 접했을 때 정신이 나가는 듯 했습니다. Ryan Cavanaugh가 여기서 이를 설명해주었습니다.

요약을 해보자면 다음과 같습니다.

• 타입스크립트는 조건부 타입을 유니온 타입으로 자동적으로 바꿉니다.
• never는 빈 유니온입니다.
• 그래서 아무것도 합칠 게 없기 때문에 조건부 타입은 다시 never가 됩니다.

여기서 유일한 해결책은 암시적으로 합치는 것을 선택하고 튜플로 타입 매개변수를 감싸는 것입니다.

type IsNever<T> = [T] extends [never] ? true : false;
type Res1 = IsNever<never> // 'true' ✅
type Res2 = IsNever<number> // 'false' ✅

이는 실제로 타입스크립트 소스 코드의 일부이며 타입스크립트가 이 코드를 외부에 노출시키면 더 좋을 듯 합니다.

요약

이 글에서 정말 많은 것을 다루었네요.

• 먼저, never 타입의 정의와 목적에 대해 다뤘습니다.
• 그리고 다양한 사례들을 살펴봤습니다.
  • never가 빈 타입인 점을 활용하여 함수에 제약사항 추가하기
  • 필요없는 유니온 멤버와 객체 프로퍼티를 필터링하기
  • 제어 흐름 분석에 안전성을 더하기
  • 유효하지 않거나 불가능한 조건부 분기를 나타내기
• 암묵적인 타입 교차때문에 타입 에러메시지에서 갑자기 never가 나타나는 이유에 대해서도 다뤘었죠
• 마지막으로 never 타입인지 확인하는 방법까지 살펴봤습니다.

이 글을 리뷰해주고 아주 소중한 피드백을 남겨준 친구 Josh에게 감사의 인사를!

원문 : https://javascriptweblog.wordpress.com/2010/09/27/the-secret-life-of-javascript-primitives/

자바스크립트에서 문자열, 숫자 또는 불리언 원시타입들을 사용할 때마다 여러분은 객체의 그림자와 강압에 숨겨진 세계에 들어가게 됩니다. 그러니 셜록홈즈의 옷장의 먼지를 털어내고 계속 읽어보세요.

기본

객체는 속성들의 집합입니다. 하나의 속성은 객체나 원시타입을 참조할 수 있고, 원시 타입은 값들로 속성을 갖지 않습니다. 자바스크립트에서 원시 타입은 다섯 가지가 있습니다. undefined, null, boolean, string 그리고 number입니다. 그 외에 모든 것들은 객체입니다. 원시타입 boolean, string, number는 그들의 객체에 대응되는 것들에 감싸질 수도 있습니다. 이 객체들은 각 Boolean, String, Number 생성자의 인스턴스들입니다.

typeof true; //"boolean"
typeof Boolean(true); //"boolean"
typeof new Boolean(true); //"object"
typeof (new Boolean(true)).valueOf(); //"boolean"

typeof "abc"; //"string"
typeof String("abc"); //"string"
typeof new String("abc"); //"object"
typeof (new String("abc")).valueOf(); //"string"

typeof 123; //"number"
typeof Number(123); //"number"
typeof new Number(123); //"object"
typeof (new Number(123)).valueOf(); //"number"

원시 타입은 속성이 없는데 왜 "abc".length는 값을 반환할까?

자바스크립트는 원시 타입과 객체를 쉽게 강제변환하기 때문입니다. 이런 경우에서 문자열 값은 length라는 프로퍼티에 접근했기 때문에 문자열 객체로 강제변환됩니다. 문자열 객체는 찰나의 순간에만 사용되고 바로 가비지 콜렉션에 의해 수집됩니다. 우리는 찰나의 이 생명체를 가둬 분석을 해볼 겁니다.

String.prototype.returnMe= function() {
    return this;
}

var a = "abc";
var b = a.returnMe();  

a; //"abc" 
typeof a; //"string" (still a primitive)
b; //"abc"
typeof b; //"object"

의미있는 많은 조사들과 마찬가지로 우리는 b를 생성했기 때문에 b가 존재하는 한 객체가 자연스럽게 수집되는 것을 방해하여 막았습니다. 하이젠베르크는 살아있습니다. 😉 (strict mode에서는 이렇게 잡을 수 없습니다.)

다음 예시는 가비지 컬렉션을 방해하지 않고 객체의 유형을 확인하는 방법입니다.

Number.prototype.toString = function() {
    return typeof this;
}

(123).toString(); //"object"

이러한 방법을 통해 원시타입은 각자의 객체 생성자가 정의한 메소드를 포함한 모든 프로퍼티에 접근할 수 있습니다.

이 객체들은 값들로 강제 변환될 수도 있는가?

주로 그렇습니다. 이러한 유형의 객체들은 단지 래퍼의 역할을 하며 그들의 값은 객체들이 감싸고 있는 원시타입입니다. 필요할 때는 자신들의 값으로 강제 변환되기도 합니다. 이 글에 대한 더 자세한 내용은 여기를 참고하세요.

// 원시값으로 강제변환되는 객체 1
var Twelve = new Number(12); 
var fifteen = Twelve + 3; 
fifteen; //15
typeof fifteen; //"number" (primitive)
typeof Twelve; //"object"; (still object)

//원시값으로 강제변환되는 객체 2
new String("hippo") + "potamus"; //"hippopotamus" 

// 변환되지 않는 객체 ('typeof' 연산자는 여전히 객체로 동작하기 때문)
typeof new String("hippo") + "potamus"; //"objectpotamus"

슬프게도 불리언 객체는 그렇게 쉽게 변환되지 않습니다. 그리고 불리언 객체는 값이 null 이나 undefined가 아니라면 true로 평가됩니다.

if (new Boolean(false)) {
    alert("true???"); 
}

일반적으로 불리언 객체에 값을 명시적으로 요청해야 합니다. 다음은 값이 "truthy"한지 "falsy"한지 결정하는데 도움이 될 수 있습니다.

var a = "";
new Boolean(a).valueOf(); //false

하지만 실제로는 이렇게 하는 것이 더 쉽습니다.

var a = Boolean("");
a; // false

또는 이렇게요.

var a = "";
!!a; //false

형변환을 이용하여 원시 타입에 값을 할당할 수 있을까?

그렇지 않습니다.

var primitive = "september";
primitive.vowels = 3;

primitive.vowels; //undefined; 

자바스크립트가 원시 타입에 프로퍼티를 할당하는 것을 감지한다면 원시 타입을 객체로 강제 형변환시켰을 겁니다. 그러나 위의 예시처럼 새로운 객체는 참조값이 없고 즉시 가비지 콜렉션에 의해 수집됩니다.

다음은 실제로 어떤 일이 일어나는지 설명하기 위한 수도 코드입니다.

var primitive = "september";
primitive.vowels = 3;
// 생성된 새로운 객체에 프로퍼티 셋
(new String("september")).vowels = 3;

primitive.vowels;
// 또 다른 객체가 생성되고 이 객체에서 프로퍼티를 찾음
(new String("september")).vowels; //undefined

보시다시피, 이러한 코드는 쓸모없을 뿐 아니라 낭비입니다.

마무리

프로퍼티를 할당하는 것은 원시타입과 달리 객체가 가지는 유일한 장점이지만 이마저도 꽤 의심스럽습니다. 문자열, 불리언, 넘버는 구체적이고 잘 정의된 목적을 가지며 프로퍼티를 갖는 것은 사람들을 혼란스럽게 할 것입니다. 또한 원시 타입은 불변값이므로 객체 래퍼의 프로퍼티를 수정할 수 없습니다.

var me = new String("Angus");
me.length = 2; //(error in strict mode)
me.length; //5 (not 2 - thanks @joseanpg)
me.valueOf(); "Angus"

그럼에도 불구하고 원시타입을 잘 이해하고 원시타입을 사용할 때 어떤 일들이 일어나는지 이해하는 것은 언어를 더 잘 이해하는데 아주 중요한 단계라고 생각합니다. 이 글이 도움이 되었길 바랍니다.

원문 : 2021.01.18에 작성된 Tao of React - Software Design, Architecture & Best Practices

성능 (Performance)

너무 빨리 최적화하려고 하지 마라

어떤 최적화를 하기 전에 최적화에 대한 이유가 있는지 확인하세요. 여러분의 어플리케이션에 영향을 주지 않음에도 맹목적으로 좋은 사례를 따라하는 것은 노력을 허비할 뿐입니다. 중요한 걸 아는 것도 필요합니다만, 성능 이전에 가독성 있고 유지보수 가능한 컴포넌트를 만드는 것을 더 우선으로 해야 합니다. 잘 쓰여진 코드가 개선하기 쉽습니다.

여러분의 앱에 성능문제가 있을 때 문제의 원인을 측정하고 무엇인지 확인하세요. 번들 사이즈가 거대하다면 리렌더링 횟수를 줄여도 소용이 없습니다. 성능 문제가 있다는 것을 일단 알면 문제의 영향 순서에 따라 수정해야 합니다.

번들 사이즈를 확인하라

브라우저에 전달되는 자바스크립트의 양은 어플리케이션 성능의 가장 주요한 요소입니다. 여러분의 앱이 엄청 빠르더라도 4MB의 JS 코드를 로드해야 한다면 아무도 여러분의 앱이 빠른 것을 알지 못할 겁니다. 하나의 번들을 전달하지 말고 여러분의 앱을 route 수준으로 쪼개도록 하세요. 가능한 최소한의 JS 코드를 전달하도록 해야 합니다.

백그라운드로 로드하거나 사용자가 다른 번들이 필요할 때 로드합니다. 어떤 버튼이 PDF를 다운로드하는 것을 트리거한다면, 버튼이 hover되었을 때 PDF 라이브러리를 다운로드하도록 지연시킬 수 있습니다.

Rerenders - 콜백, 배열, 객체

불필요한 리렌더링의 회수를 줄이는 것은 좋은 시도입니다. 다만, 불필요한 리렌더링은 여러분의 앱에 엄청난 영향을 미치는 경우가 거의 없다는 것을 유의하세요. 가장 흔한 조언은 props로 콜백 함수를 전달하는 것을 지양하는 것입니다. 각 새로운 함수가 생성될 때마다 리렌더링을 유발하기 때문입니다. 콜백함수로 인해 성능 문제를 겪은 적은 없었고, 사실 그것이 제가 접근하고자 하는 방식입니다.

여러분이 성능 문제를 겪고 있고 클로져가 원인이라면 클로져를 제거하세요. 그러나 코드의 가독성을 해치거나 더 장황하게 만들지는 마세요. 배열이나 객체를 아래로 전달하는 것은 비슷한 결입니다. 참조 체크에 실패하면 리렌더링을 유발하죠. 고정된 배열을 전달하고자 한다면, 컴포넌트 정의에 앞서 배열을 상수로 선언함으로써 동일한 인스턴스가 전달될 것입니다.

테스트 (Testing)

스냅샷 테스트에 의존하지 마라

React로 2016년부터 작업하면서 제 컴포넌트에서 스냅샷 테스트가 문제를 캐치한 적은 딱 한 번 있습니다. 인자 없이 new Date()를 호출하여 항상 현재 날짜로 기본 설정되었던 거죠. 게다가 스냅샷은 컴포넌트가 변경될 때마다 빌드 실패의 원인이 됩니다. 일반적인 워크플로우는 컴포넌트를 변경하고 스냅샷에 오류가 있는지 확인한 후 스냅샷을 업데이트하고 계속 진행합니다. 오해하지 마세요. 스냅샷 테스트는 좋은 새너티 체크지만 컴포넌트 수준의 테스트를 위한 대체품이 될 수는 없습니다. 저는 스냅샷을 생성하는 것조차를 지양합니다.

올바른 렌더링을 테스트하라

여러분의 테스트가 검증해야 하는 것은 컴포넌트가 예상대로 동작하는 것입니다. 컴포넌트가 기본값의 props와 전달되는 props로 올바르게 렌더되는지 확인해야 합니다. 주어진 인풋에 대해 함수가 올바르게 결과를 리턴하는지를 검증하세요. 스크린에서 필요한 모든 것들을 검증하세요.

상태와 이벤트를 검증하라

상태가 있는 컴포넌트는 이벤트의 응답에 따라 변경됩니다. 이벤트를 시뮬레이션하고 컴포넌트가 그에 적절히 반응하는지 확인하세요. 핸들러 함수가 호출되고 적절한 인자가 전달되는지 검증하세요. 또한 내부 상태가 잘 설정되는지 확인하세요.

테스트 엣지 케이스 (Test Edge Cases)

엣지 케이스를 테스트하라

기본적인 테스트를 다뤘다면, 엣지 케이스를 다루기 위해 몇 가지를 추가해야 합니다. 빈 배열을 전달했을 때 체킹없이 인덱스를 접근하지 않도록 해야 합니다. API 호출에서 에러를 발생시켜 컴포넌트가 해당 오류를 잘 처리하는지 확인합니다.

통합 테스트를 작성하라

통합 테스트는 전체 페이지나 큰 컴포넌트를 검증하는 것을 의미합니다. 추상화로서 잘 작동하는지 확인하는 것이죠. 이 테스트는 앱이 예상대로 잘 작동한다는 자신감을 줍니다. 컴포넌트 자체로도 잘 작동하고 유닛 테스트 단위로도 테스트를 통과할 수 있지만 통합되었을 때 문제가 있을 수 있습니다.

스타일링 (Styling)

CSS-in-JS를 사용하라

많은 사람들이 동의하지 않고 여러 논란을 야기할 의견입니다. 저는 자바스크립트에서 컴포넌트에 대한 모든 것들을 표현이 가능하기 때문에 Styled Components나 Emotion과 같은 라이브러리를 선호합니다. 관리할 파일이 하나 줄어들며 CSS 컨벤션에 대해 생각할 필요가 없습니다. 리액트에서 논리 단위는 컴포넌트이므로 관심사를 분리하는 관점에서도 컴포넌트와 관련된 모든 것들을 컴포넌트가 소유해야 합니다.

주의 : 스타일에 대한 잘못된 선택은 없습니다. SCSS, CSS 모듈, Tailwind와 같은 라이브러리 등. CSS-in-JS는 제가 추천하는 접근 방식일 뿐입니다.

Styled component를 함께 두어라.

CSS-in-JS 컴포넌트를 사용할 때 한 파일에 여러 개를 같이 두는 것이 일반적입니다. 같은 파일을 사용하는 일반 컴포넌트와 동일한 파일에 보관하는 것이 좋습니다. 그러나 너무 스타일 코드가 너무 길어지게 되면 분리해서 스타일을 사용하는 컴포넌트 근처에 두는 것이 좋습니다. Spectrum과 같은 오픈 소스 프로젝트에서 이러한 패턴을 볼 수 있습니다.

데이터 가져오기 (Data Fetching)

data fetching 라이브러리를 사용하라

리액트는 API에서 데이터를 가져오거나 업데이트하는 고집된 방법을 제공하지 않습니다. 각 팀은 API와 통실하는 비동기 함수들을 제공하는 자신들만의 서비스에 관련된 자체 구현을 만들어내죠. 이 방식을 선택하면 로딩 상태를 관리하고 http 에러들을 다루는 것들을 우리가 직접 해야 합니다. 이는 장황한 코드를 가지는 보일러플레이트를 필요로 합니다. 직접 구현하는 대신 React Query나 SWR과 같은 라이브러리를 사용하세요. hook이라는 관용적인 방식을 통해 서버와 통신하는 것을 컴포넌트 라이프사이클의 자연스러운 부분으로 만듭니다. 또한 캐싱 기능을 제공하고 로딩과 에러 상태를 관리합니다. 우리는 그 기능을 다루기만 하면 됩니다. 또한 데이터를 다루기 위해 상태 관리 라이브러리를 사용할 필요를 없애줍니다.

원문 : Never Use Semicolons
트위터

이 글은 오래된 자바스크립트 논쟁을 다시 열어보고자 작성하는 글이 아닙니다. 단 자바스크립트 스탠다드 스타일에서 "세미콜론을 사용하지 않는" 규칙을 강제하는지에 대한 궁금증에 참조용으로서 작성합니다.

여러분들이 자동 세미콜론 삽입(ASI)에 대해 걱정하지 않고 "언제나 세미콜론을 쓸 수 있다는" 생각은 완전히 잘못됐습니다.
모든 자바스크립트 개발자들은 반드시 ASI에 대해 이해해야 하며, 세미콜론을 항상 붙이더라도 마찬가지입니다. 다음 예시를 참고하세요.

function foo () {
  return
    {
      bar: 1,
      baz: 2
    };
}

세미콜론을 넣는 것을 잊었다 할지라도 괜찮습니다. ASI가 아래처럼 변경합니다.

function foo () {
  return; // <-- ASI가 여기에 세미콜론을 추가했고 여러분은 버그를 얻게 되었습니다!
    {
      bar: 1,
      baz: 2
    };
}

이런 경우로 인해 사람들이 "항상 세미콜론을 쓴다면" 이상한 ASI의 동작으로부터 안전하다는 오해를 낳게 됩니다.

ASI는 우리와 평생 함께 합니다. 이제 여러분들이 ASI가 어떻게 동작하는지에 대해 배울 시간입니다. 걱정하지 마세요. ASI는 ECMAScript 언어 표준에 잘 설명되어 있으며 모든 브라우저는 정확히 동일한 방식으로 구현합니다.

최소한으로 예기치 못한 ASI의 동작을 확인하는 용도로 린터를 사용하는 것을 고려하세요. ESLint는 예상치 못한 ASI의 동작을 잡아주는 no_unexpected_multiline 규칙을 가지고 있습니다. 또한 여러분들이 일단 린터를 사용하면 여러분들을 안전하게 해주므로 세미콜론을 사용하든 사용하지 않든 중요하지 않습니다.

The argument for “never use semicolons”

"항상 세미콜론을 사용하라"는 그렇게 간단하지 않습니다. 세미콜론을 사용하지 않는 많은 엣지 케이스들이 존재합니다. 예를 들어봅시다.

function foo () {
  return 42; // ok
};           // <-- AVOID!

var foo = function () {
}; // ok

그리고 이런 경우도 있습니다.

class Foo {
  constructor () {
    if (baz) {
      return 42; // ok
    };           // <-- AVOID!
    return 12;   // ok
  };             // <-- AVOID!
};               // <-- AVOID!

"세미콜론을 사용하지 않기"보다 "세미콜론을 항상 사용하는 것"은 더 많은 "엣지 케이스"들을 명심해야 합니다.
만약 여러분이 "세미콜론을 사용하지 않는다면" 한 가지의 규칙만이 존재합니다. [, (, ```로 라인을 시작하지 않는다.

그런 경우엔, 이렇게 단순히 ;를 추가하면 됩니다.

;[1, 2, 3].forEach(bar)

그러나 이런 식으로 많이 코드를 작성하는 편이라면, 불필요하게 똑똑한 코드를 쓰고 있는 것일지도 모릅니다.
이렇게 쓰는 게 더 간단하죠.

const nums = [1, 2, 3]
nums.forEach(bar)

그리고 여러분이 standard처럼 린터를 사용한다면, 예상치 못한 ASI가 에러로 알려지므로 기억할 필요가 없습니다.

상태관리, 이제 Recoil 하세요.

영상 링크, 김현태님

핵심 컨셉

• React 내부 상태만을 이용
• 작은 Atom 단위로 관리, 순수함수 Selector
• 리렌더링 최소화, 새로운 리액트 기능과의 호환성

비동기 데이터 다루기

export const productAsyncState = selector({
  key: 'productAsyncState',
  get: async ({get}) => {
    const idx = get(productIdxState);
    return idx > 0 ? await getProductDetail(idx) : null;
  },
});

export const productAsyncState = selectorFamily({
  key: 'productAsyncState',
  get: ({idx}) => async ({get}) => {
    return idx > 0 ? await getProductDetail(idx) : null;
  },
});

-> 이런 식으로 작성하게 되면 Suspense를 이용하라는 에러가 뜸

• indicator 컴포넌트를 미리 만들어 두고 State 호출하는 컴포넌트를 Suspense로 감싸자
• 싫으면 Loadable 사용

에러 핸들링

• <ErrorBoundary>로 감싸거나 useRecoilValueLoadable에서 state를 활용

비동기 데이터의 갱신

• 비동기 데이터 갱신에 영향을 주는 요소
  • (1) 내부에서 구독중인 다른 Recoil state의 변경을 감지 (2) 요청 파라미터가 새로운 값으로 변경
• req id에 대한 atom을 만들고 refresh 함수가 실행되면 id가 갱신되면서 (1)의 이유로 업데이트 하는 방식
• refresh hooks 대신 setter 활용 : 상태 변경이 없는 set을 실행하면 동일한 효과

Atom 구독 공유 시 주의점

• 어디서든 구독이 가능하기 때문에 여러 곳에서 영향을 받을 수 있음
• 의존 관계를 갖는 상태끼리 파일로 관리하거나 AtomFamily로 그루핑하는 방법도 존재

캐싱 컨트롤 할 수 있는 실험 버전이 등장! v.0.4

2021년 7월 27일에 작성된 Top 5 React Mistakes Web Developers Make을 읽고 번역한 글입니다. 🙂

최근, 저는 학생들을 가르치기 시작하여 가끔씩 자주 보이는 실수들을 모아 보았습니다.
지금 모은 것들의 일부를 여러분들과 공유해보고자 합니다.
또한 몇몇 분들과 인터뷰를 진행할 때 보통 이 목록에서 일부를 골랐고, 인터뷰이분들께 코드의 잘못된 점을 여쭤보기도 했습니다.

모든 예제는 코드리뷰나 인터뷰 과제에서 가져왔지만 문제에 집중하고자 단순화시켰음을 알려드립니다.

1. 컴포넌트에서 모든 구독에 대한 clean-up 함수를 선언하라

export const Component4: FC = () => {
    const [value, setValue] = useState(0);

    useEffect(() => {
        setInterval(() => setValue((value) => value + 1), 1000);
    }, []);

    return <div>{value}</div>;
};

우리가 잘 알듯이, SPA 앱에서 메모리 누수는 중요한 문제이고 반드시 신경써야 할 문제입니다. 이 코드는 메모리 누수의 이유를 알려주는 좋은 예제 코드입니다. 일부 로직을 setInterval 함수에 두었고 컴포넌트가 언마운트될 때 해당 함수를 클리어하는 것이 누락되었습니다.
useEffect에 전달되는 함수는 clean-up 함수를 반환할 수 있습니다. 그러므로 옳은 코드는 아래와 같습니다.

export const Component4: FC = () => {
    const [value, setValue] = useState(0);

    useEffect(() => {
        const interval = 
            setInterval(() => setValue((value) => value + 1), 1000);
        return () => clearInterval(interval);
    }, []);

    return <div>{value}</div>;
};

clean-up 함수에서 컴포넌트가 언마운트될 때마다 인터벌 함수를 정리함으로써 메모리 누수의 원인을 제거했습니다.
useEffect/useLayoutEffect에서 발생할 수 있는 구독에 대해 언제나 구독을 해제하는 로직을 제공해야 합니다.
setInterval이나 소켓 연결과 같은 어떤 구독이든지 말입니다.

2. useState 훅에서 업데이트되는 상태에 관련되는 함수를 메모이제이션 하지마라

새로운 학생들이 프로젝트 구현을 시작하기 전에 제가 항상 하는 한 마디가 있습니다.

너무 이른 최적화는 모든 악의 근원이다. - Donald Knuth

그러나 때때로 학생들이 개발 과정과 새로운 것들을 알아가는 과정에서 너무 열정을 쏟아 붓느라 이 말을 까먹곤 합니다.
그러면 아래와 같은 코드를 보게 됩니다.

const Component1:FC = () => {
    const [users, setUsers] = useState<User[]>([]);
    const setUserList = useCallback(setUsers, []);
    
    return <Component2 setUserList={setUserList}/>
}

그러나 리액트는 setState 함수의 동일성이 안정적이고 리렌더링될 때 변경되지 않을 거라고 보장하기 때문에 이러한 최적화는 필요하지 않습니다.
다른 한편으로는 이런 점들을 고민하고 있는 것은 멋진 일이기는 합니다.

3. 자식 컴포넌트가 memo 함수로 감싸질 때 prop으로 넘기는 인라인 함수는 메모라이즈하라

아래의 코드를 살펴보도록 합시다.

type User = {
    name: string,
    roles: string[]
}

type UserRolesProps = {
    roles: string[],
    deleteRole: (role: string) => void
}
const UserRoles: FC<UserRolesProps> = React.memo(({roles, deleteRole}) => {
    console.log('Render User Roles');
    return (
        <div>
            {roles.map((role, i) =>
                <span key={i} onClick={() => deleteRole(role)}>{role}</span>
            )}
        </div>
    );
});

export const User: FC = () => {
    console.log('Render User component');
    const [user, changeUser] = useState<User>({name: 'Peter', roles: ['admin']});

    const deleteRole = (deletedRole: string) => {
        changeUser((prevUser) => ({
            ...prevUser,
            roles: prevUser.roles.filter(role => role !== deletedRole)
        }));
    };

    const changeName = (name: string) => {
        changeUser((prevUser) => ({...prevUser, name}));
    };

    return (
        <div>
            <input value={user.name} onChange={(e) => changeName(e.target.value)}/>
            <UserRoles roles={user.roles} deleteRole={deleteRole}/>
        </div>
    );
};

코드 위치 순서 변경

User 컴포넌트와 자식 컴포넌트 하나가 있는데, UserRoles는 유저의 역할에만 의존하고 있습니다. 개발자가 UserRole을 React.memo 함수로 감싸고 있다는 것에 주목하세요. 성능 이슈를 신경써서 props가 변경되지 않았을 때 해당 컴포넌트들을 업데이트하고 싶지 않은 것입니다.
그런데 문제는 deleteRole이 인라인 prop이고 리액트가 User 컴포넌트를 리렌더링할 때 deleteRole 함수의 새 인스턴스를 계속 생성한다는 것을 간과한 것입니다. 즉 user.role이 변경되지 않았을 때 deleteRole은 각 타임마다 새로운 함수를 참조하게 됩니다.
그래서 React.memo에 감싸져 있는 컴포넌트는 의미가 없어집니다.

아마 여러분들도 이미 답을 알고 계실 겁니다. deleteRole 함수를 useCallback 함수로 감싸면 되는 것이죠.

export const User: FC = () => {
  
   // skipped for brevity

    const deleteRole = useCallback((deletedRole: string) => {
        changeUser((prevUser) => ({
            ...prevUser,
            roles: prevUser.roles.filter(role => role !== deletedRole)
        }));
    }, []);

   // skipped for brevity
};

이렇게 코드를 변경한 결과입니다.

4. 상태의 업데이트를 둘 다 가능하더라도 동기 작업보다는 비동기 작업으로 취급하라

면접에서 1000ms마다 값을 증가시키는 카운터의 간단한 구현을 요청한 적이 있습니다. 종종 제가 보던 코드를 보시죠.

function Counter() {
  let [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount(count + 1);
    }, 1000);
    return () => clearInterval(id);

 }, []);

  return <h1>{count}</h1>;
}

여러분도 예상하듯이, 라인 6에서 count 값은 함수 클로저에서 가져오므로 항상 0을 가져옵니다. 각 1000ms마다 값을 증가시키려고 함에도 말입니다. 화면에서 우리는 0과 1000ms 후에는 1을 계속 보게 될 것입니다. 카운터는 절대 증가시키지 않습니다.
리액트에서 함수형 컴포넌트가 실제로 어떻게 작동하는지를 보여주는 것이죠. code sandbox를 참고하세요

상태 값 변경을 비동기 작업처럼 처리하여 이 문제를 해결해보겠습니다.

export default function Counter() {
  let [count, setCount] = useState(0);

  useEffect(() => {
    let id = setInterval(() => {
      setCount((count) => count + 1);
    }, 1000);
    return () => clearInterval(id);
  }, []);

  return <h1>{count}</h1>;
}

setCount(count + 1) 대신에 setCount((count) => count + 1을 사용했습니다.
이 값은 함수 클로저가 아닌 이전의 리액트 컴포넌트 상태에서 가져오는 값입니다.

다른 흥미로운 케이스가 있습니다.

const Task02 = () => {
   const [count, setCount] = useState(0);

   const onClick = () => {
       setCount(count + 1);
       setCount(count + 1);
   }

   return (
       <div>
           Count: {count}
           <div>
               <button onClick={onClick}>Increment twice</button>
           </div>
       </div>
   )
}

버튼을 클릭하면 상태값이 2번 증가할 거라고 예상하지만 실제로는 그렇지 않습니다. 각 버튼을 클릭할 때 오직 1만 증가될 뿐입니다.
React는 꽤 똑똑해서 각 작업을 동기적으로 완성시키지 않습니다. 배치에서 여러 상태값 갱신을 모으기 때문에 실제로는 아래처럼 작동합니다.

Object.assign(
    prevState,
    { count: prevState.count + 1 },
    { count: prevState.count + 1 }
)

그래서 우리의 예상대로 작동하도록 하려면 비동기 작업으로 취급하여 아래처럼 수정해야 합니다.

const Task02 = () => {
   const [count, setCount] = useState(0);

   const onClick = () => {
       setCount((count) => count + 1);
       setCount((count) => count + 1);
   }

   return (
       <div>
           Count: {count}
           <div>
               <button onClick={onClick}>Increment twice</button>
           </div>
       </div>
   )
}

경험적으로 비추어 봤을 때 리액트가 상태를 동기적으로 업데이트할 수 있다는 것입니다.
그래서 많은 경우에 버그가 발생하지 않을 수 있으며 언제나 비동기적으로 상태 갱신을 유지할 수도 있습니다.
이는 React가 갱신하는 방법이고 아무도 이에 대해 반대하지 않게 때문입니다.

5. useRef hook의 사용을 남용하지 마라

배우기 시작할 때 아마 여러분은 리액트가 명령형보다 선언형 프로그래밍을 고수한다고 들으셨을 겁니다. 때때로 그 둘의 차이를 이해하기 위해 실전이 필요합니다. 여전히 useRef 훅을 많이 사용하고 있다면 여러분은 아마 이 규칙을 위반하며 선언형에서 명령형 접근법으로 관점이 바뀐 것입니다.
긴 코드 스니펫을 볼까요. codesandbox

export const App: FC = () => {
    const inputGroupRef = useRef<HTMLDivElement>(null);
    const inputRef = useRef<HTMLInputElement>(null);

    useEffect(() => {
        const handleFocus = () => inputGroupRef.current!.classList.add(styles.active);
        const handleBlur = () => inputGroupRef.current!.classList.remove(styles.active);

        inputRef.current!.addEventListener('focus', handleFocus);
        inputRef.current!.addEventListener('blur', handleBlur);

        return () => {
            inputRef.current!.removeEventListener('focus', handleFocus);
            inputRef.current!.removeEventListener('blur', handleBlur);
        }
    }, []);

    return (
        <div className={styles.container}>
            <div ref={inputGroupRef} className={styles.inputGroup}>
                <label className={styles.label}>
                    Your name
                </label>
                <input
                    ref={inputRef}
                    className={styles.input}
                    type="text"
                />
                <div className={styles.border}/>
            </div>

        </div>
    )
};

이 코드는 꽤 별로인 구현이네요. 코드를 보니 jQuery가 명령형 방식과 함께 살아있었다는 것이 생각나네요.
여기에서 우리는 컴포넌트의 상태를 명령형으로 변경시키며 DOM 트랜지션을 효과적으로 수행하는 React의 힘을 사용하고 있지 않습니다.
개발자의 의도는 각 input마다 컴포넌트의 CSS 클래스를 변경시키고자 하는 것이었는데요.
우리는 useRef의 사용을 제거해서 선언형 방식으로 코드를 재작성해보겠습니다.

export const App: FC = () => {
    const [isActive, changeState] = useState(false);

    return (
        <div className={styles.container}>
            <div className={isActive ? '${styles.inputGroup} ${styles.active}' : styles.inputGroup}>
                <label className={styles.label}>
                    Your name
                </label>
                <input
                    onFocus={() => changeState(() => true)}
                    onBlur={() => changeState(() => false)}
                    className={styles.input}
                    type="text"
                />
                <div className={styles.border}/>
            </div>
        </div>
    );
};

경험적으로 여러분은 가능하면 레퍼런스 호출을 사용하는 것을 피하는 것이 좋습니다.
여러분이 useRef 훅을 사용해야 하는 경우에 대한 3가지 좋은 이유입니다.

• focus, 텍스트 selection, 미디어 playback 관리
• 명령형 애니메이션의 호출
• 서드파티 DOM 라이브러리 결합

원문 '4 Essential Tips for Better Asynchronous Code in JavaScript'

새로운 프로그래밍 기술을 배우는 것은 여러분의 코드가 "작동하는 것"을 넘어 "더 잘" 작동하게 만드는 좋은 방법입니다. 한 두개의 어플리케이션만 만들어 봤거나 callback, promise, async/await 등으로 비동기 호출을 하는 방법을 알고 있을지라도 비동기 코드를 잘 작성하는 방법을 알게되는 건 언제나 여러분에게 유용하게 쓰일 것입니다.

저희는 자바스크립트의 싱글 스레드를 잘 다루고 효율적으로 코드를 작성하기 위해 필요한 "비동기 프로그래밍 201" 팁과 트릭을 예제와 함께 공유드릴 것입니다. "시간/콜백 지옥의 시작"을 피하고 최근에 사용되는 자바스크립트 비동기 패턴에 집중하고자 비동기 코드의 역사를 알아보겠습니다.

각 await은 async 함수로 감싸고 fakeFetch()은 다른 어떤 곳에 정의되어 있다고 가정하겠습니다.

1. 병렬적으로 실행하고 나중에 기다리게 하여 코드가 빠르게 실행되도록 하라

각 Promise들은 fetchFile(file)을 쓰자마자 GET 요청을 보내기 때문에 빠릅니다. 반면에 await은 promise가 해결될 때까지 함수의 실행을 중단합니다. 불필요한 기다림을 제거하고, 더 빠른 promise를 사용하고, 하나씩 보내지 않고 한번에 여러 파일에 대한 요청을 보냄으로써 코드를 더 효율적이고 빠르게 만들 수 있습니다.

어떻게 병렬적으로 요청을 보낼 수 있는가?

새로운 Promise를 반들고 결과를 나중에 받으면 됩니다. 아래 코드 예제에서 세 파일을 동시에 fetch하고 받은 promise는 나중에 언젠가(await)에서 resolve 되어져야 합니다.

// fake fetch function returning a new Promise object
const fetchFile = (file) => new Promise(resolve => fakeFetch(file, resolve))

// 하나씩 병렬적으로 모든 파일에 대해 요청을 보냄
const promise1 = fetchFile('file1')
const promise2 = fetchFile('file2')
const promise3 = fetchFile('file3')

// 나중에 기다리기
const file1 = await promise1

Promise 객체에는 여러 promise를 동시에 처리할 수 있는 방법들이 포함되어 있으므로 여러 파일을 동시에 fetch할 수 있는 편리한 방법이 있습니다. 예를 들어 Promise.all()은 병렬적으로 파일을 요청하고 같은 라인에서 결과를 기다립니다. 바로 값을 얻을 수 있어요!

// 값을 기다리지만 각 요청은 병렬적으로 보내지는 중
const fileArray = await Promise.all([fetchFile('file1'), fetchFile('file2'), fetchFile('file3')])

너무 많은 병렬 요청은 (특히 큰 리소스를 요청하는 상황에서) 나쁜 성능을 야기시킬 수 있음을 기억해야 합니다.

그렇다면, 언제 await을 사용해야 하는가?

코드에서 데이터끼리 의존성이 있을 때 이전 promise의 resolve된 결과값을 사용해야 합니다.

파일들을 순차적으로 받아야 한다고 가정해봅시다. 아래 코드 예제에서 file2에 대한 fetch 요청은 처음에 보낸 fetchFile() 호출이 file1와 함께 resolve되어졌을 때 보낼 수 있습니다. 동시에 요청을 보내던 이전 예제에 비하면 꽤 느립니다. 각 변수들은 promise를 참조하지 않고 파일을 참조합니다.

// 순차적으로 요청을 보냄
const file1 = await fetchFile('file1') // resolve 될 때까지 정지
const file2 = await fetchFile('file2') 
const file3 = await fetchFile('file3')

아래 예제도 순차적으로 요청을 보내야 하는 경우입니다. order를 fetch하려면 fetchUser() Promise를 기다려야 합니다.

const user = await fetchUser()
const userOrders = await fetchOrders(user)

핵심 팁 : 독립적인 비동기 작업들은 병렬 요청을 사용하여 시간 및 성능을 낭비하지 말자.

2. map()으로 Promise 배열 생성하기

위 예제에서는 가져올 파일의 수를 정확히 아는 상황에서 해당 수만큼의 promise를 실행했습니다. 임의의 길이의 파일을 fetch하려면 어떻게 해야 할까요?

정의되지 않은 길이의 집합으로 작업할 때 Javascript는 array와 array method를 사용합니다. promise를 리턴하고 promise에 fileNames 배열의 값을 매핑하는 map()과 fetchFile()을 사용하여 promise의 배열을 만들 수 있습니다.

// fake fetch function returning a new Promise object
const fetchFile = (file) => new Promise(resolve => fakeFetch(file, resolve))

// 임의의 길이를 가지는 배열
const fileNames = ['file1', 'file2', 'file3'/* ... */] 

// Promise 객체를 리턴하는 콜백을 가진 promise 배열 생성
const promises = fileNames.map(fetchFile)

일단 promise들을 배열로 쌓아둔 다음 루프를 돌면서 promise를 실행할 수도 있고, Promise.all()과 같은 이터러블을 받는 Promise 객체 메소드에 전달할 수도 있습니다.

핵심 팁 : 많은 promise를 다룰 때, promise를 배열에 저장하라.

원문 : How Netflix Scales its API with GraphQL Federation (Part 1)

넷플릭스는 루즈한 결합과 확장성이 뛰어난 마이크로서비스 아키텍처를 사용하는 것으로 알려져 있습니다. 독립적인 서비스를 통해 서로 다른 속도로 발전하며 독립적으로 확장시킬 수 있습니다. 그러나 여러 서비스에 걸쳐 사용되는 경우 복잡성을 가중시키기도 합니다. UI 개발자에게 100가지의 마이크로서비스를 노출시키는 대신 넷플릭스는 엣지에서 통합된 API 계층을 제공합니다.

UI 개발자는 큰 도메인에 대한 하나의 개념적인 API로 작업하는 단순함을 굉장히 좋아합니다. 백엔드 개발자는 API 계층이 제공하는 디커플링과 탄성을 좋아합니다. 그러나 우리의 비즈니스가 확장됨에 따라, 빠르게 혁신하는 우리의 능력이 보이지 않는 점근선에 가까워졌습니다. 개발자 수가 증가하고 도메인 복잡성이 커짐에 따라 API 집합체 계층을 개발하는 것은 더욱 어려워졌습니다.

이러한 문제를 해결하기 위해 API 계층을 강화하는 연합된(federated) GraphQL 플랫폼을 개발했습니다. 이는 확장성 및 운영성과 같은 차원들을 최소화하며 많은 일관성과 개발속도 문제를 해결합니다. 우리는 넷플릭스 스튜디오 생태계에서 이 접근법을 성공적으로 구축했으며 다른 도메인에서 동작할 수 있는 여러 패턴과 적용들을 탐사하고 있습니다. 우리는 다른 사람들에게 영감을 주고 다른 곳 또한 적용 가능성에 대한 대화를 장려하고자 이야기를 나누고자 합니다.

사례 연구 : Studio Edge

Intro to Studio Ecosystem

Netflix는 굉장히 빠르게 오리지널 컨텐츠를 제작하고 있습니다. TV 쇼나 영화가 넷플릭스에서 방영될 때까지 아주 많은 일들이 일어나고 있습니다. 이는 스카우트, 캐스팅 뿐만 아니라 거래와 계약 협상, 제작, 시각 효과와 애니메이션, 자막과 더빙 등을 포함하여 아주 많은 것들이 존재합니다. 스튜디오 엔지니어링은 이 워크플로우들을 강화하는 수백가지의 어플리케이션과 툴을 제작합니다.

Studio API

몇 년전으로 돌아가보면, 스튜디오 공간에서의 한 가지 문제점은 데이터와 데이터 관계들의 증가하는 복잡성이었습니다. 위에서 설명한 워크플로우는 연결되어 있으나 데이터와 데이터 관계는 여러 마이크로서비스로 분산되어 존재했습니다. 프로덕트 팀은 두 가지 구조적 패턴으로 이를 해결했습니다.

1. 단 하나의 결합된 레이어 : 루즈하게 결합되었기 때문에 많은 팀들이 중복되는 코드를 작성하고 각자의 프로덕트 니즈에 따라 여러 결합 레이어를 작성하는 데 많은 시간을 소모했습니다. 이는 BFF를 통해 UI 팀이나 미드티어 서비스의 백엔드 팀에 의해 수행되었습니다.

2. 다른 팀의 데이터에 대한 구체화된 뷰(materialized views) : 어떤 팀들은 시스템의 요구에 따라 다른 팀의 데이터의 구체화된 뷰를 구축하는 패턴을 사용했습니다. 구체화된 뷰는 성능상의 이점은 가지지만 데이터 일관성에 있어서는 부족했습니다. 여러 스튜디오 어플리케이션을 가르는 일관되지 않은 데이터는 2018년 스튜디오 엔지니어링에서 가장 먼저 다루어야 하는 문제점이었습니다.

Graph API : 근본적인 필요성을 더 잘 다루기 위해, 우리 팀은 "Studio API"라고 불리는 큐레이션 graph API를 제작하기 시작했습니다. 목표는 데이터와 관계를 기반으로 하나로 통일된 추상화를 제공하는 것이었습니다. Studio API는 핵심적인 공유 데이터에 접근하기 위해 유용성을 제공하는 기본적인 API 기술인 GraphQL을 사용했습니다. Studio API의 컨슈머는 그래프를 탐색하고 더 빠르게 새로운 기능을 제작할 수 있었습니다. 또한 GraphQL의 모든 필드들이 데이터를 가져오는 하나의 코드로 해결되었으므로 다른 UI 어플리케이션에서 더 적은 데이터 불일치를 관찰할 수 있었습니다.

Studio API의 병목현상

Studio API에서 노출되는 하나의 그래프는 엄청난 성공을 거두었습니다. 프로덕트 팀들은 재사용성과 쉽고 일관되는 데이터 접근을 아주 좋아했기 때문입니다. 그러나 무수히 많은 컨슈머와 그래프가 생성하는 대량의 데이터 덕분에 병목현상에 부딪히게 되었습니다.

먼저 Studio API 팀은 도메인 전문가와 프로덕트 니즈로부터 연결이 끊김으로써 스키마에 부정적인 영향을 미쳤습니다. 두 번째로 백엔드의 새로운 요소들과 Graph API를 연결하는 것은 수동이었고 마이크로서비스 아키텍처가 보장하는 빠른 진화를 방해했습니다. 마지막으로 하나의 작은 팀이 확대되는 그래프에 대한 운영과 지원을 담당하는 것은 매우 감당하기 어려운 일이었습니다.

우리는 더 좋은 방법이 필요하다고 생각했습니다. 하나로 통일되면서 디커플링되고 큐레이트되며 빠르게 움직이는 것이죠.

핵심 원칙으로 돌아오기

이 병목현상을 해결하기 위해 마이크로서비스와 모노리스를 분해한 여러 이야기들에 기댔습니다. Studio API의 하나로 통일된 GraphQL 스키마를 유지함과 동시에 리졸버의 구현을 각 도메인 팀으로 비중앙화하고자 했습니다.

2019년 초 새로운 아키텍처에 대해 브레인스토밍하고 있을 때 Apollo는 GraphQL Federation 명세를 발표했습니다. 이는 분산된 오너십과 구현과 함께 하나의 스키마의 이점을 약속했습니다. 그런 결과를 기대하며 스펙의 테스트 구현을 시도했고 GraphQL Federation 미래에 대해 아폴로와 협업하는 것에 도달했습니다. 우리의 다음 세대 구조인 "Studio Edge"는 federation을 중요한 요소로 하여 등장했습니다.

GraphQL Federation 도화선

GraphQL Federation의 목표는 두 가지입니다. 컨슈머에게 하나의 API를 제공하며 백엔드 개발자에게는 유연함과 서비스의 독립성을 주는 것입니다. 이를 달성하고자 스키마는 생성되고 어떻게 소유권이 분산되었는지 알려주도록 설명이 필요합니다. 세 가지 엔티티와 함께 예시를 살펴봅시다.

1. Movie : 넷플릭스에서 타이틀을 생성합니다. 단순함을 위해 각 타이틀은 Movie 객체라고 합시다.
2. Production : 각 Movie는 스튜디오 프로덕션과 연관되어 있습니다. 하나의 Production 객체는 위치 선정, 노점상 등 Movie를 만들기 위해 필요한 모든 것들을 추적합니다.
3. Talent : Movie에서 일하는 사람들이 Talent입니다. 배우와 감독 등을 포함합니다.

세 도메인은 세 개의 분리된 엔지니어링 팀이 소유하며 각 팀은 각자의 데이터 소스나 비즈니스 로직, 상응하는 마이크로서비스를 담당합니다. 연합되지 않은 구현에서는 Studio API 팀이 소유하며 구현하는 스키마와 리졸버를 가질 것입니다. GraphQL 프레임워크는 클라이언트로부터 쿼리를 받아 광범위한 순회를 통해 해당하는 리졸버를 호출하도록 조정합니다.

연합되는 구조로 전환하기 위해 통합된 스키마를 희생시키지 않고 각 리졸버들의 소유권을 각 담당하는 도메인으로 옮겨야 했습니다. 그러기 위해 Movie 타입을 GraphQL 서비스 바운더리로 확장해야 했죠.

Movie 타입을 GraphQL 서비스 바운더리로 확장하는 것이 기능은 Movie 타입을 Federated Type으로 만듭니다. 주어진 필드를 해결하는 것은 게이트웨이 계층으로부터 소유 도메인 서비스로 위임하는 것이 필요합니다.

Studio Edge 구조

타입을 연합하는 기능을 사용하는 것은 다음과 같은 구조를 구상했습니다.

주요한 구조적 컴포넌트

**Domain Graph Service (DGS)**는 독립적이며 규격을 준수하는 GraphQL 서비스입니다. 개발자는 각자의 연합된 GrpahQL 스키마를 DGS에서 정의합니다. API의 세부항목을 담당하는 도메인 팀은 DGS를 소유하고 운영합니다. DGS 개발자는 기존 마이크로서비스를 DGS로 전환할 것인지 아예 새로운 서비스를 스핀업 할 것인지 자유롭게 결정합니다.

Schema Registry는 모든 DGS에 대해 모든 스키마와 스키마 변경사항을 저장하는 상태가 있는 컴포넌트입니다. 개발자 툴과 CI/CD 파이프라인에서 사용되는 스키마에 대한 CRUD API를 노출합니다. 개별적인 DGS 스키마와 결합된 스키마 모두에 대해 유효성을 확인합니다. 마지막으로 레지스트리는 하나의 통합된 스키마를 구성하며 이를 게이트웨이에 제공합니다.

GraphQL 게이트웨이는 기본적으로 GraphQL 쿼리를 컨슈머에게 제공하는 역할을 합니다. 클라이언트로부터 쿼리를 받아 작은 서브 쿼리들(쿼리플랜)로 쪼개고 적절한 DGS들에게 호출을 프록싱하여 쿼리 플랜을 실행합니다.

구현 세부 사항

GrpahQL Federation을 강화하는 세 가지 주요한 비즈니스 로직 구성 요소가 있습니다.

Schema Composition

Composition은 모든 federated DGS 스키마들을 받아 하나로 통합된 스키마로 합하는 과정입니다. 구성된 스키마는 게이트웨이에 의해 그래프의 컨슈머들에게 노출됩니다.

새로운 스키마가 DGS에 추가될 때마다 스키마 레지스트리는 다음 사항들을 검증합니다.

1. 새로운 스키마는 유효한 GrpahQL 스키마이다.
2. 새로운 스키마가 나머지 DGS 스키마와 잘 구성되어 유효한 합성된 스키마를 생성한다.
3. 새로운 스키마는 이전 버전과 호환된다.

만약 모든 조건이 만족되면, 그 스키마는 스키마 레지스트리로 체크인됩니다.

Query Planning and Execution

federation config는 모든 개별적인 DGS 스키마와 구성된 스키마로 이루어집니다. 게이트웨이는 쿼리 플랜을 생성하기 위해 federation config와 클라이언트 쿼리를 사용합니다. 쿼리 플랜은 클라이언트 쿼리를 더 작은 서브 쿼리로 쪼갠 것인데 실행을 위해 DGS로 보내지고 순차적인 실행 순서와 병렬 실행 순서를 포함합니다.

위에서 참조한 스키마로부터 간단한 쿼리를 만들고 어떻게 쿼리플랜이 생성되는지 봅시다.

이 쿼리에서 게이트웨이는 federation config를 기반으로 하여 어떤 필드가 어떤 DGS에 있는지 알고 있습니다. 이 정보를 사용하여 게이트웨이는 클라이언트 쿼리를 세 가지 개별적인 쿼리로 분해합니다. 첫 번째 쿼리는 Movie DGS로 보내지는데 루트 필드 movies는 해당 DGS에서 소유하고 있기 때문입니다. 이에 대한 결과로 데이터셋에서의 첫 10가지 영화들에 대한 movieId와 title을 가져옵니다. 그러고 나서 이전 요청에서 얻은 movieId들을 사용하여 게이트웨이는 10가지 영화에 대한 production과 actors 필드를 가져오기 위해 Prodction DGS와 Talent DGS에 두 병렬 요청을 수행합니다. 완료되면 서브쿼리의 응답은 하나로 합쳐져 호출자에게 결합된 데이터 응답을 보냅니다.

성능에서 참고할 사항 : 쿼리 플래닝과 실행은 최악의 경우 1~10ms 오버헤드를 더합니다. 이는 쿼리 플랜을 생성하고 DGS 응답의 deserialization과 합쳐진 게이트웨이 결과의 serialization을 포함합니다.

Entity Resolver

이제 여러분들은 어떻게 Prodction과 Talent DGS에서 병렬적인 서브 쿼리가 동작하는지 궁금하실 겁니다. DGS가 지원하는 것은 없습니다. 이것이 퍼즐의 마지막 조각입니다.

federated 타입인 Movie로 돌아가 봅시다. 게이트웨이가 DGS들을 넘나들며 Movie를 합치려면 Movie를 정의하고 확장하는 모든 DGS는 하나 이상의 필드에 대해 프라이머리 키(e.g. movieId)를 정의해야 합니다. 이를 동작시키고자 아폴로는 @key directive를 명세에서 소개했습니다. 또한 DGS들은 일반적인 Query 필드인 _entities에 대해 리졸버를 구현해야 합니다. _entities 쿼리는 모든 federated 타입들에 대한 하나의 타입을 반화합니다. 게이트웨이는 _entities 쿼리를 사용하여 movieId로 Movie를 찾습니다.

실제로 어떻게 쿼리플랜이 생겨는지 살펴봅시다.

표현 객체는 movieId로 이루어져 있고 Movie DGS의 첫 번째 요청에 대한 응답으로부터 생성됩니다. 첫 10개의 영화 데이터를 요청했기 때문에 Prodction과 Talent DGS에 보낼 10개의 표현 객체를 가집니다.

이는 Realy의 객체 식별과 비슷하지만 약간의 차이점이 있습니다. _Entity는 하나의 union 타입이지만 Relay의 Node는 인터페이스입니다. 또한 @key를 사용하여 복합 키 뿐만 아니라 변수 키 이름과 타입을 지원할 수 있는데 Relay에서는 단일한 ID필드입니다.

함께 결합되면, 이것들은 federated API 구조의 핵심에 힘을 실어주는 요소들입니다.

요약

우리의 스튜디오 생태계 구조는 각기 다른 양면으로 진화해왔고, 아이디어와 구현 사이의 시간을 줄이며 개발자의 경험을 향상시키고, 운영을 국소화시키는 방향으로 동기부여됐습니다. 구조적인 단계는 아래와 같습니다.

주목하세요

지난 몇년동안 우리는 Studio Edge에서 federated API 구조 구성요소들을 구현했습니다. 여기까지 도달하려면 빠른 반복, 많은 부서간의 협업, 몇 가지의 피벗과 지속적인 투자가 필요합니다. 현재 70가지의 DGS를 가지며 수백명의 개발자가 있는데 Studio Edge 구조를 사용하고 있습니다. 다음 넷플릭스 테크 블로그 포스팅에서는 전체적인 해결책을 구축하는데 필요한 교차적인 관심사를 포함하여 우리가 배운 것들에 대해 공유할 것입니다.

원문 : Welcome to the World of 'NFTs'
부제 : What are Non Fungible Tokens & Why are they becoming so popular?

개요

최근, NFT로 인해 디지털 수집품의 인기가 폭발적으로 증가하고 있습니다. 아마 NFT에 대해 이야기하는 사람들을 SNS 피드에서 보셨을 겁니다.
NFT 시장이 커짐에 따라 예술, 음악, 게임, 금융산업이 뒤집히고 있습니다. NFT를 처음 듣는 사람들은 이해하기 어려울 수 있습니다.
그러니 NFT가 무엇인지 살펴보고 왜 갑자기 인터넷에서 차세대 상품이 되고 있는지 알아봅시다.

NFT에 대해 알아야 할 것들을 모두 보겠습니다. 🙂

NFT가 대체 무엇인가요?

아마 여러분들은 트위터의 공동 설립자이자 CEO인 Jack Dorsey의 유명한 트윗을 알고 있을 겁니다.
그는 자신의 첫 번째 트윗을 NFT로 판매하고 있습니다.

이 트윗이 보고자 한다면 누구나 무료로 볼 수 있는 이 디지털 아이템이 공개적으로 이용이 가능함에도 불구하고, 3월 6일 기준으로 이 트윗에 대해 가장 높게 제안한 금액이 250만 달러가 넘었습니다. 🤯

이 트윗을 "산다는 것"이 실제로 무엇을 의미하는 건가요?

여러분이 구매하는 것은 이 트윗의 디지털 증명서 인데, 생성자에 의해 검증되었고 "유일하게" 이 우주에 존재하기 때문에 여러분이 구매하는 것은 고유한 아이템이 됩니다.

그럼 정확히 NFT가 무엇인가요?

NFT(Non-Fungible Tokens)는 대체 불가능한 토큰으로 블록체인을 기반으로 하며 고유하게 특정 미디어 조각을 나타내는 기록입니다.
미디어는 디지털로 된 어떤 것이든 될 수 있습니다. "대체 불가능하다는" 것은 그 조각이 고유하며 어떠한 다른 것으로 대체 불가능하다는 것을 의미합니다. 예를 들어 우리의 법적인 현금은 대체가 가능합니다. 다른 것으로 교환할 수 있으며 동일한 가치를 가진 어떤 것으로 가질 수 있습니다.

이러한 아이템들의 소유권은 블록체인을 통해 기록됩니다. NFT는 이더리움이라고 불리는 암호화폐와 동일한 블록체인 로그에 보관되어 있습니다.
누구나 볼 수 있고 감탄할 수 있는 오픈 마켓의 유니크한 수집품들과 같습니다. 그러나 오직 한 사람만이(또는 암호화폐 지갑)만이 주어진 시간에 소유할 수 있습니다.

왜 NFT는 인기가 생겼을까요?

NFT는 지난 한 달동안 3억 달러 이상의 매출이 발생했기 때문에 최근 많은 관심을 받고 있습니다. 💰 각 NFT는 고유하고 복제될 수 없으며 희소성 있도록 설계되었습니다.

하지만 동일한 디지털 미디어를 무료로 다운로드 받을 순 없나요?🤷‍♂️

받을 수 있습니다. 그러나 NFT는 복제될 수 없는 무언가를 여러분에게 주도록 설계됩니다. 그건 바로 작업물의 소유권입니다. (물리적인 예술작품과 마찬가지로, 아티스트가 여전히 저작권과 재생산권을 가지고 있다해도 말입니다.) 물리적인 예술품 수집의 관점에서 보자면, 누구나 모네 판화를 구매할 수 있지만 원본은 한 사람만 소유할 수 있는 것이죠.

단순히 이미지나 드로잉이 아니라는 것을 이해하는 게 중요합니다. 블록체인을 독특하게 만드는 것은 블록체인의 디지털 객체로서의 존재입니다.

일반적인 암호화폐와 다르게, NFT는 직접적으로 다른 것과 교환될 수 없습니다. 두 개의 NFT는 동일할 수 없기 때문입니다.
다른 자산과 마찬가지로, 수요와 공급은 가격을 결정하는 데 중요한 열쇠입니다. NFT의 희소성으로 인해 사람들은 NFT에 많은 돈을 지불할 준비가 되어 있는 겁니다.

NFT가 인기 있는 또 다른 이유는 중앙화된 소셜 플랫폼(ex. 유튜브)이 창작자와 팬들을 연결하는 우세한 방법이 되었기 때문입니다. 이러한 구조에서 창작자의 대부분 수입의 원천은 광고인 것이죠. 플랫폼은 창작자와 소비자 사이에 플랫폼 자체의 추천 알고리즘을 삽입함으로써 자신들의 수입을 지키면서 중개자가 될 수 있도록 했습니다. NFT를 사용하면 여러분은 이러한 중개자를 완전히 제거할 수 있고, 창작자에게 근본적으로 더 나은 경제성을 제공하여 고객 구입 비용을 0에 가깝게 줄일 수 있습니다.

NFT는 어떻게 시작해야 하나요?

사람들이 디지털 상품을 사고 팔 수 있게 하는 NFT 중심으로 만들어진 시장들이 여럿 있습니다. MakersPlace.com, SuperRare.co, 그리고 Rarible.com은 디지털 NFT 예술작품에 특화된 사이트들입니다. Grimes, partner of Elon Musk, mother to X Æ A-12는 "Nfty Gateway"를 통해 NFT를 판매했지만 다른 것들도 많이 있습니다.

가장 비싼 NFT들은? 💸

Dragon the CryptoKitty는 이 우주에서 가장 비싼 가치를 지닌 NFT 중 하나인데, 대략 600이더리움의 가치를 가집니다.
농구 스타 LeBron James의 NBA 탑샷 디지털 수집 카드는 10만 달러에 판매되었습니다.
NFT 기반 게임인 Axie Infinity의 Angel인 Axie는 300 이더리움에 판매됐습니다.

결론

NFT는 여전히 아주 새롭습니다. 하나의 산업으로서 기술개선을 위해 해야 할 일이 많습니다. 여전히 우리가 직면하고 있는 가장 큰 문제는 굉장히 많은 트랜잭션을 지원할 수 있는 어플리케이션을 만드는 것입니다. NFT는 아직 상대적으로 메인스트림 사용자들이 접근할 수 없는데요. 현재는 얼리어답터나 투자자만이 블록체인 기반 플랫폼을 사용하고 있습니다. 우리는 NFT의 진입장벽을 낮추어야 합니다.

또한 비중앙화 어플리케이션보다 중앙화된 어플리케이션을 더 쉽게 확장할 수 있는 점또한 극복해야 할 장애물이 됩니다. 이 또한 우리가 적극적으로 해결하고 있는 문제입니다.

Klaytn을 이용하여 NFT 활용하기 : 발행부터 판매까지

클레이튼(Klaytn)

• 그라운드X에서 개발한 블록체인 플랫폼, 이더리움 기반
• 성능 측면 : 매 블록 당 4000 트랜잭션, 블록생성시간 1초
• BFT 컨센서스 알고리즘 도입
• 저렴한 트랜잭션 수수료

토큰 표준이 필요한 이유

클레이튼 계정 체계

• 클레이튼 상에서 다양한 계정이 생성될 수 있음, 사용자 계정일 수도 있고 스마트 컨트랙트 계정일 수도 있음
• 토큰 표준이 존재함으로써 쉽게 호출이 가능함. 누구나 쉽게 사용할 수 있는 스마트 컨트랙트...
• NFT -> KIP-17, KIP-37

NFT 사용자 시나리오

• 발행 전송 판매 전시
• 발행-전송 : KIP-17 함수 사용
• 판매 : 판매자와 구매자가 원하는 가격으로 매매할 수 있는 방법 (추가적인 서비스 레이어 기능 필요)
• 전시 : NFT 정보의 효율적 검색, 나의 NFT 전시 등

NFT 마켓플레이스 요구사항

• 추급권 : 최초 양도 이후 재판매될 때마다 수익의 일정부분 분배, 판매 즉시 추급권 적용
• 판매 방식 : 고정가, 경매
• 결제 수단 : KIP-7, KLAY
• 환불 : 구매 후 일주일간 환불기능 제공

추급권

• 대부분의 NFT 마켓플레이스에서 제공
• 표준화 되어 있지는 않음 (호환성X)
• 이더리움 2021.07.25 로열티에 대한 표준화 정립 진행 (클레이튼에서도 해당 표준에 대한 정립 필요)

다수의 추급권자는 어떻게 할 것인지에 대한 고려 부족

추급권 조회

• RoyaltyRouter : 모든 추급권을 조회할 수 있는 컨트랙트, 추급권 조회를 위해 이 컨트랙트만 알면 됨

NFT 마켓플레이스 설계/구현

• 고정값일 때 FixedPriceExchange > 환불 처리를 위한 Escrow 컨트랙트 필요

NFT 발행

1. minter(== 작가)는 서버에게 토큰에 해당하는 미디어, 메타데이터, RoyaltyInfo를 제공
2. 서버는 KIP-17 컨트랙트와 로열티인포 컨트랙트에 필요한 함수 호출 -> 새로운 NFT 발행

NFT 판매 등록 (KIP-7)

1. 판매등록을 하기 전에 해당 토큰의 전송 권한을 exchange contract에 부여 (approve)
2. 판매 등록 (가격과 주소 전달)

NFT 구매

1. 구매자가 KIP-7으로 transfer 함수 호출 (판매 대금 전송)
2. Received 함수 호출
3. 로열티 라우터를 통해 추급권 정보를 얻어옴
4. 이 정보를 바탕으로 정산 정보를 escrow에 전달
5. exchange 컨트랙트는 판매자로부터 구매자에게 해당 NFT 전송
6. 판매대금이 아직 escrow에 예치된 상태이고 일정 시간 후에 transfer가 호출되며 정산 진행

2021년 7월 28일에 작성된 Using BLoC Pattern with React을 읽고 번역한 글입니다.

처음에 BLoC(Business Logic Component) 패턴은 구글이 플러터 앱에서 상태를 관리하기 위한 방법으로 소개했습니다.
이 패턴은 컴포넌트에서 비즈니스 로직을 분리함으로써 UI 컴포넌트의 워크로드를 줄여줍니다.

시간이 지나며 다른 프레임워크 또한 BLoC 패턴을 지원하기 시작했습니다.
그리고 이 글에서는 리액트에서 BLoC 패턴을 사용하는 방법에 대해 이야기 해보고자 합니다.

리액트에서 BLoC 패턴을 사용하면 얻는 장점

BLoC 패턴 뒤에 있는 개념은 간단합니다. 위에서 볼 수 있듯이 UI 컴포넌트에서 비즈니스 로직을 분리합니다.
먼저 옵저버를 사용하여 BLoC에 이벤트를 보냅니다. 그 후 요청을 처리하면 UI 컴포넌트들은 BLoC의 옵저버블을 통해 알게 됩니다.

자, 이 접근법을 사용할 때의 장점을 자세하게 살펴봅시다.

1. 어플리케이션 로직을 업데이트하는 유연함

비즈니스 로직이 UI 컴포넌트로부터 독립적일 때 어플리케이션에 가해지는 영향도 작아질 것입니다.
UI 컴포넌트에 어떠한 영향을 주지 않고 비즈니스 로직을 변경하는 것도 가능합니다.

2. 로직의 재사용

비즈니스 로직이 한 군데에 있다면, UI 컴포넌트는 중복되는 코드 없이 로직을 재사용하여 앱의 단순함을 증가시킵니다.

3. 테스트가 쉬워짐

테스트케이스를 작성할 때 개발자들은 BLoC 자체에만 집중하면 됩니다. 코드베이스가 지저분해지지 않습니다.

4. 확장성

시간이 지나며 어플리케이션 요구사항은 변경될 수 있고 비즈니스 로직도 커지게 됩니다.
이런 상황에서 코드베이스의 명료함을 유지하고자 개발자들은 여러 BLoC를 생성할 수 있습니다.

게다가 BLoC 패턴은 플랫폼이나 환경에 종속되지 않아 개발자들은 다양한 프로젝트에서 동일한 BLoC 패턴을 사용할 수 있습니다.

개념에서 실전으로

BLoC 패턴의 사용성을 입증하고자 작은 카운터 앱을 만들어봅시다.

1단계 : 리액트 앱을 생성하고 구조를 만듭니다.

먼저 리액트 앱을 생성해야 합니다. 저는 이 앱을 bloc-counter-app이라 이름 짓겠습니다. 또한 rxjs도 사용하겠습니다.

// Create React app
npx create-react-app bloc-counter-app
// Install rxjs
yarn add rxjs

그 후 필요없는 코드를 모두 지우고 아래 목록에 따라 구조를 만듭니다.

• Blocs - 필요한 bloc 클래스 저장
• Components - UI 컴포넌트 저장
• Utils - 프로젝트의 유틸리티 파일 저장

2단계 : BLoC를 구현합니다

이제 BLoC 클래스를 구현해봅시다. BLoC 클래스는 비즈니스 로직과 관련된 모든 subject를 구현하는 역할을 합니다.
이 예시에서는 카운터 로직에 대한 역할을 수행하죠.

bloc 디렉토리 내에 CounterBloc.js라는 파일을 생성하고 pipe를 사용하여 UI 컴포넌트에 카운터를 전달했습니다.

import { Subject } from 'rxjs';
import { scan } from 'rxjs/operators';

export default class CounterBloc {
  constructor() {
    this._subject = new Subject();
  }

  get counter() {
    return this._subject.pipe(scan((count, v) => count + v, 0));
  }

  increase() {
    this._subject.next(1);
  }

  decrease() {
    this._subject.next(-1);
  }

  dispose() {
    this._subject.complete();
  }
}

클래스에는 간단한 로직만 있습니다. 그러나 앱의 사이즈가 커졌는데 비즈니스 로직을 분리하지 않았을 때 얼마나 복잡할지 상상해보세요.

3단계 : 중간 클래스로 BLoC에 아름다움을 더하세요.

이 단계에서 UI로부터 오는 카운터 요청을 다루기 위해 utils 디렉토리 내에 StreamBuilder.js 파일을 생성합니다.
게다가 개발자들은 에러를 처리하고 customer 핸들러를 구현해야 합니다.

class AsyncSnapshot {
  constructor(data, error) {
    this._data = data;
    this._error = error;
    this._hasData = data ? true : false;
    this._hasError = error ? true : false;
  }

  get data() {
    return this._data;
  }

  get error() {
    return this._error;
  }

  get hasData() {
    return this._hasData;
  }

  get hasError() {
    return this._hasError;
  }
}

AsyncSnapshot 클래스 내에서 생성자를 초기화하고 데이터를 다루고, 에러를 처리할 수 있습니다.
그러나 이 예제에서는 설명을 쉽게 하기 위해 단순히 데이터만 리턴합니다.

class StreamBuilder extends Component {
  constructor(props) {
    super(props);

    const { initialData, stream } = props;

    this.state = {
      snapshot: new AsyncSnapshot(initialData),
    };

    stream.subscribe(
      data => {
        this.setState({
          snapshot: new AsyncSnapshot(data, null),
        });
      }
    );
  }

  render() {
    return this.props.builder(this.state.snapshot);
  }
}

초기 데이터는 AysncSnapshot에 전달되어 각 구독마다 스냅샷 상태 내에 저장됩니다.
그 후 UI 컴포넌트 내에서 렌더될 것입니다.

import { Component } from 'react';

class AsyncSnapshot {
  constructor(data) {
    this._data = data;
  }
  get data() {
    return this._data;
  }
}

class StreamBuilder extends Component {
  constructor(props) {
    super(props);

    const { initialData, stream } = props;

    this.state = {
      snapshot: new AsyncSnapshot(initialData),
    };

    stream.subscribe(
      data => {
        this.setState({
          snapshot: new AsyncSnapshot(data, null),
        });
      }
    );
  }

  render() {
    return this.props.builder(this.state.snapshot);
  }
}

export default StreamBuilder;

주의 : UI 컴포넌트가 언마운트 될 때 모든 옵저버블로부터 구독을 해제하고 BLoC를 폐기해야 합니다.

4단계 : UI 컴포넌트를 구현합니다

increase()와 decrease() 메소드들은 UI 컴포넌트 내에서 바로 호출됩니다. 그러나 출력 데이터는 stream builder에 의해 다뤄집니다.

에러를 처리하기 위해 커스텀 핸들러를 구현하는 중간 층을 두는 것이 좋습니다.

import { Fragment } from 'react';

import StreamBuilder from '../utils/StreamBuilder';

const Counter = ({ bloc }) => (
    <Fragment>
        <button onClick={() => bloc.increase()}>+</button>
        <button onClick={() => bloc.decrease()}>-</button>
        <lable size="large" color="olive">
            Count:
            <StreamBuilder
                initialData={0}
                stream={bloc.counter}
                builder={snapshot => <p>{snapshot.data}</p>}
            />
        </lable>
    </Fragment>
);

export default Counter;

app.js 파일에서 BLoC는 CounterBloc 클래스를 사용하여 초기화됩니다.
그래서 Counter 컴포넌트는 BLoC를 prop으로 전달하여 사용됩니다.

// App.js
import React, { Component } from 'react';
import Counter from './components/Counter';
import CounterBloc from './blocs/CounterBloc';

const bloc = new CounterBloc();

class App extends Component {
  componentWillUnmount() {
    bloc.dispose();
  }
  render() {
    return (
      <div>
        <Counter bloc={bloc} />
      </div>
    );
  }
}
export default App;

이것이 전부입니다. 이제 여러분은 UI 컴포넌트 밖에서 비즈니스 로직을 분리된 엔터티로서 처리할 수 있고 변경할 수 있습니다.
이 예제 앱을 사용하고 개선시키고 싶다면 프로젝트 저장소를 참조하시고 PR을 날려주세요. 😃

정리

제 경험에 비추어 보면, BLoC 패턴은 작은 규모의 프로젝트에서는 오히려 오버헤드가 될 수 있습니다.
그러나 프로젝트가 커질수록 BLoC 패턴은 모듈화된 앱을 만드는 데 도움이 됩니다.

또한 rxjs에 대한 기본적인 이해와 어떻게 옵저버블이 BLoC 패턴을 구현하는지를 아는 것이 필요합니다.

저는 여러분에게 BLoC 패턴을 사용하도록 초대했으니 댓글에서 여러분의 생각을 공유해주세요.
읽어주셔서 감사합니다 !!!

Bit을 사용하여 독립적인 JS 컴포넌트를 생성하고 공유하세요

**Bit**은 독립적으로 작성되고 버전 관리되며 유지되는 컴포넌트를 사용하여 완전히 모듈화된 앱을 생성하도록 하는 확장 가능한 툴입니다.
모듈러 앱과 디자인 시스템을 설계하거나 마이크로 프론트엔드를 작성하고 제공하거나 앱 사이에서 컴포넌트를 공유할 때 사용해보세요.

2021년 7월 23일에 작성된 5 useEffect Infinite Loop Patterns을 읽고 번역한 글입니다.

일반적으로, 무한루프는 나쁜 상황입니다. 일부 엣지케이스에서는 무한루프 말고 다른 방법을 선택할 수 없을 때가 있습니다.
React의 무한루프 패턴을 알고 있는 것이 좋습니다.

무한루프가 중단 없이 작동될 때, 특히 브라우저는 여러분의 코드가 돌아가는 탭을 죽일 것입니다.
그러니 중단점 없이 Infinite Loop를 사용하지 마세요.

useEffect

useEffect는 컴포넌트에서 사이드 이펙트를 수행하게 합니다. React 16버전에서 소개되었을 때 다른 것보다 더 많이 인기를 끌었는데요. 라이프사이클 메소드인 componentDidMount, componentDidUpdate, componentWillUnmount를 결합한 기능을 제공했기 때문이죠.

useEffect는 의존성에 속한 값들이 변경되었을 때만 콜백함수를 트리거합니다. 그리고 변경을 체크할 때는 얕은 비교를 사용합니다.
여러분은 아마 useEffect를 아주 강력한 도구로 생각할 수 있고 실제로도 그렇기도 합니다.
하지만 여러분이 제대로 다루지 못하면 여러분을 파괴할 수도 있습니다.

의존성 없이

의존성 없는 useEffect는 나쁜 방법으로 고려되니 이렇게 작성하는 것은 지양하세요.
다음 코드에서 useEffect는 API를 평생 호출합니다.

useEffect(() => {
  fetch("/api/user")
    .then((res) => res.json)
    .then((res) => {
      setData(res);
    });
});

무슨 일이 발생하나요?

디펜던시가 변경되었을 때 useEffect가 콜백 함수를 호출할 때 여기에서 무한루프를 만나게 됩니다.

다른 무엇도 아닌React의 좌우명 "state나 props가 변경되었을 때 컴포넌트는 리렌더링된다"를 항상 기억해야 합니다.
이 코드에서 네트워크 호출이 성공했을 때 setData를 사용하여 상태 값을 설정하는데 이는 컴포넌트 리렌더링을 야기시킵니다.
useEffect는 비교할 값이 없으므로 또 다시 콜백을 호출하게 됩니다.

그리고 다시 fetch는 setData를 호출하고 setData가 호출되면 컴포넌트는 리렌더링되는데 이것이 반복됩니다.

어떻게 해결해야 하나요?

빈 배열로 의존성을 구체화해야 합니다.

useEffect(() => {
  fetch("/api/user")
    .then((res) => res.json)
    .then((res) => {
      setData(res);
    });
}, []); // <- dependencies

공식 문서에 따르면 디펜던시를 생략하는 것은 안전하지 않습니다.

의존값으로 사용되는 함수

useEffect는 데이터가 변경되었는지 확인할 때 얕은 비교를 수행합니다. 자바스크립트의 조건부 시스템 때문이죠. 😈

var mark1 = function(){ return ('100')}; // has a unique object reference
var mark2 = function(){ return('100')}; // has a unique object reference
mark1 == mark2; // false
mark1 === mark2; // false

다음 코드를 보시죠.

import React, { useCallback, useEffect, useState } from "react";
export default function App() {
  const [count, setCount] = useState(0);
  const getData = () => {
    return window.localStorage.getItem("token");
  }; 
  const [dep, setDep] = useState(getData());
  useEffect(() => {
    setCount(count + 1);
  }, [getData]);
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

함수 getData가 의존성 값으로 전달되었습니다.
이 코드를 실행하면 무한루프를 포함하고 있다는 Maximum update depth exceeded 에러를 뱉을 겁니다.

무슨 일이 발생했나요?

useEffect는 얕은 비교를 사용하므로 함수에 대한 얕은 비교는 언제나 false를 반환합니다.

어떻게 수정하나요?

이 문제를 해결하기 위해 우리는 useCallback을 사용해야 합니다.
useCallback은 콜백의 메모이제이션 버전을 반환하여 디펜던시가 변경되었을 때만 변경되는 함수입니다.

const getData = useCallback(() => {
    return window.localStorage.getItem("token");
  }, []); // <- dependencies

의존값으로 사용되는 배열

두 배열의 얕은 비교는 언제나 false를 리턴하므로 배열을 의존값으로 사용하는 것은 무한루프를 만들어 냅니다.
다음 코드를 보시죠.

import React, { useCallback, useEffect, useState } from "react";
export default function App() {
const [count, setCount] = useState(0);
  const dep = ['a'];
  const [value, setValue] = useState(['b']);
  useEffect(() => {
    setValue(['c']);
  }, [dep]);
  
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

여기 useEffect의 디펜던시로 dep이 전달되었습니다. 이 코드를 실행하면 브라우저 콘솔은 에러를 던집니다.

무슨 일이 발생하고 있나요?

두 배열에 대한 얕은 비교는 언제나 false이므로 useEffect는 언제나 콜백을 트리거합니다.

어떻게 수정하나요?

useCallback은 함수를 반환하므로 사용할 수 없습니다. 그렇다면? 우리는 useRef라는 다른 훅을 사용해야 합니다.

useRef은 초기값을 가지는 .current과 함께 변경 가능한 객체를 반환합니다.

import React, { useEffect, useState, useRef } from 'react';
export default function Home() {
  const [value, setValue] = useState(['b']);
  const {current:a} = useRef(['a'])
  useEffect(() => {
    setValue(['c']);
  }, [a])
}

의존값으로 사용되는 객체

두 객체의 얕은 비교는 언제나 false이므로 당연하게 useEffect는 콜백을 계속 호출합니다.

import React, { useCallback, useEffect, useState } from "react";
export default function App() {
  const [count, setCount] = useState(0);
  const data = {
    is_fetched:false
  };
  useEffect(() => {
    setCount(count + 1);
  }, [data]);
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

data는 useEffect의 디펜던시로 전달되었습니다. 이 코드를 실행하면 브라우저 콘솔에서 무한루프 에러를 뱉습니다.

무슨 일이 발생하고 있나요?

두 객체의 얕은 비교는 언제나 false이므로 useEffect의 콜백을 호출하게 되죠.

어떻게 수정하나요?

디펜던시를 메모이제이션하게 되면 무한루프를 중단시킬 수 있습니다. 그럼 어떻게 해야 할까요?
네, 또 다른 훅인 useMemo를 사용할 수 있습니다.

useMemo는 디펜던시가 변경되었을 때만 기억된 값을 재연산합니다.

import React, { useMemo, useEffect, useState } from "react";

export default function App() {
  const [count, setCount] = useState(0);
  const data = useMemo(()=>({
    is_fetched:false
  }), []); // <- dependencies
  useEffect(() => {
    setCount(count + 1);
  }, [data]);

  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <button onClick={() => setCount(count + 1)}>{count}</button>
      <h2>Start editing to see some magic happen!</h2>
    </div>
  );
}

잘못된 의존성

잘못된 의존성은 React, 심지어 javascript와 관계가 없습니다. 잘못된 의존성이 사용되는 것은 우리의 책임입니다.

import React, { useEffect, useState } from "react";
const App = () => {
  const [text, setText] = useState("");
  useEffect(() => {
    setText(text);
  }, [text]);
  return null;
};
export default App;

이 코드를 수정할 이유가 없기를 바랍니다. 수정해야 한다면 댓글로 알려주세요.

주목 : 리액트 컴포넌트 내에서 무한루프를 방지하기 위한 많은 방법들이 있지만 저는 일부만 소개했습니다.

언제나 eslint-plugin-react-hooks나 CRA를 사용하세요. 이는 프로덕션 서버에서 문제가 발생하기 전에 여러분들에게 알려줍니다.
어떤 회사는 무한루프 때문에 일주일 만에 72k를 잃었다고 합니다.

그러니 우리의 강력한 useEffect에게 특별히 신경을 써주세요.
또한 리액트에 관해 제가 작성한 최근 글도 같이 보시길 바랍니다.

1. API를 호출하는 동안 Fetch 대신 useQuery를 사용하기
2. API를 호출할 때 useState 대신 useSWR를 사용해야 하는 이유
3. React 앱에서 Axios를 사용하는 자세한 가이드

LINE NEWS에서 레이아웃 시프트 문제를 해결한 방법

LINE Akinori Inoue님 강연

• 라인 뉴스 탭 : 웹뷰(TypeScript, React) / (페이지에 따라 기술스택이 다름)
• Layout Shift 현상 : 일정시간동안 발생하는 레이아웃의 이동하는 것, 레이아웃이 콘텐츠의 로딩에 따라서 움직이는 현상 -> 잘못된 조작 유발

라인 뉴스 특징

• Personalization : 각 유저별로 보여주는 컨텐츠로 CDN 캐시를 사용할 수 없고, response time이 다른 API보다 늦어지게 됨
• A/B Testing : UI 컴포넌트 조합을 여러 개 준비해서 사용자군으로 다르게 보여줌
• Advertisements : 광고 API에는 각 유저별 키가 있어 response time이 늦어짐

Skeleton screen 적용

• 필요한 리소스를 읽을 때까지 컨텐츠의 틀을 보여주는 방법, 컨텐츠 리소스가 도착하면 스켈레톤과의 변경 -> 이동이 없어짐
• 단, 높이가 정확하게 동일해야 하는데 개인화된 컨텐츠에서는 어려움
• 화면 전체를 하나의 skeleton으로 덮어주게 해결
  • 페이드아웃 애니메이션을 디테일하게 조정
  • 스켈레톤 스크린을 출현 빈도가 높은 레이아웃으로 작성
  • 시선 집중이 가장 높은 부분은 실제와 동일하게끔

언제 Skeleton screen을 사라지게 할 것인지?

• 모든 API 요청이 올 때까지? 🙅🏽 20개가 넘는 API를 기다릴 수 없음
• 일부 API만 기다리기? 🙅🏽 개인화로 인해 유저마다 API가 달라짐
• 뷰포트에 들어가는 컨텐츠의 높이가 확정되었을 때

원문 : Garbage Collection in JavaScript

우리는 가비지(garbage)가 무엇인지 압니다. 가비지란 본질적으로 더 이상 필요없는 것을 의미합니다. 프로그래밍에서 가비지 콜렉션이란 사용하고 있지 않는 데이터의 메모리 공간을 정리하고 해당 메모리를 필요한 데이터의 메모리 공간으로 재할당합니다. 이는 거의 모든 프로그래밍 언어에서 가비지 컬렉션의 기본적인 과정입니다. 일부 프로그래밍 언어는 개발자가 직접 개입해야 하지만 어떤 언어들은 자동으로 실행됩니다. C언어 같이 저수준 프로그래밍 언어는 개발자가 더 이상 필요없는 변수나 객체들에 대해 malloc()와 free()와 같은 메소드를 사용하여 직접 메모리를 풀어주어야 합니다. 메모리를 해제하는 것은 개발자의 특권이며 메모리를 해제할 것인지를 결정하는 것은 개발자 손 안에 있습니다. 그러나 항상 그런 것만은 아닙니다. 자바스크립트와 같이 고수준 프로그래밍 언어에서는 메모리 관리 프로세스가 자동적으로 이루어집니다. 브라우저가 알아서 해줍니다.

이 섹션에서는 아래 내용을 살펴보겠습니다.

1. 메모리 관리 라이프사이클
2. 가비지 컬렉션 알고리즘
3. 메모리 누수의 위험

관리 프로세스를 더 잘 이해하기 위해 먼저 메모리 관리의 일반적인 라이프사이클을 보겠습니다.

• 먼저 변수와 객체가 생성될 때마다 메모리 공간이 할당됩니다.
• 그 다음으로는 할당된 메모리가 Read/Write 작업을 통해 사용됩니다.
• 메모리가 더 이상 필요하지 않을 때 해당 공간이 해제됩니다.

마지막 단계가 가비지 컬렉션 메커니즘이라고 불립니다. 자바스크립트에서는 자동으로 진행되며 가비지 컬렉터라고 불리는 개체가 수행합니다. 우리가 물리적으로 브라우저 엔진에서 직접 찾을 수는 없지만 말입니다. 가비지 컬렉터의 목적은 메모리 할당을 감시하고 특정 메모리가 더 이상 필요없는지 결정하는 것입니다. 더 이상 필요 없다면 메모리를 되찾습니다. 그러나 가비지 컬렉션 메커니즘은 할당된 메모리의 특정 블록이 유용하지는 결정할 수 없기 때문에 항상 근사치의 값을 가집니다.

자바스크립트에서 가비지 컬렉션 메커니즘은 아래 두 가지 알고리즘에 의해 제어됩니다.

1. 참조 카운팅 알고리즘
2. Mark and Sweep 알고리즘

하나씩 살펴봅시다.

참조 카운팅 알고리즘

먼저 참조가 무엇인지 이해해봅시다. 두 개의 객체가 주어졌을 때 한 객체가 다른 객체의 메소드나 속성에 접근할 수 있는 경우 이 객체는 다른 객체에 대한 참조값입니다. 그럼 알고리즘으로 옮겨갑시다. 참조 카운트 알고리즘은 매우 간단하고 다른 객체에 의해 참조되는지 아닌지에 따라 어떤 객체의 유용성을 결정합니다. 어떤 객체가 다른 객체에 참조되지 않는다면 가비지 값으로 간주하고 수집합니다. 간단한 예시는 아래를 보세요.

var obj = { // first object created 
 property1: { // second object created
 property2 : 10
 }
}

두 객체가 생성되었고 한 객체는 다른 객체의 프로퍼티를 참조합니다. 다른 객체는 obj 객체에 할당되어 참조됩니다. 참조를 하고 있으므로 가비지 컬렉션의 범위가 아닙니다.

var newObj = obj; // 존재하는 객체에 대한 새로운 객체가 있습니다.
obj = 10; // `obj`는 `newObj` 값에 의해 여전히 참조되므로 GC의 대상이 아닙니다.

다른 구현을 봅시다.

var anotherObj = newObj.property1;

property1은 두 개의 참조를 가집니다. 하나는 newObj 변수의 프로퍼티이고 다른 하나는 anotherObj 변수로부터 참조됩니다. 따라서 가비지 콜렉션의 대상이 아닙니다.

newObj = ‘Some string’;

obj 변수에 의해 생성된 객체는 더 이상 참조를 가지지 않습니다. 그러나 property1이 anotherObj 변수에 의해 참조되므로 가비지 컬렉션의 대상이 되지 않습니다.

anotherObj = null;

이제 어디에서도 property1 객체에 대해 참조하지 않습니다. 이 상화에서 객체는 가비지 컬렉션의 대상이 됩니다.

참조 카운팅 알고리즘은 본질적으로 너무 나이브해서 완전히 의존할 수는 없습니다. 아래의 예에서 참조 알고리즘의 힘이 크지 않습니다.

function foo() {
   var obj1 = {};
   var obj2 = {}; 
   obj1.a = obj2; 
   obj2.a = obj1;
   console.log(obj1);
   console.log(obj2);
}
foo();

출력되는 객체를 통과해보세요. 중첩된 속성들이 보이시나요? 이는 순환 참조라고 불리는 것입니다. 이 경우에서 참조 카운팅 알고리즘은 서로를 참조하는 중첩된 객체들에게 처참히도 실패합니다. 따라서 이 알고리즘을 사용했을 때 가비지 컬렉션을 할 가능성이 없습니다. 이는 다음에 살펴볼 Mark and Sweep 알고리즘으로 이어집니다.

Mark and Sweep 알고리즘

Mark and Sweep 알고리즘은 객체들에 도달하는 방법으로 GC 메커니즘을 구현합니다. 어떤 객체가 도달할 수 없는 거라면 가비지로 인식하여 수집됩니다. 알고리즘은 어떤 객체가 전혀 참조되지 않는다면 도달할 수 없다는 원리를 따르기 때문에 해당 객체를 가비지로 취급합니다.
이 과정은 window와 같이 루트 객체를 식별하고 거기서부터 모든 자식 객체들, 그리고 객체들의 자식들을 순회합니다. 이 과정에서 도달할 수 없는 일부 객체들이 있다면 그 객체들은 가비지로 수집되고 메모리를 해제합니다. 이 알고리즘은 효과적으로 순환 참조 문제를 해결합니다.

메모리 누수의 문제

개발자들은 메모리 누수를 방지하기 위해 많은 것들을 합니다. 메모리 누수를 일으키는 아주 일반적인 원인들은 아래와 같습니다.

1. 지나치게 전역변수를 많이 생성하고 로컬 스코프에서 var 키워드를 생략하여 사용하는 경우
2. setInterval()과 같은 타이머를 클리어하지 않는 경우
3. 클로저를 불필요하게 사용하는 경우 (클로져는 부모 함수가 다 실행됐음에도 부모 함수로부터 변수를 받아 항상 참조함)

따라서 우리는 위와 같은 실수들을 피해야만 합니다.

이 글은 자바스크립트에서 굉장히 간단하게 가비지 컬렉션 과정을 살펴봤습니다. 이 토픽은 굉장히 방대하지만 더 큰 지식을 위한 출발점입니다.

참고

• V8의 히든 클래스 이야기
• Writing Optimized Code in JS By Understanding Hidden Classes

원문 : Making Sense of React Hooks을 읽고 번역한 글입니다.

이번주에 Sopie Alpert와 저는 리액트 컨퍼런스에서 "Hooks" 세션에서 발표했고, Ryan Florence의 심층적인 설명을 들었습니다.

저는 Hooks proposal로 해결하고자 하는 문제들을 보기 위해 이 오프닝 키노트를 보시는 것을 강력하게 추천합니다. 그러나 1시간은 꽤 큰 투자이기 때문에 아래에서 몇 가지 Hooks에 대한 생각들을 공유하고자 합니다.

주목 : Hooks는 리액트에서 실험적인 제안입니다. 지금 당장 배울 필요는 없습니다. 또한 이 포스팅은 저의 개인적 견해를 담고 있으며 리액트 팀의 입장을 모두 반영하는 것은 아닙니다.

왜 Hooks인가요?

컴포넌트와 top-down 방식의 데이터 흐름이 큰 UI를 작고 독립적이며 재사용가능한 단위로 나눌 수 있게 한다는 것을 알고 있습니다. 그러나, 우리는 로직이 상태에 연관되어 있거나 함수나 다른 컴포넌트로 분리할 수 없기 때문에 복잡한 컴포넌트를 쪼갤 수 없는 경우가 많습니다. 때때로 사람들은 React에서 "관심사 분리"를 하지 못한다고 하죠.

이런 경우들은 아주 흔하고 애니메이션이나 폼 핸들링, 외부 데이터 소스와 연결되는 경우 등 우리가 컴포넌트로 하고 싶은 많은 것들을 포함합니다. 이러한 경우를 컴포넌트로만 해결하려고 하면 다음과 같은 결과가 생겨납니다.

• 리팩토링과 테스트하기 어려운 거대한 컴포넌트
• 다른 컴포넌트들과 라이프사이클 메소드 사이의 중복되는 로직
• props 렌더나 고차 컴포넌트와 같은 복잡한 패턴

이런 문제들을 해결하기 위한 가장 좋은 방법을 Hooks라고 생각했습니다. Hooks는 컴포넌트 내부의 로직을 재사용 가능하며 분리된 단위로 조직하는 것이 가능합니다. Hooks은 리액트 철학(명시적인 데이터 흐름과 구성)을 컴포넌트 _사이_가 아닌 컴포넌트 내부에 반영합니다. 제가 Hooks가 React 컴포넌트 모델과 자연스럽게 잘 부합한다고 느낀 이유입니다.

props의 렌더나 고차 컴포넌트와 같은 패턴과 다르게 Hooks는 여러분의 컴포넌트 트리에서 불필요한 중첩을 만들지 않습니다. mixin의 단점으로부터 고통받지 않아도 되죠.

(제가 그랬던 것처럼) 여러분이 처음에는 본능적으로 거부하고자 한다 해도, 일단은 시도해보고 다뤄보기를 권합니다. 아마 좋아하실 겁니다.

Hooks이 리액트를 어렵게 만드나요?

Hooks에 대해 자세히 알아보기 전에는 Hooks을 사용하면 더 많은 컨셉을 더해야 한다고 우려하실 수도 있습니다. 합리적인 비판입니다. Hooks을 배우는데 단기적으로는 인지적 비용이 들기는 하겠지만, 최종 결과로는 그 반대가 될 것입니다.

리액트 커뮤니티가 Hooks를 잘 수용한다면, Hooks은 리액트 어플리케이션을 작성하면서 필요한 개념의 수를 줄일 것입니다. Hooks은 함수, 클래스, 고차 컴포넌트, props 렌더 사이에 끊임없이 스위칭할 필요 없이 함수만 사용하면 되게끔 합니다.

구현 사이즈의 관점에서 Hooks은 ~1.5kB만 증가시킬 뿐입니다. 클래스를 작성하여 코드를 작성하는 것보다 Hooks를 채택하여 코드를 작성할 때 코드의 양을 줄일 수 있으므로 Hooks는 결국 여러분의 번들 사이즈를 줄일 수 있습니다. 아래 예시는 다소 극단적이지만 Hooks를 채택해야 하는 이유를 효과적으로 보여줍니다.

원문에서 예시가 사라짐

Hooks를 채택하여 새로운 컴포넌트를 Hooks 기반으로 작성해도 현재 코드에 영향을 주지 않습니다. 사실은 우리가 Hooks를 권장하는 이유는 코드의 재작성이 필요없기 때문입니다. 중요한 코드에서 Hooks로 작성하고 기다리는 것이 좋습니다. React 16.7 알파버전으로 실험해보시고 피드백이 있거나 버그가 있으면 제보해주신다면 감사하겠습니다.

Hooks가 정확히 무엇인가요?

Hooks를 이해하기 위해서 한 걸음 돌아가 코드의 재사용에 대해 생각해보아야 합니다.

오늘날 리액트 앱에서 로직을 재사용하는 방법은 여러 가지가 있습니다. 간단한 함수들을 작성해서 무언가를 연산할 때 함수들을 호출할 수 있습니다. 또한 컴포넌트를 작성할 수도 있죠. 컴포넌트는 더 강력하지만 UI를 렌더링해야 합니다. 이는 시각적이지 않은 로직을 공유할 때 불편합니다. 그래서 render props나 고차 컴포넌트와 같은 복잡한 패턴이 만들어진 것입니다. 많은 코드를 재사용하는 대신 하나의 공통적인 재사용 방법이 있다면 더 간단하지 않을까요?

함수는 코드 재사용에 있어 완벽한 메커니즘으로 보입니다. 함수 사이에 로직을 이동시키는 것은 적은 노력이 듭니다. 그러나 함수 내부에서 React의 로컬 state를 사용할 수 없습니다. 코드를 재구성하거나 옵저버블과 같은 추상화를 도입하지 않는다면 클래스 컴포넌트로부터 "윈도우 사이즈를 보고 상태를 업데이트"하거나 "시간이 지나면서 값 변경하기"와 같은 동작을 꺼내올 수 없습니다. 두 접근법은 리액트의 단순한 성질을 해치게 되죠.

Hooks는 그 문제를 정확하게 해결합니다. Hooks는 함수로부터 리액트 기능을 사용하게 합니다. 리액트는 상태, 라이프사이클, 컨텍스트와 같은 "구성요소"를 노출하는 몇 가지 빌트인 Hooks를 제공합니다.

Hooks는 일반적인 자바스크립트 함수이므로 여러분은 리액트에서 제공하는 빌트인 Hooks와 여러분의 "커스텀 훅"을 결합할 수 있습니다. 이는 복잡한 문제를 한 줄로 해결하고 여러분의 어플리케이션이나 리액트 커뮤니티에 공유할 수 있습니다.

커스텀 훅은 기술적으로는 리액트의 미래가 아닙니다. 여러분의 훅을 작성할 수 있는 것은 Hooks이 설계된 것을 자연스럽게 따라간 결과물입니다.

코드를 보여주세요!

컴포넌트를 현재 윈도우 width에 구독한다고 가정해봅시다. (좁은 뷰포트에 다른 컨텐츠를 보여준다고 가정)

이런 코드를 작성하는 방법은 여러 가지가 있습니다. 클래스를 작성하거나 라이프사이클 메소드를 사용하거나 또는 컴포넌트 사이에 재사용을 하고 싶다면 render prop, 고차 컴포넌트도 방법에 포함되죠. 하지만 이 방법보다 더 좋은 방법은 없다고 생각합니다.

function MyResoponsiveComponent() {
    const width = useWindowWidth(); // custom hook
    return (
        <p>window width is {width}</p>
    )
}

이 코드를 읽으신다면 무엇을 하고자 하는지 바로 알 수 있습니다. 컴포넌트 내에서 _window width_를 사용하고, 리액트는 해당 값이 변경될 때마다 컴포넌트를 다시 렌더링합니다. 컴포넌트에 상태나 사이드 이펙트가 있더라도 컴포넌트를 진정한 선언적으로 만드는 것이 Hooks의 목표입니다.

이 커스텀 훅을 구현하는 방법을 살펴봅시다. 현재 window width를 유지하도록 React 로컬 상태 를 사용하고, window 사이즈가 변경되면 상태 값을 설정하도록 사이드 이펙트 를 사용합니다.

import { useState, useEffect } from 'react';

function useWindowWidth() {
    const [width, setWidth] = useState(window.innerWidth);
    
    useEffect(() => {
        const handleResize = () => setWidth(window.innerWidth);
        window.addEventListener('resize', handleResize);
        return  () => {
            window.removeEventListener('resize', handleResize);
        }
    });
    
    return wudth;
}

위에서 봤듯이 useState 와 useEffect 와 같은 빌트인 리액트 Hooks가 기본 구성 요소로 제공됩니다. 컴포넌트로부터 직접적으로 사용할 수 있고 useWindowWidth 같은 커스텀 훅과 같이 사용할 수 있습니다. 커스텀 훅을 사용하는 것이 더 관용적으로 느껴집니다.

빌트인 Hooks에 대해 더 알고 싶다면 이 개요를 참고하세요.

Hooks은 완전히 캡슐화 되어 있어, 여러분이 Hook을 호출할 때마다 Hook은 실행하는 컴포넌트 내에 독립적인 로컬 상태를 가집니다. 우리 예시에서는 중요하지는 않지만 이 특징이 Hooks를 강력하게 만들어 줍니다. 상태 를 공유하는 방식이 아니라 상태 저장 논리 를 공유하는 방식입니다. top-down 데이터 흐름을 망치지 않습니다.

각 Hook은 로컬 상태와 사이드 이펙트를 가집니다. 일반적으로 함수들 사이에서 하듯이 여러 Hooks 사이에 데이터를 전달할 수 있습니다. Hooks는 자바스크립트 함수이기 때문에 인수를 받아 값을 반환합니다.

Hooks 사이에 데이터를 전달할 수 있는 것은 애니메이션, 데이터 구독, 폼 관리, 그리고 다른 상태 추상화를 표현하는 데 잘 들어 맞습니다. render props나 고차 컴포넌트와 다르게 Hooks는 렌더 트리에 "false hierarchy"를 만들지 않습니다. 컴포넌트에 부착된 평평한 "메모리 셀" 리스트에 더 가깝습니다. 추가적인 레이어를 만들지 않습니다.

그러면 클래스에서는 어떻게 하나요?

우리의 의견으로는 커스텀 훅이 Hooks 제안에서 가장 매력적인 요소입니다. 그러나 Hooks를 사용하기 위해서 React는 상태와 사이드 이펙트를 선언할 방법으로 함수를 제공해야 합니다. 그리고 useState 와 useEffect 가 실제로 하는 방식이죠. 이 문서에서 이 Hooks에 대해 더 배울 수 있습니다.

빌트인 Hooks가 커스텀 훅을 생성할 때만 유용한 것은 아닙니다. Hooks는 또한 일반적으로 컴포넌트를 정의하는 데 있어 사용 가능하고 상태와 같이 필요한 기능들을 제공합니다. 미래에 리액트 컴포넌트를 정의하는 데 있어 Hooks가 1차적인 방법이 되기를 원하는 이유입니다.

클래스를 없앨 계획은 없습니다. 여러분과 마찬가지로 페이스북에서도 무수히 많은 클래스 컴포넌트를 사용하고 있고 이를 재작성하고 싶지 않습니다. 그러나 리액트 커뮤니티에서 Hooks를 받아들인다면, 컴포넌트를 작성하는 데 두 가지 방법을 둘 필요가 없습니다. Hooks는 클래스의 모든 상황을 다 커버할 수 있습니다. 오히려 추출, 테스팅, 코드 재사용 면에 있어 더 유연함을 보여줍니다. 리액트의 미래에서 Hooks를 우리의 비전으로 제시하는 이유입니다.

Hooks는 마법이 아닌가요?

Hooks의 규칙에 놀라셨을 수도 있습니다.

Hooks는 탑 레벨에서 호출하는 것은 일반적이지 않지만, 가능한 경우에도 상태를 정의하고 싶지 않을 수 있습니다. 예를 들어 클래스에서 상태를 조건부로 정의할 수 없고 리액트 사용자에게도 이런 불만을 들은 적은 없습니다.

이러한 설계는 추가적인 구문이나 여러 함정을 만들지 않고 커스텀 훅을 활성화하는 데 아주 중요합니다. 처음에는 생소할 수 있지만 결국은 Hooks만의 기능이 가지는 가치로 트레이드 오프 할 수 있다고 생각합니다. 동의하지 않으신다면 일단 연습으로 갖고 놀아보면서 마음이 바뀌시는지 확인해보시길 바랍니다.

저희는 엔지니어들이 Hooks의 규칙에 혼란스러워 하지 않는지 확인해보고자 한달동안 실제 개발할 때 사용하고 있습니다. 실제로 개발자들이 몇 시간 안에 익숙해진다는 것을 발견했습니다. 개인적으로 저도 처음에 규칙들이 잘못되었다고 느꼈기는 하지만 금방 극복했습니다. 이 경험은 리액트를 처음 경험했을 때와 비슷했습니다. (바로 리액트를 좋아하셨나요? 저는 두 번 해보고 좋아했습니다.)

Hooks의 구현에 있어 "마법"은 없습니다. Jamie가 지적한 바와 같이 이것은 아래와 비슷해 보입니다.

원문 : https://javascript.plainenglish.io/proto-vs-prototype-in-js-140b9b9c8cd5
부제 : An explanation of the relationship between the two concepts.

prototype에 대한 설명

애플은 최근에 새로운 아이폰 모델인 iPhone 11을 출시했습니다. 그 모델은 특정한 기능을 가지는데 예를 들어 Face ID와 4K 비디오같은 것들이죠. 모든 아이폰 11은 동일한 기능들을 가지고 있습니다. 그렇다면, 새로운 아이폰 11이 호출될 때마다 아이폰11을 만드는 생성자 함수가 있다고 가정해봅시다. 적절하게 아이폰 11을 만들기 위해 모델을 참고하는 _prototype_이 필요합니다. 이 프로토타입 또는 모델은 모든 아이폰이 Face ID를 가지며 4K 비디오를 찍을 수 있도록 보장합니다. 따라서 아이폰 생성자는 반드시 제작해야 하는 프로토타입을 알고 접근해야 합니다. 이것이 생성자의 prototype 프로퍼티입니다.

function iPhone() {}; // 생성자

// a method for recognizing faces
iPhone.prototype.faceID = function() { ... };

// a method for taking 4k video
iPhone.prototype.video = function() { ... };

let newPhone = new iPhone(); // 아이폰11

여기까지 이해가 되셨나요? 그럼 __proto__에 대해 알아봅시다.

__proto__와 prototype의 관계

새로운 iPhone 11을 만들고 newPhone이라는 변수에 저장했습니다. newPhone의 내용물은 아래와 같을 겁니다.

이 아이폰11은 FaceID와 video 기능이 있는 것 같습니다! 사실 여러분은 newPhone.faceID()나 newPhone.video()를 실행할 수 있고 이 메소드들이 잘 동작하는 걸 볼 수 있습니다. 그러나 이런 함수들이 __proto__라는 객체에 저장되고 직접적으로 newPhone의 프로퍼티로 저장되지 않는 것일까요?

__proto__는 생성된 프로토타입을 가리키는 모든 클래스 _인스턴스_의 객체입니다. newPhone.__proto__는 iPhone.prototype에 대한 참조이고 따라서 정확히 동일한 것들을 지니고 있습니다. iPhone.prototype과 동일한 proto 프로퍼티를 가짐으로써, newPhone은 본질적으로 "보세요, 저는 아이폰11이라서 다른 아이폰11과 동일한 기능을 가지고 있어요! 페이스 아이디, 4K 화질 등 뭐든요." 라고 말하는 것과 같죠.

현실세계에서 prototype과 __proto__의 유일한 진짜 차이점은 전자는 클래스 생성자의 프로퍼티라는 점이고 후자는 클래스 인스턴스의 프로퍼티라는 점입니다. 다른 말로 말하면 iPhone.prototype은 iPhone을 만드는 청사진을 제공하며, newPhone.__proto__는 그 청사진에 따라 인스턴스가 만들어졌다는 것을 말해줍니다. 두 객체에 존재하는 프로퍼티들과 메소드에 대해서는... 음 정확히 같습니다.

마지막으로, 여러분은 위 이미지의 마지막 라인에 있는 proto: Object의 뜻에 대해 궁금하셨을 겁니다. newPhone.__proto__는 사실 자바스크립트 객체이기 때문에 자바스크립트 객체들 또한 특정한 "청사진"으로부터 만들어진 것입니다. 이 예시에서 newPhone.__proto__.__proto__는 Object.prototype을 나타냅니다. 이는 모든 자바스크립트 객체가 기반으로 하는 프로토타입이죠. 그게 다입니다!

원문 : How return await can slow down your code

리턴하기 전에 프로미스를 await하는 것은 여러분의 코드를 느리게 만듭니다.

요약: ESLint no-return-await rule을 사용하세요

큰 스케일의 어플리케이션 개발의 주요 패러타임은 고수준의 언어로 프로그래밍을 하는 것입니다. 고수준의 언어는 개발을 빠르게 하는 대신 런타임에서 속도가 느리다는 트레이드오프가 있습니다. 우리의 경우에서는 그 언어로 자바스크립트를 선택한 것이죠.

여러분은 아마 "진짜 성능이 중요했다면, Rust로 코드를 짰겠지" 라고 생각하실 수도 있지만 그렇게 자바스크립트가 느린 건 아닙니다. NodeJs 는 대부분의 상황에서 개발과 런타임 속도 충분히 빠릅니다. Techempower 벤치마크 결과 또한 NodeJs가 충분히 좋은 결과를 보여주는 것을 알려줍니다.

Web API같은 여러분의 코드를 1퍼센트라도 성능을 향상시킬 수 있다면, 초당 9천개의 요청을 처리할 경우 800개를 추가로 처리할 수 있다는 뜻이죠. 그리고 그건 오늘의 성능 으로 연결됩니다.

리턴하기 전에 프로미스를 await하기

다른 비동기 함수 호출을 감싸고 기다리도록 함수를 짜는 것은 비동기 자바스크립트 프로그래밍에서 아주 흔한 패턴입니다.

async function example() {
  const server = await createServer();
  const endpoints = await createEndpoints(server);

 return await startServer(server, endpoints);
}

보시다시피 위의 함수는 return 문 전에 await를 실행합니다. 그리고 그 부분이 까다롭게 만드는 부분입니다.
문제를 깊게 설명하기 전에 이것이 얼마나 느리게 만드는지 보여주는 간단한 벤치마크를 만들어보겠습니다.

benchmark

여기서 사용하는 모든 코드는 [arthur-place/the-cost-of-return-await](https://github.com/arthur-place/the-cost-of-return-await) 깃허브 저장소에 있습니다.

메인 함수인 work()는 setImmediate 함수가 호출되자마자 resolve되는 프로미스를 반환합니다. 그리고 다른 3개의 함수가 있는데 이 함수들은 동일한 결과를 만들지만 하나는 비동기이며 await을 사용합니다. 다른 하나는 그냥 비동기이고 마지막 하는 단순히 return 문만 사용합니다.

// function work(): Promise<any>;

async function doWait() {
  return await work();
}

async function dontWait() {
  return work();
}

function justReturn() {
  return work();
}

실제로는 자바스크립트가 더 이전의 EcamScript 버전으로 트랜스파일되는데 그 점이 우리가 하고자 하는 것입니다.

빌드 대상과 생성된 코드

간단한 테스트를 만들어 동일한 소스 파일을 ES3에서 ES2022까지 트랜스파일했습니다. 아래에 각 결과물들의 차이점이 있습니다.

function doWait() {
  return _doWait.apply(this, arguments);
}

function _doWait() {
  _doWait = (0, _asyncToGenerator2['default'])(
    /*#__PURE__*/ _regenerator['default'].mark(function _callee() {
      return _regenerator['default'].wrap(function _callee$(_context) {
        while (1) {
          switch ((_context.prev = _context.next)) {
            case 0:
              _context.next = 2;
              return work();

            case 2:
              return _context.abrupt('return', _context.sent);

            case 3:
            case 'end':
              return _context.stop();
          }
        }
      }, _callee);
    })
  );
  return _doWait.apply(this, arguments);
}

function dontWait() {
  return _dontWait.apply(this, arguments);
}

function _dontWait() {
  _dontWait = (0, _asyncToGenerator2['default'])(
    /*#__PURE__*/ _regenerator['default'].mark(function _callee2() {
      return _regenerator['default'].wrap(function _callee2$(_context2) {
        while (1) {
          switch ((_context2.prev = _context2.next)) {
            case 0:
              return _context2.abrupt('return', work());

            case 1:
            case 'end':
              return _context2.stop();
          }
        }
      }, _callee2);
    })
  );
  return _dontWait.apply(this, arguments);
}

function doWait() {
  return __awaiter(this, void 0, void 0, function () {
    return __generator(this, function (_a) {
      switch (_a.label) {
        case 0:
          return [4 /*yield*/, work()];
        case 1:
          return [2 /*return*/, _a.sent()];
      }
    });
  });
}

function dontWait() {
  return __awaiter(this, void 0, void 0, function () {
    return __generator(this, function (_a) {
      return [2 /*return*/, work()];
    });
  });
}

function doWait() {
  return __awaiter(this, void 0, void 0, function* () {
    return yield work();
  });
}

function dontWait() {
  return __awaiter(this, void 0, void 0, function* () {
    return work();
  });
}

async function doWait() {
  return await work();
}
async function dontWait() {
  return work();
}

제 컴퓨터는 아래의 스펙사항을 가지고 있습니다.

• Node v16.14.0
• NVM 0.39.1
• i5 9600K @5ghz OC
• 32GB @ 32mmMhz
• 1TB SSD PCIe 4.0

벤치마크 결과

아마 여러분들은 Es6가 왜 이렇게 느린지 궁금해하실 수도 있겠습니다. 저의 간단한 실험결과는 tslib generator 폴리필(__generator)은 Node 17 native function*과 yield보다 빠르다는 것을 보여줍니다. 그렇지만 이건 또 다른 얘기죠.

왜 return await이 잘못된걸까?

Babel, ES5, ES6으로 트랜스파일된 것들은 각기 다른 성능을 보여줄 것이라고 예상됩니다. 각각 다른 폴리필과 ECMAScript 버전을 사용하기 때문에 명백한 일입니다.
간단히 말해서, await은 말 그대로 기다리고 있습니다. 평가된 결과를 리턴하기 전에 프로미스가 끝나기를 기다리는 것이죠.
또한 기다리고 있는 결과 자체는 프로미스와 같은 대상일 것이라고 예상하므로 await(promise)와 await(non-promise)는 동일한 동작을 하게 되는 겁니다.
NodeJS Event Loop는 이미 지정된 코드 라인이 현재의 iteration이 끝날 때 실행되도록 스케쥴링을 했습니다. 그런 다음에야 나머지를 실행하고 내부 프로미스나 일들에 대해 기다리게 됩니다.

위의 제 주장을 뒷받침할 수 있는 간단한 방법이 있습니다.

async function withAwait() {
  console.log(1);

  // This will make nodejs wait for the
  // end of the current loop. Because it
  // "expects" that a promise was given
  // in place of 0
  await 0;

  console.log(2);
}

async function withoutAwait() {
  console.log(3);
}

withAwait();
withoutAwait();

$ node example.js
#> 1
#> 3
#> 2

다시 벤치마크 얘기로 돌아가서, 앞서 얘기한 1%가 있습니다. 그 1%는 10,000ops/s에서 100이 될 수도 있고 심지어는 1,000,000 ops/s인 서버에서 10,000이 될 수도 있습니다. 단순히 await 키워드를 잘못 사용함으로써 여러분의 함수가 반복되는 플로우를 여러번 중단된다는 것을 알 수 있죠. return문이 적절하게 사용될 때마다 세이브되는 각 밀리초들이 더해져 초당 더 많은 작업들을 할 수 있게 만듭니다. return await을 피하는 것은 성능을 향상시키는 좋은 방법입니다.

예외 처리

이전에 발했듯이, 프로미스를 리턴하기 전에 기다릴 필요가 없다면, 즉시 반환됩니다.Chain of Responsibility과 비슷하게 말입니다. 즉 리턴하는 것에 책임을 지는 대신 함수의 호출자에게 책임을 넘기게 되는데요. 이런 경우 Try-Catch Blocks을 사용하는 것이 좋습니다.

// Correct usage of `return await`
async function fn() {
  try {
    return await work();
  } catch (err) {
    return handleWorkError(error);
  }
}

위의 예시에서 await 키워드를 제거해본다면 아래와 같습니다.

// return await work();
return work();

함수 내에서 어떤 예외를 직접 throw한다 하더라고 catch 블록은 호출되지 않습니다. work() 함수가 리턴하는 프로미스는 fn() 호출자에게 자신을 처리하는 책임을 직접 전달해주기 때문입니다. fn() 함수를 호출하는 외부에 try-catch 블록을 두면, 내부 fn() catch 블록은 실행되지 않고 외부에 있는 블록만 실행됩니다.

가장 간단한 해결책

위의 예외사항을 무시하고, 여러분들은 간단히 await을 제거하시면 됩니다. 만약 ESLint를 사용하고 있다면(사용하지 않는다면 사용하세요) no-return-awaitrule을 켜두시면 됩니다.

Zero cost async 스택 추적

여러분들이 좋은 독자라면 아마 no-return-await에 대해 읽었을 것이고 스택 추적을 보존하는 것에 대해서도 보셨을 겁니다. 그렇지 않았더라도 제가 설명드리겠습니다.

요약하자면, 프로미스를 리턴하고 호출자가 예외를 처리하게 되면 스택 추적에 대한 손실(loss)가 발생하는 문제를 맞이하게 됩니다. 간단한 예시를 보여드리겠습니다.

async function foo() {
  await bar();
  return 42;
}

async function bar() {
  await Promise.resolve();
  throw new Error('BEEP BEEP');
}

foo().catch((error) => console.log(error.stack));

$ node index.js
Error: BEEP BEEP
  at bar (index.js:8:9) --> (ONLY SHOWS BAR) <--
  at process._tickCallback (internal/process/next_tick.js:68:7)
  at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
  at startup (internal/bootstrap/node.js:266:19)
  at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)
But as written on the official [v8.dev](https://v8.dev/blog) blog, they solved this problem with something called [zero-cost async stack traces](https://bit.ly/v8-zero-cost-async-stack-traces) and now you can see the exact stack trace in the console:

그러나 v8.dev 공식 블로그에 쓰인 것처럼 zero-cost async stack traces를 통해 이 문제를 해결했으며 여러분들은 이제 콘솔에서 정확한 에러 스택을 확인할 수 있습니다.

$ node index.js

Error: BEEP BEEP
   at bar (index.js:8:9)
   at process._tickCallback (internal/process/next_tick.js:68:7)
   at Function.Module.runMain (internal/modules/cjs/loader.js:745:11)
   at startup (internal/bootstrap/node.js:266:19)
   at bootstrapNodeJSCore (internal/bootstrap/node.js:595:3)
   at async foo (index.js:2:3)

제가 모든 것을 설명하진 않았으니 자세한 건 official blog post를 참고해주세요.

끝!

여러분들이 제 글을 통해 새로운 것을 배워 코드를 더 좋게 만들 수 있기를 바랍니다.

Typescript docs 참고

Utility Types

• 타입스크립트는 타입 변환을 용이하게 하기 위해 utility types 제공
• 전역으로 사용 가능

Partial<Type>

• Type의 모든 프로퍼티를 optional로 구성
• 주어진 타입의 모든 서브셋에 대한 타입으로 제공 (옵션이니까 서브셋의 경우의 수가 많음)

Require<Type>

• Partial과 반대로 모든 프로퍼티를 required로 구성

Readonly<Type>

• Type의 모든 프로퍼티를 readonly로 생성하여 재할당을 할 수 없게 함
• Object.freeze와 같이 런타임에 할당식에 대한 에러를 나타낼 때 사용하면 좋은 타입

예시

interface Todo {
  title: string;
}

const todo: Readonly<Todo> = {
  title: "Delete inactive users",
};

todo.title = "Hello";
// Cannot assign to 'title' because it is a read-only property.