> 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

Use A Reverse Proxy(Nginx)

> 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

웹 렌더링

> Your AI pair programmer
> _- [github copilot](https://copilot.github.com/)_

Github Copliot이 github preview로 나온지 8개월이 지났습니다.(2021.06.29)

처음 런칭을 발표했을 때는 그렇게 큰 기대를 갖고 있지 않았습니다. 원하는 코드를 적절하게 잘 작성해주기 보단 이상한 제안을 더 많이 하지 않을까? 더 도움이 될까? 라는 의구심이 처음엔 들었습니다. 무엇보다 바로 직전에 [tabnine](https://www.tabnine.com/) 이라고 하는 Machine Learning 기반이 AI IntelliSense 플러그인을 사용한 적이 있었는데 생각만큼 좋지 않았고 오히려 코드를 작성할 때 방해만 되는 느낌이 강했습니다. 이러한 경험이 선입견이 되어 아마 의구심이 좀 더 크게 있었던 것 같습니다.

그런데...Github Copilot Review 영상들이 하나 둘 씩 올라오게 되고, 후기들도 몇 가지 보게 되었습니다.

많은 의견들이 있었지만 대부분 첫인상은 "굉장히 놀라웠다" 라는 것이었습니다.
저도 궁금증이 더 커지기도 하고 신청을 하고 승인을 받아야 쓸 수 있다는 말에 바로 preview waitlist에 제 이름을 올렸습니다. 그리고 대략 2~3달 정도 걸린 시점에 메일이 하나 왔습니다.

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

위 메뉴얼 대로 설치를 했습니다. **그 이후로 쭉 Github Copilot을 사용했고 반년정도 사용한 것 같습니다.**

## What is Github Copilot?
> GPT-3 모델을 기반으로 하는 OpenAI Codex를 이용하여 만든 프로그램입니다.

OpenAI Codex를 통해 Github Copilot이 만들어졌고, 학습할 때 사용된 traning data는 Github에 오픈된 모든 코드가 사용되었습니다.

GitHub Copilot을 AI Pair 프로그램이라고 소개합니다. 주석과 코드에서 컨텍스트를 가져와 개별 라인과 전체 함수에 대해서 실시간 제안합니다. GitHub Copilot은 현재 Visual Studio Code, Neovim 및 JetBrains IDE 에서 사용 가능하고 현재 저는 VS Code에서 사용 중입니다.

![vscode-copilot-test](https://files.seonest.net/images/qnfqnfqnf/post/159/image.png)

## How it works?
![copilot-work-flow](https://files.seonest.net/images/qnfqnfqnf/post/160/image.png)

선언한 변수, 함수 명이나 주석을 보고 Github Copilot이 다음을 예측, 제안합니다. 프로젝트에서 이미 작성한 코드를 컨텍스트로 보고 최대한 일치하는 코드를 생성하려고 시도합니다.

IDE copilot 플러그인을 통해서 사용자의 주석이나 코드를 Github Copilot 서비스로 보내고, 이 서비스는 OpenAI Codex를 사용하여 코드를 합성하고 제안합니다.

또한, 작성 중인 파일의 다른 코드와 변수 이름과 상호작용하여 동작합니다. 반복적인 패턴을 형성하는 여러 라인을 입력하면 copilot은 동일한 패턴에 대해 더 많은 제안을 합니다.

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

## 개발자를 대체할까?

github copilot이 개발자를 대체하거나 자리를 위협할 거라고는 생각하지 않습니다.

copilot은 엔지니어가 아닙니다. 
개발에 있어서 자동화는 항상 따라다니는 수식어 같습니다. 그러나 프로그램은 그렇게 간단하지 않습니다. 항상 컨텍스트를 염두해 두어야 합니다. 

수 많은 제약사항을 파악하여 제공해주지 않습니다. 적절한 정답을 제안해주는 탁월한 능력은 있지만 그 정답이 해당 프로그램에서 적절한 수단임은 알려주진 않습니다.

어느 프로그램이나 마찬가지겠지만 copilot 또한 만능은 아니며, 누군가의 코드에 의해 생성된 AI라고 한다면 더 버그에 신경써야 합니다. 사용하면서 느꼈지만 copilot이 제공해준 코드가 늘 완벽하진 않기 때문에 그 부분은 늘 신경써야 합니다.

## 이슈
> 라이센스, 버그, 오래된 코드...

가장 큰 이슈는 라이센스 문제입니다.
github의 오픈된 모든 코드를 이용했다고 했지만 라이센스 문제가 있습니다. 
- GPL 라이센스를 가진 코드를 가지고 학습한 모델이 생성한 코드는 GPL 라이센스를 따라야 하는건가?
- 라이센스를 가진 코드를 이용해 학습하고 생성한 코드는 라이센스는 누가 가지는가?
- 등등

또한 insecure 코드나 악의적인 코드, 또는 버그 들이 포함될 가능성, parroting(학습 데이터가 그대로 나오는 현상) 등이 있습니다.

이런 문제를 해결하기 위해 지금처럼 preview를 진행하는 것으로 생각됩니다.

## Review
> Amazing

첫 인상은 "매우 놀랍다" 였습니다.

누군가가 코딩을 옆에서 누가 도와주는 느낌이었습니다. 내가 다음에 무엇을 할지 알고 있는 듯한 느낌이 들었던 적도 있습니다. AI Pair 프로그래밍에 걸맞게, 정말로 누군가와 페어 프로그래밍을 한다면 이런 느낌일까? 라는 생각도 들게 되었습니다.

### 1. 컨텍스트 유지
종종 쓰이는 문법이나 함수들에 대해서 항상 기억하지 못하기에 매번 구글링을 통해서 진행한적이 있지 않으신가요? 저는 그런 경우가 꽤 있습니다. 언어를 바꾸어 사용하거나 서버 프로그램, 클라이언트 프로그램을 동시에 작업을 하거나 이런 경우 그렇게 되는 것 같습니다.

- 이 언어에서는 이 syntax는 어떻게 작성하지?
- 이 프레임워크에서는 라우트 설정은 어떻게 진행하더라?
- 등등

머리가 부족해서 이런 경우가 꽤 되는데 그럴 때마다 구글링을 하고 오면(시간이 꽤 걸리기도 하고) "음... 내가 무엇을 하고 있었더라?" 라는 컨텍스트 유지가 어렵습니다.

copilot은 꽤 정확도가 높은 제안을 통해서 제 컨텍스트를 유지할 수 있게 도와주는 점에서 좋았습니다.

### 2. Chore
> 번거러운 설정파일, 실행 문법, 도커 설정, DB 설정 등

웹팩이나 바벨 같은 설정이나 config파일, yaml 문법 등 다양한 곳에서도 copilot의 도움을 받을 수 있어서 좋았습니다.

매 번 설정할 때마다 100을 모두 다 검색했다면, 50정도는 copilot을 통해서 "아 맞다 이거였지?" 하며 부드럽게 넘어갈 수 있었던 게 좋았습니다.

### 3. Code Convention
> 누가 읽어도 이해가능한 변수명, 함수명, 클래스명 등 가독성 있는 코드를 작성하는 규칙

copilot이 제 머리속을 뒤지지 않는 이상 제 코드에서 분석할 수 있는 요건은 정해져있습니다.

파일명, 모듈병, 변수명, 클래스명, 함수명, 주석 등이 copilot에게 제공되는 `INPUT` 입니다.
그래서 누구라도 읽어서 이해할만한 convention으로 작성해야만 정확한 copilot 제안을 `OUTPUT`으로 얻을 수 있습니다.

이런 점이 code convention을 자연스럽게 익히고 연습하도록 하는 점이 좋았습니다.

### 4. At least

copilot이 늘 정확한 제안을 하는 것은 아닙니다. 위에도 작성했듯이 프로그램 내에서 이 코드가 적절한 것 까지는 판단해주진 않습니다.

그러나 최소한 어느 길로 가야하는지, 즉 어떤 함수나 로직들이 사용되는지에 대한 최소한의 안내는 받을 수 있었던 것 같습니다. 그래서 검색할 때 시간을 줄여 빠르게 코드로 돌아올 수 있도록 해주었던 것 같습니다.

### 5. 학습 도구

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

Array range를 얻기 위한 함수를 작성하려 했는데 위와 같은 제안을 해주었습니다.
이전에 알지 못한 문법으로도 배열을 만들 수 있구나 라는 것을 배울 수 있었습니다.

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

postgres db를 처음 사용했는데 db command는 전혀 모르는 상태였습니다.
그러나 위와 같이 주석을 달고 copilot에게 제안을 받아 무리없이 사용했습니다.

### 6. 단점

인터넷에서 copilot의 결과를 가져오기 때문에 입력을 시작하고 실제로 제안을 받는 데는 딜레이가 있습니다. 간단한 코딩을 짜는데 copilot의 결과를 기다리느라 시간을 낭비하지 않아야 합니다.

tab 단축키가 제안을 적용하는 키로 설정되어있는데, 종종 짜증(?)나게 하는 경우가 있습니다.
내가 지금 누른 tab키는 indent tab으로 쓴건데 종종 copilot 적용이 되어버려 고통을 겪었던 적이 몇 번 있습니다.

위에도 작성되어 있지만 라이센스 문제가 아직 완전하게 해결된 것 같지는 않습니다. 기업에서 사용해야 될 때 항상 라이센스 문제를 생각해야 합니다. 

현재 Preview 단계이기 때문에 많이 사용해보고 많이 피드백하여 쓰는 것이 좋을 것 같습니다.

## 마무리

저는 주로 javascript, typescript 언어를 쓰며 react, node 등을 사용합니다.
docker를 쓰기도 하며, nginx, db, ci/cd 설정도 작성할 경우도 있습니다.
자주 쓰지 않거나 전혀 모르는 부분은 항상 구글링을 하며 시간을 많이 사용했었는데, copilot을 통해서 그 시간이 조금은 준 것 같습니다.

copilot이 완벽한 것도 아니며 프로그래머를 대체할 것이라고 생각도 하지 않습니다.
오히려 우리의 프로그래밍 효율성을 더 높게 만들어 더 나은 경험을 제공해줄 것이라고 생각합니다. 저 또한 그랬구요. 말그대로 CO-PILOT(부조종사) 처럼 생각하면 좋을 것 같습니다.

github은 개발자들에게 더 나은 DX(개발자 경험)를 제공하기 위한 로드맵을 가지고 있습니다.  [github.blog](https://github.blog/) 에 그와 관련한 글들이 있으니 읽어보시는 것도 좋을 것 같습니다.

## reference
- https://github.blog/2021-06-29-introducing-github-copilot-ai-pair-programmer/
- https://copilot.github.com/
- https://unicorn-utterances.com/posts/github-copilot-wont-replace-devs
