⚛️ React

React는 웹 프레임워크 시장에서 매우 인기 있는 라이브러리입니다. 2018년 React Conf에서 Hooks가 발표된 이후, 기존 클래스 컴포넌트 방식에서 함수형 컴포넌트 방식으로의 전환이 급격히 이루어졌습니다. 다양한 Hooks 중에서도 useEffect와 useLayoutEffect의 차이를 이해하지 못해 혼란스러워하는 경우가 많습니다. 이 글에서는 두 Hook의 작동 방식을 자세히 알아보고, 어떤 상황에서 각각을 사용하는 것이 좋은지 정리해보려고 합니다.<h2>사전 개념</h2>두 Hook을 이해하기 전에, React의 렌더링 과정에서 발생하는 주요 단계 두 가지를 먼저 정리해 보겠습니다.<ul><li>Render: DOM 트리를 구성하기 위해 각 요소의 스타일 속성을 계산하는 과정입니다.</li><li>Paint: 실제 화면에 렌더링된 레이아웃을 표시하고 업데이트하는 과정입니다.</li></ul><h2>useLayoutEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560964253.png" data-width="100%" data-align="center" alt="1955">useLayoutEffect는 컴포넌트가 렌더링된 직후, 화면에 그려지기 전에 동기적(synchronous)으로 실행됩니다. 이 동작 특성 덕분에 DOM을 조작하는 코드가 포함되어도 화면에 반영되기 전에 즉시 실행되기 때문에, 사용자는 깜빡임이나 불필요한 레이아웃 변경을 경험하지 않습니다.이와 같은 이유로 useLayoutEffect는 화면에 즉시 반영되어야 하는 CSS 조작이나 DOM 크기 조정 등의 작업에 적합합니다. 그러나 모든 렌더링 전에 동기적으로 실행되므로 실행 시간이 길어질 경우, 첫 화면 표시가 느려질 수 있습니다.<h2>useEffect</h2><img src="https://image.until.blog/morethanmin/article/1730560955057.png" data-width="100%" data-align="center" alt="1954">useEffect는 컴포넌트가 렌더링되고 화면에 그려진 후에 실행됩니다. 이 Hook은 비동기적(asynchronous)으로 실행되기 때문에, DOM에 변화를 주더라도 사용자가 화면에서 깜빡임이나 레이아웃 변화가 감지되기 쉽습니다. 예를 들어, 데이터를 가져오는 작업이나 이벤트 핸들러 설정과 같은 비동기 작업은 useEffect 내에서 안전하게 수행할 수 있습니다.<blockquote>주의: useEffect가 DOM에 직접적으로 영향을 주는 작업을 포함할 경우, 렌더링 후 깜빡임이 발생할 수 있어 사용 경험이 떨어질 수 있습니다.</blockquote><h2>결론</h2>일반적으로는 useEffect를 기본으로 사용하는 것이 성능상 유리합니다. 예를 들어 데이터 패칭, 이벤트 핸들러 등록, 상태 초기화 및 정리와 같은 작업들은 useEffect를 사용하는 것이 적합합니다. 그러나 화면 깜빡임을 최소화해야 하는 상황이라면 useLayoutEffect를 고려해 볼 수 있습니다. 예를 들어, 특정 상태가 초기 렌더링에 따라 다르게 적용되어 화면에 순간적인 깜빡임이 발생하는 경우, useLayoutEffect가 더 나은 사용자 경험을 제공할 수 있습니다.<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

서버 컴포넌트와 TanStack Query를 같이 적용하게된 스토리를 적어보고자 한다.<h1>목표</h1>우선 내가 구현하고자 하는 내용의 조건은 다음과 같다.<ol start="NaN"><li>서버 컴포넌트에서 n개의 데이터를 불러와 SEO를 위해 페이지를 미리 채워 놓을것.</li><li>무한 스크롤을 이용해 데이터를 더 로드할 수 있을 것</li><li>새로고침 전까지 클라이언트에서 계속 캐싱하고 있을 것</li><li>다른 카테고리 선택시 클라이언트에서 refetching 하여 데이터를 보여줄 것</li></ol>그리고 걸린 제약 조건은 다음과 같다.<ol start="NaN"><li>데이터 fetching은 third-party 라이브러리를 사용하며, 이는 서버 사이드에서만 동작하며 클라이언트에서 호출할 수 없다.</li></ol><h1>구현 과정</h1><h2>1. 서버 컴포넌트에서 데이터 Prefetching</h2><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>에서 가이드해주는 방법을 참고하여, 부모가 되는 서버 컴포넌트를 작성했다.<code spellcheck="false">page.tsx</code><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>위 코드에서 <code spellcheck="false">&lt;HydrationBoundary state={dehydrate(queryClient)}&gt;</code> 이 부분은 서버에서 가져온 데이터를 클라이언트 컴포넌트에서 사용하기 위해 직렬화를 해주는 과정이다. 직렬화가 왜 필요한지는 여기서 설명하지 않겠다.<h2>2. 무한 스크롤을 위한 클라이언트 컴포넌트 작성</h2>이제 무한 스크롤을 위해 <code spellcheck="false">useInfiniteQuery</code>를 사용할 클라이언트 컴포넌트 부분을 살펴보자. prefetch한 데이터를 가져오기 위해서는 <code spellcheck="false">usePrefetchInfiniteQuery</code> 훅을 사용해야 한다.<code spellcheck="false">Post.tsx</code><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>첫 번째 문제: 서버 사이드 전용 함수 호출</h3>여기서 첫 번째 문제가 발생했다. <code spellcheck="false">queryFn</code>에 들어가는 비동기 함수는 서버에서 실행되는 함수인데, 클라이언트 사이드에서 호출하니 에러가 발생했다.이를 해결하기 위해 Next.js의 server action을 사용했다.<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>위와 같이 감싸 준다음, <code spellcheck="false">getPostsAction</code>를 클라이언트 컴포넌트에 <code spellcheck="false">props</code>로 내려주거나, 파일을 따로 분리해서 export한 후, 클라이언트에서 import해서 사용해도 된다. 나는 후자의 방법을 선택했다.<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>지금까지의 과정을 통해 초기 데이터도 서버에서 만들어져 초기 HTML에 포함되어 나왔고, 무한 스크롤을 통한 클라이언트에서의 데이터 페칭도 정상적으로 진행 되었다.<h3>두 번째 문제: 캐싱 문제</h3>근데 캐싱이 안된다..!! 다른 페이지로 이동했다 다시 돌아오면 클라이언트 사이드에서 스크롤을 통해 가져온 데이터는 사라져 있었다. 아무리 <code spellcheck="false">staleTime</code>과 <code spellcheck="false">gcTime</code>의 옵션을 변경해도 마찬가지였다.원인은 다음과 같았다. 서버 컴포넌트(<code spellcheck="false">page.tsx</code>)가 실행 될 때마다 <code spellcheck="false">queryClient</code>를 새로 생성하기 때문에 캐시가 남아 있지 않게되고, <code spellcheck="false">staleTime</code>등의 옵션은 별 의미가 없어진다.그럼 서버에서 생성한 <code spellcheck="false">queryClient</code>를 밖으로 빼면 되지 않나? 라고 생각할 수 있지만, 서버에서 만들어지다 보니 다른 사용자들끼리 공유가될 수 있는 문제가 있다.<blockquote>참조: <a target="_blank" rel="noopener noreferrer nofollow" href="https://github.com/TanStack/query/discussions/5268">https://github.com/TanStack/query/discussions/5268</a></blockquote><h3>해결</h3>따라서 나는 서버에서 <code spellcheck="false">queryClient.prefetchQuery</code> 쓰는 것을 포기하고 다음과 같은 방법을 적용 했다.<ol><li>우선 초기 데이터를 fetching한 뒤, 데이터를 컴포넌트에 <code spellcheck="false">props</code>로 내려줬다.</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>전달 받은 데이터를 <code spellcheck="false">placeholderData</code>에 넣어 사용했다.</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><code spellcheck="false">placeholderData</code>가 아닌 <code spellcheck="false">initialData</code>에 넣을 수도 있지만, 내 조건에서는 태그를 선택시 태그에 맞는 데이터를 보여줘야했고, 데이터 페칭시 이전 데이터를 활용하여 화면에 데이터가 사라지는 것을 막기 위해 <code spellcheck="false">placeholderData</code>를 사용했다.<blockquote>참조: <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></blockquote><h1>결론</h1>SSR, RSC 등과 클라이언트 데이터 페칭 라이브러리인 TanStack Query를 적절하게 섞어서 사용할 수 있지만, 아직 완벽하게 사용할 수는 없는 느낌을 받았다. 서버측에서의 렌더링이 유행처럼 되가고 있으니 조만간 TanStack Query에서도 지원이 제대로 되었으면 좋겠다.

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

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

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

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

2-3. 클래스 컴포넌트와 함수 컴포넌트

병렬처리는 다른 방법도 있지만 일단 이 포스트에서는 Promise.all과 Worker_threads의 차이를 한번 알아보자잇일단 이 두개를 무슨 목적으로 쓰는걸까?<ol><li>성능 : 여러개의 작업을 동시에 처리해서, 실행 시간을 단축시킬래!</li><li>효율 : 여러개의 코어를 가진 프로세서를 다 활용하고싶어!</li><li>확장성 : 요청이 많아도 잘 대응해보고싶어!</li></ol>뭐 다른 이유도 많겠지만 당장 떠오르는건 이정도인 것 같네잉구현 코드부터 볼까! 다들 nest cli는 글로벌로 설치 되어있잖어~<pre spellcheck="false"><code>nest new nestjs-concurrency-test --strict</code></pre>main.ts<pre spellcheck="false"><code>import { NestFactory } from '@nestjs/core';

import { AppModule } from './app.module';

async function bootstrap() {
 const app = await NestFactory.create(AppModule);
 await app.listen(3000);
}
bootstrap();

//여긴 뭐 없다잉 </code></pre>app.controller.ts<pre spellcheck="false"><code>import { Controller, Get, Query } from '@nestjs/common';

import { AppService } from './app.service';

@Controller()
export class AppController {
 constructor(private readonly appService: AppService) {}

 @Get('promise-all')
 async testPromiseAll(@Query('i') iterations: string): Promise&lt;string&gt; {
 const start = Date.now();
 const result = await this.appService.testPromiseAll(parseInt(iterations) || 10000000);
 const end = Date.now();

 return `Promise.all: ${end - start} milliseconds, result: ${result}`;
 }

 @Get('worker-threads')
 async testWorkerThreads(@Query('i') iterations: string): Promise&lt;string&gt; {
 const start = Date.now();
 const result = await this.appService.testWorkerThreads(parseInt(iterations) || 10000000);
 const end = Date.now();

 return `Worker Threads: ${end - start} milliseconds, result: ${result}`;
 }
}</code></pre>컨트롤러에 엔드포인트 두개를 맛있게 만들었엉 NestJS는 다들 아는거 맞지? 모르면 물어봐잉쿼리 파라미터 i를 받아서 몇번 반복할건지 처리할거임 ㅋㅋ 파라미터 없으면 천만번 ㅅㄱ링리턴값은 시간이 얼마나 걸렸는지 보여줄거임. result는 사실 별로 안중요해. 어차피 파라미터가 같다면 둘은 같은 값을 뱉을것실제 로직은 당연히 서비스코드에 있으니까 별거없지? (사실 서비스코드도 별거없음)app.service.ts<pre spellcheck="false"><code>import { Injectable } from '@nestjs/common';
import path from 'path';
import { Worker } from 'worker_threads';

@Injectable()
export class AppService {
 computation(iterations: number): number {
 return Array.from({ length: iterations }, (_, i) =&gt; Math.sqrt(i)).reduce(
 (acc: number, cur: number) =&gt; acc + cur,
 0,
 );
 }

 async testPromiseAll(iterations: number): Promise&lt;number&gt; {
 const tasks = Array(4)
 .fill(null)
 .map(() =&gt; this.computation(iterations / 4));

 const results = await Promise.all(tasks);

 return results.reduce((acc: number, cur: number) =&gt; acc + cur, 0);
 }

 async testWorkerThreads(iterations: number): Promise&lt;number&gt; {
 const workerPath = path.resolve(__dirname, 'workers/worker.js');
 const workers = Array(4)
 .fill(null)
 .map(
 () =&gt;
 new Promise&lt;number&gt;((resolve, reject) =&gt; {
 const worker = new Worker(workerPath, { workerData: { iterations: iterations / 4 } });

 worker.on('message', resolve);
 worker.on('error', reject);
 }),
 );

 const results = await Promise.all(workers);

 return results.reduce((acc: number, cur: number) =&gt; acc + cur, 0);
 }
}
</code></pre>일단 Promise.all, worker_threads 에서 처리할 computation 함수를 맛있게 만들었당(처음에 for문으로 했다가 멋있어 보이려고 reduce 썼잔어 ㅋ)이 함수는 iterations 만큼 배열을 만들고, 제곱근을 계산해서 그 합을 반환할거야이 코드도 별거없어. 두 함수 다 태스크를 4개로 나눠서 처리한다다만 두 함수는 각각 다른 방식으로 동시성을 구현하는데, testPromiseAll 에서는 비동기 특성을 활용해서 동시성을 구현하지만 결국엔 '단일 스레드'에서 실행된다.testWorkerThreads 에서는 실제로 다중 스레드를 사용해서 병렬적으로 처리한다잉결과를 한번볼까?파라미터 i 를 1000000 (백만)으로 주었을때<img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119606249" alt="until-1252"><img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119620802" alt="until-1253">백만번으로는 사실 별 차이 없다 ㅇㅅㅇ 오히려 promise-all로 구현했을때 아주 조금 더 빨리, 혹은 비슷한 결과가 나옴근데 i를 10000000 (천만)으로 주었을땐<img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119686200" alt="until-1254"><img src="https://image.until.blog/rolldeep-stepmerrily/article/1724119693533" alt="until-1255">2배 이상 차이가 난단말이지, 여러번 시도해도 worker-threads가 2배 이상 빠르다!그럼 이 두 방식 각각의 장단점이 뭔지 알아볼까잇<ol><li>Promise.all 의 장단점<ul><li>장점<ul><li>매우 구현이 간편하다!</li><li>메모리를 덜 씀</li><li>Node.js 환경 말고도 브라우저에서도 쓸수 있겠지?</li></ul></li><li>단점<ul><li>CPU단에서 실제 병렬 처리는 하는것은 아님</li><li>하나의 스레드에서 실행되기 때문에 여러 작업중에 하나가 블로킹되면 전체 성능이 떡락할지도?</li></ul></li></ul></li><li>Worker Threads의 장단점<ul><li>장점<ul><li>실제로 다중 코어를 활용함</li><li>각각의 Worker가 독립되어서 안정성이 높음</li><li>무거운 연산을 할땐 엄청 빠르다!</li></ul></li><li>단점<ul><li>구현이 좀 상대적으로 귀찮음(사실 쓰기 좀 꺼려지는 가장 큰 원인)</li><li>메모리를 많이 씀</li><li>오버헤드가 발생할지도..?</li><li>Node에서 지원하기 때문에 Node가 아니면 못써잉</li></ul></li></ul></li></ol>그럼 또 이제 어디에 쓰면 좋을지 알아봐야겠지<ol><li>Promise.all 활용처<ul><li>비동기 API를 한번에 호출 할 때</li><li>간단한 병렬 처리만을 필요로 할 때</li><li>I/O 작업을 동시에 처리할 때 </li></ul></li><li>Worker Threads 활용처<ul><li>엄청 거대한 데이터 처리</li><li>엄청 복잡한 연산</li><li>CPU가 두뇌 풀가동 해야할 때(이미지나 동영상 등 ?)</li><li>백그라운드에서 오래오래 실행되어야할 때</li></ul></li></ol><h1>결론</h1>알잘딱으로 잘 선택해야한다.Promise.all 이 편하긴해.. 자매품 Promise.race도 애용하자

병렬처리는 다른 방법도 있지만 일단 이 포스트에서는 Promise.all과 Worker_threads의 차이를 한번 알아보자잇일단 이 두개를 무슨 목적으로 쓰는걸까?성능 : 여러개의 작업을 동시에 처리해서, 실행 시간을 단축시킬래!효율 : 여러개의 코어를 가진 프로세서를 다 활용하고싶어!확장성 : 요청이 많아도 잘 대응해보고싶어!뭐 다른 이유도 많겠지만 당

[NestJS] Promise.all 과 Worker_threads의 차이

Spring

<h2>1. 프로젝트 생성</h2> "스프링 부트 스타터 사이트를 이용해 프로젝트 생성" <a target="_blank" rel="noopener noreferrer nofollow" href="https://start.spring.io">https://start.spring.io</a> <ul><li>프로젝트 선택<ul><li>Project: Gradle Project</li><li>Spring Boot: 3.2.5</li><li>Packaging: Jar</li><li>Java: 17</li></ul></li><li>Project Metadata<ul><li>Group: demo</li><li>Artifact: demo</li></ul></li><li>Dependencies: Spring Web, Thymeleaf</li></ul><blockquote>선택을 마친 후 Generate 를 클릭하면 zip파일 형태로 다운받아진다. 프로젝트의 실체를 보기 위해서는 압축을 해제하고 원하는 폴더에 넣은 후 IntelliJ에서 Import를 해야 한다. Import 방법: <code spellcheck="false">Open or Import</code> 클릭 → 다운받은 프로젝트 폴더로 찾아가 <code spellcheck="false">build.gradle</code> 파일 열기</blockquote>"Gradle 전체 설정" <code spellcheck="false">build.gradle</code><pre spellcheck="false"><code class="language-auto">plugins {
	id 'java'
	id 'org.springframework.boot' version '3.2.5'
	id 'io.spring.dependency-management' version '1.1.4'
}

group = 'com.example'
version = '0.0.1-SNAPSHOT'

java {
	sourceCompatibility = '17'
}

repositories {
	mavenCentral()
}

dependencies {
	implementation 'org.springframework.boot:spring-boot-starter-thymeleaf'
	implementation 'org.springframework.boot:spring-boot-starter-web'
	testImplementation 'org.springframework.boot:spring-boot-starter-test'
	testRuntimeOnly 'org.junit.platform:junit-platform-launcher'
	compileOnly 'org.springframework.boot:spring-boot-devtools'
}

tasks.named('test') {
	useJUnitPlatform()
}</code></pre><ul><li>동작 확인<ul><li>기본 메인 클래스 실행</li><li>스프링 부트 메인 실행 후 에러페이지로 간단하게 동작 확인(<code spellcheck="false">http://localhost:8080</code> ) </li></ul></li></ul><h3>IntelliJ Gradle 대신에 자바 직접 실행</h3>최근 IntelliJ 버전은 Gradle을 통해서 실행 하는 것이 기본 설정이다. 이렇게 하면 실행속도가 느리다. 다음과 같이 변경하면 자바로 바로 실행해서 실행속도가 더 빠르다.<ul><li>Preferences → Build, Execution, Deployment → Build Tools → Gradle<ul><li>Build and run using: Gradle → IntelliJ IDEA</li><li>Run tests using: Gradle → IntelliJ IDEA</li></ul></li></ul><h2>2. 주요 라이브러리 살펴보기</h2><blockquote>Gradle은 의존관계가 있는 라이브러리를 함께 다운로드 한다. 때문에 <code spellcheck="false">Spring Web</code>이랑 <code spellcheck="false">Thymeleaf</code> 겨우 2개 추가했을 뿐인데 정말 많은 라이브러리들이 꽉꽉 들어차있는 것을 볼 수 있다. 이처럼 물밑에서는 수많은 라이브러리들은 서로가 서로를 의존하고 있는데, <code spellcheck="false">Gradle</code>은 개발자가 그 모든 라이브러리들을 일일이 추가할 필요없이 '사용하겠다'라고 선언만 해주면 알아서 필요한 것들을 가져와 설치해준다.</blockquote>"스프링 부트 라이브러리"<ul><li>spring-boot-starter-web<ul><li>spring-boot-starter-tomcat: 톰캣 (웹서버)</li><li>spring-webmvc: 스프링 웹 MVC</li></ul></li><li>spring-boot-starter-thymeleaf: 타임리프 템플릿 엔진(View)</li><li>spring-boot-starter(공통): 스프링 부트 + 스프링 코어 + 로깅<ul><li>spring-boot<ul><li>spring-core</li></ul></li><li>spring-boot-starter-logging<ul><li>logback, slf4j</li></ul></li></ul></li></ul>“테스트 라이브러리”<ul><li>spring-boot-starter-test<ul><li>junit: 테스트 프레임워크</li><li>mockito: 목 라이브러리</li><li>assertj: 테스트 코드를 좀 더 편하게 작성하게 도와주는 라이브러리</li><li>spring-test: 스프링 통합 테스트 지원</li></ul></li></ul><h2>3. View 환경설정</h2><h3>Welcome Page 만들기</h3><code spellcheck="false">resources/static/index.html</code><pre spellcheck="false"><code>&lt;!DOCTYPE html&gt;
&lt;html lang="en"&gt;
&lt;head&gt;
 &lt;meta charset="UTF-8"&gt;
 &lt;title&gt;Welcome Page&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
 Hello, This is Welcome Page.
&lt;/body&gt;
&lt;/html&gt;</code></pre><ul><li>스프링 부트가 제공하는 Welcome Page 기능<ul><li><code spellcheck="false">static/index.html</code> 을 올려두면 Welcome Page 기능을 제공한다.</li></ul></li><li>thymeleaf 템플릿 엔진<ul><li>thymeleaf 공식 사이트: <a target="_blank" rel="noopener noreferrer nofollow" href="https://www.thymeleaf.org/">https://www.thymeleaf.org/</a></li><li>스프링 공식 튜토리얼: <a target="_blank" rel="noopener noreferrer nofollow" href="https://spring.io/guides/gs/serving-web-content/">https://spring.io/guides/gs/serving-web-content/</a> </li></ul></li></ul><code spellcheck="false">demo/controller/HelloController</code><pre spellcheck="false"><code class="language-java">package com.example.demo.controller;

import org.springframework.stereotype.Controller;
import org.springframework.ui.Model;
import org.springframework.web.bind.annotation.GetMapping;

@Controller
public class HelloController {

 @GetMapping("hello")
 public String hello(Model model) {
 model.addAttribute("name", "전병우");
 return "about-me";
 }

}
</code></pre><code spellcheck="false">resources/templates/about-me.html</code><pre spellcheck="false"><code>&lt;!DOCTYPE html&gt;
&lt;html lang="ko" xmlns:th="http://www.thymeleaf.org"&gt;
&lt;head&gt;
 &lt;meta charset="UTF-8"&gt;
 &lt;title&gt;About Me&lt;/title&gt;
&lt;/head&gt;
&lt;body&gt;
 &lt;p th:text="'안녕하세요. 저는 ' + ${name} + '입니다.'"&gt;&lt;/p&gt;
&lt;/body&gt;
&lt;/html&gt;</code></pre>"thymeleaf 템플릿엔진 동작 확인" <a target="_blank" rel="noopener noreferrer nofollow" href="http://localhost:8080/hello">http://localhost:8080/hello</a> "동작 흐름 그림"<img src="https://image.until.blog/jeonbw06/article/1716809002033" alt="until-307"><ul><li>컨트롤러에서 리턴 값으로 문자를 반환하면 뷰 리졸버(<code spellcheck="false">viewResolver</code>)가 화면을 찾아서 처리한다.<ul><li>스프링 부트 템플릿엔진 기본 viewName 매핑</li><li><code spellcheck="false">resources:templates/</code> + (ViewName) + <code spellcheck="false">.html</code></li></ul></li></ul><blockquote>참고: <code spellcheck="false">spring-boot-devtools</code> 라이브러리를 추가하면, <code spellcheck="false">html</code> 파일을 컴파일만 해주면 서버 재시작 없이 View 파일 변경이 가능하다. IntelliJ 컴파일 방법: 메뉴 build → Recompile</blockquote><h2>4. 빌드하고 실행하기</h2>터미널로 이동 1. <code spellcheck="false">./gradlew build --scan</code> 2. <code spellcheck="false">cd build/libs</code> 3. <code spellcheck="false">java -jar demo-0.0.1-SNAPSHOT.jar</code> 4. 실행 확인