> 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)

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

Debug React "Hello world"

New features in React 18

> https://www.joshwcomeau.com/react/file-structure/ 
> 이 글을 읽고 번역과 저의 생각을 담은 글입니다.

프로그래밍을 할 때 개인적으로 중요한 몇 가지 요소가 있습니다.
그 중에서 가장 많은 고민과 시간을 쓰지만 딱히 답이 안나오는 것이 바로 파일,디렉토리 구조입니다.

워낙 다양한 상황과 조건들이 있고, 적절한 구조를 선택하고 시작했다고 하더라도 파일이 한 두개 쌓이면서 더 나은 구조로 변경하면서 시작되는 리팩토링 굴레에 많은 시간을 소비하게 되는 경우가 있습니다.

항상 이 부분에 대해서 고민하고 있었는데 그러던 중 이 글을 읽었고 좋은 참고가 될 것 같아서 번역과 저의 짧은 생각을 작성해보려고 합니다.
(이 글의 저자인 [Josh W. Comeau](https://twitter.com/JoshWComeau)는 [블로그](https://www.joshwcomeau.com/)를 운영중이며 https://css-for-js.dev 라는 교육 플랫폼을 운영하고 있습니다.)

## know-how
> 리액트는 파일/디렉토리 구조와 관련하여 딱히 의견이 없는 것으로 알려져 있습니다.

애플리케이션에서 파일과 디렉토리를 어떻게 구성해야 될까요?

"옳은" 방법은 없습니다. 하지만 리액트를 7년 이상 사용하면서 많은 다양한 접근들을 시도해왔습니다. 그리고 정말 만족스러운 솔루션으로 나만의 방법을 반복해왔습니다.

이 글에서, 현재 저의 프로젝트에 사용되는 구조를 공유할 것입니다.

## 시작에 앞서
> https://www.joshwcomeau.com/react/file-structure/#interactive-file-explorer
> 
> [예제 소스](https://github.com/JHSeo-git/delightful-structure.git)

만들어진 파일 구조를 미리 보면서 차근차근 설명하는 방향으로 글이 진행됩니다.
(저자는 js파일을 이용했고, 저는 ts로 적용했습니다.)

```
src
├── components
│   ├── App
│   │   ├── App.tsx
│   │   └── index.tsx
│   ├── Header
│   │   ├── Header.tsx
│   │   └── index.tsx
│   └── Widget
│       ├── Widget.constants.ts
│       ├── Widget.helpers.ts
│       ├── Widget.tsx
│       ├── Widget.types.ts
│       ├── WidgetChild.tsx
│       ├── index.tsx
│       └── use-stuff.hook.ts
├── index.tsx
```

## Priorities
> 어떤 것을 우선순위에 두고 구조를 최적화 했는지에 대해...

첫 번째는 component를 쉽게 import하기를 원했습니다. 그리고 아래와 같이 쓰기를 바랬습니다.
```js
import Button from '../Button';

// Or, using aliases:
import Button from '@components/Button';
```

그 다음으로는 IDE에서 작업할 때 `index.js`이 넘쳐나는 것을 원하지 않습니다.
(아래와 같은 상단 표시줄은 한 번쯤은 경험해보지 않았을까 싶습니다.)
![index.js-files](https://files.seonest.net/images/qnfqnfqnf/post/174/image.png)

실제로는 대부분의 IDE는 동일한 파일이 열려있으면 상위 디렉토리를 포함해서 표시해줍니다만 각 탭은 훨씬 더 많은 공간을 차지합니다.
![index.js-more-detail](https://files.seonest.net/images/qnfqnfqnf/post/175/image.png)

저의 목표는 아래와 같이 멋지고 깔끔한 component 파일명을 갖도록 하는 것입니다.
![image.png](https://files.seonest.net/images/qnfqnfqnf/post/176/image.png)

마지막으로 구조적 측면에서 feature별이 아닌 function별로 정리하고 싶습니다.
`components`, `hooks`, `helpers` 폴더 등이 필요합니다.

대게 복잡한 component는 많은 파일들이 관련될 것입니다.
- **sub-components**: main component만 사용하는 더 작은 components
- **Helper functions**
- **Custom hooks**
- 관련된 파일과 component에서 공유되어 사용되는 **Constants** or **Data**

이제 예제로 만든 `FileViewer` component를 봅시다.

> https://www.joshwcomeau.com/react/file-structure/#bonus-exploring-the-fileviewer-component
> 
> [제가 Clone한 소스코드](https://github.com/JHSeo-git/delightful-structure/tree/main/src/components/FileViewer)

- `FileViewer.tsx` - main component
- `FileContent.tsx`
- `Sidebar.tsx`
- `Directory.tsx`
- `File.tsx`
- `FileViewer.helpers.ts`

이상적으로는 이러한 모든 파일이 보이지 않는 곳에 숨겨져 있어야 합니다. 
오직 `FileViewer` 컴포넌트에서 작업할 때만 필요합니다. 그래서 `FileViewer`에서 작업할 때 그들이 보여야만 합니다.

> **One component per file? (한 파일에 한 개의 component?)**
> 
> 오랫동안, ESLint rule은 한 파일에 하나 이상의 컴포넌트가 정의되면 그것에 경고를 했습니다.
> 제가 생각하기에 이건 **silly(바보같은)** rule 입니다. 파일에는 원하는 만큼 Component를 포함할 수 있어야 합니다.
> 다시말해, 기본 기능이 동작한다면 non-trivial component를 자체 파일로 가져와야 합니다.
> 이렇게 하면 구조를 정리하는데 도움을 줍니다. 그리고 imports/styles/등등, 어떤 컴포넌트에 의해 사용되는지를 분명하게 만들어줍니다.

## The implementation
> 위에 얘기한 우선순위를 어떻게 반영하여 구현했는지 알아봅시다.

### Components

```
src
└── components
    └── FileViewer
        ├── ChevronRight.tsx
        ├── Directory.tsx
        ├── Expander.tsx
        ├── File.tsx
        ├── FileContent.tsx
        ├── FileIcon.tsx
        ├── FileViewer.helpers.ts
        ├── FileViewer.tsx
        ├── FileViewer.types.ts
        ├── Sidebar.tsx
        └── index.tsx
```

`FileViewer` component에 필요한 파일들입니다. `index.tsx`를 제외하고 말이죠.

`index.tsx`를 열어보겠습니다.

```tsx
export * from './FileViewer';
export { default } from './FileViewer';
```

기본적으로 redirection 입니다. 우리가 이 파일을 import할 때 같은 폴더 내 `FileViewer.tsx`를 가르키도록 합니다.  `FileViewer.tsx`는 *actual* 코드를 가지고 있습니다.

#### 왜 `index.js`에 코드를 바로 작성하지 않습니까?
위에서 설명했다 싶이 IDE에서는 `index.js`로 가득차게 될 것입니다. 그것을 원하진 않습니다.

#### 왜 모두 컴포넌트에서 이 파일을 가집니까?
import를 단순화하기 위해섭니다. 그렇지 않다면 component 폴더 안으로 drill 해야만 합니다. 
```tsx
import FileViewer from '../FileViewer/FileViewer';
```

`index.js`를 통한다면,
```tsx
import FileViewer from '../FileViewer';
```
 
#### 왜 이렇게 사용합니까?
`FileViewer`는 폴더입니다. 그리고 우리가 폴더를 import 하려면, 번들러는 index file을 찾을 것입니다. 이것은 web server 에서 계승된 convention입니다.(`my-website.com`은 `index.html`을 자동적으로 load 합니다. 그래서 `my-website.com/index.html` 처럼 쓰지 않아도 됩니다.)

사실, HTTP request 처럼 생각하는 것이 도움이 된다고 생각합니다. `src/components/FileViewer`를 import할 때, 번들러는 폴더를 가져오고 자동적으로 `index.js`를 load할 것입니다. `index.js`는 *301 REDIRECT*를 수행하는 것처럼 `src/components/FileViewer/FileViewer`를 가르킬 것입니다.

이것이 over-engineer된 것처럼 보일 수 있습니다. 그러나 이 구조는 제 모든 폴더에 있고, 저는 그것을 좋아합니다. 

### Hooks

hook이 특정한 component에서 사용한다면, 저는 위 구조를 유지할 것입니다. 그러나 만약 hook이 공통적으로 사용된다면 어떻게 할까요?

공통적으로 사용되고, 재사용가능한 hook은 `src/hooks` 폴더에 정의해두고, 다음과 같이 사용하고 있습니다.

```
src
└── hooks
    ├── use-boop.hook.js
    ├── use-bounding-box.hook.js
    ├── use-effect-on-change.hook.js
    ├── use-has-mounted.hook.js
    ├── use-is-onscreen.hook.js
    ├── use-throttled-state.hook.js
    ├── use-window-demensions.hook.js
    └── use-worker.hook.js
```

> **Naming convention YOLO policy (내 맘대로 규칙)**
> 
> 위에서 보았듯이 제가 2가지 규칙을 정한 것을 알 수 있습니다.
> 1. camelCase 대신에 kebab-case를 사용합니다.
> 2. 각 파일 명 끝에 `.hook`을 붙힙니다.
> 
> 솔직히 이 결정에 딱히 이유가 있지는 않습니다. 단지 보기 좋아서 이렇게 사용합니다.
> `use-thing.hook.js` 대신에 `useThing.js`를 사용하는 것이 더 좋을 수도 있습니다. 다른것도 다 괜찮습니다.
> 파일 이름에 당신이 어떠한 convention을 사용하든 전혀 문제가 되지 않습니다.

### Helpers
특정 component에 직접 연결되어 있지 않고 프로젝트 일부 목표를 달성하는 데 도움이 되는 function이 있으면 어떻게 될까요?

특정 component에서 사용하다가 공통적으로 사용된다면 위 hooks처럼 한 곳으로 이동시킵니다.

`FileViewer/FileViewer.helpers.js`에서 사용되었지만 여러 곳에서 필요하다는 것이 나타나면 `src/helpers`로 이동하여 `category.helpers.js`와 같은 이름으로 옮깁니다.

### Utils
먼저 한 가지 설명이 필요합니다.

많은 개발자들은 "helpers"와 "utils"를 동일한 것으로 다룹니다. 그러나 저는 그 2개를 구분합니다.

**Helper**는 주어진 프로젝트에 특정한 어떤것입니다. 이것은 일반적으로 다른 프로젝트와 공유되어 사용될 수 없습니다. 

**Utility**는 추상화된 작업을 수행하기 위한 공통 function 입니다. 제 정의에 따르면 `lodash` 라이브러리의 모든 function이 utility입니다.

#### 왜 lodash와 같은 utility library를 사용하지 않나요?

제가 쉽게 만들 수 없는 것들은 가끔 사용하기도 합니다. 그러나 제가 필요한 모든 utility가 library에 있는 것은 아닙니다.

몇 가지 `src/utils.js`에 사용되는 것이 있습니다. 새 프로젝트를 만들 때 파일을 복사합니다. 프로젝트 간 일관성을 보장하기 위해 NPM에 publish할 수 있지만 상당한 마찰을 추가하고 저에게 가치있는 trade-off가 아닙니다. 언젠가 될 수 있지만 아직은 아닙니다.

### Constants 

마지막으로 저는 `contants.js` 파일을 가집니다. 이 파일은 앱 전반의 constants를 가집니다. 대부분은 스타일과 관련된 것들입니다. 그러나 public key와 다른 "app data"를 저장하기도 합니다.

### Pages

"pages"와 관련해서는 여기서 다루지 않았습니다.

저는 이 section을 뺐습니다. 왜냐하면 그것은 사용되는 tool에 의존하고 있는 경우가 많기 때문입니다.

create-react-app과 같은 것을 사용할 때, pages를 가지지 않습니다. 모두 components 폴더 아래에 있습니다.

그러나 Next.js를 사용할 땐, `/src/pages`를 사용해야합니다. 각 라우트를 위해서 정해진 structure를 사용해야 합니다.

## Tradeoffs

모든 전략은 장단점을 가집니다. 여기서 언급된 구조에 몇 가지 단점에 대해서 말해보겠습니다.

### More boilerplate

하나의 컴포넌트를 만들 때마다 아래와 같은 파일을 생성해야합니다.
- `Widget/` 폴더
- `Widget/Widget.js` 파일
- `Widget/index.js` 파일

코드를 작성하기 전에 해야할 일이 많습니다.

운이 좋게도 수동으로 하지 않아도 됩니다. 저는 NPM에 [new-component](https://www.npmjs.com/package/new-component) 을 publish했습니다. 그리고 이것은 자동으로 위 파일을 생성해줄 것입니다.

![new-component](https://github.com/joshwcomeau/new-component/raw/master/docs/demo.gif?raw=true)

이 cli를 이용해 boilerplate를 만들 수 있습니다.
자신에 맞는 convention을 사용하기 위해 이 package를 fork하는 것을 환영합니다.

### Organized by function

일반적으로 구조화하는데 널리 사용되는 2가지 방법이 있습니다.

- By function (components, hooks, helpers ...)
- By feature (search, users, admin ...)

아래는 feature로 구조화된 코드 예시입니다.

```
src/
├── base/
│   └── components/
│       ├── Button.js
│       ├── Dropdown.js
│       ├── Heading.js
│       └── Input.js
├── search/
│   ├── components/
│   │   ├── SearchInput.js
│   │   └── SearchResults.js
│   └── search.helpers.js
└── users/
    ├── components/
    │   ├── AuthPage.js
    │   ├── ForgotPasswordForm.js
    │   └── LoginForm.js
    └── use-user.hook.js
```

여기에서 장점은 high-level의 views와 pages에서 low-level의 재사용한 "component library"를 구분하는 것을 가능하게 해줍니다. 또한 앱이 어떻게 구성되어 있는지 빠르게 이해할 수 있습니다.

**그러나 여기에 문제가 있습니다:** 실제로는 이와 같이 아주 좋게 구분하기 어렵습니다. 그리고 categorization하는 것은 실제 **정말로 어렵습니다.**

제가 이 구조를 가진 몇 가지 프로젝트에서 일을 했습니다. 그리고 매 번 중요한 마찰의 원인들 이었습니다.

컴포넌트를 만들 때 마다, component가 어디에 속하는지를 결정해야 합니다. 
만약 특정 사용자를 검색하는 search component를 만든다면 그것은 "search"에 포함되어야 할까요? "users"에 포함되어야 할까요?

경계가 모호하고 다른 개발자들은 동일한 것에 대해서도 다른 결정을 할 것입니다.

새로운 feature에서 일을 시작할 때 그 파일들을 찾아야 하는데 파일이 예상했던 위치에 없을 수도 있습니다. 
그 프로젝트에 있는 모든 개발자들은 어디로 가야하는지에 대한 자신들의 관념 모델을 가지고 있으며 그들의 관점에 적응하는 데 시간을 소비해야 합니다.

**그런데 진짜 중요한 문제가 있습니다:** _**refactoring**_

제품은 항상 발전하고 바뀝니다. 우리가 오늘 feature로 구분한 경계는 내일은 말이 안될 수도 있습니다. 제품이 변경되면 모든 파일을 이동하고 이름을 바꾸고 제품의 다음 버전과 조화를 이루도록 모든 항목을 재분류하는 데 **많은** 작업이 필요합니다.

**현실적으로, 그 일은 사실상 끝나지 않을 것입니다.** 
많은 문제가 있습니다; 팀은 이미 작업을 진행 중이며, 우리가 모든 파일을 이리저리 옮기면 더 이상 존재하지 않을 파일들에 반쯤 완성된 PRs이 있습니다. 이러한 갈등을 관리하는 것은 가능하지만 큰 고통입니다.

결국, _제품_ feature와 _코드_ feature 사이의 거리는 더욱더 멀어질 것입니다. 결국, 코드베이스에 있는 feature는 더 이상 존재하지 않는 제품을 중심으로 개념적으로 구성될 것입니다. 그래서 모든 구성원은 단지 어디로 가야하는 지를 기억해야만 합니다. 나누어진 경계는 직관적이 아닌 기껏해야 완전히 임의적이고 최악의 경우 오해를 가져옵니다.

사실상, 이 최악의 시나리오를 피하는 것은 _가능하지만_ 상대적으로 적은 이익을 위해 많은 추가 작업이 필요하다 라는게 제 의견입니다.

**그러나 대안이 너무 혼란스럽지 않을까요?** 대규모 프로젝트에 _수천_ 개의 React 컴포넌트가 있는 것은 드문 일이 아닙니다. function-based 접근을 사용한다면, `src/components` 내에 나란히 배치되지 않은 방대한 집합을 가진다는 것을 의미합니다.

이것은 big deal처럼 들릴 수도 있습니다. 그러나 사실, 저는 작은 비용이라고 느낍니다.
적어도 어디를 봐야하는지 정확이 알 수 있습니다. 원하는 파일을 찾기 위해 수십 가지 feature를 검색할 필요가 없습니다. 그리고 각각의 새 파일을 어디에 둘 것인지 파악하는데 0초가 걸립니다.

## Webpack aliases
> "@helpers": "./src/heleprs"

번들러를 사용할 때 alias를 사용할 경우가 있습니다.
(Webpack이 가장 많이 사용되기에 예시를 든 것 같습니다.)

Webpack은 _aliases_ 를 만들어 쓸 수 있게 해줍니다. 

```js
// This:
import { sortCategories } from '../../helpers/category.helpers';

// …turns into this:
import { sortCategories } from '@helpers/category.helpers';
```

**어떻게 동작하는지:** `@helpers`는 `/src/helpers` 폴더를 alias 합니다. 
파일을 이동할 때 import 경로를 수정할 필요가 없습니다.
(요지는 generic function폴더들을 alias해서 쓴다는 것 같습니다. 편한대로 사용하면 될 것 같습니다.)

> **Alias tradeoffs**
> 
> 모든 좋은 것들과 마찬가지로 Webpack aliases도 장단점을 가집니다.
> 
> 가장 큰 이슈는 표준이 아니라는 것입니다. native javascript import에서 벗어나 custom하게 작업합니다. 이것은 당신을 lock 합니다.
> 
> 또한 third-party 서비스들과 함께 사용하는 것을 더 어렵게 만들 수 있습니다. 
> `Storybook`으로 컴포넌트 라이브러리를 구축하거나 `Jest`로 단위 테스트를 하려면 webpack aliase를 이해하도록 이러한 tool을 구성되어야 합니다. 
> 대부분의 경우, 이것이 가능하지만 알아내기 위해 까다로울 수 있습니다.
> 
> 또한, 일부 에디터는 자동 완성에 어려움을 겪을 수 있지만 이 역시 일반적으로 구성할 수 있습니다. VSCode의 경우 alias를 `jsconfig.json`에서 구성할 수 있습니다.

```json
{
  "exclude": ["./node_modules"],
  "compilerOptions": {
    "baseUrl": ".",
    "paths": {
      "@components/*": ["./src/components/*"],
      "@constants": ["./src/constants/index.js"],
      "@helpers/*": ["./src/helpers/*"],
      "@hooks/*": ["./src/hooks/*"],
      "@utils": ["./src/utils/index.js"]
    }
  }
}
```

## 마무리하며
> **저자 마무리:**
> 
> 제가 어떻게 React 구조를 잡는지에 대한 내용이었습니다.
> 
> 위에서 언급했듯이, 파일 구조를 다루는데 옳고 그른 방법은 없습니다. 모든 접근 방식은 서로 다른 우선 순위를 지정하고 서로 다른 tradeoff를 만듭니다.
> 
> 그러나 개인적으로 이 구조가 잘 맞았습니다. 저는 제 시간을 제가 좋아하는 것(좋은 user interface를 만드는 것)에 쓸 수 있었습니다.
> 
> React는 매우 즐겁습니다. 2015년 이후부터 쭉 사용하고 있고 React로 작업할 때는 _여전히_ 즐겁습니다.

React(다른 프론트엔드 프로젝트를 할 때도) 프로젝트를 하면서 파일 구조 잡는게 항상 힘들고 어려운 것 같습니다.

이 구조와 비슷하게 사용하고 있었지만 매 번 조금씩 다르고 리팩토링 할 때도 고통을 겪은 것 같아 이 글이 저 스스로에게 조금은 도움이 되었으면 좋겠습니다.

이 글이 정답이라는 것은 절대 아닙니다. 저자가 말했듯이 옳고 그른 방법은 없습니다.
이 구조가 참고가 되어 더 즐거운 개발을 할 수 있으면 좋겠습니다.

제가 이 글에서 Clone하여 만든 파일 구조 예시 프로젝트는 [여기서](https://github.com/JHSeo-git/delightful-structure.git) 확인하시면 됩니다.

## reference

- https://www.joshwcomeau.com/react/file-structure/

Delightful React File/Directory Structure

React 18이 RC가 된지 꽤 된 것 같습니다.

Nextjs는 이에 대한 준비를 미리 계속 해오고 있었던 것 같습니다.(사실 발표는 2020년 말? 2021년 초에 되었으니...)

그에 맞춰 [example repo](https://github.com/vercel/next-rsc-demo)도 공개하여 사람들이 익숙해지도록 하는 것 같습니다. `next.config.js`도 계속해서 바뀌고 있고...
(~~너무 어려워...~~)

이 예제를 따라가면서 무엇이 바뀌었는지 체감**만** 해보는 형태로 진행했습니다.
(사실 아직 stable이 아니라 내가 잘못했는지 라이브러리에 문제가 있는건지 조차 잘 구분을 못하게습니다.)

날짜별로 시간날 때마다 진행해서 일기형태로 작성했습니다.

## 들어가면서

React 18 rc with Nextjs. 해보자?

- CSR, SSR, SSG, HTTP Streaming, RSC, Concurrent, ...

## day1

> Init: project
>
> - nextjs
> - tailwindcss

늘 그렇듯이 개발의 세계는 무한에 가까운 속도로 변화되고 있습니다.

React를 쓰고는 있지만 진정 어떻게 잘 쓰는건지는 잘 모르면서 다음 것으로 넘어가도 되는지 불안감이 있지만, 그래도 앞으로 나아가야할 것 같았습니다.

요점은 React 18이 rc가 되면서 꽤 큰 변화를 야기하게 될 것 같아 미리 공부하는 느낌으로 진행합니다.

아직 18버전이 정식 릴리즈가 되지 않았지만 Nextjs, Remix 등 주요 프레임워크에서는 이미 준비가 거의 완료된 느낌이었습니다.

저 또한 Nextjs를 많이 쓰고 있는 입장에서 어떤 것들이 획기적으로 바뀌고 얼마나 좋아졌는지 알고 싶습니다.

이렇게 조그만하게라도 시작하려 합니다.

Nextjs의 RSC example 프로젝트를 따라가면서 하나하나 차이점에 대해서 살펴볼까 합니다.

## day2

nextjs의 experiment 기능 중 concurrentFeatures(next 정식 release 12버전)를 켜면 middleware가 동작하지 않는 버그가 있습니다.(https://github.com/vercel/next.js/issues/31654)  
~~(너무 늦게 발견했어...ㅜㅜ 왜 안되는지 너무 답답했는데 진작 알아볼걸 그랬습니다...)~~

여기에 시간을 꽤 뺏기면서 반 포기상태로 잠들었습니다.

next.js canary 버전을 사용하게 되도 문제가 발생합니다. 이런 문제가 해결되는지 지켜봐야 될 것 같습니다.

개인적으로 vue nuxt를 써본 경험이 있었는데 middleware에 대한 경험은 미리 nuxt를 통해 했습니다. 그것과 거의 동일한 page middleware 형태로 보였습니다. 사용법은 nextjs가 친숙해서 더 좋았습니다.

## day3

전날 문제를 해결하고 다음 스텝인 SSR practice page를 진행했습니다. 앞에도 말했지만 clone practice이기 때문에 js를 ts로 옮긴것 빼곤 동일한 코드입니다.

그래도 네트워크 탭이라던지 내부 로그등을 찍어보며 확인하면서 진행하니 아주 조금은 공부가 되는 것 같습니다.

## day4

CSR concurrent mode를 쓰기 위해 suspense component를 사용하여 진행하였습니다.

그런데 server side에서 initial page를 generate하기 위해서 `typeof window === 'undefined'`를 썼는데 hydration에서 계속해서 오류가 나서 지웠습니다. 예제에는 분명히 동작하는 것으로 되어있지만

```bash
Unhandled Runtime Error
Error: An error occurred during hydration. The server HTML was replaced with client content
```

위 오류가 나타났습니다. server 에서 만든 html에 client 에서 hydration할 때 해당 컴포넌트를 mismatch하면서 나타나는 오류로 적혀져 있는데(`throwOnHydrationMismatchIfConcurrentMode`) reconciliation시에 current가 null이면 이 오류를 던지게 되어있습니다.

current 트리가 null이면 이런 오류가 발생하는데 이런 오류는 어떻게 해결할 수 있을까요?

React reconcilation은 VDOM을 더블 버퍼링(current, workInProgress)을 구성하여 변경 사항이 있을 때만 업데이트 하는 방식입니다. 각 노드들은 Fiber라고 하는 객체로 관리되며 실제적으로 React의 가장 중심이 되는 부분입니다. root에서 쭈우우욱 트리형태로 그려진다고 생각하시면 됩니다. 근데 그게 2개(current, wip)로 구성되어있고, 변경점만 업데이트한다! 라고 생각하는데 그게 맞나? 어째뜬 그렇습니다...(~~너무 어렵습니다...~~)

이 부분은 여기까지 생각하고... 왜 안되었는지를 해당 위치에 comment를 살펴보면...알 수 있을까?

```js
function throwOnHydrationMismatchIfConcurrentMode(fiber) {
  if ((fiber.mode & ConcurrentMode) !== NoMode) {
    throw new Error(
      'An error occurred during hydration. The server HTML was replaced with client content'
    );
  }
}

// OK, the next part is confusing. We're about to reconcile the Suspense
// boundary's children. This involves some custom reconciliation logic. Two
// main reasons this is so complicated.

우리는 Suspense boundary의 children을 reconcile 합니다. 이것은 몇가지 custom한
reconciliation logic을 포함하고 있습니다. 이것이 매우 복잡한 두 가지 이유가 다음과 같습니다.
두가지 이유라고 했는데 세가지 이유 적혀있음... 흠?

// First, Legacy Mode has different semantics for backwards compatibility. The
// primary tree will commit in an inconsistent state, so when we do the
// second pass to render the fallback, we do some exceedingly, uh, clever
// hacks to make that not totally break. Like transferring effects and
// deletions from hidden tree. In Concurrent Mode, it's much simpler,
// because we bailout on the primary tree completely and leave it in its old
// state, no effects. Same as what we do for Offscreen (except that
// Offscreen doesn't have the first render pass).

첫번째 이유. Legacy 모드에서는 이전 버전과 호환성을 위한 다른 semantics를 가지고 있습니다.
그래서 primary tree(기본 트리)는 일치하지 않는 상태를 commit 할 것입니다. fallback을 렌더하기
위한 두번째 pass에서 완전히 부서지지 않게 하기 위한 매우 영리한 hacks를 합니다. hidden tree로부터
effects와 deletions을 옮기는 것과 같은 것들입니다. concurrent mode에서는 더 쉽습니다.
우리가 기본 트리에서 완전히 가져오기 때문에, 그리고 오래된 상태를 남겨두고 effect를 남겨두지 않기 때문입니다.
Offscreen에서 하는 것과 동일합니다.(Offscreen에서 첫 번째 render pass에서 가지지 못한 것들은
제외됩니다.)

// Second is hydration. During hydration, the Suspense fiber has a slightly
// different layout, where the child points to a dehydrated fragment, which
// contains the DOM rendered by the server.

두번째 이유는 hydration입니다. hydration하는 동안 Suspense fiber는 약간 다른 레이아웃을
가집니다. 해당 레이아웃의 children은 dehydrated fragment를 가리키고 있습니다. 그리고
dehydrated fragment는 서버에서 렌더링된 DOM을 가지고 있습니다.

// Third, even if you set all that aside, Suspense is like error boundaries in
// that we first we try to render one tree, and if that fails, we render again
// and switch to a different tree. Like a try/catch block. So we have to track
// which branch we're currently rendering. Ideally we would model this using
// a stack.

세번째 이유. 위 2가지 이유를 셋팅을 하였더라도, Suspense는 우리가 먼저 하나의 tree를 렌더하려고 하는
점에서 error boundaries와 같습니다. 그리고 그것이 만약 실패한다면, 우리는 다시 tree를 렌더를 하고 다른
tree로 변경합니다. try/catch 구문 처럼 말이죠. 그래서 우리는 현재 렌더링하고 잇는 branch를 track(기록)
해야 합니다. 이상적으로 우리는 stack을 사용하여 이런 것을 모델합니다.
```

사실 읽어도 잘 모르겠습니다. 어째뜬 concurrent 모드 일 경우 hydration에서 문제가 발생하여 에러가 뜬다는 점 정도만 알 수 있을 것 같습니다. 카나리 버전이 아닌 12버전에서 concurrent 기능을 껐을 땐 에러가 발생하진 않았습니다.

## day5

### SSR

SSR(`getServerSideProps`) 할 시에 에러가 계속 나길래 어떤 문제인지 확인하는데 시간이 걸렸습니다.

에러 내용은 `getServerSideProps`의 return props가 serialize 가 안되었다는 내용이었습니다.

몇 가지 확인 결과 값이 없었을 때 JSON 타입으로 serialize를 하지 못하는 원인이 있었습니다.

이전에 react-query 사용 시에 hydrateState를 넘겨줄 때도 발생했던 적이 있었는데, 그 때 해결책은

```js
return {
  props: {
    data: JSON.parse(JSON.stringify(data)),
  },
};
```

위 형태로 반환해서 넘겨주는 것으로 해결했습니다. 아마 JSON 형태가 아닌 값이 있을 때 문제가 생기는 것 같아 한 번 감싸서 처리하도록 변경했습니다.
(특이한 것은 edge runtime 시에만 에러가 나고, nodejs runtime 시에는 에러가 나지 않았는데 원인은 잘 모르겠습니다.)

### SSG

SSG(`getStaticProps`)는 서버사이드라는 관점에서는 SSR과 거의 동일합니다. 개발 시에는 완전하게 동일하다고 볼 수 있습니다. 그 이유는 빌드 시에 generate를 하게 되는데 개발 모드에서는 매 요청마다 빌드를 하기 때문입니다.

SSR과 SSG의 차이점은 빌드 시점에 있습니다. next build 시에 SSG(`getStatcProps`)를 통해 만들어진 페이지는 빌드 시에 페이지를 pre-rendering하게 됩니다. 그래서 배포된 환경에서는 SSR이 매 요청마다 페이지를 생성하는 것에 비해 만들어진 페이지를 받아오기 때문에 훨씬 빠르게 사용자는 페이지를 받아올 수 있습니다.

### RSC

React Server Component. React 18 feature 중 하나입니다.

기존 Next.js에서도 서버에서, 클라이언트에서 동작을 구분하기 위해서는 pages 하위에 page에 해당하는 파일에서만 `getServerSideProps` `getStatisProps` 등을 통해서만 가능했습니다. 개별 컴포넌트 파일에서는 불가능 했죠.

RSC는 이것을 좀 더 명시적으로 구분하여 사용가능하게 합니다.
그러면 어떻게 서버에서 동작할 component와 클라이언트에서 동작할 component를 구분하는걸까?

파일명에 .server.js .client.js .js 형태로 구분합니다.

- .server.js: 서버에서 동작
- .client.js: 클라이언트에서 동작
- .js: 서버, 클라이언트 둘 다 사용 가능

또한 서버에서 동작할 때 필요한 번들들을 클라이언트로 내려받게 하지 않음으로 인해 번들사이즈가 줄어드는 효과도 있습니다.

### Streaming
> Concurrent features in React 18 include built-in support for server-side Suspense and SSR streaming support, allowing you to server-render pages using HTTP streaming.

concurrent기능은 react component들을 json처럼 직렬화해서 서버에서 맹글어서 HTTP Streaming합니다.

클라이언트에서 React는 직렬화된 streaming 정보를 api 결과 받는것처럼 받아서 UI를 그릴 수 있습니다. 이 구조를 통해 더 나은 사용자 경험을 제공하는게 목표로 보입니다.
(~~잘 못 이해한걸 수도 있습니다.~~)

### build

![build.png](https://files.seonest.net/images/qnfqnfqnf/post/152/build.png)

모든 페이지가 Streaming 페이지(입실론) 로 만들어집니다.(맞나?)
이제 맞는건지 잘 모르겠지만...당분간 좀 더 파봐야겠다는 생각이 듭니다.

## 느낀점

CSR이 혁신적인 느낌으로 다가온적이 있었는데 프론트 커뮤니티진영에서는 이젠 흐름이 바뀌는 것 같습니다. Nextjs처럼 SSR 프레임워크들이 대세가 되고, Remix가 무료로 공개되는 것처럼 이젠 CSR는 점점 져물고 있는 것처럼 보입니다.

가능하면 서버사이드를 통해 static한 파일을 사용자들에게 던져주고, interactive한 모든 것들을 Streaming이라는 기술로 대체해버리는 느낌으로 가고 있는 것 같습니다.

아마 React 18이 가져다 줄 영향은 React가 처음 나왔을 때의 그 느낌에 준하지 않을까 싶습니다.

이젠 React가 라이브러리를 넘어서 프레임워크로 가는 느낌이 강하게 듭니다... next.js, remix, solid.js 처럼 이젠 프레임워크라는 느낌이 들기도 합니다.

프론트엔드 개발자라면 이젠 Server, ci/cd등 devOps, Docker, k8s, as-a-service 등 반드시 알아야 하는 시대가 곧 올 것 같습니다. 아니 벌써 왔는지도 모르겠습니다.

다시 돌아가자면 저는 아직까진 Nextjs가 개인적으로 너무 좋습니다. 순수 React로 구현하는 것보다는 Nextjs를 사용하는 것이 훨씬 편하다고 느끼게 됩니다.

또한 프론트엔드 영역이 무한히 확장된다는 느낌이 강합니다. 트렌드도 상당히 빠르게 진행됩니다. 현재 사용되는 기술들도 다 알지 못하고 불안함에 휩싸이지만 그래도 해야됩니다. 지금 당장 해야됩니다. 그게 부족한 저에게 가장 중요한 것이라고 생각합니다. (~~그게 잘 안돼...~~)

> 해당 코드 예제는 아래에 공개되어있습니다.
> - https://github.com/JHSeo-git/prepare-react18
> 
> 원본 코드는 아래 주소입니다.
> - https://github.com/vercel/next-rsc-demo

React