Remix 맛보기 (1)

> https://leerob.io/blog/developer-experience-examples
> https://leerob.io/blog/dx
> _- [Lee Robinson](https://twitter.com/leeerob)_

개발의 세계에서 기술들은 너무나도 빠르게 커지고 발전하고 있습니다.

우리는 그 만큼 알아야할 것도 많아집니다. 
우리가 더 나은 사용자 경험을 위해 제품과 서비스에 적용할 수 많은 기술들이 그렇습니다.

그렇다면 우리는 더 나은 사용자 경험을 만들기 위해 이 _세계_ 에서 어떤 경험을 통해 좋은 결과를 이루어 낼 수 있을까요?

다시 말해 어떤 개발자 경험이 더 나은 결과물을 만들어 낼까요?

Vercel의 DevRel를 리딩하는 [Lee Robinson](https://leerob.io/)이 개발자 경험에 관한 짧은 블로그 글을 썼습니다.
~~(이번에 Vercel의 DX 부사장이 되었네용...)~~

> DevRel: Development Relations
> 개발자와 개발 커뮤니티를 성장시키는데 중점을 두고 있으며 팀 또는 회사 전체의 개발 문화를 조성하는 것을 담당하는 곳입니다.

이 글을 통해서 
- 좋은 팀, 회사에서 어떤 개발자 경험을 지향하는지?
- 추상적으로 느꼈던 좋은 개발자 경험이 무엇인지?
- 내가 만든다면? 내가 사용한다면? 관점에서 개발자 경험이라고 하면 무엇이 있는지?

라는 궁금증과 호기심에 이렇게 글을 옮겨봅니다.

## 들어가면서

개발자는 생산성을 원하지만 복잡한 개발툴 때문에 오히려 더 낮은 결과를 낼 때가 있습니다.

여러분들도 개발하면서 느끼시겠지만 툴에는 끌어당기는 힘이 존재합니다. 설명할 수 없는, 눈에 보이지 않는, 특별한 끌어당김이 있습니다. 

바로 이 힘이 바로 **개발자 경험(DX)입니다.**

개발자 경험(DX)는 자기력(magentic force)과 같아서 밀어내거나 끌어당깁니다. 훌륭한 개발자 경험을 가진 제품은 개발자에게 매우 중요합니다. 

> 저(저자)는 수백 개의 devtools을 사용해 왔습니다. 그 중에서 좋은 워크플로우로 유지했던 제품들은 계속해서 주변에 맴돌았습니다. Vercel은 저에게 그런 제품 중 하나였기 때문에 이곳에 합류했습니다.

## 좋은 개발자 경험을 만드는 것은 무엇일까요?
> [개발자 경험은 소프트웨어 아키텍처의 일부입니다.](https://twitter.com/matteocollina/status/1476237583105601538)
> _- Matteo Collina(member of nodejs, maintainer of fastify)_

- 프레임워크 및 라이브러리
- 문서화
- APIs

### 프레임워크 및 라이브러리

- **가능한 빠르게 Onboard**: 신박한 아이디어를 최대한 빠르게 시작할 수 있게 하는 것. 프레임워크와 라이브러리가 이 일을 빠르게 시작할 수 있도록 최적화 하는것. 예를 들어, `npx create-next-app` 또는 `brew install bat`. 개발자에게 빠른 반복, 빠른 피드백 루프를 위해 최적화하세요.
- **간편한 업그레이드**: 메이저 버전을 변경할 때 변경 사항의 "폭발 반경"을 제한하여 사람들이 종속성을 쉽게 업데이트 할 수 있도록 합니다. 이상적으로는 변경 사항이 메이저 버전에 도달하기 몇 개월 전부터 동의를 구하기 시작해야합니다. 그런 다음 메이저 버전에는 codemods(코드를 마이그레이션 하고 주요 변경사항을 수정하는 스크립트)를 포함해야합니다.
- **유용한 에러 메시지**: 오류 메시지에 하이퍼링크를 포함하여 에러를 해결할 수 있는 방법을 제공합니다. 툴을 입력할 때 피드백을 제공해야 합니다. 런타임 오류 또는 컴파일 오류 전에 빠를 수록 더 좋습니다.(ex: type check, lint). [Don't make me think](https://www.swyx.io/write-errors-that-don-t-make-me-think-24hg) 

| Facebook 개발자가 로컬 샌드박스에서 보는 오류 메시지 |
| -- |
| ![fb-error-message](https://files.seonest.net/images/qnfqnfqnf/post/273/image.png) |

- **강력한 defaults와 컨벤션**: 소프트웨어를 만드는데 "올바른 방법"에 대한 의견이 있습니다. 예를 들어 라우팅 설정에 대해 생각하지 말고 Next.js의 파일 시스템 기반 라우팅을 사용하세요. 컴파일과 번들링을 구성하게 하지 말고 webpack/swc/vite/esbuild를 사용하여 적절한 default 구성을 설정하세요.
- **탈출 구멍을 제공**:  강력한 defaults에 대한 반대로 default 구성에 벗어날 경우 탈출 구멍이 있는지 확인하는 것입니다. Next.js가 처음에 성공한 이유 중 하나는 프레임워크를 벗어나지 않고 웹팩을 쉽게 재정의할 수 있었기 때문입니다. 반면 CRA는 eject하거나 [craco](https://github.com/gsoft-inc/craco) 같은 것이 있어야만 웹팩을 재정의할 수 있습니다.
- **디펜던시에 대한 위험을 감소하세요**: `npm i next`를 하면 오직 13개 디펜던시만 설치됩니다. 나머지 디펜던시는 Next.js에 인라인됩니다. 미래에는 Next.js를 설치할 수 있는 [single binary](https://leerob.io/blog/rust)로 되길 기대합니다.

### 문서화(Documentation)

- **코드로 안내**: 개발자는 코드를 작성하기를 원합니다. 시작을 위해 코드 예제를 주세요.
- **문제를 해결(aka: 질문에 답변)**: 개발자는 질문에 대한 답변, 챌린지, 해결하고자 하는 문제를 배우기 위해 문서를 찾습니다. 다양한 방법(비디오, 텍스트, 튜토리얼, 가이드, 등등)을 통해서 답변을 제공하세요. 그래서 자신에게 적합한 방식으로 솔루션을 학습하도록 안내합니다.
- **자동화된 문서화**: API를 문서화할 때 문서가 동기화 상태를 유지하도록 소스를 원천으로 문서를 생성하는게 좋습니다. 예를 들어 Vercel의 API 문서는 API의 [OpenAPI spec](https://swagger.io/specification/)에서 자동으로 생성됩니다.
- **happy path뿐만 아니라**: 문서는 작업을 완료하려는 개발자를 위한 참조가이드입니다. 그래서 오류에 대한 검색을 하고 복사/붙여넣기 할 수 있는 솔루션을 찾는 것을 의미합니다. 해결 방법과 해킹을 문서화 하는 것도 중요합니다. 오히려 제품의 차이를 인정하고 개발자를 좌절시키지 않고 unblock하고 싶습니다.
- **훑어보기에 최적화**: 진실을 말해보자면. 우리 모두는 훑어봅니다. 특히 개발자 문서를 읽을 때 말이죠. 문제에 대한 솔루션을 찾으려고 코드 블록을 뛰어다닙니다. 최고의 DX를 제공하려면 코드 스니펫에 유용한 코드 주석을 추가하고, 원하는 기능/API의 여러 옵션 또는 순서를 보이도록 하세요.
- **정확하게**: 전문용어와 관용구를 피하세요. 줄임말을 사용하는 경우 독자가 그것이 무엇인지 알고 있다고 가정하지 마세요. 문서는 초보자와 전문가 모두가 접근할 수 있어야 합니다. Happy Path는 아니지만 접고 펼침이 가능한 "deep dive" 영역을 두어 전문가에게 도움이 되도록 하세요.
- **복잡함은 점진적으로 드러내세요**: 처음 경험을 선명하게 하면서 개발자가 제품을 계속 사용하면서 복잡한 기능에 대해 점진적으로 알립니다. 개발자가 처음부터 플랫폼 전체에 대해 배우기를 기대하는 것은 현실적이지 않습니다.

> The four interfaces of developer experience: APIs, CLIs, GUIs, and docs. Treat each as a product, so that those products can treat developers as customers
> 
> 개발자 경험의 4가지 인터페이스: API, CLI, GUI 그리고 문서. 
> 각각을 제품으로 다루고 해당 제품이 개발자를 고객으로 상대할 수 있도록 하세요.
> 
> _- [Roberta Carraro](https://twitter.com/itchymutt/status/1258579119740248066)_

### APIs

- **API 워크플로우를 깨지 마세요**: API 버전 관리는 매우 명시적이어야 합니다. 개발자들에게 새로운 버전으로 업데이트를 위한 충분한 시간을 주세요. 개인적으로 [Stripe API 버저닝](https://stripe.com/blog/api-versioning)이 좋았습니다. AWS에서는 수년간 안정적이었던 API에 대한 사용 중단 이메일을 보내고 몇 년의 업그레이드 시간을 제공하는 경우를 본 적이 있습니다.
- **API를 빠르게 사용해 볼 수 있게 하세요**: 좋아하는 API 문서들 중 몇몇은 API key를 생성하고 몇 초안에 endpoint를 시험해볼 수 있습니다. 일부는 이미 로그인되어 있다는 것을 인식하고 계정 정보를 기반으로 페이지를 개인화합니다. [Square가 아주 좋은 예입니다.](https://developer.squareup.com/explorer/square) 또한 전체 graph 스키마를 볼 수 있고 request를 만들고 mutation을 수행하고 코드를 format하고 등등을 제공하는 [GraphiQL](https://github.com/graphql/graphiql)도 좋은 예입니다.

> An API needs designing. It needs  
> - a conscious language and consistent conventions.
> - Standard auth.
> - Paging.
> - Careful error codes and messages.
> - Versioning.
> 
> API는 설계가 필요합니다.
> - 의식적인 언어와 일관된 컨벤션
> - Standard auth
> - 페이징처리
> - 잘 만들어진 에러 코드와 메시지
> - 버전 관리
> 
> _- [Jessica Joy Kerr](https://twitter.com/jessitron/status/1471351025252519936)_



## Investing in DX (Vercel)

DX는 고객에게만 중요한 것이 아니라 제품 주도 성장(product-let growth)에도 중요합니다. Vercel의 제품 및 도구의 [세계적 수준의 개발자 경험](https://leerob.io/blog/developer-experience-examples)을 제공함으로써 다음과 같은 엄청난 성장을 이루었습니다.

- **미래는 Edge**: 개발자가 몇 초만에 글로벌 애플리케이션을 `git push`하고, 수 초안에 글로벌 애플리케이션을 받아볼 있도록 함으로써 Vercel은 이제 매 주 250억 건이상의 요청을 Edge에서 처리하고 있습니다. 그리고 그 수는 꾸준히 성장하고 있습니다. Edge Function에서 [서버렌더링 SveltKit](https://sveltekit-on-the-edge.vercel.app/)과 같은 새로운 Edge 컴퓨팅 도구는 이를 더욱 발전 시킵니다.
- **프론트엔드 개발자의 역량 강화**: Next.js Discord 커뮤니티의 40,000명 정도의 개발자, 40명의 JavaScript 개발자로 구성된 [하이퍼 로컬 그룹](https://twitter.com/leeerob/status/1531695305766445056), 다음 세대의 개발자를 교육하고 활성화하는데 도움을 주고 있습니다.
- **프레임워크는 개발자를 가능하게 합니다**: 서버에서 렌더링된 React 애플리케이션을 만드는 프로세스를 단순화하기 위해 Next.js를 만들었습니다. _프레임워크_ 개발자 경험에 투자하고 개발자가 최적화된 React 사이트를 신속하게 구축할 수 있도록 함으로써 Next.js는 주간 다운로드 수 270만 이상을 달성했습니다.(그리고 Node.js / Kubernetes 보다 더 많은 [Github star](https://github.com/vercel/next.js) 도 달성했습니다.)

> Next.js는 작년 NPM 다운로드에 비해 2배 이상 증가했습니다.
> https://twitter.com/hashim_warren/status/1489309802417246212

## DX at Vercel
> Vercel에서는 개발자 경험을 위해서 어떤 것을?

훌륭한 개발자 경험을 위해서는 소프트웨어를 만드는데 일상적인 문제에 대한 공감이 필요합니다.

Vercel에서 개발자 경험은 [Developer Relations](https://leerob.io/blog/devrel-at-vercel) (커뮤니티를 만들고 제품을 홍보하는데 중점) 과 문서의 _superset_ (상위집합체) 입니다.

Vercel DX부서에는 4개의 기둥이 있습니다.

- **교육**: 모든 수준의 개발자가 웹을 만들고 기술을 마스터할 수 있도록 합니다.
- **문서**: 제품 사용에 대한 명확한 레퍼런스를 제공하고 개발자가 원하는 작업을 완료할 수 있도록 합니다.
- **커뮤니티**: 미팅, 컨퍼런스, 커뮤니티를 통해 함께 만들고 배울 수 있는 프론트엔드 개발자 커뮤니티를 육성합니다.
- **템플릿**: 성능, 접근성, 디자인에 중점을 두면서 보다 쉽게 구축을 시작할 수 있도록 합니다.

> 엔지니어링 조직에는 _내부_ 개발자 경험(또는 [개발자 생산성](https://www.airbnb.co.kr/careers/departments/engineering/dev_infra)) 팀이 있을 수도 있습니다.
> 테스트를 보다 안정적으로 만들고, 공유된 도구들을 만들고, 빌드 성능을 향상시키고 팀이 코드를 더 빠르게 배포할 수 있도록 돕습니다.

[훌륭한 개발자 경험](https://leerob.io/blog/developer-experience-examples)을 구축하는데 도움이 되는 4가지 운영 원칙이 있습니다.

- **노출되는 시간을 늘이기**: 개발자와 접촉하는 시간을 늘려서 우리 제품에 어떤 어려움을 겪는지 직접 이해합니다. 우리는 개발자들과 이야기하고 동영상을 보거나 기사를 읽고 실시간 스트리밍에 참여하기도 합니다.
- **만들면서 배우기**: 새로운 기능에 대한 알파 테스터가 되어야 합니다. 이는 교육 콘텐츠를 만들 때 도움이 될 뿐만 아니라 제품 피드백과 개선에도 좋은 영향을 줍니다.
**- 공감대 형성이 첫번째**: 모든 개발자가 양질의 소프트웨어를 빌드할 수 있도록 하려면 일상적인 문제를 이해해야 합니다. 초보자와 전문가 모두에게 공감하는 것이 중요합니다.
- **Hell yeah 또는 아니오**: 느낌이 좋지 않다면 ["hell yeal!"](https://sive.rs/hyn) 라고 말하지말고 no라고 말하세요. 이를 우리의 가치와 일치하는 가장 중요한 작업에 집중하는데 도움이 됩니다.

## 마무리하며
> Let's make the Web, faster

몇 번 우연히 지나가다가 Lee Robinson의 글이나 영상을 본 적이 있었는데 좋은 영향력을 가진 사람이라는 것이 느껴졌습니다. ~~(글도 잘 쓰고... 말도 잘하고...)~~

Vercel의 제품(특히 Next.js)을 쓰면서 문서도 정말 잘 되어있고, 개발자 경험이 좋다고 느낀적이 몇 번 있었는데 개발자 경험에 대해서 특정할 수 없는 무언가를 설명하긴 어려웠었는데 이 글을 보니 조금은 구체적으로 이해가 가는 것 같습니다.

많은 사람들이 개발자 경험을 말하지만 막상 설명하기엔 어려운 주제였는데 이 글을 보면서 어느정도 구체화 된 부분이 있었던 것 같습니다.

굳이 제품이 아닌 작게는 팀 내에서도 개발자 경험을 위해 어떤 관점에서 접근해야될지, 그런 부분도 생각하게 되는 글인 것 같습니다.

## reference

- https://leerob.io/blog/dx
- https://leerob.io/blog/developer-experience-examples

Great Developer Experience (Vercel)

Should I use pixels? or ems/rems?

Nextjs Layout RFC: New Routing System

> A Hook to define an event handler with an always-stable function identity
> (always-stable 함수로 이벤트 핸들러를 정의하기 위한 hook)
> _- [RFC: useEvent()](https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md)_

`useEvent` hook에 대한 내용의 글을 봤고 굉장히 흥미로운 내용이 있어서 글로 옮겨보려고 합니다.

아직 정식 릴리즈 되지 않은 기능이지만 많은 사람들이 기대하는 hook인건 확실한 것 같습니다.

어떤 문제점에서 출발했는지 살펴보도록 하겠습니다.

## What is the problem?

### 1. 이벤트 핸들러에서 states/props를 읽는 것은 최적화를 방해합니다.
> re-render시에 함수가 불필요하게 매번 재생성되기 때문에

아래 예시를 보겠습니다.
```tsx
function _SendButton({ onClick }: { onClick: () => void }) {
  console.log("render SendButton");
  return <button onClick={onClick}>send</button>;
}

const SendButton = React.memo(_SendButton);

export default function App() {
  const [text, setText] = React.useState("");
  const onInput = React.useCallback(
    (e: React.ChangeEvent<HTMLInputElement>) => {
      setText(e.currentTarget.value);
    },
    []
  );

  const send = () => {
    console.log("send:", text);
  };

  return (
    <div>
      <input value={text} onChange={onInput} />
      <SendButton onClick={send} />
    </div>
  );
}
```

`<input>`에 입력을 하면 `App`이 리렌더링 되므로 `send` 함수도 대상이 되며  `SendButton` 또한 prop 영향으로 리렌더링 됩니다.

이 문제를 해결하기 위해서 보통 `useCallback`을 사용합니다. 

```jsx
const send = React.useCallback(() => {
  console.log("send:", text);
}, []);
```

`useCallback`으로 `send`함수를 감싼다면 리렌더링 시에 함수가 재생성되지 않습니다. 그러나 이 예시에는 문제가 있습니다. deps 의존성 배열이 비어있기때문에 한 번만 생성되므로 최초 `text` 상태인 빈 값 만 보여지게 됩니다. 

hook은 fiber 트리에서 _실제 갈고리처럼_ 의존성 data를 가져오기 때문에 명시적 의존성 변경이 없다면 업데이트 될 수 없습니다.

따라서 `text`를 deps 배열에 추가해야 합니다.
```jsx
const send = React.useCallback(() => {
  console.log("send:", text);
}, [text]);
```

그러나... `text` 의존성이 있는 한 리렌더링 문제를 피할 수는 없습니다.

### 2. useEffect는 이벤트 핸들러가 변경될 때 재실행되선 안됩니다.

이번 예시에서 `Chat` 컴포넌트가 있습니다.
`Chat` 컴포넌트는 room에 연결될 때 몇 가지 효과를 가집니다.

room에 들어가거나 메시지를 받을 때 선택된 `theme`을 가진 toast를 보여줍니다.
그리고 `muted` 셋팅에 따라 사운드를 발생합니다.
```jsx
function Chat({ selectedRoom }) {
  const [muted, setMuted] = useState(false);
  const theme = useContext(ThemeContext);

  useEffect(() => {
    const socket = createSocket('/chat/' + selectedRoom);
    socket.on('connected', async () => {
      await checkConnection(selectedRoom);
      showToast(theme, 'Connected to ' + selectedRoom);
    });
    socket.on('message', (message) => {
      showToast(theme, 'New message: ' + message);
      if (!muted) {
        playSound();
      }
    });
    socket.connect();
    return () => socket.dispose();
  }, [selectedRoom, theme, muted]); // 🟡 의존성 중 하나라도 변경되면 재 실행됩니다.
  // ...
}
```

위 에시의 문제는 `theme`이나 `muted` 상태가 변경될 때마다 `useEffect`가 재실행(소켓 재연결)이 발생한다는 것입니다. `theme`, `muted`가 effect 내부에서 사용되므로 의존성 배열에 선언되어야 합니다. 그래서 그 중 하나라도 변경된다면 `useEffect`는 재실행되고 소켓을 destroy, recreating 하게 됩니다.

소켓 callback을 `useEffect` 밖으로 옮기고 `useCallback`으로 감싸더라도 의존성 배열에는 `theme`, `muted`를 포함해야 하고, `useEffect`는 이 callback을 의존하기에 여전히 동일하게 `useEffect`는 재실행됩니다.

```jsx
  const onConnected = useCallback((connectedRoom) => {
    showToast(theme, 'Connected to' + connectedRoom);
  }, [theme]);
  
  const onMessage = useCallback((message) => {
    showToast(theme, 'New message: ' + message);
    if (!muted) {
      playSound();
    }
  }, [muted]);
  
  useEffect(() => {
    ...
    socket.on('connected', async () => {
      await checkConnection(selectedRoom);
      onConnected(selectedRoom);
    });
    socket.on('message', onMessage);
    ...
  }, [selectedRoom, onConnected, onMessage]);
```

재생성, 재실행을 막기 위해 `theme`, `muted`를 의존성 배열에서 제거한다면 원하는 동작을 하지 못합니다. 초기 값 만을 계속 보게 될 것입니다. theme을 변경하더라도 바뀌지 않을 것이며, 음소거를 했더라도 사운드는 계속해서 들릴 것입니다.

## useEvent()
> RFC단계이며 정식 버전에 곧 릴리즈 될 것으로...

```jsx
useEvent(handler)
```

위 문제들로 인해 `useEvent()` 등장하게 됩니다.

memoize된 callback(`useCallback`)을 반환하는 hook입니다.

`useEvent()` hook [간략한 내부 구현](https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md#internal-implementation)을 보면 Ref를 통해 구현합니다.

```jsx
function useEvent(handler) {
  const handlerRef = useRef(null);

  // layout effect 전에 실행 합니다.
  useLayoutEffect(() => {
    handlerRef.current = handler;
  });

  return useCallback((...args) => {
    // 렌더리 중에 호출되면 에러를 throw 합니다.
    const fn = handlerRef.current;
    return fn(...args);
  }, []);
}
```
> concurrent mode에서 ref를 셋팅하는 것은 안전하지 않기 때문에 layout effect전에 해야합니다.
> 1. 전달된 handler을 담을 ref를 선언하고
> 2. useLayoutEffect를 통해 ref에 전달된 handler을 담습니다.
> 3. 이것(ref에 담긴 handler)을 호출하는 함수를 useCallback으로 감싸서 반환합니다.

다시 말해, 전달한 함수의 최신 버전을 호출하는 안정적인 함수를 만들어줍니다.

`useEvent` 실제 구현은 위 코드와 몇 가지 차이점이 있습니다.

주석에서 작성되어 있지만 렌더링 시에 호출이 되면 에러를 throw합니다.
(`useEffect`에서 호출되거나 다른 시기에 호출되는 것은 괜찮습니다.)

그래서 렌더링 동안에는 이 함수는 불투명(opaque)하게 처리되며 절대 호출되지 않도록 강제합니다.

"현재" 버전의 handler는 모든 layout effect가 동작하기 전에 바뀝니다.
이를 통해, 어느 한 컴포넌트의 effect가 다른 컴포넌트 상태의 이전 버전을 볼 수 있는 문제(userland's pitfall)를 피할 수 있습니다.
> ("현재" handler로 변경되는 정확한 시점은 [미해결 상태](https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md#unresolved-questions)입니다.)

그렇다면 이 `useEvent`를 통해 위 문제들을 어떻게 해결할 수 있을까요?

### 1. 이벤트 핸들러에서 states/props를 읽는 것은 최적화를 방해합니다.

```tsx
const send = useEvent(() => {
  console.log("send:", text);
});
```

`send`함수를 `useEvent()`로 감싸서 처리하는 것으로 간단하게 가능합니다.
text가 바뀌어도 함수가 재생성되지 않습니다.

### 2. useEffect는 이벤트 핸들러가 변경될 때 재실행되선 안됩니다.

```jsx
  // ✅ Stable
  const onConnected = useEvent(connectedRoom => {
    showToast(theme, 'Connected to ' + connectedRoom);
  });

  // ✅ Stable
  const onMessage = useEvent(message => {
    showToast(theme, 'New message: ' + message);
    if (!muted) {
      playSound();
    }
  });

  useEffect(() => {
    ...
    socket.on('connected', async () => {
      await checkConnection(selectedRoom);
      onConnected(selectedRoom);
    });
    socket.on('message', onMessage);
    ...
  }, [selectedRoom]); // ✅ room이 바뀔 때에만 재실행됩니다.
```

`useEvent`를 onConnected 함수와 onMessage 함수를 `useCallback` 대신 사용하여 의존성을 제거하였습니다. 그래서 `useEffect`에서 의존성도 제거할 수 있습니다.

이를 통해 
- `theme`, `muted`가 바뀌어도 함수가 재생성되지 않으며
- `selectedRoom`이 바뀔 때만 `useEffect`가 재실행됩니다. 

## 주의해야 할 점
> render 시에 호출되는 함수인 경우엔 여전히 useCallback을 사용해야 합니다.

`useEvent`는 React Ref를 사용하기 때문에 concurrent 기능에 영향을 줄 수 있기에 렌더링 시에 호출되면 안됩니다.

예를 들어 `renderItem` callback은 `useEvent`를 사용하면 안됩니다. 대신 `useCallback`을 사용해야 합니다.

```jsx
function ThemedGrid() {
  const theme = useContext(ThemeContext);
  const renderItem = useCallback((item) => {
    // 렌더링 시 호출되기에 이벤트가 아닙니다.
    return <Row {...item} theme={theme} />;
  }, [theme]);
  return <Grid renderItem={renderItem} />
}
```

> linter: callback앞에 on, handle이 붙은 callback인 경우에 `useEvent`를 사용해야 하는 것을 lint하도록

## 염려되는 점
- **React에 새로운 개념이 추가되는 점입니다.**
    - 사람들은 이미 새로운 함수 정의와 관련된 사례("`useCallback`을 모든 곳에 사용해야되나요?")로 어려움을 겪고 있습니다.
    - 그러나 `useEvent`가 실제 사용에서 불가피하다고 생각합니다. 왜냐하면 first-class API, 공유된 표현, 베스트 practices의 이점들 때문입니다.
- **일반적인 이벤트 핸들러와 비교했을 때 `useEvent`로 감싸는 것은 더 시끄러워보입니다.**
    - 이벤트 핸들러가 아닌 동일한 문제를 위해 사용하는 `useCallback`과 비교해야 합니다. `useEvent`는 좀 더 사용하기 편하게 개선되었습니다.(의존성 배열 없음, invalidation 없음). 또한 선택 사항이므로 원하는 경우 코드를 그대로 유지할 수 있습니다.
- **`useEvent`라는 명칭, DOM 이벤트 핸들러보다 더 넓은 용어를 포함합니다.**
    - `useStableCallback`이나 `useCommittedCallback`으로도 부를 수 있습니다. 그러나 요점은 이벤트 핸들러에 사용하도록 권장하는 것입니다.
- **`useCallback`에 비교해서 `useEvent`는 commit 단계에서 추가적인 작업이 필요합니다.**
    - 그러나 실제로 이러한 패턴은 이미 많이 사용되고 있습니다. 이런 사례를 가진 많은 라이브러리와 제품이 존재하지만 타이밍 문제로 고통받는 솔루션 보다 전반적으로 더 나은 것처럼 보입니다. 
- **몇 가지 엣지 케이스가 있습니다. 그러나 크게 문제가 있진 않을 거라고 생각합니다.**
    - `useEvent`에서의 "현재" 버전의 값은 "호출" 당시의 값을 의미합니다. 이것이 진정한 "라이브" 바인딩을 얻지 못한다는 것을 의미합니다. 이러한 이유로 이벤트는 일반적으로 비동기식이 되면 안됩니다. 단지 fire-and-forget(발생시키고 잊어버려라)으로 다루는게 가장 좋습니다.
    - `onSomething={cond ? handler1 : handler2}`와 같은 "조건부 이벤트" 경우에 `onSomething`이 의존성에 포함되어있다면 `cond`가 변경될 때 재실행 될 것입니다. `useEvent`로 감싼다면 "보호"할 수 있습니다.
## Alternative(?): useRefData
> _- [Alternative to useEvent](https://jser.dev/react/2022/05/07/alternatives-to-useevent.html)_

ref를 이용하여 대체할 수 있는 hook을 만들어보면서 더 이해해보려 합니다.

```tsx
const [text, setText] = React.useState("");
const textRef = React.useRef(text);

React.useLayoutEffect(() => {
  textRef.current = text;
}, [text]);

const send = React.useCallback(() => {
  console.log("send:", textRef.current);
}, []);
```

> concurrent mode에서 ref를 셋팅하는 것은 안전하지 않기 때문에 useEffect보다 더 이른시기에 동작하는 useLayoutEffect에서 사용합니다.

위 코드는 잘 동작합니다. 그러나 더 많은 상태를 관리해야된다면 어떨까요? 
코드는 더 못생겨질 것이고 관리는 더 어려워집니다.

그래서 재사용가능한 hook으로 다시 만들어보자면,
```jsx
function useRefData(data) {
  const ref = React.useRef(data);
  React.useLayoutEffect(() => {
    ref.current = data;
  }, [data]);
  return ref;
}
```

```jsx
const textRef1 = useRefData(text1);
const textRef2 = useRefData(text2);

const send = React.useCallback(() => {
  console.log("send:", textRef1.current, textRef2.current);
}, []);
```

`useRefData`라는 hook을 만들어 조금 더 보기 좋아보이게 바꾸어 보았습니다.
그러나 여전히 "아름답진" 않습니다. 한 개의 data만 받을 수 있기도 하고 많은 상태가 있을 땐 여전히 못생겼습니다.

```jsx
function useRefData(...args) {
  const refs = args.map(React.useRef);
  React.useLayoutEffect(() => {
    for (let i = 0; i < args.length; i++) {
      refs[i].current = args[i];
    }
  }, args);

  return React.useCallback(() => refs.map((ref) => ref.current), []);
}
```

```jsx
const getData = useRefData(text1, text2);

const send = React.useCallback(() => {
  const [text1, text2] = getData();
  console.log("send:", text1, text2);
}, [getData]);
```

`useEvent`와 매우 흡사한 느낌입니다. `useEvent`와 비교해서 거의 동일한 개념적 구현을 가집니다.

```jsx
const rawCallback = () => {
  console.log("send:", text1, text2);
};

const callback = useRefData(rawCallback)()[0];
```

1. `useRefData`: 입력 데이터를 안정화
2. `useEvent`: 사용을 안정화

어떤 것이 더 나아보이나요?
1. `useRefData`: 이해하기 쉽지만 망치기도 쉽습니다.
2. `useEvent`: 추가적인 이해가 필요하지만 관리하기 더 쉽습니다.

## 마무리하며

`useCallback`과 의존성 문제로 인해서 `Ref`를 가끔 사용하면서 시간을 꽤 소비할 경우가 많았는데 이 hook이 나온다면 훨씬 간단하게 문제를 해결할 수 있을 것 같다는 생각이 듭니다.

다만 위에도 작성되어있듯이 점점 더 복잡해지는 느낌은 듭니다. 
(~~나만 그런걸 수도...~~)

명칭에 Event가 들어가서 약간 헷갈릴 수도 있을 것 같은데 이벤트 핸들러에 주로 사용되도록 권장하기에 괜찮을 것 같기도 합니다. 다른 것도 마찬가지니까 어느정도 명칭에 익숙해지면 자연스럽게 받아들여지지 않을까 싶습니다.

다음에는 이전 포스트에 React Deep Dive하는 글에 이어서 써볼까 싶습니다.

> 여담이긴한데 최근에 RN을 만지고 있는데 네이티브쪽은 영 모르겠네여 ㄷㄷ
근데 Flutter3가 나왔다고 하니 뭔가... Flutter를 해볼껄 그랬나 싶기도 하고...
요샌 이러고 있습니다. ㅎ

## reference
- https://github.com/reactjs/rfcs/blob/useevent/text/0000-useevent.md
- https://jser.dev/react/2022/05/07/alternatives-to-useevent.html

React RFC: useEvent()

> useEffect 내에서 data fetch를 다룰 때 종종 발생하는 버그를 이해하고 Suspense를 이용해 어떻게 다루는지 확인해보려고 합니다.
> https://17.reactjs.org/docs/concurrent-mode-suspense.html#suspense-and-race-conditions

입력 변화의 타이밍이나 순서가 예상과 다르게 작동하면 정상적인 결과가 나오지 않게 될 위험이 있는데 이를 Race condition(경쟁 상태)라고 합니다.

React useEffect 같은 react life-cycle 내에서 data fetch를 다룰 때 종종 이런 버그가 났던 것 같습니다.

마지막에 요청했던 결과가 아닌 이전 결과가 화면에 렌더링 된다던지... 그런 이슈 입니다.

이번 글에서는 Race condition을 어떻게 다루고 Suspense를 이용하면 간단하게 처리할 수 있는지 확인해보도록 하겠습니다.

## Race condition in useEffect

이해를 위해 예시 프로젝트와 함께 살펴보겠습니다.

```tsx
function Profile() {
  const [id, setId] = useState(1);

  return (
    <>
      <button onClick={() => setId(getNextId(id))}>Next</button>
      <ProfileComponent id={id} />
    </>
  );
}

export default Profile;
```

Next 버튼을 누르면 다음 id를 가진 user의 profile로 전환 해주는 page를 만들어보았습니다.
`<ProfileComponent />` 는 id를 prop으로 받아 user 정보와 user에 해당하는 post를 렌더링하는 component입니다.

```tsx
type Props = {
  id: number;
};

function ProfileTimeline({ id }: Props) {
  const [post, setPost] = useState<PostT | null>(null);

  useEffect(() => {
    fetchPost<PostT>(2000 * Math.random(), id).then(p => setPost(p));
  }, [id]);

  if (post === null) {
    return <h2>Loading post...</h2>;
  }
  return (
    <>
      <h3>{post.title}</h3>
      <p>{post.body}</p>
    </>
  );
}

function ProfileComponent({ id }: Props) {
  const [user, setUser] = useState<UserT | null>(null);

  useEffect(() => {
    fetchUser<UserT>(1000 * Math.random(), id).then(u => setUser(u));
  }, [id]);

  if (user === null) {
    return <p>Loading profile...</p>;
  }

  return (
    <>
      <h1 style={{ color: 'purple' }}>Name : {user.name}</h1>
      <ProfileTimeline id={id} />
    </>
  );
}
```

2개의 fetch가 존재하고 user정보를 useEffect를 통해서 fetch를 하고 post도 마찬가지로 useEffect를 통해 fetch합니다.

fetchUser와 fetchPost는 `Math.random()`을 통해 0~1 사이의 랜덤한 float값을 곱하여 delay후 실제 fetch를 수행합니다.

useEffect를 보면 dependency에 `[id]`를 넣어둔 것을 확인할 수 있습니다.
id가 변경되면 useEffect를 다시 실행하도록 만들어야 하기 때문입니다. 그렇지 않으면 새로운 데이터를 fetch하지 못합니다.

![normal-case.png](https://files.seonest.net/images/qnfqnfqnf/post/226/image.png)

처음에는 잘 작동하는 것처럼 보입니다. 하지만 "Next" 버튼을 아주 빠르게 클릭하게 되면 무언가 이상하게 동작하는 것을 콘솔 로그를 통해 볼 수 있습니다.

**마지막에 보냈던 요청 뒤에 그 이전에 보냈던 요청이 돌아오는 경우가 발생할 때가 있는데 그로 인해서 setState시에 이전 요청의 결과값으로 덮어쓰게 되는 경우가 발생합니다.**

![race-condition](https://files.seonest.net/images/qnfqnfqnf/post/225/image.png)

fetchPost를 보게되면

1. id가 2로 바뀌면서 fetchPost(2) 시작
2. id가 3로 바뀌면서 fetchPost(3) 시작
3. fetchPost(3) 완료되어 setState와 함께 re-render
4. fetchPost(2) 완료되어 setState와 함께 re-render

위 이미지에서 그 이전 fetchPost: 2 가 마지막 요청인 fetchPost: 3 요청을 덮어쓰면서 기대했던 결과와는 다른 결과가 나오게 되었습니다.

useEffect 내에서 data fetch를 주의깊게 사용하지 않는다면 이런 race condition을 종종 마주칩니다.

이 문제는 고칠 수 있습니다. useEffect 내에서 cleanup function을 이용해 오래된 요청을 무시하거나 취소할 수 있습니다. 하지만 이는 직관적이지 않고 디버깅하기도 어렵습니다.

```tsx
useEffect(() => {
  ...
  // cleanup function
  return () => {
    ...
  }
}, [deps])
```

React component에는 고유한 "life-cycle"이 있습니다. 특정 시점마다 props를 받거나 state를 업데이트 합니다. 

각각 비동기 요청 또한 자신만의 "life-cycle"을 가집니다. 요청이 출발했을 때 시작되며, 응답이 돌아오면 끝납니다. 

어려운 점은 여러 프로세스가 서로에게 영향을 미치는 그 순간 여러 프로세스들을 "동기화"하는 작업입니다. 이 문제는 생각하기 어렵습니다.

## Race condition in Suspense

위 예제를 Suspense를 이용해 다시 작성해보겠습니다.

```tsx
const initialResource = suspenseProfileData<UserT, PostT>(1);

function Profile() {
  const [resource, setResource] = useState(initialResource);

  return (
    <>
      <button
        onClick={() => {
          const nextUserId = getNextId(resource.userId);
          setResource(suspenseProfileData(nextUserId));
        }}
      >
        Next
      </button>
      <ProfileComponent resource={resource} />
    </>
  );
}

export default Profile;
```

resource는 suspense를 위한 특별한 형태입니다.

```tsx
// Suspense integrations like Relay implement
// a contract like this to integrate with React.
// Real implementations can be significantly more complex.
// Don't copy-paste this into your project!
export function wrapPromise<T>(promise: Promise<T>) {
  let status = 'pending';
  let result: T;
  let suspender = promise.then(
    r => {
      status = 'success';
      result = r;
    },
    e => {
      status = 'error';
      result = e;
    }
  );
  return {
    read() {
      if (status === 'pending') {
        throw suspender;
      } else if (status === 'error') {
        throw result;
      } else if (status === 'success') {
        return result;
      }
    },
  };
}
```

예시를 위해 제공된 코드 중에 있고 자세히 보면 특이한 것은 "pending"인 경우 promise 함수를 throw 하는 것을 볼 수 있습니다. error처럼 말이죠. React Suspense에서 promise를 다루는 방식이 이렇다라고만 이해하고 넘어가도록 하겠습니다. ~~(주석처럼 이것을 그대로 프로젝트에 복사해서 쓰지 마세요.)~~

```tsx
type Props = {
  resource: typeof initialResource;
};

function ProfileTimeline({ resource }: Props) {
  const post = resource.posts.read();
  return (
    <>
      <h3>{post!.title}</h3>
      <p>{post!.body}</p>
    </>
  );
}

function ProfileDetails({ resource }: Props) {
  const user = resource.user.read();

  return <h1 style={{ color: 'purple' }}>Name : {user!.name}</h1>;
}

function ProfileComponent({ resource }: Props) {
  return (
    <Suspense fallback={<h2>Loading profile...</h2>}>
      <ProfileDetails resource={resource} />
      <Suspense fallback={<h2>Loading posts...</h2>}>
        <ProfileTimeline resource={resource} />
      </Suspense>
    </Suspense>
  );
}
```

"Next"를 누르면 다음 profile정보에 대한 요청을 실행시키고, 그 resource를 ProfileComponent 컴포넌트 prop으로 전달합니다.

```tsx line(3)
<>
  <button
    onClick={() => {
      const nextUserId = getNextId(resource.userId);
      setResource(suspenseProfileData(nextUserId));
    }}
  >
    Next
  </button>
  <ProfileComponent resource={resource} />
</>
```

**setState할 때 응답이 오기전까지 기다리지 않는다는 점을 확인하세요.**
**오히려 전혀 반대 방법입니다. 즉, 요청을 시작시킨 뒤에 즉시 state를 설정합니다.(그 후 렌더링을 시작합니다.)**
데이터를 얻게 되자마자, React는 `<Suspense>` 컴포넌트 내에 컨텐츠를 "fills in(주입)"합니다.

![race-condition-suspense](https://files.seonest.net/images/qnfqnfqnf/post/228/image.png)

실제 fetched 는 fetchUser(2)가 fetchUser(3) 보다 늦게 응답이 온 것으로 콘솔로그는 찍혔습니다.

그러나 위 코드에서 보았듯이 응답이 오기 전에 즉시 state를 설정했기 때문에 화면에 렌더링 된 것은 마지막에 요청한 fetchUser(3) 의 결과가 렌더링 됩니다.

| | |
| :--: | :--: |
| ![image.png](https://files.seonest.net/images/qnfqnfqnf/post/229/image.png) | ![image.png](https://files.seonest.net/images/qnfqnfqnf/post/230/image.png) |

fetchUser를 보게되면

1. "Next" 클릭하여 id가 2인 suspense resource를 setState
2. resource(id = 2)를 prop으로 받는 ProfileComponent re-render
3. fetchUser(2) 시작
4. "Next" 클릭하여 id가 3인 suspense resource를 setState
5. resource(id = 3)를 prop으로 받는 ProfileComponent re-render
6. fetchUser(3) 시작
7. fetchUser(3) 완료
8. resource(id = 3) 응답 결과 따라 ProfileComponent children 렌더링
9. fetchUser(2) 완료 되지만 무시됨

이 코드는 매우 읽기 좋게 작성되어있지만. 기존 예제들과 달리 Suspense 버전에서는 race condition으로부터 고통받지 않습니다. 그 이유가 궁금하실 겁니다. 
그 이유는 바로 Suspense 버전에서는 코드 상에서 _time(시간)_ 에 대해 그다시 신경을 쓰지 않아도 되기 때문입니다. 

race condition이 존재했던 기존의 코드에서는 **_이후의 적당한 시점에_ state를 설정**해야 했습니다. 그렇게 안하면 위에서 보듯이 기대하지 않은 결과가 나올 수 있습니다.
그러나 Suspense에서는 **state를 _즉시_ 설정**합니다. 따라서 오작동하는 것이 더 어렵습니다.

> 위 예제코드는 공식 문서에서 [codesandbox](https://codesandbox.io/s/sparkling-field-41z4r3)를 통해 소스를 제공하고 있고 제 [github 코드](https://github.com/JHSeo-git/react-hello-world/tree/main/apps/ex-suspense-render)에서도 확인할 수 있습니다.

## 마무리하며

useEffect내에서 data fetch를 주로 하고 state를 설정하는 방식을 많이 사용했습니다.
지금도 그런 프로젝트들이 많구요.

loading이나 error관리, 복잡해지는 구조 등에 매 번 좀 더 나은 구조를 위해서 고민했던 것 같습니다.

적당한 시점에 state를 설정해야한다는 것이 간단한 코드 내에서는 그래도 처리하겠는데 점점 더 코드가 복잡해지면 매우 힘든 경우도 있다는 것을 경험해보니 이런 Suspense와 같은 것이 너무 반갑습니다.

Suspense는 직관적이고 읽기 좋게 작성할 수 있습니다. 다음에 설명하겠지만 error-boundary를 통해 error 관리도 선언적으로 관리할 수 있게 되어 가독성 좋아집니다. 

저 같은 경우 머리도 좋지 않고 "컨텍스트"를 잃어버리면 돌아오고 나서도 한참 헤매는 경우가 많습니다.~~(거기다 코드도 엄청 줄어듭니다)~~

이와 같이 직관적이라면 "컨텍스트"를 잃게 되더라도 빨리 돌아와 빠르게 회복될 것 같아 매우 좋을 것 같습니다.

적극적으로 사용해봐야겠다고 다짐 해봅니다.

## reference

- https://17.reactjs.org/docs/concurrent-mode-suspense.html#suspense-and-race-conditions

Fixing race condition in React

React Hydration 문제에 대해서

> React에서 Data Fetch를 좀 더 이해하기 위해 다음 글을 직접 예시로 작성해보고 내용을 옮겨보았습니다.
> https://17.reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense

오랫동안 이해가 되지 않던 개념이나 문제들이 그 다음 문제를 해결하면서 같이 이해가 되었던 적이 있지 않았나요?

저는 종종 그런 경우가 있었습니다.

이번에는 React에서 Data Fetch를 다루는 방법을 좀 더 이해하고 잘 다루기 위해 Suspense를 포함한 여러 방법에 대해 알아보고자 합니다.

## 들어가면서

React(뿐만아니라 Web Client 프로그램)에서 Data를 fetch하는 방식은 다양하게 있습니다.

각 방식마다 사용자 경험 향상을 위한 여러 방법들이 존재했습니다. 비동기 Fetch, Data State를 관리하기 위한 방대한 보일러플레이트(redux, mobx 등)를 만들어야 할 경우도 있었습니다.

또한, 더 나은 UX와 DX를 제공하기 위한 다양한 기능들을 가진 tool([react-query](https://react-query.tanstack.com/), [swr](https://swr.vercel.app/ko)등)이 나왔고 개발자들은 그 중에 더 나아보이는 tool을 사용하거나 자신들만의 무언가를 만들어 사용합니다.

그러나 React 18에 Suspense가 공식 Release되었고, Data Fetch를 선언적으로 다룰 수 있고 더 쉽게 접근할 수 있고 더 나은 사용자 경험을 제공할 수 있게 되었습니다.

## Data Fetching 접근 방식

- **Fetch-on-render**(ex: useEffect 안에 fetch): 컴포넌트가 렌더링되고 난 뒤에 effect와 lifecycle 내에서 data를 fetching하는 것을 뜻합니다. 이 접근법은 보통 "waterfall"로 이끕니다.
- **Fetch-then-render**(ex: Suspense를 사용하지 않는 Relay): 최대한 일찍 다음 화면을 위한 전체 data를 fetching하는 것을 뜻합니다. data가 준비되었을 때 다음 스크린이 그려집니다. 이는 data가 도착할 때가지 아무것도 못한다는 것을 의미합니다.
- **Render-as-you-fetch**(ex: Suspense를 사용하는 Relay, React): 최대한 일찍 다음 화면에 사용될 전체 data를 fetching하는 것을 뜻합니다. 그와 동시에 다음 화면을 렌더링합니다(~~네트워크 응답이 오기 전에~~). data stream을 통해서 React는 data가 완전히 fetch될 때까지 해당 data를 필요로 하는 컴포넌트의 렌더링을 재시도합니다.

3개로 간단한게 나누어서 설명했지만, 실제로는 여러 방법들을 섞어가며 문제를 해결합니다. 그렇지만 서로간의 tradeoff를 잘 비교할 수 있도록 분리하여 생각해보겠습니다.

여러 예제를 이용하면 더 이해하기 쉬울 것 같아 몇 가지 예제를 공식 문서에서 가져와서 동작하면서 이해보려고 합니다.

> React Docs: [concurrent-mode-suspense](https://ko.reactjs.org/docs/concurrent-mode-suspense.html#approach-1-fetch-on-render-not-using-suspense)
> Example Repo: https://github.com/JHSeo-git/react-hello-world/tree/main/apps/ex-fetch-render

### 1. Fetch-on-render (Suspense 사용안함)
> React 에서 흔히 사용되는 접근법이고, 저 또한 대부분의 프로젝트에 사용하고 있었습니다.

직역하자면 "렌더링 후에 Fetch" 라고도 할 수 있습니다.

React에서는 가장 흔한 방식이고 useEffect를 이용해 data fetch를 다룹니다.

```js
useEffect(() => {
  fetchSomething();
}, []);
```

useEffect를 통해서 fetch된 data를 state에 업데이트하여 화면에 렌더링 하도록 하는 방식입니다.

예제에는 2개의 fetch를 사용하고, 순차적으로 호출됩니다.

```ts
function ProfileTimeline() {
  const [posts, setPosts] = useState<PostT[] | null>(null);

  useEffect(() => {
    fetchPosts<PostT[]>(2000).then(p => setPosts(p));
  }, []);

  if (posts === null) {
    return <h2>Loading posts...</h2>;
  }
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

function Profile() {
  const [user, setUser] = useState<UserT | null>(null);

  useEffect(() => {
    fetchUser<UserT>(1000).then(u => setUser(u));
  }, []);

  if (user === null) {
    return <h2>Loading profile...</h2>;
  }

  return (
    <>
      <h1 style={{ color: 'purple' }}>Name : {user.name}</h1>
      <ProfileTimeline />
    </>
  );
}

export default Profile;
```

위의 코드를 실행하면 아래와 같은 순서로 진행되는 것을 볼 수 있습니다.
(fetch-on-render를 확실히 구분하기 위해 delay를 넣어 구분했습니다.)

1. fetchUser: user 정보 fetch 시작
2. loading profile...(1초)
3. fetchUser: user 정보 fetch 완료
4. fetchPosts: posts 정보 fetch 시작
5. loading posts...(2초)
6. fetchPosts: posts 정보 fetch 완료

fetchUser가 1초가 소요된다면, 1초가 지난뒤에야 `<ProfileTimeline />`이 호출되므로 그제서야 fetchPosts fetch를 시작할 수 있습니다.

![fetch-on-render.png](https://files.seonest.net/images/qnfqnfqnf/post/206/fetch-on-render.png)

이것을 "waterfall" 이라고 부르며, 병렬로 호출될 수 있었으나 의도하지 않게 순차적으로 실행되는 현상입니다.

| | | |
|:--:|:--:|:--:|
|![1](https://files.seonest.net/images/qnfqnfqnf/post/207/image.png)|![2](https://files.seonest.net/images/qnfqnfqnf/post/208/image.png)|![3](https://files.seonest.net/images/qnfqnfqnf/post/209/image.png)|

waterfall은 "fetch-on-render" 코드에서 흔히 발생하는 현상입니다. 이를 고치는 것은 가능하지만, 앱이 커짐에 따라 많은 사람들은 이 문제를 근본적으로 막을 수 있는 해결책을 원했습니다.

### 2. Fetch-then-render (Suspense 사용안함)
> Relay의 경우, component가 필요로 하는 data를 정적으로 분석할 수 있는 _fragments_ 로 옮겨서 이 문제를 해결합니다. 이 _fragments_ 는 이후에 하나의 단일 쿼리로 통합됩니다.
> 
> [Relay](https://relay.dev/): React application에서 GraphQL data를 다루기 위한 Meta(facebook)에서 만든 JavaScript framework 입니다.

대게 라이브러리들은 data fetch를 더 중앙화된 방법을 제공함으로써 waterfall 문제를 해결합니다. 

여기에서는 Relay를 예시로 들지 않습니다. 대신, data fetch를 하나로 합쳐, 앞서 설명한 것과 유사한 코드를 예시로 사용합니다.

```ts
function fetchProfileData<T, U>() {
  return Promise.all([fetchUser<T>(1000), fetchPosts<U>(2000)]).then(([user, posts]) => {
    return { user, posts };
  });
}

// 최대한 빨리 fetch 하기
const fetchProfile = fetchProfileData<UserT, PostT[]>();

type ProfileTimelineProps = {
  posts: PostT[] | null;
};

function ProfileTimeline({ posts }: ProfileTimelineProps) {
  if (posts === null) {
    return <h2>Loading posts...</h2>;
  }
  return (
    <ul>
      {posts.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

function Profile() {
  const [user, setUser] = useState<UserT | null>(null);
  const [posts, setPosts] = useState<PostT[] | null>(null);

  useEffect(() => {
    fetchProfile.then(data => {
      setUser(data.user);
      setPosts(data.posts);
    });
  }, []);

  if (user === null) {
    return <h2>Loading profile...</h2>;
  }

  return (
    <>
      <h1 style={{ color: 'purple' }}>Name : {user.name}</h1>
      <ProfileTimeline posts={posts} />
    </>
  );
}

export default Profile;
```

Promise.all을 통해 두 요청을 병렬로 요청하여 동시에 fetch를 시작합니다.
그래서 위의 코드를 실행하면 아래와 같은 순서로 진행되는 것을 볼 수 있습니다.

1. fetchProfileData: user 정보 fetch 시작
2. fetchProfileData: posts 정보 fetch 시작
3. loading profile... , loading posts... (2초)
5. fetchProfileData: user 정보 fetch 완료
6. fetchProfileData: posts 정보 fetch 완료

![fetch-then-render](https://files.seonest.net/images/qnfqnfqnf/post/210/image.png)

| | |
|:--:|:--:|
|![1](https://files.seonest.net/images/qnfqnfqnf/post/211/image.png)|![2](https://files.seonest.net/images/qnfqnfqnf/post/212/image.png)|

기존에 존재하던 "waterfall" 현상은 고쳤지만, 의도하지 않은 또다른 문제를 만들었습니다.

Promise.all을 사용하는 과정에서 _모든_ data fetch가 완료되기를 기다려야 합니다.
user fetch는 1초만에 끝났지만, posts fetch는 2초가 걸리기 때문에 2초 동안은 기다려야 render를 할 수 있는 구조입니다.

물론, 이 예시에서는 좀 더 낫게 고칠 수 있습니다. 
Promise.all을 없애고, 두 promise를 별도로 기다리게 하면 됩니다.

```ts
useEffect(() => {
    fetchUser<UserT>(1000).then(u => setUser(u));
    fetchPosts<PostT[]>(2000).then(p => setPosts(p));
  }, []);
```


하지만 이런 방식은 data와 component tree 복잡도가 올라갈수록 점진적으로 더 어려워집니다. data tree내의 어떤 부분이 사라지거나 stale 상황에서는 신뢰할 수 있는 component를 작성하기 어렵습니다. 따라서 모든 data를 fetch한 다음에 렌더링하는 것이 더 현실적인 옵션이 될 수 있습니다.

### 3. Render-as-you-fetch (Suspense 사용)

앞 선 방식에서는 `setState`를 호출하기 전에 data를 fetch 하였습니다.

1. fetch 시작
2. fetch 완료
3. 렌더링 시작

Suspense를 사용하면, fetch를 먼저 시작하면서도 2,3번 단계의 순서를 바꿀 수 있습니다.

1. fetch 시작
2. **렌더링 시작**
3. **fetch 완료**

**Suspense를 사용하면, 렌더링을 시작하기 전에 응답이 오기를 기다리지 않아도 됩니다.** 
네트워크 요청을 시작하고난 후 _거의 바로_ 렌더링을 시작 시킵니다.

```ts
// 이것은 Promise가 아닙니다. Suspense를 위해 만든 특별한 객체입니다. (코드를 참고하세요)
const resource = suspenseProfileData<UserT, PostT[]>();

function ProfileTimeline() {
  const posts = resource.posts.read();
  return (
    <ul>
      {posts!.map(post => (
        <li key={post.id}>{post.title}</li>
      ))}
    </ul>
  );
}

function ProfileDetails() {
  const user = resource.user.read();

  return <h1 style={{ color: 'purple' }}>Name : {user!.name}</h1>;
}

function Profile() {
  return (
    <Suspense fallback={<h2>Loading profile...</h2>}>
      <ProfileDetails />
      <Suspense fallback={<h2>Loading posts...</h2>}>
        <ProfileTimeline />
      </Suspense>
    </Suspense>
  );
}

export default Profile;
```

![suspense](https://files.seonest.net/images/qnfqnfqnf/post/213/image.png)

| | | |
|:--:|:--:|:--:|
|![1](https://files.seonest.net/images/qnfqnfqnf/post/214/image.png)|![2](https://files.seonest.net/images/qnfqnfqnf/post/215/image.png)|![3](https://files.seonest.net/images/qnfqnfqnf/post/216/image.png)|

위 코드를 실행시키면 렌더링할 때 아래와 같은 일이 나타나는 것을 볼 수 있습니다.

1. 이미 `suspenseProfileData()` 내에서 request를 시작했습니다. 이 함수는 promise를 반환하지 않고 특별한 "resource"를 줍니다. 
(보다 현실적인 예시에서는 Relay와 같은 data 라이브러리에서 Suspense 통합버전을 제공할 것입니다.)
2. React는 `<Profile>` 렌더링을 시도합니다. child component로 `<ProfileDetails>` 와 `<ProfileTimeline>`을 반환합니다.
3.  React는 `<ProfileDetails>` 렌더링을 시도합니다. `resource.user.read()`를 호출합니다. 아직 fetch된 data가 없으므로 이 component "일시중단(suspend)" 합니다. React는 이 component를 skip 하고 tree 상의 다른 component 렌더링을 시도합니다.
4. React는 `<ProfileTimeline>` 렌더링을 시도합니다. `resource.posts.read()`를 호출합니다. 아직 fetch된 data가 없으므로 위와 마찬가지로 "일시중단(suspend)" 하고, 이 component를 skip하고 다른 component 렌더링을 시도합니다.
5. 렌더링을 시도할 component가 남아있지 않습니다. `<ProfileDetails>`가 "일시중단"된 상태이므로 React는 트리 상에서 `<ProfileDetails>` 위에 존재하는 것 중 가장 가까운 `<Suspense>` Fallbak을 찾습니다. 그것은 `<h2>Loading profile...</h2>` 입니다. 일단 지금으로서는 할 일이 다 끝났습니다.

`resource` 객체는 아직은 존재하지 않지만 결국엔 load될 data입니다.
`read()`를 호출할 경우, data 가져오거나 또는 component를 "일시중단" 합니다.

data stream을 더 보게 되면, React는 렌더링을 다시 시도하고, 그 때마다 React가 "더 깊은 곳까지" 처리할 수 있게 됩니다. `resource.user`를 불러오고나면, `<ProfileDetails>` 컴포넌트는 성공적으로 렌더링이 이루어지고 `<h2>Loading profile...</h2>` Fallback은 더 이상 필요가 없어집니다. 결국엔 모든 data가 준비될 것이고, 화면 상에는 Fallback이 사라질 것입니다.

이것은 아주 흥미로운 의미를 가집니다.
단일 요청으로 모든 필요한 data를 충족시킬 수 있는 GraphQL 클라이언트를 사용할지라도, _response를 stream하는 것은 컨텐츠를 더 일찍 보여줄 수 있게 해줍니다_

render-as-you-fetch(fetch _이후_ 가 아닌) 덕분에 `user`가 `posts`보다 더 일찍 나타나게 되더라도 응답이 완료되기도 전에 `<Suspense>` boundary 외부를 "unlock" 할 수 있게 됩니다.
이전 "fetch-then-render" 방식에서도 "waterfall"은 나타납니다 **: fetch와 렌더링사이에.** 
Suspense는 애초부터 이러한 waterfall을 경험하지 않고 Relay와 같은 라이브러리 들은 이러한 이점을 가지고 있습니다.

코드 상에서 "로딩 여부를 확인하는" `if(...)` 가 제거된 것도 확인하세요.
단지 보일러플레이트 코드를 제거하는 것 뿐만 아니라 신속한 디자인 변경을 간단하게 해줍니다.

예를 들어, user정보와 posts가 항상 함께 "나타나도록" 해야한다면, 그 둘 사이의 `<Suspense>` 를 제거해주면 됩니다. 또는 각 컴포넌트에게 _고유한_ `<Suspense>`를 부여하여 각각을 독립시켜줄 수도 있습니다. 

Suspense는 로딩 상태의 기본 단위를 바꿀 수 있게 해주고 방대한 코드 변경 없이 로딩 상태 위치를 조정할 수 있도록 해줍니다.

## 마무리하며
> 위 예제코드는 [공식문서](https://17.reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense)에서 codesandbox로도 제공해주고 있고 제가 작성한 [github repo](https://github.com/JHSeo-git/react-hello-world/tree/main/apps/ex-fetch-render)에서도 확인할 수 있습니다.

fetch-on-render, fetch-then-render, render-as-you-fetch 등등의 말은 지나가다 많이 듣고 보았던거 같은데 막상 설명하기가 어려운 점이 있던걸 보아 제대로 알지 못하고 있었던 것 같습니다.

공식문서를 보는 것이 많이 도움이 된다는 것을 이번에도 배워갑니다.

그리고 직접 만들고 분석하는 것도 도움이 되는 것 같습니다. 완벽하게 이해하기에는 무리지만 나중에 다시 보게될 때 금방 이해하고 넘어갈 수 있지 않을까 싶습니다.

위 마지막 예시에서 보면 fetch(사실은 suspense를 위한 특별한 "객체")를 렌더링을 수행하기전에 실행되는 것을 볼 수 있습니다. (네트워크 탭을 보면 더 확실히 알 수 있습니다.)
그리고 렌더링을 실제로 시작할 때는 **이미 fetch가 완료된 데이터**를 읽기만 할 뿐입니다.

앱이 커지고 방대해지면 이 개념을 이해하지 못한다면 적용하기 꽤나 까다롭겠다라고 생각한 부분입니다.

다음엔 조금 더 복잡한 앱에서의 early fetch와 같은 것들을 포함해서 더 궁금한 점에 대해서 좀 더 알아보려 합니다.

## reference

- https://github.com/JHSeo-git/react-hello-world/tree/main/apps/ex-fetch-render
- https://ko.reactjs.org/docs/concurrent-mode-suspense.html#approach-1-fetch-on-render-not-using-suspense
- https://17.reactjs.org/docs/concurrent-mode-suspense.html#traditional-approaches-vs-suspense

Traditional Approaches vs Suspense in React

> 아래 글, 영상을 보고 이해하고자 옮겨보려고 합니다.
> 
> https://www.youtube.com/watch?v=OcB3rTln-fI
> https://github.com/JSerZANP/react-source-code-walkthrough-en/blob/main/chapters/1-debug-hello-world.md

Front-End Developer라고 할 만한 실력을 가지고 있는지 매일 의심스럽습니다.

React가 어떻게 동작되는지 관심은 늘 있었지만 어물쩡 넘어갔던 적이 많았던 것 같습니다.

이런 글을 읽으면 즐겁기도 하지만 늘 저의 바닥을 확인하는 시간이 되기도 합니다.

서두가 길었지만 React를 Deep-Dive하기 전에 확실히 알고 넘어가야 하는 부분인 것 같아 이렇게 옮기려고 합니다.

React 또는 Web에서 디버깅은 어떻게 해야할지 아직까지도 잘 모르는 것 같습니다. (주로 무지성 `console.log`를 쓸 때가 많았던 것 같습니다.)

이번에 읽은 글은 React에서 Debug에 대한 얘기입니다.
(~~사실 React를 Deep하게 이해하고 싶어 글을 읽다가 이 부분이 꽤 기억에 남아 먼저 옮기고 시작해보려고 합니다.~~)

[JSer](https://github.com/JSerZANP) 라는 Front-End Developer가 작성한 React 강의(?) 첫 번째 Walkthrough 내용입니다.

이 글 이외에도 React를 사용하면서 이해하기 어려운 Deep 로직을 잘 설명해주는 [글](https://jser.dev/)과 [영상](https://www.youtube.com/c/JSerJSer)이 이어지니 읽어보시는 걸 추천드립니다.

여기서는 디버그 시 아래 2가지 경우를 알려줍니다.

- Chrome Profiler
- Breakpoints

이것을 사용해보기 위해 프로젝트 Set up 부터 하도록 하겠습니다.

## Set up

우선 React team에서 제공하는 Hello world 환경을 셋팅해봅시다.
(React 컨트리뷰트 방법 중에 간단한 dev runtime을 사용하기에 [해당 문서](https://reactjs.org/docs/how-to-contribute.html)를 참고하시면 도움이 될 것 같습니다.)

```bash
git clone https://github.com/facebook/react.git
cd react
yarn install
```

빌드를 하기 위해서는 [사전에 필요한 확인](https://reactjs.org/docs/how-to-contribute.html#contribution-prerequisites)이 있습니다.
(대부분은 충족하실 거고, 저 같은 경우는 JDK가 설치되어 있지 않아 설치하였습니다.)

그 다음 build를 해주시면 됩니다.
> The easiest way to try your changes is to run yarn build react/index,react-dom/index --type=UMD and then open fixtures/packaging/babel-standalone/dev.html. This file already uses react.development.js from the build folder so it will pick up your changes.

```bash
yarn build react/index,react-dom/index --type=UMD
```

성공하면 다음과 같이 빌드가 완료됩니다.
![build](https://files.seonest.net/images/qnfqnfqnf/post/194/image.png)

그 다음 `fixtures/packaging/babel-standalone/dev.html` 파일을 크롬에서 열면 됩니다. (React 18이 되면서 `render`함수 deprecated error 가 뜨지만 여기서는 무시하도록 합니다.)

![dev.html](https://files.seonest.net/images/qnfqnfqnf/post/196/image.png)

위와 같은 화면이 뜨면 준비는 완료되었습니다.

빌드된 내용을 조금 더 설명하자면 다음과 같습니다.

```html

<script src="../../../build/node_modules/react/umd/react.development.js"></script>
<script src="../../../build/node_modules/react-dom/umd/react-dom.development.js"></script>
```

```html

<script src="https://unpkg.com/babel-standalone@6/babel.js"></script>
```

```html

<div id="container"><h1>Hello World!</h1></div>
```

```html

<script type="text/babel">
  ReactDOM.render(
    <h1>Hello World!</h1>,
    document.getElementById('container')
  );
</script>
```

## Debug

> react-devtool을 파일로 직접 실행한 HTML에서도 확인하고 싶으시면 [설정](https://github.com/facebook/react/tree/main/packages/react-devtools#the-react-tab-doesnt-show-up)을 해야합니다.
> ![debug-tool.png](https://files.seonest.net/images/qnfqnfqnf/post/199/debug-tool.png)
> 또는, serve 와 같은 툴을 이용해 서버를 직접 실행하여도 무방합니다.

- Chrome Profiler
- Breakpoints

### Chrome Profiler
> https://developer.chrome.com/docs/devtools/evaluate-performance/#record

크롬 개발자도구에는 runtime을 record하여 performance를 측정할 수 있는 도구가 있습니다.


![performance](https://wd.imgix.net/image/admin/eZtzzkEKshRv8KFYbajF.png?auto=format&w=845)

위 코드로 record를 하면 아래와 같이 나오게 됩니다.

![record](https://files.seonest.net/images/qnfqnfqnf/post/200/image.png)

이걸 보면 브라우저에서 많은 일을 하는 것을 볼 수 있습니다.
그래서 너무 많은 정보가 있지만 그 중에 필요한 부분만 볼 것이기 때문에 걱정 안하셔도 됩니다.
(~~사실 필요한 부분을 찾는게 더 어렵달까...~~)

중간 영역에 `Main`이라고 하는 부분을 중점적으로 볼 것입니다.

![babel-render](https://files.seonest.net/images/qnfqnfqnf/post/201/image.png)

> 최신 크롬 브라우저에서 실행했을 시에 개발자 도구 performance에서 위와 같이 render 함수가 나타나지 않는 것을 확인했습니다. 원인이 무엇인지는 모르겠지만 'Evaluate Script' 라는 표시만 나타날뿐 call stack이 나타나지 않아서 이리저리 확인해보다가 포기하고 Chromium browser로  확인해보니 정상적으로 나와서 그것으로 확인했습니다.

bar 색깔은 function call과 같은 작업이 완료된 것을 의미합니다. 대부분의 연한 초록색 영역은 babel이 code를 변환 작업한 영역이라 여기서는 넘어가도록 하겠습니다.

그것보단 바로 우측에 있는 `render`를 보겠습니다. 이것이 바로 `ReactDOM.render()`가 작업한 영역입니다.

이 `render` 부분을 더 자세하게 보겠습니다. (스크롤 업, 다운으로 확대, 축소가 가능합니다.)

![render-detail](https://files.seonest.net/images/qnfqnfqnf/post/202/image.png)

화살표로 그려놨듯이 bar의 진행방향은 **위에서 아래로**, **그 다음 왼쪽에서 오른쪽** 입니다.

1. 맨 위, 맨 왼쪽을 보면 root call은 `render` 입니다. 
2. `render`는 `legacyRenderSubtreeIntoContainer`를 호출합니다.
3. 그 다음 `legacyCreateRootFromDOMContainer`를 호출합니다.
4. ...

이젠 call tree를 쉽게 이해할 수 있을 것입니다.

그래서 real DOM을 업데이트하는 마지막 call은 우측 하단에 있고 그것은 `commitPlacement`입니다. 

그리고 해당 부분을 focus한다면, 위 이미지 하단에 보듯이 실제 function 라인 링크해주고 있어서 찾아갈 수 있습니다.

![function-link](https://files.seonest.net/images/qnfqnfqnf/post/203/image.png)

이렇게 call tree에서 문제가 있는 부분을 따라가면서 해당 함수 라인을 찾아갈 수 있습니다.

### Breakpoints
> 중단점

대부분의 IDE를 사용하면 디버그할 때 가장 많이 사용되는 기능 중에 하나일 것입니다.

크롬 개발자 도구에서도 그 기능을 사용할 수 있습니다.

위에서 문제가 될 부분을 call tree를 통해 찾아갔다면 **해당 부분의 라인을 눌러서** breakpoint를 걸 수 있습니다.

![breakpoint](https://files.seonest.net/images/qnfqnfqnf/post/204/image.png)

페이지를 다시 호출하면 해당 함수가 호출될 때 breakpoint를 걸었기 때문에 해당 부분에 멈추어있습니다. 

우측을 보면 그 시점의 call stack, local variable 등을 볼 수 있습니다.

## 다음은

이젠 profiler를 통해 call tree를 이해하고 특정 함수에 breakpoint를 걸어 디버깅을 할 수 있습니다.

그러나 React 동작 코드를 이해하기 위해서는 모든 함수가 어떻게 동작하는지 알아야 합니다. 

다음은 profiler를 통해 나온 모든 함수를 따라가 이해해보도록 하겠습니다.

## reference

- https://www.youtube.com/watch?v=OcB3rTln-fI
- https://github.com/JSerZANP/react-source-code-walkthrough-en/blob/main/chapters/1-debug-hello-world.md
- https://reactjs.org/docs/how-to-contribute.html