react19를 찾아보다가 흥미로운 사실을 발견했다. 그건 바로 forwardRef가 사라졌다는 것이다. 이전에 이미지를 전달했을 떄 forwardRef로 했던 기억이 있어 react19이전에 했었던 프로젝트를 회고할 겸 forwardRef가 어떤것이었고 react19에서는 어떻게 바뀌었는지 알아보도록 하겠다.

forwardRef?

컴포넌트가 ref를 받아 하위 컴포넌트로 전달하도록 하기 위해 사용됐다. 리액트 19 이전에는 ref를 클래스 컴포넌트와 DOM 요소에만 사용할 수 있도록 제한했기 때문에 함수형 컴포넌트에서는 본질적으로 ref를 받을 수 없었다.

ref prop으로 전달 시 undefined를 반환했고 함수형 컴포넌트에서 ref 사용 불가 경고 발생, TypeError발생 등… ref를 바로 전달하기란 불가능했다.

⛔ 사용법 (이젠 의미가 없어졌지만.. react19이전 버전을 사용할 경우는 필수로 해야한다.)

1. 자식 컴포넌트를 forwardRef로 감싸기
2. 두 번째 매개변수로 ref받기
3. 받은 ref를 원하는 DOM요소에 연결하거나 useImperativeHandle를 이용해서 자식 컴포넌트의 메서드 호출하면 된다.

useImperativeHandle

ref에 직접 내재화된 메서드를 정의할 수 있는 hook이다. 필자는 물론 해당 hook을 사용해 본적이 없다.

하지만 사용을 했을 때 다음과 같은 장점이 있다고 한다.

1. 자식 컴포넌트의 내부 메서드를 부모에 노출시킬 수 있다.
2. DOM 요소에 직접 접근하지 않고도 자식 컴포넌트와 상호작용이 가능하다.
3. 커스텀 메서드나 값들을 ref를 통해 부모에게 제공할 수 있다.

활용 예제코드는 아래와 같다.

increment()와 getValue() 메서드를 부모에서 호출하며 부모에서 자식의 내부 상태를 직접 조작하지 않고도 제어 가능하다. 마지막으로 내부 상태를 안전하게 조회하고 수정할 수 있는 인터페이스 제공하는 예시의 코드이다.

import React, { forwardRef, useImperativeHandle, useRef } from 'react';

// 자식 컴포넌트에 노출할 메서드 타입
interface CounterHandle {
  increment: () => void;
  getValue: () => number;
}

// 최소한의 카운터 컴포넌트
const Counter = forwardRef<CounterHandle>((props, ref) => {
  const [count, setCount] = React.useState(0);

  // 부모에게 노출할 메서드 정의
  useImperativeHandle(ref, () => ({
    increment: () => setCount(prev => prev + 1),
    getValue: () => count
  }));

  return <div>내부 카운트: {count}</div>;
});

// 부모 컴포넌트
const App = () => {
  const counterRef = useRef<CounterHandle>(null);
  const [message, setMessage] = React.useState('');

  return (
    <div>
      <Counter ref={counterRef} />
      <button onClick={() => counterRef.current?.increment()}>
        외부에서 증가
      </button>
      <button 
        onClick={() => {
          const value = counterRef.current?.getValue();
          setMessage(`현재 값: ${value}`);
        }}
      >
        값 확인
      </button>
      {message && <p>{message}</p>}
    </div>
  );
};

export default App;

typescript이슈

타입스크립트에서 forwardRef 사용 시 'Component definition is missing display name' 에러가 발생했었다. 이는 forwardRef() 함수를 호출할 때 익명 함수를 넘기게 되면 브라우저에서 React 개발자 도구를 사용할 때 컴포넌트의 이름이 나오지 않아 발생하는 이슈였었다.

이를 해결하기 위해서는 CustomInput.displayName = "CustomInput"; 와 같이 함수 호출의 결과를 displayName에 설정하거나, CustomInput = forwardRef(CustomInput); 와 같이 forwardRef() 함수의 호출 결과로 기존 컴포넌트를 대체하는 방법이 있다. 필자는 전자의 방법을 활용하였다. 이것들을 하지 않으면export가 제대로 되지 않았었다.

적용예시

필자는 Next.js Image컴포넌트를 활용하여 이미지src를 전달할 때 사용하였다. Next.js의 Image 컴포넌트는 최적화된 이미지 처리를 위한 특별한 컴포넌트이며, 내부적으로 복잡한 최적화를 수행하며, 이 과정에서 ref를 올바르게 전달하려면 forwardRef가 필요했다. ref를 지정해서 하면 다른 컴포를 건드리지 않고도 ref를 전달받을 수 있었다.

const GuestImage = (prop : prop) => {
  return (
    <ImageBox>
        <Image src={prop.src} alt='이미지 경로' fill className='rounded-[20px]'/>
    </ImageBox>
  )
}

interface ILayout {
  imgsrc: string;
  title: string;
  first: string;
  now: string;
}

const GuestResultLayout = forwardRef<HTMLDivElement, ILayout>((props, ref) => {
  return (
    <div ref={ref} className="py-2">
      <div className="mb-8 flex justify-center">
        <GuestImage src={props.imgsrc} />
      </div>
        );
});
// ✅ display name 설정

GuestResultLayout.displayName = "GuestResultLayout";

export default GuestResultLayout;

// 부모컴포넌트에서 해당 GuestResultLayout을 사용할 때

              <GuestResultLayout
                imgsrc={imgUrl} // 함수 컴포넌트는 ref가 존재하지 않음!
                title={data.data.title}
                first={data.data.first}
                now={data.data.now}
              />

react19에서의 변경사항

리액트 19에서는 다른 프로퍼티처럼 함수형 컴포넌트에 ref를 직접 전달할 수 있게 되어서 더 이상 forwardRef를 사용할 필요가 없어졌다.

react19이전과 이후의 코드차이는 결론만 말하자면 forwardRef가 사라지고 ref타입을 지정해줘야 한다. react19버전이었다면 코드는 ****다음과 같았을 것이다.

type prop = {
  src: string;
  ref?: React.Ref<HTMLImageElement>;
};

const GuestImage = (prop : prop) => {
  // ref prop을 직접 받음 (React 19)
  const { src, ref } = prop;

  return (
    <ImageBox>
      <Image 
        ref={ref} 
        src={src} 
        alt='이미지 경로' 
        fill 
        className='rounded-[20px]'
      />
    </ImageBox>
  );
};
// ref 프로퍼티의 타입을 추가
const GuestResultLayout = (props: ILayout & { ref?: React.Ref<HTMLDivElement> }) => {
  const { imgsrc, title, first, now, ref } = props;

  return (
    <div ref={ref} className="py-2">
      <div className="mb-8 flex justify-center">
        <GuestImage src={imgsrc} />
      </div>
      // 생략... 
  );
};

변경하면서의 장점

1. 간단한 사용 : 더 이상 ref를 넘기기 위해 forwardRef를 사용해야 하는 복잡성이 줄어들었다.
2. 보일러플레이트 코드가 줄어듦 : 매번 불필요하게 함수로 감쌀 필요 없이 깔끔한 코드 작성이 가능해졌다.
3. 일관된 패턴 : 함수형 컴포넌트, 클래스 컴포넌트, 그리고 DOM 요소에서 ref를 동일한 방식으로 처리할 수 있다.

⚠️주의사항

• 이전 버전과의 호환성 : forwardRef 코드는 계속 동작하지만, 앞으로를 대비해 점진적으로 마이그레이션 하는 것이 좋다.
• 라이브러리 호환성 : react query때도 마찬가지로 아직 react19가 적용되지 않은 라이브러리에서는 여전히 forwardRef를 사용할 수 있기 때문에 변경 점을 체크해야 한다.
• 예외케이스 존재 : 클래스 컴포넌트에서는 ref의 동작이 변경되지 않는다. DOM 요소에서는 JSX 요소에서 계속 ref를 직접 사용할 수 있다.

forwardRef는 호환성을 위해 현재는 있지만 점차 사라질 것이므로 점진적으로 마이그레이션을 하는 것이 좋다.

참고자료

forwardRef – React

[번역] 리액트 19 forwardRef 지원 중단: 앞으로 ref를 전달하기 위한 표준 가이드

[React]React 버전 18과 19에서의 ref 전달 방식 비교 분석하기(forwardRef)

[React] forwardRef 사용법, typescript 사용 시 발생하는 에러

지난 포스팅에서 useSuspenseQuery와 useQuery의 차이점, 그리고 Next.js에서 활용할 때 왜 바로 사용하면 안 되는지 등등을 배웠다. 그러면서 CSR적인 해결책만 내놨었는데 이번에는 Hydration API로 Server Rendering환경에서의 Next.js에서 어떻게 동작하고 사용할 수 있는지를 다뤄보도록 하겠다.

⛔ 주의사항 이 포스팅은 단순 사용에 초점을 두기보다는 흐름 및 설명을 두었으며 Next.js렌더링 동작 과정을 이해했다는 가정하에 작성을 한 것이다. 그러므로 Next.js의 렌더링 동작 과정을 모른다면 가볍게 알아보고 본다면 이해가 더 쉬울 것이다.

Server Rendering

먼저 아래의 방식들을 이해하려면 서버 렌더링에 대해 간단하게 알아야 한다. 서버 렌더링은 사용자가 페이지를 로드하는 즉시 볼 수 있는 초기 HTML을 서버에서 생성하는 행위이다. 이는 페이지 요청 시 즉시 발생할 수 있으며(SSR), 이전 요청이 캐시 되었거나 빌드 시간에 미리 생성(SSG)할 수도 있다.

클라이언트 렌더링의 경우 페이지가 나타나기까지 3번의 과정이 필요하다.

1. |-> Markup (without content)
2.   |-> JS
3.     |-> Query

서버 렌더링의 경우엔 위의 과정을 아래와 같이 변환한다.

1. |-> Markup (with content AND initial data)
2.   |-> JS

서버 렌더링을 통해 내용이 채워져 있고 data가 초기화되어있는 html을 생성하기 위해서는 마크업을 생성/렌더링 하기 전에 해당 데이터를 미리 가져와야(prefetch)하며, 데이터를 직렬화 가능한 형식으로 dehydrate시켜 마크업에 포함시키고 클라이언트에서는 react query 캐시로 해당 데이터를 hydrate하여 새로운 fetch를 클라이언트에서 추가적으로 할 필요가 없도록 해야 한다.

initialData

서버에서 pre-fetching 후 Props로 내려주어 useQuery 등 훅의 옵션인 initialData에 데이터를 넣어주는 방식이다.

해당 방법은 간단하긴 하지만 아래와 같은 한계점이 존재하여 대부분 아래의 Hydration을 활용한다. 한계점은 다음과 같다.

🔥 한계점

• 더 깊은 컴포넌트에서 useQuery를 호출하는 경우 해당 지점까지 initialData를 전달해야 한다.
• 여러 위치에서 동일한 쿼리를 호출하는 경우 그중 하나만 initialData를 전달하는 것은 앱이 변경될 때 문제가 발생할 수 있다. useQuery에 initialData를 가진 컴포넌트를 제거하거나 이동하는 경우 더 깊이 중첩된 useQuery는 더 이상 데이터가 없을 수도 있다. initialData를 필요로 하는 모든 쿼리에 전달하는 것은 번거롭다.
• 서버에서 쿼리가 언제 가져온 것인지 알 수 없기 때문에 dataUpdatedAt과 쿼리를 다시 가져와야 하는지 결정하는 방법은 페이지가 로드된 시점을 기준으로 한다.
• 쿼리에 대해 이미 캐시에 데이터가 있는 경우 새로운 데이터가 이전 데이터보다 최신이라도 initialData는 이를 덮어쓰지 않는다. (getServerSideProps가 매번 호출되어 새 데이터를 가져오지만, initialData 옵션을 사용하기 때문에 클라이언트 캐시와 데이터는 절대 업데이트되지 않는다.)

Hydration API

React Query에서는 dehydrate와 hydrate 함수를 제공하여 이 과정을 간소화한다.

Hydrate?

hydrate는 클라이언트 측에서 직렬화된 상태를 받아 이를 React Query의 상태로 변환한다. 서버에서 미리 가져온 데이터를 클라이언트의 쿼리 캐시에 적용하여, 네트워크 요청 없이 데이터를 사용할 수 있게한다.

Dehydrate?

dehydrate는 서버에서 불러온 데이터를 클라이언트로 전송하기 위한 직렬화 과정을 말하며, HydrationBoundary는 이러한 직렬화된 데이터를 클라이언트에서 사용할 수 있도록 하기 위한 맥락에서 사용한다.

useQuery를 통해 데이터를 불러오는 과정에서 HydrationBoundary 내에 의해 직렬화되었던 데이터가 활용되며, 이러한 방식을 통해 데이터를 효율적으로 관리하고 네트워크 요청을 줄일 수 있다. 이는 Next.js의 서버사이드 렌더링(SSR) 및 정적 사이트 생성(SSG)의 이점과 결합되어, 보다 빠른 페이지 로드 속도와 개선된 사용자 경험을 제공한다.

Prefetch

특정 데이터가 필요하거나 필요할 것으로 예상될 때, prefetching을 사용하여 미리 그 데이터를 캐시에 저장할 수 있다. 다양한 prefetching 패턴이 있다.

1. 이벤트 핸들러에서
2. 컴포넌트 내에서
3. 라우터 통합을 통해
4. 서버 렌더링 중

4번은 후술할 목차에서 다룰 것이다. prefetching의 한 가지 특별한 용도는 요청 폭포(Request Waterfalls)를 방지하는 것이다.

✨ 요청 폭포? 요청 폭포란 데이터 가져오기가 순차적으로 발생하여 성능 저하를 일으키는 상황이다.

// 요청 폭포가 발생하는 컴포넌트 구조
function BlogPage({ postId }) {
  // 포스트 데이터를 가져옴 - 첫 번째 요청
  const { data: post, isLoading: postLoading } = useQuery({
    queryKey: ['post', postId],
    queryFn: () => fetchPost(postId)
  });
  if (postLoading) return <Loading />;
return (
    <div>
      <PostDetails post={post} />
      {/* 포스트가 로드된 후에만 Comments 컴포넌트가 렌더링됨 */}
      <Comments postId={postId} />
    </div>
  );
}
function Comments({ postId }) {
  // 포스트 렌더링 후 두 번째 요청이 시작됨
  const { data: comments, isLoading } = useQuery({
    queryKey: ['comments', postId],
    queryFn: () => fetchComments(postId)
  });
if (isLoading) return <Loading />;
return (
    <div>
      {comments.map(comment => (
        <CommentItem key={comment.id} comment={comment} />
      ))}
    </div>
  );
}

이런식으로 순차적 요청을 해버리면 총 로딩 시간은 포스트 로딩 시간 + 댓글 로딩 시간이기 때문에 성능이 저하된다.

prefetchQuery

useQuery 등으로 필요하거나 렌더링되기 전에 쿼리를 미리 가져오는 데 사용할 수 있는 비동기 메서드이다.

이러기 때문에 뒤에 후술하듯이 Next.js에서 SSR을 사용할 때 데이터를 미리 가져오는 메서드로 사용하며, 서버에서 데이터를 미리 생성한 후 이후의 fetch에서는 이미 완성된 초기 데이터를 사용한다. 초기 페이지 로드 시 필요한 데이터를 미리 서버에서 불러와 클라이언트에 전달하는 것이다.

기본 사항

• 기본적으로 이 함수들은 queryClient에 구성된 기본 staleTime을 사용하여 캐시의 기존 데이터가 신선한지 또는 다시 가져와야 하는지 결정한다.
• 여기서의 staleTime은 prefetch에만 사용되므로, useQuery 호출에도 설정해야 한다.
• 팁 : 서버에서 prefetching을 하는 경우, 각 prefetch 호출에 특정 staleTime을 전달하지 않아도 되도록 해당 queryClient에 대해 0보다 높은 기본 staleTime을 설정하는 것이 좋다.
• prefetch된 쿼리에 대한 useQuery 인스턴스가 없으면, gcTime에 지정된 시간 후에 삭제되고 가비지 컬렉션이 된다.
• 또한 CSR 한정으로 Suspense와 함께 사용이 가능하다. 데이터를 로드하지만 컴포넌트를 중단시키지 않기 때문이다.

fetchQuery와는 어떤 차이점이 있을까?

사실상 기능은 동일하다. 다만 차이가 있다면 에러를 포함한 결과값, 데이터를 미리 가져오느냐 아니냐의 차이가 있다.

fetchQuery는 쿼리를 가져오고 캐싱하는 데 사용할 수 있는 비동기 메서드이다.

fetchQuery는 prefetchQuery와 달리 실패할 경우 에러를 던지며 결과값에 대한 return을 할 수 있다. 이는 서버에서 받은 queryData를 통해 jotai의 hydrateAtom 초기화나 SSR에서의 error boundary를 이용할 때 유용하다. fetchQuery는 실패한 경우에도 에러를 던질 수 있어 더 유연한 사용이 가능하다.

useQuery와 옵션은 대부분 비슷하지만 해당 부분들은 제외된다.

제외되는 부분 → 이들은 useQuery와 useInfiniteQuery에만 사용된다. enabled, refetchInterval, refetchIntervalInBackground, refetchOnWindowFocus, refetchOnReconnect, refetchOnMount, notifyOnChangeProps, throwOnError, select, suspense, placeholderData

반면 prefetchQuery는 공식문서의 설명에서도 fetchQuery와는 다르게 여기서만 렌더링되기 전에 미리 가져온다는 설명을 볼 수 있다. prefetchQuery를 통해 가져오는 쿼리에 대한 데이터가 이미 캐싱 되어 있으면 데이터를 가져오지 않는다. prefetchQuery는 항상 성공한 쿼리만 dehydrate를 해준다. 반환값을 보면 Promise<TData>가 아닌 Promise<void>인 것을 보면 알 수 있다. 그러기 때문에 결과가 필요 없이 쿼리만 가져오고 싶다면 이 메서드를 사용해야 한다.

Server Rendering & Hydration

활용예시

필자의 경우에는 useQuery API를 사용하였는데 공식문서 말로는 모든 쿼리를 항상 prefetch하는 한 useSuspenseQuery로 대체하는 것도 가능하다고 한다. useSuspenseQuery를 사용할 때 쿼리를 프리페치하는 것을 잊으면, 결과는 사용 중인 프레임워크에 따라 달라진다. 일부 경우, 데이터는 서버에서 Suspend되어 가져와지지만 클라이언트로 하이드레이션되지 않고, 클라이언트에서 다시 가져오게 된다. 이런 경우 서버와 클라이언트가 서로 다른 것을 렌더링하려고 했기 때문에 마크업 하이드레이션 불일치가 발생한다.

그러므로 웬만하면 useQuery API로 사용해보자

사용방법의 흐름은 다음과 같다.

• 프레임워크 로더 함수에서 const queryClient = new QueryClient(options)를 생성한다.
• 로더 함수에서 prefetch하려는 각 쿼리에 대해 await queryClient.prefetchQuery(...) 실행한다.
  • 가능한 경우 await Promise.all(...)을 사용하여 쿼리를 병렬로 가져오는 것이 좋다고 한다.
  • prefetch되지 않은 쿼리가 있어도 괜찮다. 이들은 서버 렌더링되지 않고, 대신 애플리케이션이 인터랙티브해진 후 클라이언트에서 가져와진다. 이는 사용자 상호작용 후에만 표시되는 콘텐츠나, 더 중요한 콘텐츠의 로딩을 차단하지 않기 위해 페이지 아래쪽에 있는 콘텐츠에 좋다.
• 로더에서 dehydrate(queryClient)를 반환한다. 이를 반환하는 정확한 구문은 프레임워크마다 다르다.
• 프레임워크 로더에서 가져온 dehydratedState를 사용하여 트리를 <HydrationBoundary state={dehydratedState}>로 감싼다. dehydratedState를 얻는 방법도 프레임워크마다 다르다.
  • 이는 각 라우트마다 수행하거나, 보일러플레이트를 줄이기 위해 애플리케이션 최상단에서 수행할 수 있다.

대학생 때 활용했던 코드는 다음과 같았다.

export default function Index({ dehydratedState }: { dehydratedState: DehydratedState }) {
  const router = useRouter();
  const hostNickname = decodeURIComponent(router.query.name as string);
  const hostSuffixArray = useGetSuffixArray(hostNickname) as string[];

  return (
    <HydrationBoundary state={dehydratedState}>
      <main className="bg--layout">
        <div className="flex flex-col justify-center p-7 mb-20">
        {// ... 생략}
        </div>
        <Footer />
      </main>
    </HydrationBoundary>
  );
}

// 통계 데이터 표시 컴포넌트
function StatisticsContent({ hostNickname, hostSuffixArray }) {
  const resetInfo = useUserStore.use.resetInfo();
  const router = useRouter();
  const { data, error, isLoading } = useQuery({
    queryKey: ["host-stats"],
    queryFn: useGetStatistic,
  });

  // 에러 처리는 useEffect으로 분리하였다.
  useEffect(() => {
    if (error) {
    // ... 생략
    }
  }, [error]);

  if (isLoading) return <ProgressCompo />;

  return data?.data ? (
    <WhiteBox className="font-Neo" isStatistic>
      <StatisticForm
        data={data.data}
        hostNickname={hostNickname}
        hostSuffixArray={hostSuffixArray}
      />
    </WhiteBox>
  ) : null;
}

export async function getServerSideProps(context) {
  const { name } = context.params;
  const queryClient = new QueryClient();

  try {
  await queryClient.prefetchQuery({
    queryKey: ["host-stats"],
    queryFn: useGetStatistic,
  });

    return {
      props: {
        dehydratedState: dehydrate(queryClient),
      },
    };
  } catch (error) {
    // 서버 측 에러 처리
  }
}

공식문서에 따르면 흥미로운 세부 사항은 실제로 세 개의 queryClient가 관련된다는 것이다. 프레임워크 로더는 렌더링 전에 발생하는 일종의 "프리로딩" 단계이며, 이 단계에는 프리페칭을 수행하는 자체 queryClient가 있다. 이 단계의 dehydrate된 결과는 서버 렌더링 프로세스와 클라이언트 렌더링 프로세스 모두에 전달되며, 각각은 자체 queryClient를 가진다. 이는 둘 다 동일한 데이터로 시작하여 동일한 마크업을 반환할 수 있도록 보장한다.

이…이게 무슨 소리지? 싶어서 나름 혼자서 정리를 해보았다.

이걸 좀 쉽게 풀어보자

SSR 프레임워크에서 React Query를 사용할 때 실제로 세 단계의 처리 과정과 세 개의 queryClient가 존재한다.

1. 프리로딩 단계(첫 번째 queryClient)

    [사용자 요청] → [서버] → [로더 함수 실행]
                             ↓
                  [프리로딩용 queryClient 생성]
                             ↓
                   [prefetchQuery로 데이터 로드]
                             ↓
                      [dehydrate 실행]

   필요한 데이터를 미리 가져오기 위하여 페이지 렌더링 전에 실행된다. 이를 통해 가져온 데이터의 스냅샷을 생성한다.(dehydratedState)

2. 서버 렌더링 단계(두 번째 queryClient)

    [dehydratedState] → [새 queryClient 생성] → [HydrationBoundary로 감싸기]
                                             ↓
                                       [React 컴포넌트 렌더링]
                                             ↓
                                          [HTML 생성]

   브라우저로 보낼 초기 HTML 만들기 위해 실제 HTML을 생성하는 단계이다. 첫 번쨰 단계에서 가져온 데이터를 재사용하므로 refetch를 하지 않는다.

3. 클라이언트 하이드레이션 단계(세 번째 queryClient)

    [브라우저가 HTML 받음] → [dehydratedState 추출] → [새 queryClient 생성]
                                                   ↓
                                          [HydrationBoundary로 감싸기]
                                                   ↓
                                             [React 활성화]

   정적 HTML을 인터랙티브 앱으로 전환하기 위해 브라우저에서 실행된다. 서버에서 가져온 동일한 데이터로 시작하며 이는 서버와 클라이언트가 일치한다.

이를 통해서 다음과 같은 특징들을 가질 수 있다.

1. 동일한 데이터 보장 : 서버와 클라이언트가 동일한 데이터로 렌더링되어 hydration 오류를 방지한다.
2. 성능 최적화 : 클라이언트에서 불필요한 재요청을 방지한다.
3. 단계 분리 : 각 단계를 명확히 분리한다.

쉽게 말해, 서버에서 데이터를 한 번 가져와서 그 "결과물"을 서버 렌더링과 클라이언트 초기화 모두에 재사용하는 구조라고 보면 된다.

에러 처리를 하고 싶다면?

React Query는 기본적으로 graceful degradation전략을 사용하는데 이는 다음을 의미한다.

1. queryClient.prefetchQuery(...)는 절대 에러를 발생시키지 않는다.
2. dehydrate(...)는 실패한 쿼리를 제외하고 성공한 쿼리만 포함한다. 이로 인해 실패한 쿼리는 클라이언트에서 재시도되며, 서버 렌더링 결과에는 전체 콘텐츠 대신 로딩 상태가 포함된다.

하지만 중요한 콘텐츠가 누락된 경우 상황에 따라 404나 500 상태 코드로 응답하고 싶을 수도 있다. 이런 경우에는 queryClient.fetchQuery(...)를 대신 사용해야 한다. 이 방법은 실패할 때 에러를 발생시켜 적절한 방식으로 처리할 수 있게 해주기 때문이다. 예시는 다음과 같이 작성할 수 있다.

// SSR에서의 예시
export async function getServerSideProps() {
  const queryClient = new QueryClient();

  try {
    // 이 데이터는 반드시 있어야 함 - 없으면 404 응답
    await queryClient.fetchQuery({
      queryKey: ['critical-data'],
      queryFn: fetchCriticalData
    });

    return {
      props: {
        dehydratedState: dehydrate(queryClient)
      }
    };
  } catch (error) {
    // 중요 데이터 로드 실패 시 404 반환
    return {
      notFound: true // 404 페이지 렌더링
    };
  }
}

어떤 이유로 재시도를 피하기 위해 실패한 쿼리를 디하이드레이트된 상태에 포함시키고 싶다면, shouldDehydrateQuery 옵션을 사용하여 기본 함수를 재정의하고 자체 로직을 구현할 수 있다. 아래는 공식문서 코드이다.

dehydrate(queryClient, {
  shouldDehydrateQuery: (query) => {
    // This will include all queries, including failed ones,
    // but you can also implement your own logic by inspecting `query`
    return true
  },
})

참고자료

Prefetching & Router Integration | TanStack Query React Docs

Server Rendering & Hydration | TanStack Query React Docs

서버에서 React Query prefetching 한 데이터 사용하기

SSR에서 React-Query 사용하기

Next.js에서 fetch와 tanstack-query 효율적으로 사용하기

⛔ 주의사항 이 포스팅은 사용하기에 초점을 두기보다는 각 hook들에 대한 속성 및 설명에 초점을 두었다. 또한 SSR에 관한 부분을 작성한 것이 아니기 때문에 이 부분은 추후 포스팅에서 다룰 예정이다.

useQuery

v4에서의 변경사항들

콜백들 삭제 + status값 일부 변경

v5에서의 변경사항은 onSuccess, onError, onSettled 콜백들은 이제 사용되지 않는다. 이는 개발자의 의도와 다르게 행동할 수 있기 때문이다.

1. 상태 동기화를 목적으로 사용했을 때 추가 렌더링 발생 ex) onSuccess 콜백에 로컬 또는 전역 상태 업데이트
2. 캐시를 사용할 경우, 콜백이 실행되지 않을 가능성이 존재한다.

캐시에서 데이터를 읽어올때 onSuccess 는 문제를 일으킬 수 있다. fetch가 발생해야 onSuccess가 실행되는데 캐시된 데이터를 사용하면 re-fetch되지 않으면서 onSuccess가 호출되지 않을 수 있기 때문이다. 이러한 버그는 이유를 알지 못하면 추적하기 어려웠다.

위와 같은 이유로 콜백함수들을 없앴지만 그럼에도 콜백을 사용해야 한다면 다음과 같은 방법으로 하면 된다.

1. 전역 콜백으로 처리

   • queryClient 설정을 할 때 queryCache 부분의 onError를 다음과 같이 처리한다.

     const queryClient = new QueryClient({
     queryCache: new QueryCache({
       onError: (error) =>
         toast.error(`Something went wrong: ${error.message}`),
     }),
     })

2. useEffect 사용

      React.useEffect(() => {
        if (query.data) {
          // ... 
        }
      }, [query.data])

   • 캐시된 데이터든 새로 fetch한 데이터든 실행이 된다. useEffect의 dependency가 동작하기 때문

3. useQuery의 select사용

    export const useTodosQuery = () =>
      useQuery({
        queryKey: ['todos'],
        queryFn: fetchTodos,
        select: (data) => data.map((todo) => todo.name.toUpperCase()),
      })

   • 데이터가 있을 때마다 실행되는 option이다. 이럴 경우 undefined인 경우를 고려할 필요가 없다.

4. isLoading, isPending, isFetching, isError 등으로 컴포넌트 내에서 처리한다. 이런 값들을 이용해서 컴포넌트에서 적절한 UI처리가 가능하기도 하다.

    function TodoList() {
      const todos = useQuery({
        queryKey: ['todos'],
        queryFn: fetchTodos
      })
   
      if (todos.isPending) {
        return 'Loading...'
      }
   
      // 에러 처리 방식
      //  todos.status === 'error' 로도 확인할 수 있다. 여기서의 todos는 queryKey로 보면 된다. 
      if (todos.isError) {
        return 'An error occurred'
      }
   
      return (
        <div>
          {todos.data.map((todo) => (
            <Todo key={todo.id} {...todo} />
          ))}
        </div>
      )
    }

⭐ react query의 status로도 상태를 체크할 수 있다. status에 pending, error, success이 있기 때문이다.

const { status } = useQuery({ 
  queryKey: ['todos'], 
  queryFn: fetchTodos 
})
if (status === 'loading') {
  return <div>Loading...</div>
}
if (status === 'error') {
  return <div>Error!</div>
}
if (status === 'success') {
  return <div>Data loaded!</div>
}

이러면 isLoading, isError등을 활용하는 것과 동일한 결과를 얻어낼 수 있다.

status 변경

loading → pending

isLoading → isPending

isPending && isFetching의 기능인 isInitialLoading → isLoading

remove메서드 삭제

캐시에서 쿼리를 제거하는 remove메서드를 이제 사용하지 않는다. 쿼리를 제거한 다음 렌더에는 새로운 로딩 상태로 이어지기 때문에 활성화 되어 있는 쿼리를 제거하는 것은 맞지 않다고 하기 때문이다. 쿼리를 제거해야 하는 경우에는 queryClient.removeQueries({ queryKey: key })를 사용해야 한다고 한다.

const queryClient = useQueryClient();
 const query = useQuery({ queryKey, queryFn });
- query.remove()
+ queryClient.removeQueries({ queryKey })

suspense 삭제

useQuery에서 사용되던 suspense: boolean 옵션은 제거되었다. 이러면 useQuery에서의 suspense는 어디로갔냐할 수 있지만 뒤에 후술할 훅들이 suspense를 사용해 데이터 패칭을 하게 된다.

useSuspenseQuery

v5부터는 useSuspenseQuery, useSuspenseInfiniteQuery와 useSuspenseQueries를 사용함으로써 안정적으로 suspense를 사용해 데이터 패칭을 할 수 있다. 새로 추가된 suspense hook은 로딩과 에러 상태를 Suspense와 ErrorBoudnary가 처리하기 때문에 status가 언제나 success인 data 값을 반환한다.

기존 useQuery와의 차이점

• 성공한 결과만을 전달해줘서 반환이 undefined일 때를 생각하지 않아도 된다.
• 이 훅을 사용하려면 Promise가 발생하는 부모의 컴포넌트에서 Suspense로 반드시 묶어줘야한다.
• isPending, pending, isLoading 등을 사용하지 않아도 된다.

Options

대부분은 useQuery와 동일하지만 다음 옵션들은 제거된다.

• throwOnError(에러를 throw할지 여부)

  • throwOnError의 기본값을 보다시피 데이터가 undefined가 될 수 있어서 제거되었다고 볼 수 있다.

    throwOnError: (error, query) => typeof query.state.data === 'undefined'

• enabled(쿼리 활성화 여부)

• placeholderData(임시 데이터)

반환값

대부분은 비슷하지만 아래의 차이점이 있는데 그 이유는 Suspense가 로딩 상태를 처리하므로 컴포넌트가 렌더링되는 시점에는 이미 데이터가 있는 상태로 보기 때문이다.

• 위에 서술되었다시피 data는 항상 보장된다. 즉, undefined일 수 없다는 것이다.
• isPlaceholderData가 없다. (임시 데이터를 사용하지 않는다.)
• status는 항상 success이다.

취소가 작동하지 않는다.

suspense의 작동 방식 때문에 요청 취소 기능을 사용할 수 없다.

⭐ Suspense의 작동 방식

1. Suspense는 Promise가 resolve될 때까지 렌더링을 중단(suspend)한다.
2. 한번 Promise가 시작되면, React는 그 Promise의 완료를 기다린다.
3. 이 시점에서 Promise를 취소하더라도 Suspense는 여전히 원래 Promise의 결과를 기다리게 된다.

이러기 때문에 suspense 모드를 사용할 때는 상태값과 에러 객체가 필요하지 않으며, 대신 React.Suspense 컴포넌트를 사용한다. 쿼리를 조건부로 활성화/비활성화 할 수가 없다. 일반적으로 의존적인 쿼리의 경우 이는 필요하지 않고 suspense를 사용하면 컴포넌트 내의 모든 쿼리가 순차적으로 가져와지기 때문이다.

SSR에서 무작정 사용하기X

App router가 14까지도 안정성에 있어 문제가 있어왔어서 app router 대신에 page router를 활용해서 useSuspenseQuery를 무작정 활용하려고 했을 때 바로 에러가 나왔었다…

Next.js의 SSR에서 왜 바로 사용을 못할까?

기본적으로 따로 CSR을 설정해주지 않는 이상 Next.js는 SSR형태이다.

여러 글을 읽게 되었고 그 중 인상적인 것을 보았다.

1. Suspense는 서버 사이드에서 지원되지 않는다.
2. 서버에서 렌더링 될 때 Suspense를 읽는다.

⭐ Page Router의 SSR 동작방식

1. 서버에서 전체 페이지를 한 번에 렌더링
2. HTML을 클라이언트로 전송
3. 클라이언트에서 hydration 이 과정에서 서버에서 Suspense를 만나면 제대로 처리하지 못하며 Suspense 내부의 데이터 페칭이 끝날 때까지 전체 렌더링이 블로킹된다.

Solution

SSR을 활용할 경우에는 prefetchQuery, Hydration API를 활용하여 해야한다.

CSR로 처리를 하거나 ReactQueryStreamedHydration의 기능을 활용해야 한다.

⭐ ReactQueryStreamedHydration? 컴포넌트에서 useSuspenseQuery를 호출하는 것만으로도 서버(클라이언트 컴포넌트 내)에서 데이터를 가져올 수 있게 해준다. SuspenseBoundaries가 해결됨에 따라 결과가 서버에서 클라이언트로 스트리밍 된다. useSuspenseQuery를 Suspense 경계로 감싸지 않고 호출하면, fetch가 완료될 때까지 HTML 응답이 시작되지 않는다. 이를 구현하려면 먼저 실험적인 패키지를 설치하고 앱을 ReactQueryStreamedHydration 컴포넌트로 감싸면 된다.

활용 예시코드

// app/providers.tsx
function makeQueryClient() {
  return new QueryClient({
    defaultOptions: {
      queries: {
        // SSR에서는 보통 클라이언트에서 즉시 리페칭하는 것을 피하기 위해
        // staleTime을 0보다 큰 값으로 설정한다.
        staleTime: 60 * 1000,
      },
    },
  })
}
let browserQueryClient: QueryClient | undefined = undefined

function getQueryClient() {
  if (isServer) {
    // Server: 항상 새로운 쿼리 클라이언트를 생성한다.
    return makeQueryClient()
  } else {
    // Browser: 이미 있는 쿼리 클라이언트가 없을 때만 새로 만든다
    // React가 초기 렌더링 중에 일시 중단될 때  새로운 클라이언트를 다시 만들지 않기 위함이다.
    // 만약 쿼리 클라이언트 생성 아래에 suspense 경계가 있다면 이는 필요하지 않을 수 있다.
    if (!browserQueryClient) browserQueryClient = makeQueryClient()
    return browserQueryClient
  }
}
export function Providers(props: { children: React.ReactNode }) {
  const queryClient = getQueryClient()

  return (
    <QueryClientProvider client={queryClient}>
      <ReactQueryStreamedHydration>
        {props.children}
      </ReactQueryStreamedHydration>
    </QueryClientProvider>
  )
}

하지만 ReactQueryStreamedHydration은 아직 정식출시버전이 아니기 때문에 page-router를 활용할 때에는 csr로 처리를 하여서 같이 사용하는 수밖에 없다. 필자의 경우에는 csr로 돌려서 활용하였다. 다음과 같이 말이다.

const FriendComponents = () => {
  const FriendCardCompo = dynamic(() => import("./FriendCardCompo"), {
    ssr: false,
  });
  return (
    <div>
      <ErrorBoundary>
        <Suspense fallback={<div>loading중...</div>}>
          <FriendCardCompo />
        </Suspense>
      </ErrorBoundary>
    </div>
  );
};
// useSuspenseQuery활용하는 부분
function useGetFriendList({ date, page }: { date: string; page: number }) {
  const fetchGetFriendList = async () => {
    const response = await request<null, IfriendList, FriendParam>({
      uri: //...,
      method: "get",
      params: //...
    });

    return response.data;
  };

  const { data: friendData } = useSuspenseQuery({
    queryKey: ["get-friendList", date, page],
    queryFn: fetchGetFriendList,
  });

  return { friendData };
}

app router의 경우에는 dynamic대신 ‘use client’를 사용해야 한다.

use()

결론만 말하자면 해당 기능을 react-query활용하려면 실험적으로 가능하다고 한다. 이 때는 useSuspenseQuery가 아닌 useQuery와 함께 사용하면서 Suspense를 활용할 수 있다. Suspense를 사용할 수 있기 때문에 ErrorBoundary또한 활용할 수 있다.

useQueryResult? @tanstack/react-query에서 제공하는 타입으로, useQuery 훅의 반환 타입이다. 아래와 같이 구성되어 있다.

type UseQueryResult<TData> = {
  data: TData
  error: Error | null
  status: 'loading' | 'error' | 'success'
  promise: Promise<TData>  // 여기 promise 속성이 있음
  // ... 기타 속성들
}

import React from 'react'
import { useQuery } from '@tanstack/react-query'
import { fetchTodos, type Todo } from './api'

function TodoList({ query }: { query: UseQueryResult<Todo[]> }) {
// 자식 컴포넌트에서 Promise를 받아 resolve된 값을 반환
  const data = React.use(query.promise)

  return (
    <ul>
      {data.map((todo) => (
        <li key={todo.id}>{todo.title}</li>
      ))}
    </ul>
  )
}

export function App() {
// 부모 컴포넌트에서 쿼리 실행
  const query = useQuery({ queryKey: ['todos'], queryFn: fetchTodos })

  return (
    <>
      <h1>Todos</h1>
      <React.Suspense fallback={<div>Loading...</div>}>
        <TodoList query={query} />
      </React.Suspense>
    </>
  )
}

use()를 사용하면 data가 undefined가 될 수 있을까?

결론부터 말하자면 아니요다. 그 이유는 use()의 흐름을 보면 되기 때문이다.

1. Promise가 resolve되면 실제 데이터를 반환한다.
2. reject되면 가장 가까운 Error Boundary로 에러를 throw한다.
3. 아직 pending 상태면 Suspense로 중단한다.

즉, 데이터가 undefined인 상황이 발생하기 이전에 Suspense와 Error Boundary로 처리가 되기 때문에 useSuspenseQuery와 마찬가지로 data는 항상 정의되어 있음이 보장된다.

참고자료

SSR 환경에서 Suspense와 useSuspenseQuery가 오작동하는 문제 해결하기

react-query v5에 useQuery의 onSuccess가 사라졌다.

TanStack Query V5 톺아보기

Migrating to TanStack Query v5 | TanStack Query React Docs

리액트 상태관리

양방향 바인딩을 하는 Angular나 Vue와 달리 리액트는 단방향 바인딩을 지원한다.

즉, 부모의 상태를 자식으로 전달할 수는 있지만 반대의 방향(자식 → 부모)으로는 불가능하다는 것이다.

props drilling

부모 컴포넌트가 있고 그 자식인 A, 그리고 A의 자식인 B, B의 자식인 C가 있다고 해보자.

만약 A의 상태값을 C에서 사용한다면, B는 사용하지 않음에도 불구하고 상태값을 props로 전달해야 한다.

만약 Volume이 커지고 상태값도 더 많아지고 복잡해진다면 props drilling이슈로 골머리를 앓을 수 있다.

이를 해결하기 위해서 나온 것이 상태 관리 툴이라고 생각하면 된다.

Context API는 해결책이 안될까?

리액트에서는 context API가 존재하고 이를 사용하면 컴포넌트의 깊이 여부와 상관없이 데이터가 필요한 컴포넌트에서만 가져다 쓸 수 있도록 할 수 있다.

다만 Volume이 커질수록 Provider의 개수가 많아져서 Provider hell이 발생할 수 있고 동일한 Provider 하위에서 context를 구독하는 모든 컴포넌트는 Provider의 value prop이 바뀔 때마다 모두 리렌더링 된다는 치명적인 단점이 있다..

그리고 근본적으로 Context API는 상태 관리 도구가 아니라고 한다.

공식 문서에도 Context는 props 없이 데이터를 받을 수 있게 해주는 기능이라고 적혀있을 뿐, 상태 관리를 한다는 내용은 없다.

즉, Context는 만들어진 상태를 단순히 전달할 뿐, 리액트에서의 상태를 관리하는 훅은 useState와 useReducer 훅인 것이다.

Flux

MVC패턴

프론트엔드에서도 MVC패턴을 구조화할 수 있다.

1. View가 Controller에게 이벤트를 보내면
2. Controller는 Model을 업데이트하고
3. Model은 View를 업데이트한다.
4. Controller가 View를 직접 업데이트할 수도 있다.(ex. 정렬)

이런 패턴은 규모가 커지게 되면 Controller마다 많은 Model, View를 가지고 있게 되어 복잡해진다.

또한 MVC 패턴에서의 데이터 흐름은 양방향으로 이루어지는데 이는 단방향 데이터 흐름을 지향하는 리액트와는 맞지 않는 아키텍처였다.

Flux 패턴

MVC에서는 사용자의 상호작용(Action)은 Controller가 담당했다. Store는 상태 관리를 하는 곳이라고 보면 된다.

1. Action이 들어오면 어떤 Store에 할당할 지 Dispatcher가 판단한다.
2. Store는 Action에 의해 상태가 변경되면 View에서 변경점을 표현해준다.
3. 변경된 데이터는 View에 반영되며, View에서는 다시 Action을 받을 수 있다.

Redux

나오게 된 배경

싱글톤 모델

Flux는 여러 개의 스토어를 사용하는 구조였는데 스토어 간 의존성 관리가 큰 문제였다.

Redux는 싱글톤 모델을 선택함으로써 모든 것이 의존성 없이 다른 곳에 접근할 수 있게 되었다. reducer는 뒤에 서술하겠지만 순수하기 때문에 여러 상태 조각들을 다루는 모든 로직은 스토어 밖에 있어야 한다. Redux가 처음에 고치지 못한 유일한 결함은 보일러플레이트였다.

우리가 흔히 아는 RTK는 이러한 악명 높은 보일러플레이트를 단순화해주었다.

모듈식 상태에서는 의존성 트리가 너무나 복잡해져서 최선의 해결책이 다름 아닌 “그냥 하지 말자”로 귀결되었다.

즉, “모든 것이 서로 접근 가능하니까 의존성 문제가 없다!”라는 접근인 것이다.

데메테르의 법칙 (기존 Flux패턴의 문제점)

정의

• 각 유닛은 다른 유닛에 대해 제한된 지식만 가져야 한다. 현재 유닛과 “밀접하게”관련된 유닛만 알면 된다.
• 각 유닛은 자신의 친구들하고만 대화해야 한다. 모르는 사람과는 대화하지 말아라.

이 법칙은 원래 OOP를 위해 만들어졌지만, React 상태 관리를 포함한 여러 분야에 적용할 수 있다. 쉽게 말해서 Store가 이런 행동을 못하도록 막는 것이다.

1. 다른 스토어의 내부 구현에 과도하게 의존하는 것
2. 굳이 알 필요도 없는 스토어를 사용하는 것
3. 명시적으로 의존성을 선언하지 않고 다른 스토어를 마음대로 사용하는 것

사실 스토어 간의 의존성은 좋은 모듈식 시스템의 자연스러운 부분이다. 스토어가 새로운 의존성을 추가해야 한다면, 그렇게 하되 최대한 명시적으로 해야 한다. 코드를 보면 다음과 같다.

PromosStore.dispatchToken = dispatcher.register(payload => {
  if (payload.actionType === 'add-to-cart') {
    // wait for CartStore to update first:
    dispatcher.waitFor([CartStore.dispatchToken])

    // now send the request
    sendPromosRequest(UserStore.userId, CartStore.items).then(promos => {
      dispatcher.dispatch({ actionType: 'promos-fetched', promos })
    })
  }

  if (payload.actionType === 'promos-fetched') {
    PromosStore.setPromos(payload.promos)
  }
})

PromosStore는 여러 의존성을 다양한 방식으로 선언하고 있다. CartStore를 기다리고 읽으면서, 동시에 UserStore도 읽고 있다. 이러한 의존성을 발견하려면 PromosStore의 구현 코드를 직접 뒤져봐야만 한다. 다시 말해서 의존성이 너무 암시적이라 직접 봐야만 하는 것이다.

이 예시는 매우 단순하고 인위적이지만, Flux가 데메테르의 법칙을 어떻게 잘못 해석했는지 보여준다. Flux 구현을 작게 유지하려는 바람에서 비롯된 것일 수 있지만 바로 이 부분이 Flux의 약점이 되었다.

Redux패턴 구조 및 정의

Redux는 Reduce + Flux의 합성어이다. 여기서 Reducer는 순수함수 역할을 한다.

💡 순수함수는 “동일한 인자가 주어졌을 때 항상 동일한 결과를 반환, 외부의 상태를 변경하지 않는 함수”를 뜻한다.

Flux의 Dispatcher 는 사라졌는데, 이는 Store 한개로 전부 관리하기 때문이다.

💡 Redux가 Flux인가요? 이거에 대한 확답을 하긴 어렵지만 Flux로부터 영향을 받았다고 보면 된다. Redux는 순수 함수를 통해 더 간단화된 Flux 아키텍처라고 할 수 있다. 자세한 건 아래 공식문서에서 확인할 수 있다. redux 공식문서

• 💡 다른 상태 관리 라이브러리와 Redux를 비교하고자 한다면 redux-toolkit(RTK)과 비교하는 게 맞을 것이다. Redux에서 권장하는 구현 방식이 redux-toolkit이기 때문!

💡 RTK의 장점

1. createSlice를 통해 action과 reducer를 한 번에 생성할 수 있다.
2. immer를 내장하여 불변성 관리가 쉽다.
3. 보일러플레이트 코드가 크게 줄어든다

이 모든건 기존 Redux의 복잡한 설정 없이도 깔끔하게 상태 관리를 할 수 있다는 것이다.

사용법 흐름

RTK 기준으로 작성했다.

1. 저장할 state와 action을 만든다.

    import { createSlice, PayloadAction } from '@reduxjs/toolkit';
   
    interface Todo {
      id: number;
      text: string;
      completed: boolean;
    }
   
    const initialState: Todo[] = [];
   
    const todosSlice = createSlice({
      name: 'todos',
      initialState,
      reducers: {
        addTodo: (state, action: PayloadAction<string>) => {
          state.push({
            id: Date.now(),
            text: action.payload,
            completed: false
          });
        },
        toggleTodo: (state, action: PayloadAction<number>) => {
          const todo = state.find(todo => todo.id === action.payload);
          if (todo) {
            todo.completed = !todo.completed;
          }
        }
      }
    });
   
    export const { addTodo, toggleTodo } = todosSlice.actions;
    export default todosSlice.reducer;

2. action을 토대로 reducer를 만든다. a. RTK의 장점으로서 createSlice가 자동으로 리듀서와 액션을 생성해준다.

3. reducer들을 합친다.

    // app/store.ts
    import { configureStore } from '@reduxjs/toolkit';
    import todosReducer from '../features/todos/todosSlice';
   
    export const store = configureStore({
      reducer: {
        todos: todosReducer,
        // 다른 리듀서들도 여기에 추가할 수 있다.
      }
    });
   
    export type RootState = ReturnType<typeof store.getState>;
    export type AppDispatch = typeof store.dispatch;

4. rootReducer를 store에 저장한다.(3번에서 이미 처리를 하였다.)

5. provider를 통해 store에 접근할 수 있게 한다.

    // index.tsx or App.tsx
    import { Provider } from 'react-redux';
    import { store } from './app/store';
   
    function App() {
      return (
        <Provider store={store}>
          <TodoList />
        </Provider>
      );
    }

6. useDispatch, useSelector를 사용한다.

    // components/TodoList.tsx
    import { useDispatch, useSelector } from 'react-redux';
    import { RootState } from '../app/store';
    import { addTodo, toggleTodo } from '../features/todos/todosSlice';
   
    function TodoList() {
      const dispatch = useDispatch();
      const todos = useSelector((state: RootState) => state.todos);
   
      const handleAddTodo = (text: string) => {
        dispatch(addTodo(text));
      };
   
      const handleToggle = (id: number) => {
        dispatch(toggleTodo(id));
      };
   
      return (
        <div>
          <button onClick={() => handleAddTodo("새로운 할 일")}>
            할 일 추가
          </button>
   
          {todos.map(todo => (
            <div key={todo.id} onClick={() => handleToggle(todo.id)}>
              <input
                type="checkbox"
                checked={todo.completed}
                readOnly
              />
              <span style={{ textDecoration: todo.completed ? 'line-through' : 'none' }}>
                {todo.text}
              </span>
            </div>
          ))}
        </div>
      );
    }
   
    export default TodoList;

Zustand

zustand 는 단순화된 Flux 패턴을 사용하는 작고 빠르고 확장가능한 상태관리 솔루션이며, Hooks 를 기반으로하는 간편한 API가 있다. 이 라이브러리는 스토어 생성 함수를 호출할 때 클로저를 활용한다. 클로저는 함수와 그 함수가 선언될 당시의 lexcial environment을 기억하는 것으로, 스토어의 상태는 스토어 조회나 변경을 해주는 함수 외부 스코프에서 항상 유지되도록 만들어졌다.

그렇게 되면, 상태의 변경, 조회, 구동 등을 통해서만 스토어를 다루고 실제 상태는 애플리케이션 생명주기 동안 의도치 않게 변경되는 것을 방지시킬 수 있다.

즉, 해당 라이브러리는 Redux처럼 Flux를 사용하는 친구이며 Redux보다 더 간단하고 직관적인 훅 기반의 API 제공과 Provider로 감싸지 않아도 된다는 점에서 러닝커브가 낮다. 또한 SSR을 공식적으로 지원해준다.

기본 사용

create 함수로 스토어를 생성한다. create 함수의 콜백은 set, get 매개변수를 가지며, 이를 통해 상태를 변경하거나 조회할 수 있다.

create 함수의 콜백이 반환하는 객체에서의 속성은 state이고, 메소드는 action이다.

import { create } from 'zustand'
export const use이름Store = create((set, get) => {
  return {
    상태: 초깃값,
    액션: () => {
      const state = get()
      const { 상태 } = state
      set({ 상태: 상태 + 1 })
    }
  }
})

필자는 처음 사용했을 때 다음과 같은 방식을 사용했었다.

• create<타입>()으로 create의 함수의 제네릭으로 상태와 액션 타입을 전달하였지만 이 중 states와 actions를 분리하여 관리를 하였다.

type TFeedBackStore = {
  states: {
    data: Array<TFeedBack>;
    mentorInfo: TFeedBack;
    ratingMenteeId: number;
    open: boolean;
  };
  actions: {
    setData: (data: TFeedBack) => void;
    setMenteeId: (id: number) => void;
    resetMenteeId: () => void;
    setOpen: () => void;
    reset : () => void;
  };
};
const useFeedBackStore = create<TFeedBackStore>()(
  devtools((set) => ({
  states: { //.... },
  actions: {
      setData: (data: TFeedBack) => {
        set((state) => ({
        // .....
   }))
);

• 상태 초기화는 resetState함수를 추가하였는데 다음과 같이 initialState를 설정해두었다.

const initialState = {
  data: [],
  mentorInfo: {} as TFeedBack,
  ratingMenteeId: 0,
  open: false,
};
// .....
const useFeedBackStore = create<TFeedBackStore>()(
  devtools((set) => ({
  states: { //.... },
  actions: {
      setData: (data: TFeedBack) => {
        set((state) => ({
        // .....
       reset : () => set({states : initialState}),
   }))
);

• 혹은 부분으로 사용할 땐 다음과 같이 활용하였다.

    type TFeedBackStore = {
      states: TFeedBackState;
      actions: {
        // .....
        resetStates: (keys?: Array<keyof TFeedBackState>) => void; 
      };
    };
    // 활용 부분
        resetStates: keys => {
          if (!keys) {
            // 전체 states 초기화
            set({ states: initialState });
            return;
          }
          // 특정 states만 초기화
          set((state) => ({
            states: {
              ...state.states,
              // 여기선 객체를 사용하였기 때문에 Object.fromEntries()을 활용했다.
              // 만약에 그냥 배열의 배열을 반환해도 된다면 해당 부분은 생략해도 된다.
              ...Object.fromEntries(
                keys.map(key => [key, initialState[key]])
              )
            }
          }));

• Zustand의 상태를 모니터링할 수 있는 개발자 도구를 사용할 수 있다. devtools미들웨어를 사용하면, 개발자 도구가 활성화된다.

• 스토리지는 persist 미들웨어를 사용하여 상태를 저장하고 불러올 수 있다. 스토리지에 저장될 스토어의 고유한 이름을 필수 옵션(name)으로 제공해야 해야 한다. 또한 로컬 스토리지를 기본으로 사용하며, 필요하면 세션 스토리지나 커스텀 스토리지를 만들어 사용할 수도 있다.

필자는 zustand를 사용했을 때 아래 사이트의 도움을 많이 받았고 이 외에도 다양한 기능들이 있으니 필요에 따라 확인해서 활용하면 좋을 것이다. 여기서 다 다루기에는 Zustand 포스팅이 아니라서 생략하도록 하겠다. Zustand 핵심 정리

Proxy

Proxy 방식은 JavaScript의 Proxy 객체를 활용하여 객체의 속성에 대한 접근, 할당, 삭제 등을 가로채고 추가적인 로직을 수행하는 방식이다. → 객체를 직접 관찰하고 변경 사항을 자동으로 감지할 수 있다.

MobX

흐름

1. Action이 실행되면 상태값이 Update된다.
2. 해당 값을 구독하는 곳에 Notify가 된다.
3. Notify가 되면 렌더링이 트리거된다.

MobX에서는 Action이 직접 상태를 업데이트할 수 있고 Redux에 비해 코드량이 훨씬 적으며 Proxy방식이기 때문에 객체지향적인 성격을 가지고 있다. 다만…. 커뮤니티가 너무 작다는 큰 문제점이 있다.

Atomic

Atomic패턴이라는 새로운 접근방식이 등장하였다. 이건 기존의 단방향 데이터 흐름을 다르게 해석한 것이다.

Atom

스토어라고 부르던 것들이 이제는 "아톰(atom)"이라는 이름으로 바뀌었고, 각각이 독립적으로 동작하면서도 필요할 때 서로 연결될 수 있게 되었다. 특히 이 아톰들의 장점은 다음과 같았다.

1. 코드를 나눠서 필요할 때만 불러올 수 있다.
2. React의 최신 기능들도 지원한다.
3. 다른 아톰과의 관계를 명확하게 선언할 수 있다.

상태는 atom이라는 작고 독립적인 단위로 나뉜다. 이러한 atom에 접근해야하는 컴포넌트는 이를 구독하고 atom이 업데이트되면 다시 렌더링된다.

Recoil

Recoil은 Context API 기반으로 구현된 라이브러리이다. Redux의 가장 큰 단점인 거대한 보일러 플레이트 작성을 하는 대신, Recoil은 react의 useState와 유사하게 사용할 수 있으며, 굉장히 간결하게 작성할 수 있다. 다만 Recoil은 업데이트를 안하는…

Recoil의 공식 문서에 따르면 Recoil의 출시 컨셉은 다음과 같다.

💡 출시 컨셉

• Boilerplage-free API 제공
• Concurrent Mode(동시성 모드)를 비롯한 새로운 React 기능들과의 호환 가능성
• Code Splitting - 상태 정의에 대한 증분 및 분산 가능
• 상태에서 파생된 데이터 사용
• 파생된 데이터에 대한 동기/비동기 모두 가능
• 캐싱

atom 은 컴포넌트들이 구독할 수 있는 상태의 단위를 의미하며, selector 는 상태를 동기/비동기적으로 변경시킬 수 있는 순수 함수를 의미한다.

Jotai

Jotai 는 Conext 의 리렌더링 문제 해결을 위해 만들어진 React 에 특화된 상태관리 라이브러리로 recoil 에서 영감을 받아 제작되었다.  Recoil처럼 atomic 개념을 따르는 친구이며, recoil과 달리 key를 정의할 필요가 없으며 여러 Provider를 정의할 수 있다. (만약 Provider를 사용하지 않으면 글로벌에 존재하는 atom에 저장된다.) 또한 SSR을 공식적으로 지원한다.

store기능으로 리액트 컴포넌트 밖에서 훅 없이 상태를 바꿀 수는 있지만 권장하지는 않는다.

그리고 Jotai는 렌더링에 대한 최적화가 큰데  원래 대용량 객체나 배열 형태의 state에서 변경사항이 생기면 일반적으로 해당 상태를 사용하는 모든 컴포넌트에서 리렌더링이 발생하지만 이러한 문제점을 optics 라는 외부 라이브러리를 사용해 해결했다고 한다.

사용 예시들

1. 기본적인 Provider 사용 예시

    import { Provider, atom, useAtom } from 'jotai';
   
    // 여러 개의 Provider를 사용할 수 있음
    function App() {
      return (
        <Provider>
          <FeatureA />
        </Provider>
        <Provider>
          <FeatureB />
        </Provider>
      );
    }
   
    // Provider 없이도 사용 가능 (글로벌 스토어에 저장)
    function AppWithoutProvider() {
      return <FeatureA />;
    }

2. Provider Scope를 활용한 독립적인 상태 관리

    import { Provider, atom, useAtom } from 'jotai';
   
    const countAtom = atom(0);
   
    function Counter() {
      const [count, setCount] = useAtom(countAtom);
      return (
        <button onClick={() => setCount(c => c + 1)}>
          count: {count}
        </button>
      );
    }
   
    // 각 Provider는 독립적인 상태를 가짐
    function App() {
      return (
        <div>
          <Provider>
            <Counter /> {/* 이 카운터의 상태는 */}
          </Provider>
          <Provider>
            <Counter /> {/* 이 카운터의 상태와 독립적 */}
          </Provider>
        </div>
      );
    }

3. optics를 활용한 대규모 상태 최적화 예시

    import { atom, useAtom } from 'jotai';
    import { focusAtom } from 'jotai-optics';
   
    // 대규모 상태를 가진 atom
    const bigDataAtom = atom({
      users: [
        { id: 1, name: 'John', settings: { theme: 'dark', notifications: true } },
        { id: 2, name: 'Jane', settings: { theme: 'light', notifications: false } },
        // ... 수많은 사용자 데이터
      ]
    });
   
    // optics를 사용해 특정 사용자의 설정만 포커싱
    const userSettingsAtom = focusAtom(bigDataAtom, optic => 
      optic.prop('users').filter(user => user.id === 1).prop('settings')
    );
   
    function UserSettings() {
      const [settings, setSettings] = useAtom(userSettingsAtom);
   
      // 이제 전체 상태가 아닌 특정 사용자의 설정만 구독
      return (
        <div>
          <label>
            Theme:
            <select
              value={settings.theme}
              onChange={e => setSettings({
                ...settings,
                theme: e.target.value
              })}
            >
              <option value="light">Light</option>
              <option value="dark">Dark</option>
            </select>
          </label>
          <label>
            Notifications:
            <input
              type="checkbox"
              checked={settings.notifications}
              onChange={e => setSettings({
                ...settings,
                notifications: e.target.checked
              })}
            />
          </label>
        </div>
      );
    }

그래서 어떻게 사용하면 좋을까?

top-down에는 flux가, bottom-up에는 atomic이 잘 맞다고 생각한다.

💡 top-down과 bottom-up 형식?

1. top-down형식의 상태 관리 예시 : 최상위 메뉴에서 선택된 어떤 값이라거나 유저 및 권한 정보에 관한 상태관리
2. bottom-up 형식의 상태 관리 예시 : 하위 컴포넌트의 모달에 관한 상태 관리

최상위에서 선택된 어떤 아이템이나, 유저 및 권한에 대한 핸들링이 개발 시 우선 사항이라면 flux패턴 라이브러리를 사용한 뒤 이후 상태들에 따라 flux패턴 라이브러리를 유지하거나 atomic패턴 라이브러리를 부분적으로 도입하고, 그렇지 않은 경우라면 atomic패턴 라이브러리로 가볍게 아톰을 선언해서 사용하는 편이다.

요약본

참고자료

현대 앱 아키텍쳐 설명 (Backend/Frontend/MVC/Flux/Redux/MSA)

How Atoms Fixed Flux | HackerNoon

개발자 단민 | Redux MobX Zustand Recoil Jotai 뭐가 이렇게 많아

시작하기 전에

해당 글은 1/12에 노션으로 작성한 걸 2부로 나눈 것입니다. 이번 포스팅은 Debounce, Throttle, 이벤트 시뮬레이션을 다룬 것입니다.

Debounce, Throttle

여기서는 간단히 다루도록 하겠다. 아예 안 다루기에는 이벤트 최적화 방법 중 하나라 애매하기 때문이다.

Debounce

• 연속적으로 발생한 이벤트를 하나로 처리하는 방식이다.
• 주로 처음이나 마지막으로 실행된 함수만을 실행한다.

• 동작원리
  • 쉽게 말해 계속해서 이벤트가 발생할 때 앞선 타이머를 리셋하고 타이핑을 멈추고나서 setTimeout으로 설정된 특정 시간이 지나면 딱 한번만 함수가 동작하는 방식이라고 보면 된다.
• 주로 사용처 : 키워드 검색 혹은 자동완성 기능에서 api 함수 호출 횟수를 최대한 줄이고 싶을 때, 사용자가 창크기 조정을 멈출때까지 기다렸다가 resizing Event를 반영하고 싶을 때

Throttle

• 출력을 조절한다는 의미로 이벤트를 일정주기마다 발생하도록 하는 기법
• 100ms를 준다면 이벤트는 100ms동안 최대 한 번만 발생하게 된다.
• 즉 마지막 함수가 호출된 후 일정시간이 지나기전에 다시 호출되지 않도록 하는 것이다.
  • 연이어 발생한 이벤트에 대해 일정한 delay를 포함시켜 연속적으로 발생한 이벤트는 무시하는 방식이다.
• 동작원리
  • 이것도 일종의 setTimeout기법인데 첫 번째 이벤트가 발생한 후 내가 설정한 시간 동안 발생한 해당 이벤트들은 전부 무시된다. 결과적으로 500ms라고 가정한다면 그 시간 동안 최대 1번의 이벤트만이 발생하는 것이다.(마지막과는 상관이 없는 것이다)
• 주로 사용처 : 스크롤, lodash라이브러리

💡 문제점

다만 throttle, debounce 함수의 단점이 존재한다. 동작원리를 보면 알다시피 둘 다 setTimeout이라는 WebAPI에 의해 실행되는데 setTimeout, setInterval은 정확한 지연 시간을 보장해주지 않는다. 저번에 비동기 API Tasks들을 Task Queue에 넣어둔 후 순차적으로 처리한다는 것을 보았었는데 Queue에 저장된 비동기 태스크를 처리하는 시점은 Call Stack이 비어져 있을 경우이다. → 이 때 시점이 setTimeout 또는 setInterval에 할당해준 delay와 맞지 않는 경우 등록해둔 callback은 실행되지 않을 수도 있다. 즉, 정교함은 약간 떨어질 수 있다는 것이다.

해결 방안들

Lodash 사용

debounce 내부 코드를 뜯어보면 기존과 차이점이 다음과 같다.

1. 입력이 들어오면 현재 시간과 마지막 호출 그리고, delayTime (wait) 을 비교하고, lastArgs, lastThis, lastCallTime 를 저장한다.
   • lastArgs, lastThis를 저장해서 함수 실행 컨텍스트를 정확하게 유지한다.
   • lastCallTime을 저장하고 계속 추적함으로써 실제 호출 간격을 정확하게 측정한다.
2. timerId 가 세팅되지 않았다면, leadingEdge 를 호출하여, startTimer(timerExpired, wait) 로 timerId 를 세팅한다.
   • leadingEdge와 뒤에 후술할 trailingEdge로 실행 시점을 명확하게 구분하여 콜백 실행 시점을 더 정확하게 제어가 가능하다.
3. wait 시간이 지나면 timerExpired 로 마지막 입력 시간 (lastCallTime) 을 비교하여, 만약 입력이 계속 들어오고 있다고 판단되면, timerId = startTimer(timerExpired, remainingWait(time)) 반복한다.
   • timerExpired에서 입력이 계속 들어오는지 확인하고 remainingWait로 타이머를 다시 설정한다.
   • remainingWait로 남은 시간을 동적으로 계산해 타이밍 정확도를 향상시킨다.
4. 만약 더이상 입력이 없고, 시간이 지났다면, trailingEdge(time) 를 호출하여, invokeFunc() 에서, func.apply(thisArg, args) 으로 callback 을 전달하게 한다.

requestAnimationFrame

requestAnimationFrame은 브라우저의 화면 갱신 주기에 맞추어 함수를 호출하는 방법으로, 화면이 새로 그려질 때(Repaint)마다 함수가 실행한다. 즉, 실제 화면이 갱신되어 표시되는 주기에 따라 함수를 호출해주기 때문에 자바스크립트가 프레임 시작 시 실행되도록 보장한다. requestAnimationFrame을 이용해 쓰로틀링 적용하고 repaint를 개선한 사례에 대한 글이다. scroll event 최적화로 웹페이지 성능 개선하기

Intersection Observer API

스크롤 이벤트 관리 시 해당 API를 사용하면 해결할 수 있다.

Intersection Observer API는 상위 요소 또는 최상위 문서의 viewport와 대상 요소 사이의 변화를 비동기적으로 관찰할 수 있는 수단을 제공한다. Intersection Observer API는 특정 요소가 다른 요소와의 교차점에 들어가거나 나갈 때 또는 두 요소 간의 교차점이 지정된 양만큼 변화될 때 실행되는 콜백 함수를 코드에 등록할 수 있다.

즉, 기존 scroll 이벤트의 문제점을 개선하고자 개발되었다.

해당 부분의 자세한 부분은 여기서 확인할 수 있다. 실무에서 느낀 점을 곁들인 Intersection Observer API 정리

결국 Intersection Observer를 이용한다는 것은 WebAPI에 이벤트를 위임하는 것이고, 따라서 자연스럽게 메인 스레드의 자유도도 보장한다고 볼 수 있다.

이벤트 시뮬레이션

JS로 언제든 원하는 이벤트를 발생시킬 수 있다. 이 기능은 웹 애플리케이션을 테스트할 때 유용하다.

✨ 왜 유용할까?

1. 테스트 자동화
   • 실제로 마우스를 클릭하거나 키보드를 누르지 않고도 테스트를 자동으로 실행할 수 있다.
   • ex ) 버튼 클릭 시 팝업 띄우기를 실제 클릭 없이 테스트가 가능하다.
2. 다양한 상황 테스트가 가능하다.
   • 사용자가 하기 어려운 복잡한 이벤트 조합을 쉽게 테스트할 수 있다.
   • ex ) 마우스를 특정 좌표로 이동하면서 동시에 키를 누르기

createEvent 방식

document의 createEvent 메서드로 event 객체를 생성하고, 이벤트에 관한 정보를 초기화한 후, dispatchEvent 메서드로 이벤트를 발생시킨다.

// 예시
// 이벤트 객체 생성
var event = document.createEvent("MouseEvent");

// 이벤트 초기화 (세부 정보 설정)
event.initMouseEvent(
    "mouseover",  // 이벤트 타입
    true,         // 버블링 여부
    true,         // 취소 가능 여부
    window,       // 이벤트가 발생한 윈도우
    0,            // 클릭 횟수
    0, 0,         // 화면 좌표
    0, 0,         // 클라이언트 좌표
    false         // 컨트롤 키 누름 여부
);

// 이벤트 발생시키기
document.getElementById("myDiv").dispatchEvent(event);

DOM 4 레벨 방식

MouseEvent() 생성자를 이용하여 MouseEvent 객체를 초기화 & 생성한 후, dispatchEvent 메서드로 이벤트를 발생시킨다. MouseEvent 이외에도 KeyboardEvent, FocusEvent 등 Event Interface를 상속받는 다양한 생성자가 있다.

Event Interface? DOM에서 발생하는 이벤트를 나타낸다. 다양한 이벤트 종류는 아래 사이트에서 참고 가능하다. Event Interface

// MouseEvent 생성자를 직접 사용
const event = new MouseEvent('mouseover', {
    bubbles: true,
    cancelable: true,
    view: window,
    // 다른 옵션들도 한번에 설정 가능
});
// 이벤트 발생시키기
document.getElementById("myDiv").dispatchEvent(event);

다음은 활용 예시 코드이다. 이런식으로 이벤트 시뮬레이션을 사용하면 자동화된 테스트를 작성할 수 있고, 사용자 상호작용이 필요한 복잡한 기능도 쉽게 테스트할 수 있다.

function testButtonClick() {
    // 버튼 클릭 이벤트 시뮬레이션
    const clickEvent = new MouseEvent('click', {
        bubbles: true,
        cancelable: true
    });

    const button = document.getElementById('submitButton');
    button.dispatchEvent(clickEvent);

    // 이벤트 발생 후의 결과 확인하기
    assert(document.getElementById('result').textContent === '성공');
}

참고자료

Debounce 와 throttle 은 뭐고 각각 언제 사용할까?

JavaScript | Event 메모리 최적화와 Event 시뮬레이션

쓰로틀링과 디바운싱 알아보기

MDN - requestAnimationFrame()

누끼 따는 것도 귀찮… 얜 포실핑입니다 4기에 나오는 ~ 모른다고요? 괜찮아요 5기가 이제 대세라서~~

react19에서는 여러가지 변경사항이 있었는데 그 중 가장 눈에 들어온 건 use였다. use를 읽다보면 useEffect, useContext를 대체할 수 있다고 나온다. react는 계속해서 업데이트 될 것이기 때문에 use에 대해 알아볼 겸 어떻게 useEffect와 useContext를 대체할 수 있는지 궁금해서 작성하게 되었다.

use

📃 use 개념설명 use는 Promise나 Context와 같은 데이터를 참조하는 React API

// 기본 사용 방식
const value = use(resource);
// 활용 예시
import { use } from 'react';
function MessageComponent({ messagePromise }) {
  const message = use(messagePromise);
  const theme = use(ThemeContext);

다른 React Hook과 달리 use는 if와 같은 조건문과 반복문 내부에서 호출할 수 있다. Promise와 함께 호출될 때 use Hook은 Suspense 및 Error Boundary와 통합된다. 서버 컴포넌트에서 클라이언트 컴포넌트로 Promise Prop을 전달하여 서버에서 클라이언트로 데이터를 스트리밍할 수 있다.

한줄 요약 : use 훅은 비동기 데이터 페칭 또는 context 를 비동기로 불러올 수 있다.

useContext 대신 use로 context 참조하기

결론부터 말하자면 use훅을 사용할 시 context 관리가 더 직관적으로 된다.

useContext는 컴포넌트의 최상위 수준에서 호출해야 하지만, use는 if와 같은 조건문이나 for와 같은 반복문 내부에서 호출할 수 있다. 이는 use 훅이 유연하다는 것을 보여주고, useContext 을 대체할 수 있음을 보여준다.

use는 context의 context value를 반환하고 use는 context 값을 결정하기 위해 항상 이를 호출하는 컴포넌트의 위쪽에서 가장 가까운 context provider 를 찾는다.

코드 사용 방법은 기존 useContext를 사용하듯이 쓰면 된다.

// ContextExample.tsx, use(React19) 사용
import { use } from 'react';
import { ThemeContext } from '../context/ThemeContext';

export default function ContextExample() {
  const { setTheme } = use(ThemeContext);

  const handleThemeToggle = () => {
    setTheme((prevTheme) => {
      if (prevTheme === 'light') {
        return 'dark';
      } else {
        return 'light';
      }
    });
  };

  return (
    <div>
      <button onClick={() => handleThemeToggle()}>Switch Theme</button>
    </div>
  );
}
//App.tsx
import { ThemeContext } from './context/ThemeContext';
import ContextExample from './components/ContextExample';

function App() {
  const { theme } = use(ThemeContext);

  return (
    <div className={`App ${theme}`}>
      <ContextExample />
    </div>
  )
}

export default App;

⚠️ 주의점 useContext와 마찬가지로, use(context)는 항상 이를 호출하는 컴포넌트의 위쪽에서 가장 가까운 Context Provider를 찾는다. 위쪽으로 탐색하며, use(context)를 호출하는 컴포넌트 내부의 Context Provider는 고려하지 않는다!

useEffect 대신 use로 async data fetching하기

둘의 차이를 설명하기 이전에 기존에 어떻게 하였는지 먼저 코드로 보여주겠다.

코드

import React, { useState, useEffect } from 'react';

const DataFetchingComponent = () => {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      try {
        const response = await fetch('https://api.example.com/data');
        const result = await response.json();
        setData(result);
      } catch (err) {
        setError(err.message);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []);

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error}</p>;

  return (
    <div>
      <h1>Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default DataFetchingComponent;

// 혹은 다른 예시
import React, { useState, useEffect } from 'react';

async function fetchPerson(): Promise<Person> {
  const response = await fetch('https://swapi.py4e.com/api/people/1/');
  return response.json();
}

interface Person {
  name: string;
  [key: string]: any; // 기타 속성을 허용
}

function PersonComponent() {
  const [person, setPerson] = useState<Person | null>(null);

  useEffect(() => {
    // async data fetch
    fetchPerson().then((data) => setPerson(data));
  }, []);

  if (!person) return <h1>Loading...</h1>;

  return <h1>{person.name}</h1>;
}

export default PersonComponent;

흐름 1️⃣ useEffect는 데이터 가져오기를 시작하기 위해 컴포넌트가 마운트된 후 트리거된다. 2️⃣ 적절한 UI를 관리하고 표시하기 위해 loading, data, error 상태를 유지하거나 데이터 유무에 따른 처리를 한다. → 이에 해당하는 상태를 관리하거나 데이터 유무확인을 별도로 했어야 했다. 3️⃣ 데이터가 가져와지면 상태가 업데이트되어 데이터를 표시하기 위한 리렌더링이 트리거된다.

useEffect를 사용한 데이터 페칭에서는 Suspense와 Error Boundary를 사용할 수 없었다. 기존에는 에러가 떠서 Suspense나 Error관련 컴포넌트를 만들어서 처리를 했었지 이유에 대해서는 자세히 알아보진 않았었다. 이유는 다음과 같다.

1️⃣ useEffect는 컴포넌트가 렌더링된 후에 실행되기 때문에, 데이터 로딩 상태를 Suspense로 처리할 수 없다. 2️⃣ useEffect 내부에서 발생하는 에러는 이미 컴포넌트가 마운트된 후이기 때문에 Error Boundary로 캐치할 수 없었다.

Suspense나 Error Boundary는 서버 렌더링 단계에서 데이터 요청 상태를 파악할 수 있게 만들었기 때문에 react-query와 주로 활용했던 것을 많이 볼 수 있다.

하지만 use() 훅을 사용하게 된다면 더 이상 useState()와 같은 상태 관리 훅에 의존할 필요가 없게 된다.

use() 훅을 활용한 코드

import React, { use } from 'react';

async function fetchData() {
  const response = await fetch('https://api.example.com/data');
  if (!response.ok) {
    throw new Error('Failed to fetch data');
  }
  return response.json();
}

const DataFetchingComponent = () => {
  // `use()` promise가 resolve될 때까지 컴포넌트 렌더링이 중지된다.
  const data = use(fetchData());

  return (
    <div>
      <h1>Data:</h1>
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
};

export default DataFetchingComponent;

// 관리하는 다른 예시

import React, { use, Suspense } from 'react';

// Async function to fetch data
async function fetchPerson() {
  const response = await fetch('https://swapi.py4e.com/api/people/1/');
  return response.json();
}

// Person component using `use()`
function PersonComponent() {
  const person = use(fetchPerson());
  return <h1>{person.name}</h1>;
}

// App component with Suspense fallback
function App() {
  return (
    <Suspense fallback={<h1>Loading...</h1>}>
      <PersonComponent />
    </Suspense>
  );
}

export default App;

1️⃣ use()를 사용하면 promise가 resolve될 때까지 컴포넌트 렌더링이 일시 중단됩니다. 오류가 발생하면 Suspense 에러 바운더리를 트리거 할 수 있다. 2️⃣ React가 내부적으로 처리하기 때문에 부수 효과로 데이터 페칭을 수동으로 관리할 필요가 없다. 3️⃣ 이제 loading이나 error 같은 상태를 수동으로 추적하지 않고도 Suspense 에러 바운더리를 사용하여 전역적으로 관리할 수 있다.

🚨 결론을 말하자면 Suspense와 Error Boundary모두 한 컴포넌트에 너무나 많은 역할이 부담을 덜기 위해서 나온 것이기 때문에 use를 사용한다면 더 간결하게 코드를 작성하며 컴포넌트 역할을 덜어낼 수 있다.

서버에서 클라이언트로 데이터 스트리밍하기

위에서 잠깐 다뤘던 Suspense와 Error Boundary 사용을 useEffect 대신 use훅을 활용하면 가능하다고 했었다. 어떻게 할 수 있는지 좀 더 자세하게 다뤄보도록 하겠다.

Promise 처리는 서버 컴포넌트에서? 아니면 클라이언트 컴포넌트에서?

Promise resolve는 둘 다 할 수 있긴 하다.

다만, 서버 컴포넌트에서 await를 사용한다면 완료될 때까지 렌더링이 차단된다. 서버 컴포넌트에서 클라이언트 컴포넌트로 Promise를 Prop으로 전달하면 Promise가 서버 컴포넌트의 렌더링을 차단하는 것을 방지할 수 있다.

서버 컴포넌트는 한 번만 실행되어 Promise를 한 번만 만들지만, 클라이언트 컴포넌트는 화면이 다시 그려질 때마다 Promise를 새로 만들어야 하기 때문이다.

이를 활용하여 관리자용과 일반 사용자용 API 요청을 따로 가질 수 있다. 이전에는 React 훅을 조건부로 호출할 수 없었지만, use는 이러한 틀을 깨고 활용할 수 있다. 다음과 같은 코드로 말이다.

if (isAdmin) {
  use(getAllUsers)
} else {
  use(getUsersInMyAccount)
}

React는 확실히 SSR과 폼 작업에 중점을 두면서 서버 및 비동기 코드 작업을 더 쉽게 만들고 있다는 모습을 보여준다.

주의사항

🔥 use는 try-catch 블록에서 호출할 수 없다. try-catch 블록 대신 컴포넌트를 Error Boundary로 래핑하거나 Promise의 catch 메서드를 사용하여 대체값을 제공해야 한다.

🔥 React 컴포넌트 또는 Hook 함수 외부에서, 혹은 try-catch 블록에서 use를 호출하고 있는 경우에 Suspense Exception이 일어날 수 있다. try-catch 블록 내에서 use를 호출하는 경우 컴포넌트를 Error Boundary로 래핑하거나 Promise의 catch를 호출하여 오류를 발견하고 Promise를 다른 값으로 리졸브한다.

→ 웬만하면 Error Boundary를 활용하자

🔥 use는 렌더링 중에 생성된 Promise를 지원하지 않는다.

렌더링 중에서 생성된 Promise는 매 렌더링마다 새로운 Promise가 생성될 수 있어 예측 불가능한 동작을 발생시킬 수 있으며, React 렌더링 모델의 순수성과 일관성을 해칠 수 있다.

🔥 다른 use~훅들과 마찬가지로 컴포넌트나 use로 시작하는 커스텀Hook 내부에서 호출되어야 한다.

🔥 서버 컴포넌트에서 데이터를 fetch할 때는 use보다 async/await을 사용한다. → 이건 아까 서버 컴포넌트에서 Promise 처리에서 다뤘으니 생략하겠다.

동작방식

동작원리

결론만 말하면 Promise를 use API로 처리한다. 여기서는 컴포넌트가 Suspense와 Error Boundary로 감싸져 있다고 가정하겠다.

1. pending일 때는 Suspense의 fallback UI를 렌더링하고
2. rejected가 되면 가장 가까운 Error Boundary의 fallback UI를 렌더링한다.
3. resolve될 때까지 기다렸다가 데이터를 받아 Suspense 내부 컴포넌트를 렌더링한다.

내부 동작원리

function use<T>(usable: Usable<T>): T {
  if (usable !== null && typeof usable === 'object') {
    if (typeof usable.then === 'function') {
        // Thenable 객체인 경우
      const thenable: Thenable<T> = (usable: any);
      return useThenable(thenable);
    } else if (usable.$$typeof === REACT_CONTEXT_TYPE) {
        // Context 객체인 경우 
      const context: ReactContext<T> = (usable: any);
      return readContext(context);
    }
  }
  // 둘 다 아닌 경우
  throw new Error('An unsupported type was passed to use(): ' + String(usable));
}

thenable 객체 처리

let thenableIndexCounter: number = 0;
let thenableState: ThenableState | null = null;

export function createThenableState(): ThenableState { // Thenable 상태 초기화
  return [];
}

function useThenable<T>(thenable: Thenable<T>): T {
  // 각 Promise 객체에 고유한 인덱스를 할당하여 구분
  const index = thenableIndexCounter;
  thenableIndexCounter += 1;
  if (thenableState === null) {
    // Thenable 상태가 없다면 초기화(단순히 배열을 생성하는 것이다)
    thenableState = createThenableState();
  }
  const result = trackUsedThenable(thenableState, thenable, index);
  const workInProgressFiber = currentlyRenderingFiber; // 현재 렌더링 중인 Fiber
  const nextWorkInProgressHook =
    workInProgressHook === null
      ? workInProgressFiber.memoizedState
      : workInProgressHook.next; // 다음 작업 중인 Hook을 식별

  if (nextWorkInProgressHook !== null) {
  } else {
    // 훅의 디스패처 설정
    const currentFiber = workInProgressFiber.alternate;
    // 컴포넌트가 마운트, 업데이트 되는지에 따라 적절한 디스패처 선택
    ReactSharedInternals.H =
      currentFiber === null || currentFiber.memoizedState === null
        ? HooksDispatcherOnMount
        : HooksDispatcherOnUpdate;
  }
  return result; // Promise에서 해결된 값이거나 아직 해결되지 않은 값일 수 있다.
}

⭐ 정리

1. 각 thenable 객체에 고유한 인덱스를 부여해서 구분하고 thenableState가 없다면 배열로 초기화한다.
2. 그 후 thenable 객체를 시작하고 추적할 수 있는 trackUsedThenable 함수를 호출한다.
3. 컴포넌트가 초기 마운트이거나 업데이트인지 상태에 따라 적절한 디스패치를 설정한다.
4. 마지막으로 결과를 반환하는데, 이 때 결과는 Promise의 상태에 따라 달라진다.

여기서 나오는 thenableIndexCounter와 thenableState는 실제로 각 fiber에 대해 finishRenderingHooks()에서 초기화된다. 이는 thenableState가 매 렌더링마다 새로 생성된다는 것을 의미한다.

trackUsedThenable thenable 객체 추적 함수

최대한 DEV 부분은 제외했다. 직접 구현할 수 없는 부분이기 때문이다.

function noop(): void {} // 빈 함수(핸들러 추가용, 메모리 누수 방지)
export function trackUsedThenable<T>(
  thenableState: ThenableState,
  thenable: Thenable<T>,
  index: number,
): T {
  const trackedThenables = getThenablesFromState(thenableState);
  const previous = trackedThenables[index];
  if (previous === undefined) {
  // 새로운 thenable이라면 추적한다.
  trackedThenables.push(thenable);
  }else {
    if (previous !== thenable) {
      // 기존과 다르면 이전 thenable은 유지한다.
      // noop 함수는 빈 함수로, thenable에 핸들러를 추가하여 메모리 누수를 방지한다.
      thenable.then(noop, noop);
      thenable = previous;
    }
  }
 // 상태에 따라 다르게 처리한다.
 switch (thenable.status) {
    case 'fulfilled': {
      const fulfilledValue: T = thenable.value;
      return fulfilledValue;
    }
    case 'rejected': {
      const rejectedError = thenable.reason;
      checkIfUseWrappedInAsyncCatch(rejectedError);
      throw rejectedError;
    }
    default: {
        // 상태가 문자열이라면 noop 핸들러를 추가한다.
      if (typeof thenable.status === 'string') {
      thenable.then(noop, noop);
      } else {
      const root = getWorkInProgressRoot();
        if (root !== null && root.shellSuspendCounter > 100) {
        // suspense 관련 작업의 수가 100을 초과한 경우 에러를 throw
        throw new Error(
            'async/await is not yet supported in Client Components, only ' +
              'Server Components. This error is often caused by accidentally ' +
              "adding `'use client'` to a module that was originally written " +
              'for the server.',
          );
        }
        // 상태를 pending으로 설정하고 성공 및 실패에 대한 callback
        const pendingThenable: PendingThenable<T> = (thenable: any);
        pendingThenable.status = 'pending';
        pendingThenable.then(
        // success callback하는 부분
          fulfilledValue => {
            if (thenable.status === 'pending') {
              const fulfilledThenable: FulfilledThenable<T> = (thenable: any);
              fulfilledThenable.status = 'fulfilled';
              fulfilledThenable.value = fulfilledValue;
            }
          },
          // error callback하는 부분
          (error: mixed) => {
            if (thenable.status === 'pending') {
              const rejectedThenable: RejectedThenable<T> = (thenable: any);
              rejectedThenable.status = 'rejected';
              rejectedThenable.reason = error;
            }
          },

        );
      }
      // Check one more time in case the thenable resolved synchronously.
      switch (thenable.status) {
      // ... 생략
       suspendedThenable = thenable;
      throw SuspenseException; // Suspense 예외를 throw

    }
  }
}

⭐ 정리

1. thenable 추적 배열에서 이전 thenable 확인
   ❌ : 새로 추가
   ✅ : 기존 것과 비교하여 처리를 한다. (기존 것과 다르면 기존 것을 재사용하고 noop핸들러에 추가하여 메모리를 관리한다.)

2. thenable 상태가 fulfilled라면 값을 반환하고, rejected라면 에러를 던진다.

3. pending 상태라면 빈 핸들러를 추가하여 메모리 누수를 방지한다.

4. 위 조건에 부합하지 않는 경우(커스텀 thenable 객체)라면 현재 트리의 루트를 가져와 shellSuspendCounter(suspense 관련 작업의 수)를 체크하고 100을 초과한다면 에러를 던진다.

5. 커스텀 thenable에서 처리를 하고 성공 or 실패했을 때 동작할 핸들러(상태 변경, 값 반환 등)를 추가한다.
   상태가 fulfilled라면 값을 반환하고, rejected라면 에러를 던진다.

6. 위 조건에 부합하지 않는 경우(미해결 된 pending 상태) Suspense 상태로 간주하여 suspendedThenable에 thenable을 저장하고 SuspenseException를 throw한다.

💡 noop 함수를 핸들러에 추가하는 이유

Promise에 .then() or .catch() 핸들러가 없으면, 그 Promise는 가비지 컬렉션이 지연될 수 있어 메모리 누수의 원인이 될 수 있다.

• noop이라는 빈 함수를 핸들러에 추가함으로써 Promise가 해결되거나 거부될 때 처리된 것으로 간주하고 필요 없어졌을 때 가비지 컬렉션의 대상으로 만들 수 있다.

readContext?

이거는 useContext()는 단순히 readContext()의 별칭이라고 보면 되는데 그 이유는 내부적으로 같은 의미로 쓰이기 때문이다. useContext의 동작 원리는 여기서 다루진 않겠다.

const HooksDispatcherOnMount: Dispatcher = {
  readContext,
  use,
  useCallback: mountCallback,
  useContext: readContext, 
}

use Hook을 조건문이나 반복문 내부에서 호출할 수 있는 이유

대부분의 useXXX() 훅들은 Fiber 노드에서 데이터를 저장하고 접근하며, 이 데이터 포인트들은 연결 리스트를 형성하여 해당 Fiber에 연결된다.

useState를 예시로 들자면 mountWorkInProgressHook()과 updateWorkInProgressHook()이 연결 리스트에서 올바른 데이터를 설정하고 가져오므로 호출 순서가 중요하다.

• 초기 마운트 단계에서 mountWorkInProgressHook를 호출하여 새로운 Hook 노드를 생성하고 연결 리스트에 추가한다. 이 Hook 노드에 초기 상태 값을 저장한다.
• 업데이트 단계에서 updateWorkInProgressHook를 호출하여 기존 Hook 노드를 찾아 업데이트한다. 이 과정에서 이전 상태 값을 읽고 새로운 상태 값을 설정한다.

즉 React에서는 매 렌더링마다 같은 순서로 Hook이 호출되어야 React가 올바른 Hook 노드를 찾아 데이터를 관리할 수 있기 때문에 useState와 같은 React Hook들은 호출 순서가 중요한 것이다.

하지만 useThenable()의 경우 데이터는 promise 자체에 첨부되고, readContext()의 경우 데이터는 Context Provider의 가장 가까운 조상 Fiber 노드에서 가져온다.

그렇기 때문에 use Hook은 useThanble과 readContext를 호출하기 때문에 조건문이나 반복문에서 호출될 수 있는 것이다.

🤷 그러면 readContext를 호출하는 useContext도 조건문이나 반복문에서 사용할 수 있지 않을까? useContext도 조건문이나 반복문 내에서 사용해도 문제가 없지만 Lint Rule에서 경고를 표시한다고 한다.

참고자료

[React] React 19 기능 다시 살펴보기

use – React

New React 19 use hook–deep dive

New React 19 Features You Should Know – Explained with Code Examples

How to use... "use", the new React 19 API

use Hook의 내부 동작 원리

How does use() work internally in React?

시작하기 전에

해당 글은 1/12에 노션으로 작성한 걸 2부로 나눈 것입니다. 다음 포스팅은 Debounce, Throttle, 이벤트 시뮬레이션을 다룰 것입니다.

Event

• 웹페이지에서 마우스를 클릭했을 때, 키를 입력했을 때, 특정요소에 포커스가 이동돼었을 때 어떤 사건을 발생시키는 것

• 대부분 상호작용이 되는 곳은 전부 이벤트가 활용된다.

• 기본적인 이벤트 종류 (자세한 내용은 아래 사이트에서 쉽게 확인할 수 있다.) 이벤트 종류 확인하기

  • UI 이벤트 : load, scroll…
  • 키보드 이벤트 : keydown, keyup
  • 마우스 이벤트 : click, mouseover, mousedown…
  • 폼 요소 이벤트 : submit, focus…
  • CSS 이벤트 : transitioned

Event 객체

이벤트가 발생하면 브라우저는 이벤트 객체라는 것을 만든다. 여기에 이벤트에 관한 상세한 정보를 넣은 다음, 핸들러에 인수 형태로 전달한다.

• event.target : 이벤트가 발생한 요소 (사용자가 의도한 가장 명확한 요소)
• event.currentTarget : 이벤트에 바인딩된 DOM요소를 가리킨다. 즉, addEventListener 앞에 기술된 객체를 가리키는 것
• event.type : 발생한 이벤트 종류
• event.cancelable : 기본 동작을 취소시킬 수 있는 여부
• event.key : 키보드를 친 경우 어떤 키를 쳤는지 알 수 있는 요소
• event.eventPhase : 이벤트 흐름 상에서 어느 단계에 있는지 반환
• event.clientX / event.clientY : 포인터 관련 이벤트, 커서의 상대 좌표

-> 여기서 좌표는 모니터 기준 좌표가 아니라 브라우저 화면 기준 좌표이다!

Event handler

• 이벤트에 반응하려면 이벤트가 발생했을 때 실행되는 함수인 핸들러를 할당해야 한다.

• 핸들러는 사용자의 행동에 어떻게 반응할지를 JS코드로 표현한 것 → Event Listener라고도 볼 수 있다.

• 핸들러는 여러 가지 방법으로 할당할 수 있으며 다음과 같이 있다.

  • HTML안에 on[event] 속성에 할당하기 ex ) button onclick="alert('클릭')"

  • DOM 프로퍼티에 on[event]을 사용하기

    • 대상 DOM 요소에 on 접두사를 붙인 이벤트명으로 이벤트 핸들러 프로퍼티를 설정하고 이벤트 발생시 처리할 함수를 등록하기

      • addEventListener() 메소드 활용하기

      • addEventListener 메소드를 이용하여 대상 DOM 요소에 이벤트를 바인딩하고 해당 이벤트가 발생했을 때 실행될 콜백 함수(이벤트 핸들러)를 지정한다.

      • 이 방식은 위의 두 방식과 달리 하나의 이벤트에 대해 하나 이상의 이벤트 핸들러를 추가할 수 있고 뒤에 서술할 캡처링과 버블링을 지원한다. 마지막으로 HTML 요소뿐만 아니라 모든 DOM요소(HTML, XML, SVG)에 대해 동작한다. 브라우저는 웹 문서(HTML, XML, SVG)를 로드한 후, 파싱하여 DOM을 생성한다.

❓ 코드 차이

Event 성능 최적화

페이지에 존재하는 이벤트 핸들러의 개수가 페이지 성능에 직접적인 영향을 미친다. 가령 input에 계속 동작한다던지, scroll 이벤트, resize 이벤트마다 발생하는 핸들러가 여러 개라면? omg..

• 원인

  • 각 함수가 메모리를 점유하는 객체이기 때문이다. (함수가 객체라는 건 다른 포스팅에서 봤죠?) 즉 메모리를 많이 사용할수록 성능은 떨어질 수 밖에 없다.
  • 이벤트 핸들러를 많이 할당하려면 DOM 접근도 많아지고 이는 전체 페이지의 응답성을 떨어트리게 된다.

• 개선 방법

  • 이벤트 위임 - 이벤트 핸들러 개수 줄이기 → 이는 뒤에 후술할 것

  • 더 이상 필요하지 않은 이벤트 핸들러 제거하기

    • 문서에서 요소를 제거하거나 페이지를 떠나는 경우, 요소는 제거되지만 이벤트 핸들러는 남아 메모리를 점유한다. 요소를 제거할 것이라면 잔류 핸들러를 직접 제거하는 것이 좋고 그러기 위해서는 떠나기 전에 onunload 이벤트 핸들러를 이용하여 잔류 핸들러를 모두 제거하는 것이 좋다.

    • 단, onunload 이벤트 핸들러를 사용하면 페이지가 bfcache에 저장되지는 않으므로 잘 선택해야 한다.

      💡 bfcache?

           back/forward cache의 약자로 이전/다음으로 이동할 때, 페이지 전체를 캐싱하여 페이지를 로드하는 시간과 데이터를 절약하는 기법

Event 전파

위에서 설명했다시피 계층적 구조에 포함되어 있는 HTML요소에 이벤트가 발생할 경우 연쇄적 반응이 일어나는 것

Bubbling

자식 요소에서 발생한 이벤트가 부모 요소로 전파되는 것 즉, 특정 화면 요소에서 이벤트가 발생하면 해당 이벤트가 상위의 화면 요소들로 전달되어 가는 특성을 가진다.

Capturing

자식 요소에서 발생한 이벤트가 부모 요소부터 시작하여 이벤트를 발생시킨 자식 요소까지 도달하는 것 즉, 이벤트가 발생했을 때 해당 이벤트가 최상위 요소인 body부터 해당 이벤트가 발생한 태그까지 전달되며 내려가는 특징을 가진다.

흐름

계층적 구조에 포함되어 있는 HTML 요소에 이벤트가 발생할 경우 연쇄적 반응이 일어난다. 즉, 이벤트가 전파되는데 전파 방향에 따라 버블링(Event Bubbling)과 캡처링(Event Capturing)으로 구분할 수 있다.  주의할 것은 버블링과 캡처링은 둘 중에 하나만 발생하는 것이 아니라 캡처링부터 시작하여 버블링으로 종료한다는 것이다. 즉, 이벤트가 발생했을 때 캡처링과 버블링은 순차적으로 발생한다. 흐름을 보면 다음과 같다.

1. 캡처링 단계 : 이벤트가 하위 요소로 전파되는 단계
2. 타깃 단계 : 이벤트가 실제 타깃 요소에 전달되는 단계 → 리스너 실행
3. 버블링 단계 : 이벤트가 상위 요소로 전파되는 단계

전파가 왜 있을까? 논리적으로는 자식 요소가 부모 요소 영역 안에 위치하고 있기 때문에 자식 요소만을 클릭했다 하더라도 부모 요소도 클릭했다고 넓은 영역에서 보면 맞는 말이기 때문… (그 A는 B이고 B는 C면 A는 C이다 같이…), 이벤트 위임과 같은 기법을 사용하면 이벤트를 일일이 등록하지 않아도 되므로 성능적으로 좋기 때문

전파 방지 방법

만일 부모와 자식 둘 다 이벤트를 등록한 상태에서, 자식 요소만 클릭했을 때만 이벤트 발생하고 부모 요소는 이벤트를 발생시키고 싶지 않은 상황에서 이벤트 동작 자체를 바꿀 수 없으므로 이벤트 전파를 방지 처리를 하는 식으로 해결해야 한다.

전파 방지는 필요한 경우가 아니면 죽은 영역이 될 수 있는 위험이 있으므로 아키텍처를 잘 고려해서 사용해야 한다.

e.stopPropagation()

버블링 또는 캡처링 설정에 따라 상위, 하위로 가는 이벤트 전파를 막을 수 있다. 즉, 각 엘리먼트의 이벤트 리스너만 동작할 수 있게 해준다.

e.stopImmediatePropagation()

이벤트 전파와 더불어 형제 이벤트 실행을 중지한다. 동일한 child 요소의 이벤트 리스너가 2개 등록 되어 있을 때, 어떠한 조건에서 클릭 이벤트를 두 번 실행하지 않고 한 번만 실행토록 하길 원한다면 유용하다.

위의 e.stopPropagation() 은 그 함수 자체의 전파는 막아주지만 다른 형제 핸들러들이 동작하는 건 막지 못하므로 요소에 할당된 다른 핸들러의 동작도 막으려면 해당 함수를 쓰는 것이 좋다.

e.target으로 조건 걸어 방지

정교하게 하고 싶을 때 직접 조건 분기를 통해 일일이 지정해 주는 방식이다.

e.preventDefault()

이벤트 전파 , 형제 이벤트 실행 중지 뿐만 아니라 기본 이벤트 동작 자체를 취소한다.

Event 위임

다수의 자식 요소에 각각 이벤트 핸들러를 바인딩하는 대신 하나의 부모 요소에 이벤트 핸들러를 바인딩하는 방법, DOM 트리에 새로운 자식 태그 요소를 추가하더라도 이벤트 처리는 부모 요소인 태그 요소에 위임되었기 때문에 새로운 요소에 이벤트를 핸들러를 다시 바인딩할 필요가 없다.

왜 사용해야 할까?

• 하나의 이벤트 핸들러를 사용하여 여러 이벤트를 효율적으로 처리할 수 있다고 한다.
  • 이는 결국 전체 페이지의 이벤트 유형을 효율적으로 관리하는 데 도움이 된다.

• 관리할 기능 자체가 줄어들기도 하고 사용 메모리 축소, DOM을 다루는 코드가 적어진다는 장점을 가지게 된다. 또한 동적으로 추가되는 요소에도 이벤트를 자동으로 적용 가능한 동적 요소 처리에도 유용하다.

• React와 Vue.js와 같은 곳에서 각 이벤트 처리 방식이 다를 수 있지만 이벤트 위임의 기본적인 개념은 동일하게 적용된다.

  • React

    JSX를 사용하여 이벤트 핸들러를 직접 작성하고, event.target을 이용하여 이벤트 처리한다.

  • Vue.js

    v-on 지시어를 사용하여 이벤트 핸들러를 등록하고, $event 객체를 통해 이벤트 정보에 접근한다.

참고자료

PoiemaWeb

이벤트 입문 - Web 개발 학습하기 | MDN

🌐 한눈에 이해하는 이벤트 흐름 제어 (버블링 & 캡처링)

Javascript 이벤트 전파와 이벤트 위임

티니핑 캐릭터들로 무거운 포스팅을 환기하고 싶

시작하기 전에

이전에 비동기 처리 방식에 대한 질문이 왔었고 그 때 당시에는 어물쩡하게 답했지만 제대로 알 필요가 있다고 생각하여 포스팅을 오랜만에 하게 되었다.

해당 글은 1/5에 노션으로 작성한 걸 옮긴 것입니다.

비동기 함수

• JS는 기본적으로 단일 스레드이기 때문에 동기적으로 문제를 해결
• 비동기 처리란 특정 코드가 끝날때 까지 코드의 실행을 멈추지 않고 다음 코드들을 먼저 실행하는 것

비동기 로직

콜 스택 (Call Stack)

함수의 호출을 스택방식으로 기록하는 자료구조, 한 번에 하나의 Task만 처리 가능

마이크로태스크 큐 (Microtask Queue)

Promise, async/await와 같은 비동기 호출의 Callback함수들은 해당 스택에 담기게 된다.

Eventloop는 현재 실행중인 Task가 있는지, 큐들에 적재된 Task가 있는지 주기적으로 확인하고 만약 실행중인 Task가 콜 스택에 없다면 큐에서 꺼내와 콜 스택에 올리고 실행시키는 역할을 한다.

즉, Promise를 반환하면 비동기로 실행된다고 해서 병렬로 실행된다는 아니라는 것

Promise의 then, catch, finally로 전달되는 Callback 함수가 비동기로 실행되는 것!

Callback 함수

• 나중에 호출하는 함수
• 대표적인 방식은 setTimeout으로, 후순위로 밀려나고 callback함수를 사용해서 동기적으로 코드가 작성하는 것처럼 보여줄 수 있다.
• 예제코드(한 번 실행 예시를 먼저 생각해 볼 것) 문제 1

// 코드 실행이 어떻게 될까요? 🙃
function processOrder(orderNumber) {
    if (!orderNumber) {
        return console.log("주문번호가 없습니다");
    }
    console.log(`주문 ${orderNumber}번 처리중...`); 
    startCooking(); 
}

function checkInventory(item, callback) {
    console.log("재고 확인중..."); 
    console.log(`${item} 찾는중...`);

    setTimeout(() => {
        const stock = {
            '파스타': { quantity: 5, orderNum: 'A123' },
            '피자': { quantity: 0, orderNum: 'B456' },
            '샐러드': { quantity: 3, orderNum: 'C789' }
        };
        callback(stock[item]?.orderNum);
    }, 2000);
}

function startCooking() {
    setTimeout(() => {
        console.log("조리 시작!"); 
        setTimeout(() => {
            console.log("완성되었습니다!"); 
        }, 1000);
    }, 1500);
}

function orderFood(menu, callback) {
    console.log(`${menu} 주문이 들어왔습니다`);
    checkInventory(menu, callback);
}

orderFood('파스타', processOrder);

• 코드 실행 답

    // 실행 결과
    // "파스타 주문이 들어왔습니다" 
    // "재고 확인중..." 
    // "파스타 찾는중..." 
    // (2초 후) "주문 A123번 처리중..."
    // (1.5초 후)"조리 시작!" 
    // (1초 후)"완성되었습니다!" 

• 다만 비동기 처리 로직을 위해 콜백 함수를 연속해서 사용하면 콜백지옥이 발생한다.

  • 이를 해결하고 싶으면 Promise나 Async를 사용하면 되지만 만약 코딩으로만 해결하고 싶다면 콜백 함수를 분리하면 된다.

Promise

• 비동기 처리에 사용되는 객체

• Promise의 상태(처리 과정)

  • Pending(대기) : 비동기 처리 로직이 아직 완료되지 않은 상태
    • new Promise() 메서드를 호출하면 해당 상태가 되는데 콜백 함수를 선언할 수 있고, 콜백 함수의 인자는 resolve, reject
  • Fulfilled(이행) : 비동기 처리가 완료되어 프로미스가 결과 값을 반환해준 상태
    • 콜백 함수의 인자 resolve가 실행하면 해당 상태가 된다.
    • 이행 상태가 되면 then()을 이용하여 처리 결과 값을 받을 수 있다.
  • Rejected(실패) : 비동기 처리가 실패하거나 오류가 발생한 상태
    • reject가 실행하면 해당 상태가 되고 실패한 이유(실패 처리의 결과 값)를 catch()로 받을 수 있다.

• 여러 개 프로미스 연결하기 (Promise Chaining)

  • then() 메서드를 호출하고 나면 새로운 프로미스 객체가 반환 (약간 아래와 같은 방식으로)

    function getData() {
    return new Promise({
      // ...
    });
    }
    
    // then() 으로 여러 개의 프로미스를 연결한 형식
    getData()
    .then(function(data) {
      // ...
    })
    .then(function() {
      // ...
    })
    .then(function() {
      // ...
    });
    

async&await

• async function를 실행하면 Promise 객체가 반환
• async function의 return 값은 promise의 resolve값이 된다.
• async await의 오류는 try catch로 잡아낼 수 있다.
• await는 promise 상태가 다 진행될 때까지 기다렸다가 다음으로 진행
  • 그러므로 await 위치가 promise 객체를 생성하는 함수 앞에 놓이는 것

WebAPI

웹 코드를 작성하는데 필요한 작업들을 모아둔 API들

브라우저나 nodeJS와 같은 런타임에 탑재되어 있다.

여기에 있는 API는 대표적으로 fetch, setTimeout, setInterval 등이 있다.

비동기 처리의 핵심

코드 예제

실행 방식을 제대로 이해해보기 velog는 아쉽게도 토글 기능을 지원하지 않기 때문에 안 보고 최대한 해보고 정답을 보기

async function asyncProcess() {
 console.log('Process Start');
 await new Promise((resolve) => {
   console.log('Inner Works');
   resolve('done');
 }).then((data) => {
   console.log('First Complete');
 });
 console.log('Process End');
}

console.log('Initialize');
asyncProcess().then(() => {
 console.log('All Done');
});
console.log('Keep Going');

• 코드 정답

    /* 실행 순서:
    "Initialize"
    "Process Start"
    "Inner Works"
    "Keep Going"
    "First Complete"
    "Process End"
    "All Done"
    */

async function asyncFunction() {
    console.log('First Step');

    new Promise(resolve => {
        console.log('Inner Promise');
        resolve('data');
    }).then(data => {
        console.log('Promise Resolved');
    });

    Promise.resolve().then(() => {
        console.log('Quick Promise');
    });

    console.log('Last Step');
}

console.log('Start Process');
asyncFunction().then(() => {
    console.log('All Complete');
});
console.log('End Process');

• 코드 정답

    /* 실행 순서:
    "Start Process"
    "First Step"
    "Inner Promise"
    "Last Step"
    "End Process"
    "Promise Resolved"
    "Quick Promise"
    "All Complete"
    */

출처

[Javascript]비동기 처리(callback, promise, async/await)

Javascript 비동기 함수의 동작원리 (feat. EventLoop)

Promise.all() - JavaScript | MDN

자바스크립트 Promise 쉽게 이해하기

이번에는 Utility Type과 관련되어 필자가 배웠던 부분을 정리해보고자 한다. 5부로 마지막을 짓고 이제 프로젝트와 관련된 부분을 정리해보고자 한다. 🙇‍♂️ 지난번 회고에서도 적었듯이 최대한 정확한 정보로 작성하고는 있지만 불가피하게 잘못 된 정보를 적을 수도 있다는 점 미리 양해바란다.

Utility Types

TypeScript는 일반적인 유형 변환을 용이하게 하는 여러 유틸리티 유형을 제공하며, 이 유틸리티는 전역적으로 사용할 수 있다. 이 중 몇 개만 정리할 것이다.

Partial<T>

특정 객체 타입의 모든 프로퍼티를 선택적 프로퍼티로 바꿔주는 타입

//예시
interface Post {
    title : string;
    tags : string[];
    content : string;
    thumnailURL ?: string;
}
const draft : Partial<Post> => {
    title : "제목은 나중에",
    content : "임시저장용",
} // 원래는 tags도 담아야 하지만 선택적 프로퍼티로 바뀌어 안 넣어도 된다.

Required<T>

특정 객체 타입의 모든 프로퍼티를 필수 프로퍼티로 바꿔주는 타입

//예시
interface Post {
    title : string;
    tags : string[];
    content : string;
    thumnailURL ?: string;
}
const draft : Required<Post> => {
    title : "제목은 나중에",
    content : "임시저장용",
    tags : ["hello"],
    thumnailURL : "",
} /* thrumnailURL이 선택적 프로퍼티였지만 Required 유틸리티 타입을 쓰게 되면,
    필수 프로퍼티로 되어 넣지 않으면 에러를 일으킨다.*/

Readonly<T>

readonly의 기능과 똑같고 모든 프로퍼티가 읽기전용으로 된다. 수정이 불가능하다.

Pick<T, K>

객체 타입으로부터 특정 프로퍼티만 뽑아내는 타입

//예시
interface Post {
    title : string;
    tags : string[];
    content : string;
    thumnailURL ?: string;
}
const draft : Pick<Post, “title | content”> => {
    title : "제목은 나중에",
    content : "임시저장용",
} //원래는 tags를 필수로 넣어야 되지만 이럴경우 title과 content만 쓸 수 있다.

Omit<T, K>

객체 타입으로부터 특정 프로퍼티를 제거하는 타입

Omit<Post, “title”> -> title이라는 프로퍼티를 안 넣겠다라는 의미가 된다.

Record<T, K>

// 이럴 경우 이름만 다르고 프로퍼티가 같은 객체가 담겨있기 때문에 비효율적인 모습을 보인다.
type Thumbnail = {
    large : {
        url : string;
    };
    medium : {
        url : string;
    }
    small : {
        url : string;
    }
}
//Record활용하기
type Thumbnail = Record<“large” | “medium” | ”small”, {url : string} > //앞부분은 key 뒷부분은 value를 담게된다.

Exclude<T, U>

T에서 U를 제거하는 타입

type T0 = Exclude<"a" | "b" | "c", "a">;
//type T0 = "b" | "c"

type Shape =
  | { kind: "circle"; radius: number }
  | { kind: "square"; x: number }
  | { kind: "triangle"; x: number; y: number };

type T3 = Exclude<Shape, { kind: "circle" }>

/*
type T3 = {
    kind: "square";
    x: number;
} | {
    kind: "triangle";
    x: number;
    y: number;
}
*/

‼️Extract<T, U>의 경우는 Exclude와 반대로 T에서 U에 해당하는 타입을 추출한다.‼️

type T0 = Extract<"a" | "b" | "c", "a" | "f">;
//type T0 = "a"
//위의 type Shape를 응용하면
type T2 = Extract<Shape, { kind: "circle" }>
/*
type T2 = {
    kind: "circle";
    radius: number;
}
*/

ReturnType<T>

함수의 반환값 타입을 추출하는 타입

function funcA(){return “hello”}
type ReturnA = ReturnType<typeof funcA>;

⭐️(...args: any)의 의미⭐️ …arg <- 매개변수 몇개가 들어와도 상관이 없는 것을 의미하며 :any는 저 매개변수들이 모두 any타입이다~라는 뜻

📚참고문헌 https://www.inflearn.com/course/한입-크기-타입스크립트/dashboard https://www.typescriptlang.org/docs/handbook/utility-types.html#handbook-content

이번에도 계속해서 TypeScript와 관련되어 필자가 헷갈리는 부분을 적어보고자 한다. 이번에는 타입조작이랑 관련된 방법만 작성할 것이다. 🙇‍♂️ 지난번 회고에서도 적었듯이 최대한 정확한 정보로 작성하고는 있지만 불가피하게 잘못 된 정보를 적을 수도 있다는 점 미리 양해바란다.

타입 조작

다양한 타입 연산자를 조합하여 복잡한 연산과 값을 간결하고 유지보수 가능한 방식으로 표현할 수 있다. 대표적인 방식으로는 Generic이 있으며 typeof도 이에 해당한다. 이 두 가지 방법 외에도 기존의 타입이나 값에 기반하여 새로운 타입을 표현하는 방법에 대해 다룰 것이다.

Indexed Access Types

객체,배열,튜플 타입에서 특정 프로퍼티 혹은 요소의 타입을 추출하는 타입을 의미한다. 예를 들어 다음과 같은 interface가 있다고 가정을 해보자

interface Post {
  title: string;
  content: string;
  author: {
    id: number;
    name: string;
  };
}

Post라는 interface에 있는 author에 프로퍼티가 점점 많이 필요하게 된다면 어떻게 할까? 다음과 같이 작성할 수도 있지만 이는 비효율적이기도 하고 author 프로퍼티가 늘어날 때마다 수정을 해야되기 때문에 이 방법은 피해야 한다. function printAuthorInfo(author: { id: number; name: string, age: number }) ⬅️ 이런 방식은 피해야 된다. Indexed Access Types를 활용하면 다음과 같이 나타낼 수 있다.

function printAuthorInfo(author: Post["author"]) 다만 이 Types를 활용할 때에는 아래와 같은 규칙을 지켜야 한다. 1️⃣ 값이 아니라 타입만 명시할 수 있으며 존재하지 않는 건 쓸 수 없다! 2️⃣ author라는 객체에 특정 property만 가져오고 싶다면 ?(예를들면 author.name) ➡️ Post[“author”][“name”] 이런식으로 표현하면 된다! 3️⃣ 만약 Post가 list형태로 되어있다면, Post[number] 이런식으로 해당 요소만 찾으면 된다.(아래 코드 참고)

//3번 규칙 관련 코드
const MyArray = [
  { name: "Alice", age: 15 },
  { name: "Bob", age: 23 },
  { name: "Eve", age: 38 },
];
type Person = typeof MyArray[number];
/*  type Person = {
    name: string;
    age: number;
}*/
type Age = typeof MyArray[number]["age"];
//   type Age = number
// 혹은 아래와 같이 표현할 수 있다.
type Age2 = Person["age"];
//   type Age2 = number

Keyof Type Operator

특정 객체 타입으로부터 프로퍼티 키들을 모두 스트링 리터럴 유니온 타입으로 추출하는 연산자

• 언제 쓸까? interface 안에 property가 많은데 이 중에 key값을 찾아서 쓰고 싶을 때 일일이 key : “name” | “age” | … 이런형식은 비효율적이므로 이럴 때 사용한다.
• 형식 및 유의할 점 형식 ➡️ key : keyof Person 이런식으로 해주기! 유의할 점➡️keyof연산자는 무조건 뒤에 타입만 사용할 수 있다!

//Keyof Type Operator 활용 예시
interface Person {
  name: string;
  age: number;
  location: string; // 3개의 프로퍼티
}

function getPropertyKey(person: Person, key: keyof Person) {
  return person[key];
}

const person: Person = {
  name: "밍글",
  age: 27,
  location : "Seoul"
};

console.log(getPropertyKey(person,"location")); 
// 이런식으로 key는 문자열 형태로("") 호출해주기
// Seoul

Mapped Types

기존의 객체 타입으로부터 새로운 객체 타입을 만드는 타입 ex. 수정하는 기능(변경되는 값만 바꾸고 싶은 경우. 전체를 보내면 필요없는 부분도 수정이 되어야 하기 때문) 사용 방식 ➡️ [key in “id” | “name” | “age” (혹은 keyof User)] ?: User[key]

//코드 예시
interface User {
  id: number;
  name: string;
  age: number;
}

type PartialUser = {
  [key in "id" | "name" | "age"]?: User[key];
};

(...)

readonly 📖 readonly 속성을 통해 요소들을 읽기전용으로만 만들 수 있다.(object관련) 그냥 요소 앞에 readonly를 추가하면 된다. ex) readonly name : Name array의 경우 push가 안되는거지 filter나 map은 가능하다.

Template Literal Types

스트링 리터럴 타입을 기반으로 정해진 패턴의 문자열만 포함하는 타입(실제로 사용하는 경우는 특수하다.) 예시코드

type Color = "red" | "black" | "green";
type Animal = "dog" | "cat" | "chicken";

type ColoredAnimal = `${Color}-${Animal}`;

const coloredAnimal : ColoredAnimal = '' 
//이렇게 하면 해당 부분에 `red-dog` | 'red-cat' | 'red-chicken' | 'black-dog' ... 등 담을 수 있다.

Conditional Types

//조건부 타입 예시
 type A = number extends string ? String : number;
// 이거의 답은 거짓이므로 type A는 number type이 되는 것!
//제네릭과 조건부 타입 예시
type StringNumberSwitch<T> = T extends number ? string : number;
let varA : StringNumberSwitch<number> //string
//반대로 StringNumberSwitch<string>을 넣으면 number타입으로 된다.

⭐️함수에서 활용해보기(with generic)⭐️

//예시코드
function removeSpaces(text : string | undefined | null){
    if(typeof text === “string”){return text.replaceAll(“ “,””);}
    else {return undefined}
}

이렇게 작성해도 되지만 이럴경우에 const result = removeSpaces(“hello my name is Mingle”) 는 string | undefined으로 타입을 추론하기 때문에 뒤에 as string을 넣어줘야만 toUpperCase()같은 기능을 쓸 수 있다. 이를 generic과 조건부 타입을 활용한다면 as string을 안 써도 된다. 단, 이 방법의 경우 overload도 활용해야 한다

function removeSpaces<T>(text : T) : T extends string ? string : undefined;
function removeSpaces(text : any){    if(typeof text === "string"){return text.replaceAll(' ','')}
    else {return undefined}}
const result = removeSpaces('hello my name is Mingle');
const newResult = result.toUpperCase();
const otherResult = removeSpaces(undefined);
console.log(newResult); //대문자로 치환되서 나오게 된다.
console.log(typeof otherResult); //undefined

Distributive Conditional Types

//예시
type StringNumberSwitch<T> = T extends number ? string : number;
const testA = StringNumberSwitch<number | string>;
// 유니온 타입으로 할당하게 되면 하나하나 다 확인을 하기 때문에 유니온 타입으로 가지게 된다.
type Exclude<T,U> = T extends U ? never : T;
type A = Exclude<number | string | boolean, string>;
/*이 경우 경우의 수를 number,string | string,string | boolean, string으로 각각 조건부로 보게 되고,
결과는 number | never | boolean이 된다.
이 때 never는 사라지게 되므로 최종적으로 number | boolean type이 된다.*/

만약 유니온 타입으로 만들기 싫다면 ? type Exclude<T,U> = [T] extends [U] ? never : T; <- 이런식으로 각 조건문에 []를 하면 된다.

Inferring Within Conditional Types

조건부 내에서 특정 타입만 딱 추론해 내올 수 있는 것을 뜻한다. 이로써 true 분기 내에서 Type의 요소 타입을 어떻게 찾아내는지를 지정한다. 주로 함수 타입에서 반환 타입을 추출할 때 사용한다.

type ReturnType<T> = T extends () => infer R ? R : never;
type A = ReturnType<()=>string> // string
type B = ReturnType<()=>number> // R이 number로 자동으로 추론
type C = ReturnType<number> // 이럴때는 추론이 불가능하게 된다. any타입으로 판단하게 되고 에러를 일으킨다.

📚참고문헌 https://nomadcoders.co/typescript-for-beginners https://www.inflearn.com/course/한입-크기-타입스크립트/dashboard https://www.typescriptlang.org/docs/handbook/2/types-from-types.html ⬅️ 해당 부분 중 Type Manipulation을 참고

이번에도 계속해서 TypeScript와 관련되어 필자가 헷갈리는 부분을 적어보고자 한다. Javascript에 있는 내용일 수도 있지만 최대한 겹치는 부분은 피하면서 적을 예정이다. 🙇‍♂️ 이번엔 Interface, Class, Generic에 관해서 집중적으로 다뤄보고자 한다.📖 지난번 회고에서도 적었듯이 최대한 정확한 정보로 작성하고는 있지만 불가피하게 잘못 된 정보를 적을 수도 있다는 점 미리 양해바란다.

Interface

interface란?

타입에 이름을 지어주는 또 다른 문법, 객체의 구조를 정의하는데 특화된 문법(상속, 합침 등의 특수한 기능을 제공한다)이다.

⭐️타입과 차이점?

• 인터페이스 자체에서 유니온이나 인터섹션을 만들 수는 없다. 꼭 이용해야한다면 타입 별칭이나 타입 주석에 따로 해줘야한다.
• 선언 합침 => 인터페이스의 경우에는 동일한 이름으로 하고 선언해도 문제가 되지 않는데, 나중에 다 합쳐져 있기 때문이다. (중복선언 가능, 선언 merge가 된다.) 하지만 재선언을 할 수는 없다.. 하더라도 동일한 타입만 적용이 가능하기 때문

interface 상속하는 방법

interface Animal {
  name: string;
  color: string;
}

interface Dog extends Animal {
  breed: string;
}

interface Cat extends Animal {
  isScratch: boolean;
}

interface Chicken extends Animal {
  isFly: boolean;
}

🚨Point🚨 프로퍼티에 재 정의가 가능하지만, 다시 정의하는 타입이 슈퍼타입 동일한 이름의 원본 프로퍼티의 하위여야 한다. (쉽게 말해서 Animal name에 string을 해놨는데 Dog name에 number로 재설정을 할 수가 없다는 뜻!) 다중확장도 가능하다. 예를 들어 extends Dog,Cat일 경우에는 Dog, Cat에 해당하는 프로퍼티를 모두 갖게 되는 것이다.

Class

예전에 Class기록한 곳 class constructor나 상속과 같은 Class 기본적인 부분은 다루지 않을 것이다. 위의 링크에서도 일부만 다뤘는데 그 이유는 다른 문법에서도 이 Part는 OOP부분으로 비슷하게 나오기 때문에 작성하지 않는 점 양해바란다. https://www.typescriptlang.org/docs/handbook/2/classes.html ⬆️ 이 사이트에 가면 공식적으로 나와 있기 때문에 참고하면 좋을 것 같다.

Interface & Class

Class Character implements CharacterInterface { interface부분이 설계도같은 느낌이 된다. 그러고 Interface에 있는 부분을 다 넣어주면 되고 constructor도 만들어줄 수 있다. interface는 무조건 public만 지정을 해줄 수 있다 }

예시코드

abstract class User{constructor(protected firstName:string,
protected lastName:string){}
abstract sayHi(name:string):string
abstract fullName():string}

class Player extends User{fullName(){return `${this.firstName}`}
sayHi(name:string){return `Hello ${name}.My name is ${this.fullName()}`}}

//추상 클래스는 이것으로부터 인스턴스를 만드는 것을 허용하지 않는다. new User이런거 안됨
//추상 클래스를 인터페이스로 바꾸기

interface User{firstName:string,
lastName:string,
sayHi(name:string):string
fullName():string}
//extends는 JS의 용어이기 때문에 implements라는 용어를 쓸 것이다.
//인터페이스를 상속할 때에는 property를 private으로 만들 수 없다.(무조건 public만 가능!)
class Player implements User{constructor(public firstName:string,
public lastName:string){}
fullName(){return `${this.firstName}`}
sayHi(name:string){return `Hello ${name}.My name is ${this.fullName()}`}
}

/*인터페이스는 고유한 사용처가 있다.클래스의 모양을 알려준다.인터페이스도 타입으로 쓸 수 있고
여러 개의 인터페이스 상속 받는 것도 가능하다*/

Generic

사용법

func<T> Type을 저장하는 변수라는 뜻 매개변수랑 반환값도 T로 바꿔줘야 한다. 함수를 호출했을 때 Type이 추론된다. 예시코드

function func<T>(value: T): T {
  return value;
}

let num = func(10);
// number 타입
// 튜플처럼 만들고 싶다면? Func<[number, number, number]>([1,2,3]); 

❗️알아두면 좋은 것 ❗️ <T,U>(a : T , b : U) => 여러 개 선언해서 사용이 가능하다. 제네릭으로 배열을 할당하고 0번째 index를 호출하고 싶다면? 그러면 매개변수에 T[]로 해주면 된다. 그러면 어떤 타입인지는 몰라도 그 타입의 형태가 배열일것이다 라고 추론을 하게 된다. 혹은 매개변수에 [T, …unknown[]] 이렇게 하기(이 경우에는 0번째 index말고는 다른 곳의 type은 필요없을 때만 활용이 가능하다.) 타입은 몰라도 length를 알고 싶다면? <T extends {length : number}> ⬅️ 이러면 length라는 프로퍼티를 가지는 타입만 추론이 가능하게 된다.

제네릭 인터페이스 와 제네릭 타입 별칭

코드예시

interface KeyPair<K, V>{
key : K;
Value : V;
}
//타입을 직접 할당을 해줘야 에러가 안 일어난다!
const keyPair : KeyPair<string, number> = { key : “key”, value : 0,}

인덱스 시그니처를 제네릭과 조합하여 더 유연하게 활용이 가능하다.

예시는 두 개의 타입 변수를 활용한 코드이다.

interface Map<V> {[key : string] : V;} 
interface MainPlaylistProps<V, U>{
    [key : string] : V | U;
}

const exampleMap :MainPlaylistProps<number,string> = {
  type: "playlist",
  playlistIdx: 3,
  playlistName: "test",
  backgroundIdx: 1,
  userIdx: 0,
  imageIdx: 2,
}

❗️type에 따라서 다르게 지정하는 제네릭 인터페이스의 활용 예시❗️

interface User {name : string, profile : Student | Developer;} 제네릭을 활용할 시 ➡️ interface User{name : string, profile : T} 이를 활용하고 싶다면 ➡️ User<Developer> User<Student> 이렇게 지정을 해줘야한다.

제네릭 클래스

기존 클래스와의 차이점?

기존의 클래스의 경우, number[]와 string[]가 동시에 필요하다면 두 개의 별도의 class를 만들어야 하는 비효율 발생하게 된다. 이를 제네릭 클래스를 활용할 경우에는 이러한 비효율을 방지할 수 있다.

  //제네릭 클래스 활용 예시
  class List<T>{constructor(private list : T[]){} push(data : T){this.list.push(data)}}

📚참고문헌 https://nomadcoders.co/typescript-for-beginners https://www.inflearn.com/course/한입-크기-타입스크립트/dashboard https://www.typescriptlang.org/docs/handbook/2/classes.html

이번에는 지난 1부에 이어서 계속해서 TypeScript와 관련되어 필자가 헷갈리는 부분을 적어보고자 한다. Javascript에 있는 내용일 수도 있지만 최대한 겹치는 부분은 피하면서 적을 예정이다. 🙇‍♂️ 아마 다음에 적을 Class같은 부분은 다른 링크를 달아두어 최대한 TypeScript와 관련된 부분만 적을 것이다. 👨‍💻 지난번 회고에서도 적었듯이 최대한 정확한 정보로 작성하고는 있지만 불가피하게 잘못 된 정보를 적을 수도 있다는 점 미리 양해바란다.

Type에 대한 Part

객체 Type의 호환성

결론부터 말하자면 객체타입은 프로퍼티를 기준으로 호환성을 가진다. 예를 들어 Animal의 프로퍼티가 있고 Dog가 Animal의 프로퍼티를 그대로 가지고 있으면서 breed라는 프로퍼티가 더 있는 상황이라면, Dog는 Animal의 서브타입이라고 볼 수 있게 된다.

즉, 서브 타입일수록 슈퍼 타입의 속성을 그대로 가지면서 속성이 더 많아진다고 볼 수 있다.

대수타입

여러개의 타입을 합성해서 새롭게 만들어낸 타입

1. Union (|)

유니언 타입은 서로 다른 두 개 이상의 타입들을 사용하여 만드는 것으로, 유니언 타입의 값은 타입 조합에 사용된 타입 중 무엇이든 하나를 타입으로 가질 수 있다. 조합에 사용된 각 타입을 유니언 타입의 멤버라고 부른다. ex. string | number; -> 문자열 또는 숫자를 받을 수 있게 된다. ‼️유의사항 : TypeScript에서 유니언을 다룰 때는 해당 유니언 타입의 모든 멤버에 대하여 유효한 작업일 때에만 허용된다. 예를 들어 string | number라는 유니언 타입의 경우, string 타입에만 유효한 메서드는 사용할 수 없다.‼️

2. Intersection (&)

두 개 이상의 타입들이 공통적으로 가지고 있는 타입으로 좁혀서 만든다. ex. number & string -> never로 만들어지게 된다.

타입 추론

일반적인 변수를 선언할 때 자동으로 타입을 추론해준다. 함수의 경우에는 return문 다음의 반환값을 기준으로 추론가능하다.

타입 단언

원하는 기능을 만들기 어려울때 {} as 타입이름 으로 간주를 시켜주면 된다!

규칙 A as B A가 B의 슈퍼타입이거나 서브타입이어야 한다. 즉, A와 B가 완전 독립적인 타입이면 안된다는 것이다.

Non null 단언 (!.) Ex) post.author!.length

TypeScript에는 명시적인 체크를 수행하지 않고도 타입에서 null과 undefined를 제거하는 특별한 구문이 있다. 어떤 표현식 뒤에 !를 쓰면, 이는 해당 값이 null 또는 undefined가 아니라고 타입 단언을 하는 것이다.

타입 좁히기

1. typeof

if(typeof a === ‘number’){ let b = a + 1} 이런식으로 typeof를 먼저 조건을 걸어주면 된다.

2. instanceof

예를 들어 typeof로는 Date를 정확히 분류가 되지 않는다. 이럴 때 instanceof를 사용하면 Date의 객체냐 이렇게 판별을 해줄 수 있다. (클래스여야 가능! 객체 타입은 활용 불가능)

3. in

"value" in x. 여기서 "value"는 문자열 리터럴이고 x는 유니온 타입으로 가정해보자. "true" 분기는 x의 타입을 좁혀서 옵셔널 속성 또는 필수 속성 value를 가진 타입으로 좁히게 되고, "false" 분기는 optional 속성이거나 속성 value가 없는 타입으로 좁히게 된다. ex . value && “age” in value <- value가 존재하며 value안에 age가 있는지 확인하는 구문이다.

함수와 Type

함수 타입

한 줄로 정리하자면, 어떤 [타입의] 매개변수를 받고, 어떤 [타입의] 결과값을 반환하는지 보여주면 된다. 선택적 매개변수로 만드는 방법 -> ?: ex) name ?: string

Call Signatures

Call Signatures은 타입을 만들 수 있고, 함수가 어떻게 작동하는 지 서술해 둘 수 있다.

예시 ) type Add=(a:number, b:number) ⇒number const add:Add = (a,b) ⇒ a+b

이 방식이 좋은 이유는 프로그램을 디자인하면서 타입을 먼저 생각하고 그 다음 코드를 구현 할 수 있기 때문이다.

overloading

같은 이름의 함수를 매개변수의 개수나 타입에 따라 여러가지 버전으로 정의하는 방법이다. 여기서는 코드로 2가지의 예시를 보여주도록 하겠다.

// 버전들 -> 오버로드 시그니쳐
function func(a: number): void;
function func(a: number, b: number, c: number): void;

// 실제 구현부 -> 구현 시그니쳐
function func(a: number, b?: number, c?: number) {
  if (typeof b === "number" && typeof c === "number") {
    console.log(a + b + c);
  } else {
    console.log(a * 20);
  }
}

func(1);        // ✅ 버전 1 - 오버로드 시그니쳐
func(1, 2);     // ❌ 
func(1, 2, 3);  // ✅ 버전 3 - 오버로드 시그니쳐

//파라미터의 개수가 다른 경우에 overloading
type Add = {
(a:number, b: number) : number,
(a:number, b:number, c: number): number,}

const add:Add = (a,b,c) => {
return a + b} //이러면 오류가 발생하는데 c는 필수일수도 아닐수도 있기 때문에(즉, 옵션이라는 것!)
//해결방안
const add:Add = (a,b,c?:number) => {
if(c) return a+b+c
return a + b} 

사용자 정의 타입 가드

예를 들어 Animal이라는 타입이 있고 Dog와 Cat의 타입이 있다고 가정해보자. type Animal = Dog | Cat 해당 타입(Dog,Cat)의 프로퍼티를 다 알고 있어야하는게 문제가 될시에 어떻게 Dog와 Cat 타입을 나눌 수 있을까? (혹은 이 이상의 타입들을 어떻게 나눌 수 있을까?) 그럴 땐 함수를 만들어서 function isDog(animal : Animal){ return (animal as Dog).isBark !== undefined;} 이런식으로 해주면 된다. 하지만 이렇게 하는데도 반환되는 type은 Animal로 되기 때문에 저 리턴하는 함수에다가 animal is Dog를 추가해줘야 한다.

function isDog(animal: Animal): animal is Dog { return (animal as Dog).isBark !== undefined; }

📚참고문헌 https://nomadcoders.co/typescript-for-beginners https://www.inflearn.com/course/한입-크기-타입스크립트/dashboard https://www.typescriptlang.org/docs/handbook/2/narrowing.html

오랜만에 글을 써 보는 것 같다. 현재 마무리 된 프로젝트와 관련된 글도 써야하고 Next.js와 관련된 글도 써야하는데 또 새로운 회고록을 적게 되었다. TypeScript와 관련되어 필자가 헷갈리는 부분을 적어보고자 한다. Javascript에 있는 내용일 수도 있지만 최대한 겹치는 부분은 피하면서 적을 예정이다. 🙇‍♂️ 최대한 정확한 정보로 작성하고는 있지만 불가피하게 잘못 된 정보를 적을 수도 있다는 점 미리 양해바란다.

TypeScript

타입스크립트(TypeScript)는 자바스크립트의 슈퍼셋인 오픈소스 프로그래밍 언어이며 마이크로소프트에서 개발, 유지하고 있으며 엄격한 문법을 지원한다. 출처 : https://ko.wikipedia.org/wiki/타입스크립트

왜 TypeScript를 쓰는가? (JavaScript의 단점)

TypeScript를 쓰는 이유는 다음과 같이 나타낼 수 있다. *1. TS는 타입 안정성이 있다. * JS는 타입 안정성이 존재하지 않는다. 아래에 예시코드를 보여주도록 하겠다.

[1,2,3,4] + false
> '1,2,3,4false' //이렇게 배열이 사라지고 문자열처럼 취급하게 된다.

function divide(a,b){
    return a/b
}
divide(2,3);
divide("xxxxx"); //-> 이런식으로 해도 error메시지를 따로 띄우지는 않는다. 그냥 NaN이라고 할뿐

이렇듯 JS는 자유롭고 유연한 언어이기 때문에 가끔 문법상 말이 안되는 코드들도 허용을 해 주는 경우가 많다. TS는 JS를 더 안전하게 사용할 수 있도록 타입 관련 기능들을 추가한 언어라고 보면 된다. 2. TS는 버그 발생을 줄일 수 있다. JS의 또 다른 단점으로는 코드가 잘못되었음에도 실행되기 전에 잡아주지 않고, 실행되고 나서 잡아준다는 점이 존재한다. 그러나 TS는 실행되기 전에 타입과 맞지 않는다면 실행을 시키지 않기 때문에 버그 발생을 줄일 수 있다.

TypeScript 적용 방식

❗️ *TS는 직접 타입을 줘도 되고 안 줘도 된다.(안 줄 경우에는 변수를 집어넣을 때 그 변수에 담는 value로 type을 추론한다) *❗️

변수명 : 타입 = 타입에 맞는 값 ex) let b : boolean = true;

optional value

• object를 만들 때 해당 변수를 선택적으로 가질 수 있게 하는 것
• 형식 → 변수명 ?: 타입
• 즉, 해당 변수가 있어도 되고 없어도 되게 만드는 것 (다만 있으면 해당 타입만 가능)

type User 이런식으로 별도의 type을 만들어서 객체로 할 수 있다.

//예시코드
type Player = { name:string,age?:number
}
const player1 : Player = {name = "nico"};
const player2 : Player = {name = "Lynn", age:12};

인덱스 시그니처

만약 해당 type에 100개이상의 변수가 있는데 변수명만 다르고 타입이 다 똑같다면 일일이 적는건 비효율적이다. 이럴 때 인덱스 시그니처를 이용하면 변수명을 일일이 설정하지 않아도 된다. 사용방식 예시) [key : string] : string

🚨주의할 사항

• 인덱스 시그니처를 이용하게 되면 객체에 아무것도 안 담아도 허용을 해준다. (규칙을 위반하지만 않으면 다 허용을 해주기 때문)
• 그렇기 때문에 꼭 필요한 변수일 경우에는 따로 변수명을 만들어 타입 지정을 해줘야한다.*
• 인덱스 시그니처에는 따로 지정한 property value의 타입이 다 동일해야 한다. 일치하지 않은 경우에는 에러가 생긴다. 만약에 인덱스 시그니처에 number타입으로 지정을 했는데 따로 변수명을 만들어 string타입을 지정하게 된다면 에러를 일으키게 된다.

Typescript 타입 종류(Enum, any, unknown, never)

기본 타입들은 JS에서도 다룬 적이 있기 때문에 생소한 타입을 위주로 작성해보고자 한다.

Enum type

여러가지 값들에 각각 이름을 부여해 열거해두고 사용하는 타입이다.

//예시코드
 enum Role{ADMIN = 0, USER = 1, GUEST = 2}
//적용예시
const user = {
  name : "nicki",
  role : Role.ADMIN
}

왜 사용할까? 만약 Role에 따라 다른 값을 줘야 하는데 몇 백개의 객체를 만들 시 잘못 입력하여 오류가 발생할 수 있는 가능성이 있기 때문에 이를 방지하기 위해 사용한다.

any, unknown, never type

any, unknown : 특정 변수의 타입을 우리가 확실히 모를때 사용한다. 모든 타입을 허용하기 때문에 최대한 지양해서 사용해야 한다.

unknown(any와의 차이점) : 모든값을 저장할 수 있지만 집어넣기는 불가능하다.

never : 존재하지 않는, 불가능한 타입. 즉, 아무것도 담을 수 없다. never의 경우 Error와 같은 함수에서 예외가 발생할 때나 함수 parameter에 여러 타입을 넣었는데 (ex) hello(name : string | number)) 해당 타입이 없을 때 사용한다. ex) eturn하지 않고 오류를 발생시킬 때 → ex) throw new Error(”xxx”)

📚참고문헌 https://nomadcoders.co/typescript-for-beginners https://www.inflearn.com/course/한입-크기-타입스크립트/dashboard

이번에는 Next.js를 설치하고 tailwind와 emotion의 방식을 섞은 twin.macro라는 새로운 라이브러리를 적용할 것이다.🙇‍♂️ 참고로 Next.js는 설치 설정을 어떻게 하냐에 따라 twin.macro를 적용하는 방식이 약간씩 다르기 때문에 적용방식은 따로 또 적어보도록 하겠다.

Next.js 설치하기

‼️일단 저번 Vite 설치방식에서 말했다시피 될 수 있으면 node 버전은 18이상을 권장한다.‼️ 아래 사진과 같이 npx create-next-app@latest --ts(typescript 적용 안할 땐 --ts는 없애도 좋다.)를 입력하고 설정을 해주면 된다.

설정여부는 ESLint, Tailwind CSS, src/ 디렉토리 여부가 있는데 사진에서는 ESLint를 No로 하였지만 실제에서는 3개 다 Yes를 해주었다. TailwindCSS를 쓰기 싫은 경우에는 No로 지정해주면 된다. ❗️하지만 twin.macro를 쓸 거라면 무조건 Yes를 해서 번거로움을 줄이자❗️ src 디렉토리도 자유지만 웬만하면 하는 걸 추천한다. 나중에 폴더가 많아지면 전체 폴더에서 보여지는 게 더러울 수 있기 때문이다.

App Router (recommended) ? 이게 Yes냐 No냐에 따라 구조가 약간 달라진다. App Router는 설정하면서 많이 낯설었는데 공식문서에 따르면 다음과 같은 특징을 가지고 있다고 한다.

참고문헌 : https://engineering.udacity.com/what-is-next-js-app-router-is-it-ready-for-the-main-stage-bed07ef9519f Next.js는 항상 파일 시스템의 강력함을 활용하여 고유한 라우팅 처리 방식을 가지고 왔습니다. App Router는 이전의 Page Router 구현을 개선하여 다음과 같은 새로운 기능을 포함합니다:

• 여러 페이지에서 공유할 수 있는 레이아웃(Layouts).
• URL에 영향을 주지 않고 라우트를 조직화할 수 있는 Route Groups.
• 의미 있는 로딩 상태를 생성하는 데 도움이 되는 로딩 UI.
• 컨텍스트에 따라 다양한 방식으로 라우트를 로드할 수 있는 Intercepting Routes. 이 외에도 포함된 많은 기능이 더 있으며, 더 자세한 내용은 공식 문서를 확인하는 것을 추천합니다.

이거는 프로젝트 사람들끼리 의논해서 어떻게 할 지 결정하면 될 것이다. 마지막으로, import alias 파트는 Yes를 하길 추천한다. No를 해도 상관은 없지만 ../../파일이름 이런식으로 약간 지저분한거를 간단하게 적용할 수 있다. @/*를 기본으로 설정해두면 무난하게 할 수 있을 것이다.

설치가 완료되면 해당 폴더에 들어간 뒤 npm run dev를 하면 된다.

yarn으로 설치를 할 시에는 yarn create-next-app으로 해주면 되고 yarn dev로 시행을 해주면 된다.

실행했을 때 다음과 같은 메인페이지가 뜨면 성공이다.

Twin.macro

이번에 새롭게 도입할 twin.macro는 Tailwind의 장점과 css-in-js의 유연성을 함께 느낄 수 있다고 공식문서에 나와있다. 무슨 소리인가 하면 tailwind에도 props에 따라 스타일을 다르게 주는 것이 가능하고 styled components처럼 다음과 같이 설정하는 것도 가능하다.

import tw, { styled } from 'twin.macro'

const StyledInput = styled.input(({ hasBorder }) => [
  `color: black;`,
  hasBorder && tw`border-purple-500`,
])
const Input = () => <StyledInput hasBorder />

그러면 이걸 어떻게 초기설정을 하면 되냐 다음과 같이 설정해주면 된다. 참고한 사이트는 나중에 참고문헌으로 남길 것이다.

1. 설치 항목 및 설정

npm i @emotion/react @emotion/styled npm i -S @emotion/serialize npm i -D twin.macro babel-loader @emotion/babel-plugin babel-plugin-macros @babel/plugin-syntax-typescript @babel/preset-react yarn일 경우에는 yarn add로 저 위를 다 설치해주면 된다.😅

2. 최상단에 withTwin.js를 만들어주고 다음과 같이 작성해준다.

/* eslint-disable no-param-reassign */
const path = require('path');

const includedDirs = [path.resolve(__dirname, 'src')];

module.exports = function withTwin(nextConfig) {
  return {
    ...nextConfig,
    webpack(config, options) {
      const { dev, isServer } = options;
      config.module = config.module || {};
      config.module.rules = config.module.rules || [];
      config.module.rules.push({
        test: /\.(tsx|ts)$/,
        include: includedDirs,
        use: [
          options.defaultLoaders.babel,
          {
            loader: 'babel-loader',
            options: {
              sourceMaps: dev,
              presets: [
                [
                  '@babel/preset-react',
                  { runtime: 'automatic', importSource: '@emotion/react' },
                ],
              ],
              plugins: [
                require.resolve('babel-plugin-macros'),
                require.resolve('@emotion/babel-plugin'),
                [
                  require.resolve('@babel/plugin-syntax-typescript'),
                  { isTSX: true },
                ],
              ],
            },
          },
        ],
      });

      if (!isServer) {
        config.resolve.fallback = {
          ...(config.resolve.fallback || {}),
          fs: false,
          module: false,
          path: false,
          os: false,
          crypto: false,
        };
      }

      if (typeof nextConfig.webpack === 'function') {
        return nextConfig.webpack(config, options);
      }
      return config;
    },
  };
};

3. src파일에 types를 만들어주고 twin.d.ts 파일을 다음과 같이 작성한다.

import 'twin.macro';
import { css as cssImport } from '@emotion/react';
import styledImport from '@emotion/styled';
import CSSInterpolation from '@emotion/serialize';

declare module 'twin.macro' {
  const styled: typeof styledImport;
  const css: typeof cssImport;
}

declare module 'react' {
  interface DOMAttributes<T> {
    tw?: string;
    css?: CSSInterpolation;
  }
}

4. tsconfig.json 및 next.config.js설정

//tsconfig.json
 "types": ["types"] // add

//next.config.js
const withTwin = require('./withTwin');

/** @type {import('next').NextConfig} */
const nextConfig = withTwin({
  reactStrictMode: true,
  swcMinify: true,
});

module.exports = nextConfig;

5. 적용시켜보기 (Pages Router version)

1️⃣ pages 폴더 안에 원하는 이름의 폴더를 만들고 index.tsx를 생성한 뒤 만들고 싶은 style을 넣는다.

//예시
import tw, { css, styled } from "twin.macro";

const ChangeButton = styled.button(
  ({ hasTrue }: { hasTrue: boolean }) => [
    tw`w-24 h-20`,
    css`
      border-radius: 20px;
    `,
    hasTrue ? tw`bg-red-400` : tw`bg-blue-400`,
  ]
);

2️⃣ index.tsx에 해당 스타일을 가져다 쓴다.

const Blog = () => {
  const [color, setColor] = useState(false);
  return (
    <div>
      Blog
      <ChangeButton
        hasTrue={color}
        onClick={() => {
          setDark(!color);
        }}
      >
        색깔 좀!!
      </ChangeButton>
    </div>
  );
};

export default Blog;

3️⃣ [http://localhost:3000/폴더이름] 으로 이동한다. 그러면 다음과 같은 그림이 나오게 된다.

6. 적용시켜보기 (App Router version)

방법은 다 똑같은데 다음과 같은 차이점을 가진다.

1️⃣ app 폴더 안에 원하는 이름의 폴더를 만들고 page.tsx를 생성한 뒤 만들고 싶은 style을 넣는다.

2️⃣ page.tsx에 해당 스타일을 가져다 쓴다.** 단, 맨 윗줄에 무조건 "use client";를 추가해줘야 한다!** ⭐️또한 useState가 안된다면 React를 import한뒤 React.useState를 해보자

3️⃣ 그리고 layout.tsx파일에서 해당 부분을 주석처리를 해준다. 여기도 마찬가지로 "use client"를 추가해준다.

//주석 처리 할 부분
// export const metadata = {
//   title: "Create Next App",
//   description: "Generated by create next app",
// };

4️⃣ 이동하는 방식은 똑같다. 아래 사진은 좀 다르기 때문에 다음과 같이 나타나면 성공이다.

🚨만약 실행이 안된다면🚨 npm install -D babel-loader @babel/core @babel/preset-env webpack를 하고 다시 시행해보자! yarn은 yarn add로 저 위를 다시 install해주면 된다! 그리고 next.config.js에 swcMinify: true 부분을 없애면 된다.

이번에는 Next.js를 설치하였고 twin.macro를 설정하고 설치한 방식에 따라 적용하는 방식을 보여주었다. 처음에 했을 때는 오류도 많이 나고 해서 눈물났지만 🥲 막상 되는 모습을 보니깐 뿌듯하다. 😆 다음에는 기초적인 부분을 다룰 예정이다.

📚 twin.macro 참고문헌 https://github.com/MyeonghoonNam/eslint-prettier-setting-practice/tree/main/next-typescript-twinmacro https://github.com/ben-rogerson/twin.macro

이번에는 Next.js를 사용하기 이전에 뻘짓했던(?) 새로운 library인 twin.macro를 적용할 것이기 때문에 이번에는 vite방식으로 설치하는 방식을 다룰 것이고 다음에는 Next.js와 twin.macro를 연결짓는 방식을 소개하도록 하겠다.

1. 기본 설정 준비하기

먼저 next.js에 vite를 적용하기 위해서는 node version이 최신화되어 있어야 한다. 공식문서에서는 버전 14.18+ 또는 16+ 의 Node.js를 요구한다고 되어있지만 다만 일부 템플릿의 경우 더 높은 버전의 Node.js를 요구할 수 있기 때문에 현재 가장 최신인 18+ 버전을 추천한다. https://nodejs.org/en

Mac버전 최신화하는 방법 (brew버전)

1. brew install node@18
2. 현재 사용하고 있는 쉘 환경설정 파일을 수정하기

‼️이 때 이 예시처럼 작성해야 되는데 설치를 하였을 때 터미널 아래에 저렇게 스크립트로 추가하라고 문구를 줄 것이다. 그거를 그대로 가져다 써야 한다‼️

2. 왜 vite로 했는가?

아래의 사이트를 참고하였고, 2022년 기준으로 "신규 개발의 경우 Vite를 채택하는 사례도 늘어나고 있었습니다." 이 문구에서 vite를 한 번 시도를 해보자라는 생각을 가지게 되었다. Next.js vs Vite가 많길래 대체 어떤 친구인가 궁금했었다. 또한 다음 프로젝트를 할 때 어떤 모듈 번들러를 선택할거냐는 질문에 물론 webpack이 여전히 많긴 하지만 vite도 그에 못지 않게 많다는 점에서 직접 시도를 해보고 싶었다. https://engineering.linecorp.com/ko/blog/uit-survey2022-report

Vite 플러그인

https://vitejs-kr.github.io/plugins/ 이 부분을 참고를 하였고 여기서 가장 중요한 부분인 swc에 대해서 설명하고자 한다. Vite플러그인 중에 swc를 사용하긴 하는데 Babel대신 사용한다고 보면 된다. 빌드 중 플러그인을 사용하게 된다면 SWC+esbuild를 사용하고, 그렇지 않다면 esbuild만을 사용한다고 한다. 비표준 React 확장이 필요하지 않은 대규모 프로젝트의 경우, 콜드 스타트와 Hot Module Replacement(HMR)이 훨씬 빠르게 작동할 수 있다고 나와 있다.

3. 설치 방식

아래대로 설치를 하면 된다! 아래는 조금 복잡하게 나와 있지만 Select a framework/variant 이 부분만 본인이 원하는 방식대로 잘 선택해서 하면 된다. 그런 다음에 꼭 그 폴더에 들어가서 npm install을 해줘야 한다! 그러지 않으면 error가 일어나서 프로젝트를 시행할 수가 없다.

구동은 터미널이나 vs code로 해당 폴더에 들어가서 npm run dev를 해주면 된다. 아래 예시 사진는 twin.macro를 도입한 버튼을 추가로 적용시킨 모습이기 때문에 사진과 다를 수 있다.

이번에는 Next.js와는 관련은 없지만 비교대상으로 가끔 나오는 Vite로 한 번 설치를 해보았다. 일단 느낀점은 React구조와 크게 다를바가 없다는 것을 느꼈다. 하지만 이번 프로젝트에서는 Next.js를 사용할 것이기 때문에 어떻게 설치하는지만 보여주고 다음 포스팅에는 Next.js설치와 twin.macro를 연결지어서 보여줄 예정이다.

📚참고문헌(글에 있는 거 제외) 설치 영상사이트 node upgrade mac version

마지막 파트이기도 한 이번 10부에서는 전에 다루지 않았었던 일부 주제를 간단하게 다룰 예정이다. fetch같은 경우는 다른 포스팅에서 다뤘었기 때문에 이번 글에서는 제외될 예정이다. 그러면 마지막으로 시작해보도록 하겠다.🙇‍♂️

File and FileReader

File

File 객체는 Blob을 상속하며 파일 시스템 관련 기능이 추가된 객체이다.

File 객체를 얻는 방법은 두 가지가 있다.

1. new File(fileParts, fileName, [options])

• fileParts는 Blob/BufferSource/String 값들의 배열
• fileName은 파일 이름을 나타내는 문자열
• options는 선택적인 객체로, 다음과 같은 속성을 포함할 수 있다
  • lastModified - 파일의 마지막 수정 시간을 나타내는 정수형 타임스탬프

2. <input type="file">이나 드래그 앤 드롭, 기타 브라우저 인터페이스를 통해 파일을 얻는 것

• File 객체는 Blob을 상속하기 때문에 Blob 객체와 동일한 속성을 가지고 있으며, 추가로 두 개의 속성을 가지고 있다.

  • name : 파일의 이름
  • lastModified : 파일의 마지막 수정 시간을 나타내는 타임스탬프입니다

  예시코드

  <input type="file" onchange="showFile(this)">
  <script>
  function showFile(input) {
  let file = input.files[0];
  
  alert(`File name: ${file.name}`); // e.g my.png
  alert(`Last modified: ${file.lastModified}`); // e.g 1552830408824
  }
  </script>

FileReader

FileReader는 Blob(그리고 따라서 File도) 객체에서 데이터를 읽는 주된 목적을 가진 객체이다.

디스크에서 데이터를 읽는 것은 시간이 걸릴 수 있으므로, FileReader는 이벤트를 사용하여 데이터를 전달한다.

생성자 : let reader = new FileReader();

주요메서드

• readAsArrayBuffer(blob): 이진 형식 ArrayBuffer로 데이터를 읽는다.

• readAsText(blob, [encoding]): 주어진 인코딩 (기본값은 utf-8)으로 텍스트 문자열로 데이터를 읽는다.
• readAsDataURL(blob): 이진 데이터를 읽고 base64 데이터 URL로 인코딩한다.
• abort(): 작업을 취소한다.

읽기 작업이 진행되는 동안의 이벤트

loadstart: 로딩이 시작 progress: 읽는 동안 발생 load: 오류 없이 읽기 완료 abort: abort()가 호출 error: 오류가 발생 loadend: 읽기가 성공 또는 실패로 완료

결과에 접근하기

reader.result: 결과 (성공한 경우) reader.error: 오류 (실패한 경우)

다음과 같이 할 수 있다.

<input type="file" onchange="readFile(this)">

  <script>
function readFile(input) {
  // 입력된 파일 가져오기
  let file = input.files[0];

  // FileReader 객체 생성
  let reader = new FileReader();

  // 파일을 텍스트 형식으로 읽기
  reader.readAsText(file);

  // 파일 읽기가 완료된 후 처리할 동작
  reader.onload = function() {
    console.log(reader.result);
  };

  // 파일 읽기 도중 오류가 발생한 경우 처리할 동작
  reader.onerror = function() {
    console.log(reader.error);
  };
}
</script>

브라우저에 데이터 저장하기

쿠키

웹 서버가 브라우저에게 지시하여 사용자 로컬 컴퓨터에 저장하는 4K 이하의 작은 데이터로, HTTP 프로토콜의 일부이다.

쿠키는 주로 웹 서버에 의해 만들어진다. 서버가 HTTP 응답 헤더(header)의 Set-Cookie에 내용을 넣어 전달하면, 브라우저는 이 내용을 자체적으로 브라우저에 저장하게 된다. 브라우저는 사용자가 쿠키를 생성하도록 한 동일 서버(사이트)에 접속할 때마다 쿠키의 내용을 Cookie 요청 헤더에 넣어서 함께 전달한다.

쿠키 구성

쿠키 쓰기와 읽기

자바스크립트에서 쿠키 접근하는 방식 : document.cookie

• 읽기 document.cookie는 name=value 쌍으로 구성되어있고, 각 쌍은 ;로 구분한다. 이때, 쌍 하나는 하나의 독립된 쿠키를 나타낸다. ;을 기준으로 document.cookie의 값을 분리하면 원하는 쿠키를 찾을 수 있다. 정규 표현식이나 배열 관련 함수를 함께 사용한다.
• 쓰기 document.cookie에 직접 값을 쓸 수 있다. 이때 cookie는 데이터 프로퍼티가 아닌 접근자(accessor) 프로퍼티이다. document.cookie에 값을 할당하면, 브라우저는 이 값을 받아 해당 쿠키를 갱신한다. 이때, 다른 쿠키의 값은 변경되지 않는다.

다만 쿠키는 다음과 같은 한계가 존재한다.

• 쿠키의 크기는 4KB로 제한->충분한 양의 정보 저장 한계
• 쿠키는 불필요한 트래픽 발생 • 브라우저가 웹 서버에 요청을 보낼 때마다 함께 전송하기 때문
• 쿠키는 윈도우마다 독립적인 값을 저장 불가 • 브라우저의 모든 윈도우들이 공유하므로

localStorage와 sessionStorage

웹 스토리지 객체(web storage object)인 localStorage와 sessionStorage는 브라우저 내에 키-값 쌍을 저장할 수 있게 해준다.

웹 스토리지란 ? 사용자 로컬 컴퓨터의 저장 공간으로서, 웹 서버의 저장 부담과 네트워크 트래픽이 감소한다. 웹 스토리지 객체 조작은 모두 자바스크립트 내에서 수행된다.

웹 스토리지 객체 프로퍼티

setItem(key, value) – 키-값 쌍을 보관 getItem(key) – 키에 해당하는 값을 받음 removeItem(key) – 키와 해당 값을 삭제 clear() – 모든 것을 삭제 key(index) – 인덱스(index)에 해당하는 키를 받음 length – 저장된 항목의 개수를 얻기

웹 스토리지 이벤트

setItem, removeItem, clear를 호출할 때 발생

key – 변경된 데이터의 키(.clear()를 호출했다면 null) oldValue – 이전 값(키가 새롭게 추가되었다면 null) newValue – 새로운 값(키가 삭제되었다면 null) url – 갱신이 일어난 문서의 url storageArea – 갱신이 일어난 localStorage나 sessionStorage 객체

JavaScript animations

CSS로 처리하기 어려운 애니메이션 또는 더 세밀한 제어가 필요한 경우, JavaScript를 사용할 수 있다. JavaScript 애니메이션은 requestAnimationFrame을 통해 구현된다. 이 내장 메서드는 브라우저가 다시 그리기를 준비할 때 콜백 함수를 실행할 수 있도록 설정한다. 보통 그 시간은 매우 빠르지만, 정확한 시간은 브라우저에 따라 다르다.

CSS와 다른 특징이라고 하면 JavaScript 애니메이션은 어떤 타이밍 함수를 사용할 수 있다. 다양한 예제와 변형을 다루어 더 다양한 기능을 구현할 수 있다. CSS와 달리 여기서는 베지어 곡선에 제한받지 않는다.(draw에 대해서도 마찬가지)

Animation 구현 예시 코드는 다음과 같다.

let start = Date.now(); // 시작 시간을 기억

let timer = setInterval(function() {
  // 시작으로부터 경과한 시간 계산
  let timePassed = Date.now() - start;

  if (timePassed >= 2000) {
    clearInterval(timer); // 2초 후에 애니메이션을 종료
    return;
  }

  // timePassed에 해당하는 순간에 애니메이션을 그리기
  draw(timePassed);

}, 20);

/* timePassed가 0에서 2000까지 변함에 따라
left는 0px에서 400px까지의 값을 가진다.*/
function draw(timePassed) {
  train.style.left = timePassed / 5 + 'px';
}

다음은 requestAnimationFrame을 통한 애니메이션 설정 관련 함수 예시코드이다.

function animate({timing, draw, duration}) {

  let start = performance.now();

  requestAnimationFrame(function animate(time) {
    // timeFraction은 0에서 1까지 진행
    let timeFraction = (time - start) / duration;
    if (timeFraction > 1) timeFraction = 1;

    // 현재 애니메이션 상태 계산
    let progress = timing(timeFraction);

    draw(progress); // 그리기

    if (timeFraction < 1) {
      requestAnimationFrame(animate);
    }

  });
}

duration: 애니메이션의 총 시간 (밀리초 단위) timing: 애니메이션 진행을 계산하는 함수. 0에서 1까지의 시간 분수를 받고, 애니메이션 진행 상태를 반환(일반적으로 0에서 1 사이의 값) draw: 애니메이션을 그리는 함수.

처음에 가볍게 시작했던 JS튜토리얼이 이제서야 끝났다. 작성하면서 이해가 안 된 부분도 있었고 간과하던 부분들도 있었다. 튜토리얼이라고 썼기 때문에 해당 참고자료들에서 심화된 느낌의 부분들은 작성하지 않았다. 이번 JS 튜토리얼을 끝냈기 때문에 다음은 무엇을 다룰까 생각을 하다가 Next.js를 나름대로 짧게나마 다뤄보려고 한다. 아마 JS에 비해서는 부족할 수도 있겠지만 최대한 자세하게 작성을 하려고 한다. 그럼 다음 튜토리얼 시리즈는 Next.js로 만나도록 하겠다.🏃🏻

폼(form) 조작에 사용되는 요소에는 특별한 프로퍼티와 이벤트가 많기 때문에 따로 분리하여 작성하기로 하였다. 그럼 두말하지 않고 바로 시작해보도록 하겠다 👨‍💻

폼(form)

특수한 컬렉션인 document.forms의 구성원 폼의 이름이나 순서를 사용해 문서 내의 폼에 접근할 수 있다.

document.forms.my - 이름이 'my'인 폼 document.forms[0] - 문서 내의 첫 번째 폼

폼의 요소를 가져오는 방법 : form.elements 다만 먼저 이름이나 순서를 사용해 원하는 폼을 가져와야 한다.

폼(form) 요소

input과 textarea

input과 textarea 요소의 값은 input.value (string) 또는 input.checked(boolean)을 사용해 얻을 수 있다.

select과 option

select의 프로퍼티 select.options – <option> 하위 요소를 담고 있는 컬렉션 select.value – 현재 선택된 <option> 값 select.selectedIndex – 현재 선택된 <option>의 번호(인덱스)

select의 multiple 속성이 있는 경우 <option> 하위 요소에 있는 selected 프로퍼티를 추가·제거를 해준 뒤, 선택된 여러 개의 option이 담긴 컬렉션은 다음 예시처럼 select.options를 사용해 얻을 수 있다.

활용 예시 코드

<select id="select">
  <option value="apple">Apple</option>
  <option value="pear">Pear</option>
  <option value="banana">Banana</option>
</select>

<script>
  // 세 가지 코드의 실행 결과는 모두 똑같다.
  select.options[2].selected = true;
  select.selectedIndex = 2;
  select.value = 'banana';
</script>

focus와 blur

focus 이벤트는 요소가 포커스를 받을 때, blur 이벤트는 포커스를 잃을 때 발생한다. elem.focus()와 elem.blur() 메서드를 사용하면 요소에 포커스를 줄 수도 있고 제거할 수도 있다.

⚠️유의해야 할 점⚠️

• onblur는 요소가 포커스를 잃고 난 후에 발생하기 때문에 onblur 안에서 event.preventDefault()를 호출해 포커스를 잃게 하는걸 '막을 수 없다’라는 사실
• focus와 blur 이벤트는 버블링 되지 않는다. 캡처링이나 focusin, focusout을 사용하면 이벤트 위임 효과를 볼 수 있다.

이벤트(submit 제외)

저번에는 어느 것이 있었는지 간략하게 보여줬다면 이번에는 form에서 자주 쓰이는 이벤트인 change, input, cut, copy, paste을 다뤄보도록 하겠다. submit은 따로 소제목으로 다루도록 하겠다.

change

change 이벤트는 요소 변경이 끝나면 발생한다.

• 텍스트 입력 요소인 경우에는 요소 변경이 끝날 때가 아니라 포커스를 잃을 때 이벤트가 발생하게 된다.
• input 이벤트는 사용자가 값을 수정할 때마다 발생한다.

cut, copy, paste

cut, copy, paste 이벤트는 ClipboardEvent 클래스의 하위 클래스이며 각각 값을 잘라내기·복사하기·붙여넣기 할 때 발생한다. input 이벤트와는 달리 세 이벤트는 event.preventDefault()를 사용해 기본 동작을 막을 수 있다. 이렇게 하면 아무것도 복사·붙여넣기 할 수 없다.

/* 잘라내기·복사하기·붙여넣기 동작을 시도하면
모든 동작들이 중단되고 얼럿창을 통해 중단된 이벤트 이름을 보여준다*/
<input type="text" id="input">
<script>
  input.oncut = input.oncopy = input.onpaste = function(event) {
    alert(event.type + ' - ' + event.clipboardData.getData('text/plain'));
    return false;
  };
</script>

이벤트(submit)

submit 이벤트는 폼을 제출할 때 발동 되는데, 주로 폼을 서버로 전송하기 전에 내용을 검증하거나 폼 전송을 취소할 때 사용한다. 한편, form.submit() 메서드는 자바스크립트만으로 폼 전송을 하고자 할 때 사용합니다. submit()메서드는 동적으로 폼을 생성하고 서버에 보내고자 할 때 사용한다.

폼을 전송하는 방법

1. <input type="submit">이나 <input type="image"> 클릭하기
2. input 필드에서 Enter 키 누르기
3. submitForm.addEventListener("submit", 이벤트 핸들러 함수)

form.submit()을 호출하면 자바스크립트로 직접 폼을 서버에 전송할 수 있다. form.submit() 메서드가 호출된 다음엔 submit 이벤트는 생성되지 않는다. 개발자가 form.submit()을 호출했다면 스크립트에서 이미 필요한 모든 조치를 했다고 가정하기 때문이다.

let form = document.createElement('form');
form.action = 'https://google.com/search';
form.method = 'GET';

form.innerHTML = '<input name="q" value="테스트">';

// 폼을 제출하려면 반드시 폼이 문서 안에 있어야 한다.
document.body.append(form);

form.submit();

이번에는 이벤트에서 다뤄보도록 하겠다. 이벤트의 종류가 너무 많기 때문에 자주 사용하는 이벤트위주로 적을 예정이다. 또한 폼 관련 이벤트는 다음 9부에서 다룰 예정이다. 혹시나 다른 이벤트들도 알고 싶다면 1부에서 알려줬던 참고문헌에 들어가 찾으면 될 것이다. 👨‍💻

이벤트

마우스클릭,키보드입력,이미지나HTML문서의로딩,타이머의타임 아웃 등 사용자의 입력 행위나 문서나 브라우저의 상태 변화를 자바스 크립트 코드에게 알리는 통지(notification)

이벤트 리스너

발생한 이벤트에 대처하기 위해 작성된 자바스크립트 코드

이벤트 핸들러

이벤트가 발생했을 때, 호출될 자바스크립트 코드 함수

이벤트 핸들러 할당하는 방법

1. HTML 속성 : HTML 안의 on<event> 속성에 핸들러를 할당하는 방법 ex) <input value="클릭해 주세요." onclick="alert('클릭!')" type="button">
2. DOM 프로퍼티 on<event>을 사용하여 핸들러를 할당 ex ) elem.onclick = function() { alert('감사합니다.');};
3. addEventListener 기본문법형식 : element.addEventListener(event, handler, [options]); event : 이벤트 이름(예: "click") handler : 핸들러 함수 options : 아래 프로퍼티를 갖는 객체

addEventListner예시코드

document.addEventListener("keydown", function (e) { //keydown이벤트를 수행했을 때 
  if (e.code === "Enter") { //Enter를 눌렀을 시
    e.preventDefault(); //기본으로 정의된 이벤트를 작동하지 못하게 한다.
  }
});

⭐️이벤트 객체 : function(e)의 e에 해당하는 부분으로써 이벤트가 발생하면 브라우저는 이벤트 객체(event object)라는 것을 만든다. 여기에 이벤트에 관한 상세한 정보를 넣은 다음, 핸들러에 인수 형태로 전달한다.

blur : 포커스를 잃었을 때 발생

버블링 & 캡처링

버블링

한 요소에 이벤트가 발생하면, 이 요소에 할당된 핸들러가 동작하고, 이어서 부모 요소의 핸들러가 동작하게 된다. 즉, 가장 최상단의 조상 요소를 만날 때까지 이 과정이 계속되며, 요소 각각에 할당된 핸들러가 동작하게 된다.

그림으로 나타내면 다음과 같이 나타낼 수 있다. 3번을 수행할 시, 3 -> 2 -> 1 순서로 각 요소에 할당된 이벤트 핸들러가 동작하게 되는 것이다.

중단하는 방법은 event.stopPropagation()를 사용하면 된다. 다만 꼭 필요한 경우 아니면 이 방법은 추천하지 않는다.

event.target

이벤트가 발생한 가장 안쪽의 요소는 타깃(target) 요소라고 불리고, event.target을 사용해 접근할 수 있다.

❗️event.target vs this(=event.currentTarget)❗️ event.target은 실제 이벤트가 시작된 ‘타깃’ 요소 this는 ‘현재’ 요소로, 현재 실행 중인 핸들러가 할당된 요소를 참조

아래 코드를 보면 핸들러는 form.onclick 하나밖에 없지만 이 핸들러에서 폼 안의 모든 요소에서 발생하는 클릭 이벤트를 ‘잡아내고(catch)’ 있다. 클릭 이벤트가 어디서 발생했든 상관없이 <form> 요소까지 이벤트가 버블링 되어 핸들러를 실행시키기 때문이다. form.onclick 핸들러 내의 this와 event.target은 다음과 같다. this(event.currentTarget) –<form>요소에 있는 핸들러가 동작했기 때문에 <form>요소를 가리킵니다. event.target – 폼 안쪽에 실제 클릭한 요소를 가리킨다.

<!DOCTYPE HTML>
<html>

<head>
  <meta charset="utf-8">
  <link rel="stylesheet" href="example.css">
</head>

<body>
  클릭하면 <code>event.target</code>과 <code>this</code>정보를 볼 수 있습니다.

  <form id="form">FORM
    <div>DIV
      <p>P</p>
    </div>
  </form>

  <script src="script.js"></script>
</body>
</html>

//script.js
form.onclick = function(event) {
  event.target.style.backgroundColor = 'yellow';

  setTimeout(() => {
    alert("target = " + event.target.tagName + ", this=" + this.tagName);
    event.target.style.backgroundColor = ''
  }, 0);
};

캡처링

캡처링의 경우는 자세히 다루지 않겠다. 동작 방식이 버블링의 반대 형식으로 진행되기 때문이다. 버블링 그림을 다시 가져와서 3번을 수행하게 될 때 캡처링의 방식은 1 -> 2 -> 3번 순으로 동작하게 되는 것이다.

커스텀 이벤트 디스패치

이벤트 생성자

내장 이벤트 클래스는 DOM 요소 클래스같이 계층 구조를 형성한다. 그 중 가장 최상단에 있는 Event 클래스의 객체를 생성하는 방법은 다음과 같다. let event = new Event(type[, options]);

type : 이벤트 타입을 나타내는 문자열로 "click"같은 내장 이벤트, "my-event" 같은 커스텀 이벤트가 올 수도 있다.

options – 두 개의 선택 프로퍼티가 있는 객체가 온다.

• bubbles: true/false – true인 경우 이벤트가 버블링 된다. 기본값은 false로 되어 있다.
• cancelable: true/false – true인 경우 브라우저 '기본 동작’이 실행되지 않는다. 기본값은 false로 되어 있다.

만약 이벤트를 직접 만드는 경우라면 CustomEvent 생성자를 써야 한다. CustomEvent 생성자엔 detail이라는 추가 프로퍼티를 명시할 수 있는데, 여기에 이벤트 관련 정보를 저장해야 한다. 이렇게 하면 모든 핸들러에서 event.detail을 통해 커스텀 이벤트의 정보를 알 수 있다. 예시는 아래코드에 명시되어 있을 것이다.

dispatchEvent

elem.dispatchEvent(event)를 호출해 요소에 있는 이벤트를 반드시 실행시켜줘야 한다.

예시코드

<h1 id="elem">Hello from the script!</h1>

<script>
  // 버블링이 일어나면서 document에서 이벤트가 처리됨
  document.addEventListener("hello", function(event) { // (1)
    alert("Hello from " + event.target.tagName); // Hello from H1
  });

  // 이벤트(hello)를 만들고 elem에서 이벤트 디스패치
  let event = new Event("hello", {bubbles: true}); // (2)
  elem.dispatchEvent(event);

  // document에 할당된 핸들러가 동작하고 메시지가 얼럿창에 출력됨

</script>

//또 다른 예시
<h1 id="elem">이보라님, 환영합니다!</h1>

<script>
  // 추가 정보는 이벤트와 함께 핸들러에 전달됨
  elem.addEventListener("hello", function(event) {
    alert(event.detail.name);
  });

  elem.dispatchEvent(new CustomEvent("hello", {
    detail: { name: "보라" }
  }));
</script>

웹 페이지 내의 모든 콘텐츠를 객체(document)로 나타내주는데, 이 객체(document)는 수정이 가능하다. 즉, DOM 구조에 접근한다는 것은 문서와 문서 요소에 접근한다는 것과 같은 원리이다. DOM과 브라우저를 렌더링할 때 다음과 같은 과정을 거친다.

DOM 트리

DOM에 따르면, 모든 HTML 태그는 객체이다. 이런 모든 객체는 JS를 통해 접근할 수 있고, 페이지를 조작할 때 이 객체를 사용한다. 예를 들어 document.body는 <body>태그를 객체로 나타낸 것이다. DOM은 HTML을 아래와 같은 태그 트리 구조로 표현한다. 사진에서는 포함되지 않았지만 문자는 텍스트 노드가 된다. 개발자 도구를 사용하면 DOM을 검사해보고, 수정할 수 있는데 가장 많이 쓰이는 방법은 Chrome 개발자 도구 문서 사이트이다.https://developers.google.com/web/tools/chrome-devtools 로 가면 다양한 기능을 살펴볼 수 있다.

getElement, querySelector

document.getElementById 혹은 id를 사용하여 요소 검색하기

요소에 id 속성이 있다면 위치에 상관없이 메서드 document.getElementById(id)를 이용해 접근할 수 있다. 혹은 id 속성값을 그대로 딴 전역 변수를 이용해 접근할 수도 있지만 이 방법은 예시로 보여주긴 하겠지만 추천하지 않는다. 전역 변수를 사용하는 것을 지양하기 때문이다. 예시

<!doctype html>
<body>
<!-- getElementById로 요소얻기 -->
<p id="firstP">안녕하세요</p>
<!-- id를 그대로 딴 전역 변수 이용하여 요소얻기 -->
<p id="secondP">반가워요</p>

<script>
  // 요소 얻기
  let p = document.getElementById('firstP');

  // 배경색 변경하기
  p.style.background = 'red';
  secondP.style.background = 'yellow';
</script>
</body>

결과화면

🚨유의점 id는 유일무이해야 한다. 즉, 문서 내 요소의 id 속성값은 중복되어선 안 된다. 같은 id를 가진 요소가 여러 개 있으면 document.getElementById같이 id를 이용해 요소를 검색하는 메서드의 동작이 제대로 되지 않기 때문이다.

getElementsBy*

태그나 클래스 등을 이용해 원하는 노드를 찾아주는 메서드도 있다.

elem.getElementsByTagName(tag) – 주어진 태그에 해당하는 요소를 찾고, 대응하는 요소를 담은 컬렉션을 반환한다. 매개변수 tag에 "*"이 들어가면, '모든 태그’가 검색된다. elem.getElementsByClassName(className) – class 속성값을 기준으로 요소를 찾고, 대응하는 요소를 담은 컬렉션을 반환한다.

이 방법은 2가지 특징을 가지고 있다.

1. 요소 하나가 아닌, 컬렉션을 반환한다. 만약에 문서에 여러 input요소가 있다면 컬렉션을 순회하거나 인덱스를 사용해 요소를 얻고 그 요소에 값을 할당해야 한다.

   // (문서에 input 요소가 있다면) 아래 코드는 잘 동작하게 된다.
   document.getElementsByTagName('input')[0].value = 5;

2. 문서에 변경이 있을 때마다 컬렉션이 '자동 갱신’되어 최신 상태를 유지한다. 뒤에 설명할 querySelector는 자동으로 갱신되지 않고 '정적'인 상태로 유지한다.

querySelectorAll

이 메서드는 elem의 자식 요소 중 주어진 선택자에 대응하는 요소 모두를 반환한다. 아래 예시는 마지막 li 요소를 모두 alert해주고 있다.

<!doctype html>
<body>
<ul>
  <li>1-1</li>
  <li>1-2</li>
</ul>
<ul>
  <li>2-1</li>
  <li>2-2</li>
</ul>
<script>
  let elements = document.querySelectorAll('ul > li:last-child');

  for (let elem of elements) {
    alert(elem.innerHTML); // "1-2", "2-2"
  }
</script>
</body>

querySelector

이 메서드는 elem의 자식 요소 중 주어진 선택자에 대응하는 '첫번째'요소만 반환한다. 위의 예시를 활용하면 1-2만 반환하는 모습을 볼 수 있다.

<!doctype html>
<body>
<ul>
  <li>1-1</li>
  <li>1-2</li>
</ul>
<ul>
  <li>2-1</li>
  <li>2-2</li>
</ul>
<script>
  let elements = document.querySelector('ul > li:last-child');

  alert(elements.innerHTML); // "1-2"
</script>
</body>

matches : 요소 elem이 주어진 선택자와 일치하는지 여부를 판단해준다. 일치한다면 true, 아니라면 false를 반환한다. closest : elem 자기 자신을 포함하여 선택자와 일치하는 가장 가까운 조상 요소를 찾을 수 있게 한다.

DOM 노드

DOM 노드 중 일부만 설명할 것이다.

innerHTML 요소 안의 HTML을 알아낼 수 있다. 이 프로퍼티를 사용하면 요소 안의 HTML을 수정할 수도 있다. hidden true로 설정하면 CSS에서 display:none을 설정한 것과 동일하게 동작한다. tagName/nodeName tagName 프로퍼티는 요소 노드에만 존재한다. nodeName은 모든 Node에 있다. 요소 노드를 대상으로 호출하면 tagName과 같은 역할을 한다. 텍스트 노드, 주석 노드 등에선 노드 타입을 나타내는 문자열을 반환한다.

속성 vs 프로퍼티

속성은 HTML 안에 쓰인다면 프로퍼티는 DOM 객체 안에 쓰인다.

속성과 함께 쓰이는 메서드는 다음과 같이 있다.

• elem.hasAttribute(name) – 속성 존재 여부 확인

• elem.getAttribute(name) – 속성값을 가져옴
• elem.setAttribute(name, value) – 속성값을 변경함
• elem.removeAttribute(name) – 속성값을 지움
• elem.attributes – 속성의 컬렉션을 반환함

DOM 조작하기

요소 생성

1️⃣ document.createElement(tag) : 태그 이름(tag)을 사용해 새로운 요소 노드를 만든다.

const link = document.createElement("div");

2️⃣ document.createTextNode(text) : 주어진 텍스트(text)를 사용해 새로운 텍스트 노드를 만든다.

let textNode = document.createTextNode('안녕하세요.');

요소 삽입

JS에서 지원하는 요소 삽입 메서드는 다음과 같이 있다.

• node.append(노드나 문자열) – 노드나 문자열을 node 끝에 삽입합니다.

• node.prepend(노드나 문자열) – 노드나 문자열을 node 맨 앞에 삽입합니다.
• node.before(노드나 문자열) –- 노드나 문자열을 node 이전에 삽입합니다.
• node.after(노드나 문자열) –- 노드나 문자열을 node 다음에 삽입합니다.
• node.replaceWith(노드나 문자열) –- node를 새로운 노드나 문자열로 대체합니다. 예시는 append와 prepend를 이용한 방법이다.

  <!doctype html>
  <body>
  <ol id="ol">
  <li>0</li>
  <li>1</li>
  <li>2</li>
  </ol>
  <script>
  ol.before('before'); // <ol> 앞에 문자열 'before'를 삽입함
  ol.after('after'); // <ol> 뒤에 문자열 'after를 삽입함
  let liFirst = document.createElement('li');
  liFirst.innerHTML = 'prepend';
  ol.prepend(liFirst); // <ol>의 첫 항목으로 liFirst를 삽입함
  let liLast = document.createElement('li');
  liLast.innerHTML = 'append';
  ol.append(liLast); // <ol>의 마지막 항목으로 liLast를 삽입함
  </script>
  </body>

insertAdjacentHTML

elem.insertAdjacentHTML(where, html)에서 첫 번째 매개변수는 elem을 기준으로 하는 상대 위치로, 다음 값 중 하나여야 한다.

'beforebegin' – elem 바로 앞에 html을 삽입 'afterbegin' – elem의 첫 번째 자식 요소 바로 앞에 html을 삽입 'beforeend' – elem의 마지막 자식 요소 바로 다음에 html을 삽입 'afterend' – elem 바로 다음에 html을 삽입

<!doctype html>
<body>
<div id="div"></div>
<script>
  // <div id="div"></div> 앞에 삽입
  div.insertAdjacentHTML('beforebegin', '<p>안녕하세요.</p>');
  //<div id="div"></div> 뒤에 삽입
  div.insertAdjacentHTML('afterend', '<p>안녕히 가세요.</p>');
</script>
</body>

요소 삭제

node.remove() 사용하면 노드를 삭제할 수 있다.

요소 좌표 얻기

elem.getBoundingClientRect() 메서드는 elem을 감싸는 가장 작은 네모의 창 기준 좌표를 DOMRect 클래스의 객체 형태로 반환한다. elem.getBoundingClientRect()의 각 프로퍼티를 그림으로 표현하면 다음과 같이 나타난다.

Error Handling

아무리 코드를 잘 짠다고 해도 에러를 발생시킬 수 있다. 원인은 실수, 입력 오류, 잘못된 서버 응답 등 다양하기 때문에 에러가 발생하면 스크립트는 ‘죽고’(즉시 중단되고), 콘솔에 에러가 출력된다. 이 때 Error Handling을 이용하여 스크립트가 죽는 걸 방지하고, 에러를 ‘잡아서(catch)’ 더 합당한 무언가를 할 수 있게 한다.

try...catch

//기본 문법
try {

  // 코드...
  // 1. 먼저 try에 해당하는 코드가 실행된다
  // 2. 에러가 없다면, try 안의 마지막 줄까지 실행되고, catch 블록은 스킵한다.

} catch (err) {

  // 에러 핸들링
  // 3. 에러가 있다면, try문의 코드는 중단되고 catch(err) 블록으로 제어 흐름이 넘어간다. 
  //변수 err에는 무슨 일이 일어났는지에 대한 설명이 담긴 에러 객체를 포함한다.

}

throw 연산자

에러를 직접 만들 수 있다. 이론상으론, throw 인수에 모든 것을 넘길 수 있지만, 대개 내장 Error 클래스를 상속받은 에러 객체를 인수에 넘긴다.

//JSON.parse의 에러 종류
try {
  JSON.parse("{ 잘못된 형식의 json o_O }");
} catch(e) {
  alert(e.name); // SyntaxError
  alert(e.message); // JSON Parse error: Unrecognized token '잘'
}

//JSON 에러 throw로 처리하는 예시
let json = '{ "age": 30 }'; // name이 없는 불완전한 데이터

try {

  let user = JSON.parse(json); // <-- 에러 없음

  if (!user.name) {
    //JSON Parse의 error 종류는 SyntaxError였기 때문
    throw new SyntaxError("불완전한 데이터: 이름 없음");
  }

  alert( user.name );

} catch(e) {
  alert( "JSON Error: " + e.message ); // JSON Error: 불완전한 데이터: 이름 없음
}

⭐️try..catch는 오직 런타임 에러에만 동작한다 ⭐️try..catch는 동기적으로 동작한다. ⭐️ 에러 객체가 필요 없으면 catch(err) { 대신 catch {를 쓸 수 있다. ⭐️try..catch는 finally를 이용하여 확장할 수 있다

try {
   ... 코드를 실행 ...
} catch(e) {
   ... 에러 핸들링 ...
} finally {
   ... 항상 실행 ...
}
   // ‼️try..catch..finally 안의 변수는 지역 변수‼️
   // ‼️finally 절은 try..catch 절을 빠져나가는 어떤 경우에도 실행‼️
   /* finally 안의 코드가 실행되고 난 후,
   try값이 바깥 코드가 반환됨
   (return이 try블록 안에 있는 경우)*/

에러 다시 던지기

1️⃣ catch가 모든 에러를 받는다. 2️⃣ catch(err) {...} 블록 안에서 에러 객체 err를 분석한다. 이 때 에러 타입을 instanceof 명령어로 체크한다. 3️⃣ 에러 처리 방법을 알지 못하면 throw err를 해서 에러를 다시 던진다.

//에러를 다시 던져 예상치 못한 에러를 처리하기
function readData() {
let json = '{ "age": 30 }'; // 불완전한 데이터
try {

  let user = JSON.parse(json);


//   if (!user.name) {
//     throw new SyntaxError("불완전한 데이터: 이름 없음");
//   }

  blabla(); // 예상치 못한 에러

  alert( user.name );

} catch(e) {

  if (e instanceof SyntaxError) {
    alert( "JSON Error: " + e.message );
  } else {
    throw e; // 에러 다시 던지기 (*)
  }

}
}

try {
  readData();
} catch (e) {
  alert( "External catch got: " + e ); // 에러를 잡음
}

Promise와 async,await

동기와 비동기

비동기는 응답과 요청이 동시에 일어나지 않는 걸 의미한다(즉, 요청을 한번에 받고 응답에 대한 결과를 주기 때문에 한번에 여러 작업을 할 수 있다) 동기는 그 반대의 의미를 지닌다. 그림으로 보면 다음과 같이 나타낼 수 있다. 그림 참고자료 : https://liarchild.tistory.com/35

Promise

비동기 작업이 맞이할 미래의 완료 또는 실패와 그 결과 값을 나타낸다. Promise의 상태는 3가지로 분류할 수 있는데 사실상 이행과 거부라고 나타날 수 있다. ➡️ 그 이유는 대기 상태를 지나야 이행 혹은 거부 두 상태 중 하나를 반환하게 되기 때문!

1️⃣ 대기(pending) : 비동기 작업 진행중인 상태, 초기 상태 2️⃣ 이행(fulfilled) : 연산이 성공적으로 완료됨 3️⃣ 거부(rejected) : 연산이 실패함

Promise의 결과에 따라 .then 또는 .catch로 수행할 수 있다.

.then : resolve일 때 수행되며, 다음과 같이 두 함수를 활용할 때는 꼭 return을 해야한다. 그 이유는 return이 .then에 해당하는 Promise를 담당하기 때문이다. .catch : reject일 때 어떤 곳에 error가 나도 한꺼번에 처리가 가능하다.

//.then .catch 사용 예시 
.then(postId => {
   console.log('Post:', postId)
   return getComments(postId)
//생략
.catch(message => console.log(message));

async, await

왜 사용할까?

1. 어떤 코드가 먼저 실행되었는지 순서를 알기 어려워진다. → 에러 원인 불명확 → 디버깅 어려움 → 코드 예측성 떨어짐
2. 코드 중첩 → 가독성 떨어짐

사용할 시 이점

function 앞에 async 키워드를 추가 할 때 이점 1️⃣ 함수는 언제나 Promise를 반환한다. 2️⃣ 함수 안에서 await를 사용할 수 있다. Promise 앞에 await 키워드를 붙이면 자바스크립트는 Promise 가 처리될 때까지 대기하게 된다. 처리가 완료되면 조건에 따라 아래와 같은 동작이 이어지게 된다. 1️⃣ 에러 발생 – 예외가 생성됨(에러가 발생한 장소에서 throw error를 호출한 것과 동일함) 2️⃣ 에러 미발생 – Promise 객체의 result 값을 반환

사용 예시 코드

async function f() {

  let promise = new Promise((resolve, reject) => {
    setTimeout(() => resolve("완료!"), 1000)
  });

  let result = await promise; // Promise가 이행될 때까지 기다림 (*)

  alert(result); // "완료!"
}

f();