⚛️ React

<p>React는 웹 프레임워크 시장에서 매우 인기 있는 라이브러리입니다. 2018년 React Conf에서 Hooks가 발표된 이후, 기존 클래스 컴포넌트 방식에서 함수형 컴포넌트 방식으로의 전환이 급격히 이루어졌습니다. </p><p>다양한 Hooks 중에서도 <strong>useEffect</strong>와 <strong>useLayoutEffect</strong>의 차이를 이해하지 못해 혼란스러워하는 경우가 많습니다. 이 글에서는 두 Hook의 작동 방식을 자세히 알아보고, 어떤 상황에서 각각을 사용하는 것이 좋은지 정리해보려고 합니다.</p><h2>사전 개념</h2><p>두 Hook을 이해하기 전에, React의 렌더링 과정에서 발생하는 주요 단계 두 가지를 먼저 정리해 보겠습니다.</p><ul><li><p><strong>Render</strong>: DOM 트리를 구성하기 위해 각 요소의 스타일 속성을 계산하는 과정입니다.</p></li><li><p><strong>Paint</strong>: 실제 화면에 렌더링된 레이아웃을 표시하고 업데이트하는 과정입니다.</p></li></ul><h2>useLayoutEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560964253.png" data-width="100%" data-align="center" alt="1955"><p><strong>useLayoutEffect</strong>는 컴포넌트가 렌더링된 직후, 화면에 그려지기 전에 동기적(synchronous)으로 실행됩니다. 이 동작 특성 덕분에 DOM을 조작하는 코드가 포함되어도 화면에 반영되기 전에 즉시 실행되기 때문에, 사용자는 깜빡임이나 불필요한 레이아웃 변경을 경험하지 않습니다.</p><p>이와 같은 이유로 useLayoutEffect는 화면에 즉시 반영되어야 하는 CSS 조작이나 DOM 크기 조정 등의 작업에 적합합니다. 그러나 모든 렌더링 전에 동기적으로 실행되므로 실행 시간이 길어질 경우, 첫 화면 표시가 느려질 수 있습니다.</p><h2>useEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560955057.png" data-width="100%" data-align="center" alt="1954"><p><strong>useEffect</strong>는 컴포넌트가 렌더링되고 화면에 그려진 후에 실행됩니다. 이 Hook은 비동기적(asynchronous)으로 실행되기 때문에, DOM에 변화를 주더라도 사용자가 화면에서 깜빡임이나 레이아웃 변화가 감지되기 쉽습니다. 예를 들어, 데이터를 가져오는 작업이나 이벤트 핸들러 설정과 같은 비동기 작업은 useEffect 내에서 안전하게 수행할 수 있습니다.</p><blockquote><p><strong>주의</strong>: useEffect가 DOM에 직접적으로 영향을 주는 작업을 포함할 경우, 렌더링 후 깜빡임이 발생할 수 있어 사용 경험이 떨어질 수 있습니다.</p></blockquote><h2>결론</h2><p>일반적으로는 <strong>useEffect</strong>를 기본으로 사용하는 것이 성능상 유리합니다. 예를 들어 데이터 패칭, 이벤트 핸들러 등록, 상태 초기화 및 정리와 같은 작업들은 useEffect를 사용하는 것이 적합합니다. </p><p>그러나 <strong>화면 깜빡임을 최소화</strong>해야 하는 상황이라면 useLayoutEffect를 고려해 볼 수 있습니다. 예를 들어, 특정 상태가 초기 렌더링에 따라 다르게 적용되어 화면에 순간적인 깜빡임이 발생하는 경우, useLayoutEffect가 더 나은 사용자 경험을 제공할 수 있습니다.</p><h2>Reference</h2><a data-type="bookmark" href="https://pubudu2013101.medium.com/what-is-the-real-difference-between-react-useeffect-and-uselayouteffect-51723096dc19" target="_blank"><div class="content"><div><div class="title">What is the real difference between React useEffect and useLayoutEffect?</div><div class="description">If you are a React.js developer, you will know that these are widely used React.js hooks when doing frontend development. Most of us…</div></div><div class="href">https://pubudu2013101.medium.com/what-is-the-real-difference-between-react-useeffect-and-uselayouteffect-51723096dc19</div></div><img src="https://miro.medium.com/v2/resize:fit:1200/1*ZtfwJC3TDzDVvonp5S5asA.jpeg"></a>

React는 웹 프레임워크 시장에서 매우 인기 있는 라이브러리입니다. 2018년 React Conf에서 Hooks가 발표된 이후, 기존 클래스 컴포넌트 방식에서 함수형 컴포넌트 방식으로의 전환이 급격히 이루어졌습니다. 다양한 Hooks 중에서도 useEffect와 useLayoutEffect의 차이를 이해하지 못해 혼란스러워하는 경우가 많습니다. 이 글에서

React에서 useEffect와 useLayoutEffect 차이점

Apache Kafka

<p>서버 컴포넌트와 TanStack Query를 같이 적용하게된 스토리를 적어보고자 한다.</p><p></p><h1>목표</h1><p>우선 내가 구현하고자 하는 내용의 조건은 다음과 같다.</p><ol start="NaN"><li><p>서버 컴포넌트에서 n개의 데이터를 불러와 SEO를 위해 페이지를 미리 채워 놓을것.</p></li><li><p>무한 스크롤을 이용해 데이터를 더 로드할 수 있을 것</p></li><li><p>새로고침 전까지 클라이언트에서 계속 캐싱하고 있을 것</p></li><li><p>다른 카테고리 선택시 클라이언트에서 refetching 하여 데이터를 보여줄 것</p></li></ol><p>그리고 걸린 제약 조건은 다음과 같다.</p><ol start="NaN"><li><p>데이터 fetching은 third-party 라이브러리를 사용하며, 이는 서버 사이드에서만 동작하며 클라이언트에서 호출할 수 없다.</p></li></ol><p></p><h1>구현 과정</h1><h2>1. <strong>서버 컴포넌트에서 데이터 Prefetching</strong></h2><p><a target="_blank" rel="noopener noreferrer nofollow" href="https://tanstack.com/query/latest/docs/framework/react/guides/advanced-ssr#nesting-server-components">TanStack Query 공식 문서</a>에서 가이드해주는 방법을 참고하여, 부모가 되는 서버 컴포넌트를 작성했다.</p><p><code spellcheck="false">page.tsx</code></p><pre spellcheck="false"><code>export default async function PostPage() {
 &nbsp;const queryClient = new QueryClient()
​
  // prefetch할 query를 지정한다.
 &nbsp;await queryClient.prefetchQuery({
 &nbsp; &nbsp;queryKey: ['posts'],
 &nbsp; &nbsp;queryFn: () =&gt; PostService.getPostsByTag("initial"),
  })
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;HydrationBoundary state={dehydrate(queryClient)}&gt;
 &nbsp; &nbsp; &nbsp;&lt;Posts /&gt;
 &nbsp; &nbsp;&lt;/HydrationBoundary&gt;
  )
}</code></pre><p>위 코드에서 <code spellcheck="false">&lt;HydrationBoundary state={dehydrate(queryClient)}&gt;</code> 이 부분은 서버에서 가져온 데이터를 클라이언트 컴포넌트에서 사용하기 위해 직렬화를 해주는 과정이다. 직렬화가 왜 필요한지는 여기서 설명하지 않겠다.</p><h2><strong>2. 무한 스크롤을 위한 클라이언트 컴포넌트 작성</strong></h2><p>이제 무한 스크롤을 위해 <code spellcheck="false">useInfiniteQuery</code>를 사용할 클라이언트 컴포넌트 부분을 살펴보자. prefetch한 데이터를 가져오기 위해서는 <code spellcheck="false">usePrefetchInfiniteQuery</code> 훅을 사용해야 한다.</p><p><code spellcheck="false">Post.tsx</code></p><pre spellcheck="false"><code>export default function Posts() {
 &nbsp;const { data, fetchNextPage, isFetchingNextPage } = await queryClient.prefetchInfiniteQuery({
 &nbsp; &nbsp;queryKey: ["posts"],
 &nbsp; &nbsp;queryFn: () =&gt; PostService.getPostsByTag("initial"),
 &nbsp; &nbsp;initialPageParam: undefined,
  });
 &nbsp;
 &nbsp;// ...생략
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;div&gt;
   &nbsp;  {data....}
 &nbsp; &nbsp;&lt;/div&gt;
  )
}</code></pre><h3><strong>첫 번째 문제: 서버 사이드 전용 함수 호출</strong></h3><p>여기서 첫 번째 문제가 발생했다. <code spellcheck="false">queryFn</code>에 들어가는 비동기 함수는 서버에서 실행되는 함수인데, 클라이언트 사이드에서 호출하니 에러가 발생했다.</p><p>이를 해결하기 위해 Next.js의 server action을 사용했다.</p><pre spellcheck="false"><code class="language-typescript">const getPostsAction = async (tag: string, startCursor?: string) =&gt; {
 &nbsp;"use server";
 &nbsp;return await BlogService.getPostsByTag(tag, startCursor);
};</code></pre><p>위와 같이 감싸 준다음, <code spellcheck="false">getPostsAction</code>를 클라이언트 컴포넌트에 <code spellcheck="false">props</code>로 내려주거나, 파일을 따로 분리해서 export한 후, 클라이언트에서 import해서 사용해도 된다. 나는 후자의 방법을 선택했다.</p><pre spellcheck="false"><code class="language-typescript">const { data, fetchNextPage, isFetchingNextPage } = useInfiniteQuery({
 &nbsp;queryKey: ["posts"],
 &nbsp;queryFn: ({ pageParam }: { pageParam: string | undefined }) =&gt;
 &nbsp; &nbsp;getPostsAction({ startCursor: pageParam, tag }),
 &nbsp;initialPageParam: undefined,
 &nbsp;getNextPageParam: (lastPage, pages) =&gt; lastPage.next_cursor || undefined,
 &nbsp;staleTime: Infinity,
 &nbsp;gcTime: Infinity,
});</code></pre><p>지금까지의 과정을 통해 초기 데이터도 서버에서 만들어져 초기 HTML에 포함되어 나왔고, 무한 스크롤을 통한 클라이언트에서의 데이터 페칭도 정상적으로 진행 되었다.</p><h3>두 번째 문제: 캐싱 문제</h3><p>근데 캐싱이 안된다..!! 다른 페이지로 이동했다 다시 돌아오면 클라이언트 사이드에서 스크롤을 통해 가져온 데이터는 사라져 있었다. 아무리 <code spellcheck="false">staleTime</code>과 <code spellcheck="false">gcTime</code>의 옵션을 변경해도 마찬가지였다.</p><p>원인은 다음과 같았다. 서버 컴포넌트(<code spellcheck="false">page.tsx</code>)가 실행 될 때마다 <code spellcheck="false">queryClient</code>를 새로 생성하기 때문에 캐시가 남아 있지 않게되고, <code spellcheck="false">staleTime</code>등의 옵션은 별 의미가 없어진다.</p><p>그럼 서버에서 생성한 <code spellcheck="false">queryClient</code>를 밖으로 빼면 되지 않나? 라고 생각할 수 있지만, 서버에서 만들어지다 보니 다른 사용자들끼리 공유가될 수 있는 문제가 있다.</p><blockquote><p>참조: <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/TanStack/query/discussions/5268">https://github.com/TanStack/query/discussions/5268</a></p></blockquote><h3><strong>해결</strong></h3><p>따라서 나는 서버에서 <code spellcheck="false">queryClient.prefetchQuery</code> 쓰는 것을 포기하고 다음과 같은 방법을 적용 했다.</p><ol><li><p>우선 초기 데이터를 fetching한 뒤, 데이터를 컴포넌트에 <code spellcheck="false">props</code>로 내려줬다.</p></li></ol><pre spellcheck="false"><code class="language-typescript">async function PostPage() {
 &nbsp;const initialPosts = await getPostsAction({ tag: "all" });
​
 &nbsp;return (
 &nbsp; &nbsp;&lt;section&gt;
 &nbsp; &nbsp; &nbsp;&lt;BlogPostList
 &nbsp; &nbsp; &nbsp; &nbsp;initialPosts={initialPosts}
 &nbsp; &nbsp; &nbsp;/&gt;
 &nbsp; &nbsp;&lt;/section&gt;
  );
}</code></pre><ol start="2"><li><p>전달 받은 데이터를 <code spellcheck="false">placeholderData</code>에 넣어 사용했다.</p></li></ol><pre spellcheck="false"><code>const getPlaceholderData = (): InfiniteData&lt;
 &nbsp;BlogPostsResultType,
 &nbsp;string | undefined
&gt; =&gt; {
 &nbsp;const cache = queryClient.getQueryData&lt;
 &nbsp; &nbsp;InfiniteData&lt;BlogPostsResultType, string | undefined&gt;
 &nbsp;&gt;(["posts", "all"]);
 &nbsp;return (
 &nbsp; &nbsp;cache || {
 &nbsp; &nbsp; &nbsp;pages: [initialPosts],
 &nbsp; &nbsp; &nbsp;pageParams: [],
 &nbsp;  }
  );
};
​
const { data, fetchNextPage, isFetching, isFetchingNextPage } =
  useInfiniteQuery({
   &nbsp;queryKey: ["posts", selectedTag],
   &nbsp;queryFn: ({ pageParam }: { pageParam: string | undefined }) =&gt;
   &nbsp; &nbsp;getPostsAction({ startCursor: pageParam, tag: selectedTag }),
   &nbsp;initialPageParam: undefined,
   &nbsp;getNextPageParam: lastPage =&gt; lastPage?.next_cursor,
   &nbsp;placeholderData: getPlaceholderData(),
   &nbsp;refetchOnMount: false,
   &nbsp;staleTime: Infinity,
   &nbsp;gcTime: Infinity,
  });</code></pre><p><code spellcheck="false">placeholderData</code>가 아닌 <code spellcheck="false">initialData</code>에 넣을 수도 있지만, 내 조건에서는 태그를 선택시 태그에 맞는 데이터를 보여줘야했고, 데이터 페칭시 이전 데이터를 활용하여 화면에 데이터가 사라지는 것을 막기 위해 <code spellcheck="false">placeholderData</code>를 사용했다.</p><blockquote><p>참조: <a target="_blank" rel="noopener noreferrer nofollow" href="https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query">https://tkdodo.eu/blog/placeholder-and-initial-data-in-react-query</a></p></blockquote><h1>결론</h1><p>SSR, RSC 등과 클라이언트 데이터 페칭 라이브러리인 TanStack Query를 적절하게 섞어서 사용할 수 있지만, 아직 완벽하게 사용할 수는 없는 느낌을 받았다. 서버측에서의 렌더링이 유행처럼 되가고 있으니 조만간 TanStack Query에서도 지원이 제대로 되었으면 좋겠다.</p>

서버 컴포넌트와 TanStack Query를 활용해 특정 기능을 구현한 과정을 공유하고자 합니다.

서버 컴포넌트와 TanStack Query 사용기

<h3>0. 16.8버전 이전의 함수 컴포넌트</h3><p>0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.</p><p>즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적으로 사용됐다. 함수 컴포넌트가 각광받기 시장한 것은 16.8버전에서 hook이 등장한 이우였다.</p><p>함수 컴포넌트에서 hook이 등장한 이후 함수 컴포넌트에서 상태나 생명주기 메서드 비슷한 작업을 흉내낼 수 있게되자 상대적으로 보일러플레이트가 복잡한 클래스 컴포넌트보다 함수 컴포넌트를 많이 쓰기 시작했다.</p><h1>1. 클래스 컴포넌트</h1><p>기본적으로 클래스 컴포넌트를 만들려면 클래스를 선언하고, extends로 만들고 싶은 컴포넌트를 extends해야한다.</p><ul class="tight" data-tight="true"><li><p>React.Component</p></li><li><p>React.PureComponent</p></li></ul><pre spellcheck="false"><code class="language-jsx">// Component 제네릭에 props, state를 순서로 넣어준다.
class SampleComponent extends React.Component&lt;SampleProps, SampleState&gt;
</code></pre><ul><li><p>constructor(): 컴포넌트가 초기화되는 시점에 호출된다. 컴포넌트의 state를 초기화해주는 역할을 한다.</p></li><li><p>super(): 컴포넌트를 만들면서 상속받은 상위 컴포넌트에 접근할 수 있게 도와준다.</p></li><li><p>props: 함수 인자에 넣는 것과 비슷하게 컴포넌트에 특정 속성을 전달하는 용도로 쓰인다.</p></li><li><p>state: 클래스 컴포넌트 내부에서 관리하는 값을 의미한다. 값은 항상 객체여야만 하고, 해당 값에 변화가 있을 때 리렌더링이 발생한다.</p></li><li><p>method: 렌더링 함수 내부에서 사용되는 함수이며, 보통 DOM에서 발생하는 이벤트와 함꼐 사용된다.</p><ul><li><p>constructor에서 this를 바인드 하는 방법: 생성된 함수에 bind를 활용해 강제로 this를 바인딩해야 한다. (일반적인 함수로 메서드를 만든다면 this가 undefined로 나온다. 생성자가 아닌 일반 함수로 호출하게 되면 this 전역 객체가 바인딩 되기 때문이다.</p><pre spellcheck="false"><code class="language-jsx">this.handleClick = this.handleClick.bind(this)
</code></pre></li><li><p>화살표 함수를 쓰는 방법: 실행 시점이 아닌 작성 시점에 this가 상위 스코프로 결정되는 화살표 함수를 사용한다면 굳이 바인딩을 하지 않아도 된다.</p><pre spellcheck="false"><code class="language-jsx">const sampleFunction = () =&gt; {}
</code></pre></li><li><p>렌더링 함수 내부에서 함수를 새롭게 만들어 전달하는 방법: 메서드 내부에서 새롭게 함수를 만들어서 전달하는 방법이다.</p><pre spellcheck="false"><code class="language-jsx">&lt;button onClick={()=&gt; this.handleClick()}&gt;증가&lt;/button&gt;
</code></pre><p>그러나 이 방법을 사용하게 되면 매번 렌더링이 일어날 때마다 새로운 함수를 생성해서 할당하게 되므로 최적화를 수행하기 매우 어려워진다.</p></li></ul></li></ul><h2>클래스 컴포넌트의 생명주기 메서드</h2><p>클래스 컴포넌트를 사용하면서 가장 많이 언급되는 것이 바로 생명주기이다. 클래스 컴포넌트는 많은 코드가 생명주기 메서드에 의존하고 있다.</p><p>생명주기 메서드가 샐행되는 시점은 크게 3가지로 나눌 수 있다.</p><ul class="tight" data-tight="true"><li><p>마운트(mount): 컴포넌트가 마운트(생성)되는 시점</p><ul class="tight" data-tight="true"><li><p>가상 돔에 붙는 순간</p></li></ul></li><li><p>업데이트(update): 이미 생성된 컴포넌트 내용이 변경(업데이트)되는 시점</p><ul class="tight" data-tight="true"><li><p>상태나 UI가 변경이 될 때</p></li></ul></li><li><p>언마운트(unmount): 컴포넌트가 더이상 존재하지 않는 시점</p><ul class="tight" data-tight="true"><li><p>컴포넌트가 사라질 때, DOM 트리가 빠질 때</p></li></ul></li></ul><h3>render()</h3><p>리액트 클래스 컴포넌ㅌ의 유일한 필수 값으로 항상 쓰인다.</p><p>목적: 컴포넌트 UI를 렌더링 하기 위해서 쓰인다.</p><p>실행 시점: 마운트와 업데이트 과정에서 일어난다.</p><p>💡 한가지 주의해야 할 점은 render() 함수는 항상 순수해야 하며 부수 효과가 없어야 한다.</p><blockquote><p>부수 효과가 있으면 return 값이 변경될 수 있기 때문에 화면에 나오는 부분을 예측할 수 있도록 순수해야 한다.</p></blockquote><p>같은 입력값(props 또는 state)이 들어가면 항상 같은 결과물을 반환해야 한다는 뜻이다. 따라서 render() 내부에서 state를 직접 업데이트하는 this.setState를 호출해서는 안된다.</p><p>state를 변경하는 일은 클래스 컴포넌트의 메서드나 다른 생명주기 메서드 내부에서 발생해야 한다. 그러므로 이 함수는 항상 최대한 간결하고, 깔끔하게 작성하는 것이 좋다.</p><h3>componentDidMount()</h3><p>클래스 컴포넌트가 마운트되고 준비가 됐다면 그 다음으로 호출되는 메서드가 바로 componentDidMount()이다.</p><p>목적: render와 다르게 내부에서, state 값을 변경할 수 있기 때문에 UI를 업데이트 하기 위해 쓰인다.</p><p>실행 시점: 컴포넌트가 마운드되고 준비되는 즉시 실행된다.</p><p>💡 componentDidMount는 만능이 아니며 성능 문제를 일으킬 수 있음에 주의하자.</p><p>일반적으로 state를 다루는 것은 생성자(constructor)에서 하는 것이 좋다.<br>componentDidMount에서 this.setState를 허용하는 것은 다음과 같다.</p><ol class="tight" data-tight="true"><li><p>생성자 함수에서 할 수 없는 것</p></li><li><p>API 호출 후 업데이트</p></li><li><p>DOM에 의존적인 작업</p></li></ol><h3>componentDidUpdate()</h3><p>목적: 일반적으로 state나 props의 변화에 따라 DOM을 업데이트하는 등에 쓰인다.</p><p>실행 시점: 컴포넌트 업데이트가 일어난 이후에 바로 실행된다.</p><p>💡 그러나 적절한 조건문으로 감싸지 않는다면 this.setState가 계속해서 호출되는 일이 발생할 수 있다.</p><h3>componentWillUnmount()</h3><p>목적: 메모리 누수나 불필요한 작동을 막기 위한 클린업 함수를 호출하기 위한 최적의 메소드다.</p><p>실행 시점: 컴포넌트가 언마운트되거나 더 이상 사용되지 않기 직전에 호출된다.</p><p>이 메서드 내에서는 this.setState를 호출할 수 없다, 다음과 같은 상황에서 주로 사용한다.</p><ol class="tight" data-tight="true"><li><p>이벤트 제거 (window.removeEventListener)</p></li><li><p>API 호출을 취소</p></li><li><p>setInterval, setTimeout으로 생성된 타이머 제거</p></li></ol><h3>shouldComponentUpdate()</h3><p>목적: state나 props 변경으로 리액트 컴포넌트가 다시 리렌더링되는 것을 막고 싶을 때 사용한다.</p><p>실행 시점: this.setState가 호출되면 리렌더링을 일으킨다. 그러나 해당 생명주기 메서드는 컴포넌트에 영향을 받지 않는 변화에 대해 정의할 수 있다.</p><p>💡 일반적으로 state 변화에 따라 컴포넌트가 리렌더링 되는 것은 굉장히 자연스러운 일이므로, 해당 메서드를 사용하는 것은 성능 최적화 상황에서만 고려해야 한다.</p><p>앞서 클래스 컴포넌트에는 두가지 유형, 즉 Component와 PureComponent가 있다. 이 둘의 차이점이 바로 해당 생명주기를 다루는데 있다.</p><p>Component의 경우 버튼을 누르는 대로 즉 state가 업데이트되는 대로 렌더링이 일어나지만, PureComponent는 state의 값이 업데이트되지 않아서 렌더링이 일어나지 않았다. PureComponent는 state 값에 대해 얕은 비교를 수행해 결과가 다를 때만 렌더링을 수행한다.</p><p>PureComponent는 먼저 얕은 비교만 수행하기 때문에, state가 객체와 같이 복잡한 구조의 데이터 변경은 갑지하지 못하기 때문에 개발자가 생각한대로 제대로 작동하지 않는다. 또한 애플리케이션에서 대다수의 컴포넌트가 PureComponent로 구성돼있다면 오히려 성능에 역효과를 미칠 수 있다.</p><blockquote><p>PureComponent의 경우 객체의 참조값이 바뀌어야 업데이트 된다, hook의 경우는 객체의 참조값을 갈아치운다.</p></blockquote><h3>지금까지 언급한 생명주기 메서드 정리</h3><p>렌더단계: virtualDOM에서 그려지는 과정</p><p>커밋단계: 실제 브라우저에 반영하는 단계</p><h3>static getDerivedStateFromProps()</h3><p>이제는 사라진 componentWillreceiveProps를 대체할 수 있는 메서드다.</p><p>실행 시점: render()를 호출하기 직전에 호출된다.</p><p>static으로 되어 있어 this에 접근할 수 없다. 여기서 반환하는 객체는 해당 객체의 내용이 모든 state로 들어가게 된다.</p><p>💡 명심해야 할 점은 해당 메서드도 마찬가지로 모든 redner() 실행 시에 호출된다는 점이다.</p><h3>getSnapShotBeforeUpdate()</h3><p>최근에 도입된 메서드중 하나로, componentWillUpdate()를 대체할 수 있는 메서드다.</p><p>실행 시점: DOM이 업데이트되기 직전에 호출된다.</p><p>다음과 같은 상황에서 주로 사용한다.</p><ol class="tight" data-tight="true"><li><p>렌더링되기 전에 윈도우 크기를 조절</p></li><li><p>스크롤 위치 조정</p></li></ol><h3>⭐&nbsp;getDerivedStateFromError()</h3><p>목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.</p><p>실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다.</p><p>getDerivedStateFromError(error)를 인수로 받는다. 여기서 error는 하위 컴포넌트에서 발생한 에러를 말한다.</p><p>💡 getDerivedStateFromError는 반드시 state 값을 반환해야 하며, 부수효과를 발생해서는 안된다.</p><p>그 이유는 getDerivedStateFromError의 실행시점 때문이다. 자식 컴포넌트에서 에러가 발생했을 때 어떻게 렌더링할 지 결정하는 용도로 제공되기 때문에 반드시 미리 정의해둔 state 값을 반환해야 한다.</p><p>또한 여기서 말하는 부수효과란 에러에 따른 상태 state를 반환하는 것 외의 모든 작업을 의미한다. (ex. console.error)</p><h3>⭐&nbsp;componentDidCatch()</h3><p>해당 3가지 메서드 getSnapShotBeforeUpdate, getDerivedStateFromError, componentDidCatch는 아직 리액트 훅으로 구현돼 있지 않기 때문에 이 3가지 메서드가 필요하다면 반드기 플래스 컴포넌트를 사용해야 한다.</p><p>목적: 자식 컴포넌트에서 에러가 발생했을 때 렌더링 하기 위해 사용한다.</p><p>실행 시점: 자식 컴포넌트에서 에러가 발생했을 때 호출된다, getDerivedStateFromError에서 에러를 잡고 state를 결정한 이후에 실행된다.</p><p>componentDidCatch(error, 어떤 컴포넌트가 에러를 발생시켰는지 해당 컴포넌트의 정보를 가지고 있는 info)를 인자로 받는다.</p><p>💡 componentDidCatch는 getDerivedStateFromError에서 하지 못했던 부수 효과를 수행할 수 있다.</p><p>getDerivedStateFromError는 렌더 단계에서 실행되지만, componentDidCatch는 커밋단계에서 실행디기 때문이다.</p><p>일반적으로 앞의 두 메서드는 ErrorBoundary, 즉 에러 경계 컴포넌트를 만들기위해 많이 사용된다. 그러나 모든 에러를 잡아낼 수 있는 것은 아니다. ErrorBoundary 외부에 있는 에러는 잡을 수 없다.</p><p>이를 반대로 생각하여 ErrorBoundary를 여러 개 선언해서 컴포넌트 별로 에러 처리를 다르게 적용할 수 있다. 이렇게 하면 에러가 발생한 컴포넌트 트리 영역만 별도로 처리해서 애플리케이션 전체에 에러가 전파되어 표시되는 것을 방지할 수 있다.</p><blockquote><p>해당 메서드는 주로 에러 로깅할 때 사용한다. (GA, Centry) → 특정 컴포넌트에서 어떠한 에러가 발생했는지 알 수 있기 때문</p></blockquote><h2>클래스 컴포넌트의 한계</h2><ul class="tight" data-tight="true"><li><p>데이터 흐름을 추적하기 어렵다.</p><ul class="tight" data-tight="true"><li><p>데이터를 바꿀 수 있는 위치가 너무 많다.(DidUpdate, DidMount…)</p></li></ul></li><li><p>애플리케이션 내부 로직의 재사용이 어렵다.</p><ul class="tight" data-tight="true"><li><p>로직을 재사용하려면 HOC를 통해 해결이 가능하지만, 고차 컴포넌트를 많이 감싸게 되면 래퍼 지옥에 빠져들 위험성이 커진다.</p></li></ul></li><li><p>기능이 많아질수록 컴포넌트의 크기가 커진다.</p></li><li><p>클래스는 함수에 비해 상대적으로 어렵다.</p></li><li><p>코드 크기를 최적화하기 어렵다.</p><ul class="tight" data-tight="true"><li><p>번들 크기를 줄이는 게 어렵다.</p></li></ul></li><li><p>핫 리로딩을 하는 데 상대적으로 불리하다.</p></li></ul><blockquote><p>트리 쉐이킹 → 나무를 흔든다 → 나무에 걸려있는게 떨어진다</p></blockquote><p>중복선언된 로직을 호이스팅 하여 미사용된 함수/변수를 지운다. (메모리 낭비이기 때문)</p><p>변수명을 바꿔준다 → 변수 명을 길게 한 것을 최소화하기 위해</p><blockquote><p>핫 리로딩 → 변경사항이 일어나면, 앱을 다시 시작하지 않고서도 해당 변경된 코드만 업데이트하여 변경 사항을 빠르게 적용하는 기법</p></blockquote><h2>함수 컴포넌트</h2><ol class="tight" data-tight="true"><li><p>render 내부에 필요한 함수를 선언할 때 this 바인딩을 조심할 필요가 없음</p></li><li><p>state는 객체각 아닌 각각의 원시값으로 관리되어 훨씬 사용하기 편하다.</p></li><li><p>렌더링하는 코드인 return에서 굳이 this를 사용하지 않아도 props와 state에 접근할 수 있게 됐다.</p></li></ol>

0. 16.8버전 이전의 함수 컴포넌트0.14 버전에서 소개된 함수 컴포넌트는 staless functional component, 이른바 무상태 함수 컴포넌트였다. 별도의 상태 없이 단순히 어떠한 요소를 정적으로 렌더링하는 것이 목적이었다.즉, 함수 컴포넌트는 클래스 컴포넌트에서 별다른 생명주기 메서드나 상태가 필요없이 render만 하는 경우에만 제한적