이안의 평일코딩

리액트 19: 새로운 프론트엔드 시대를 여는 기능 정리

이안92 — Thu, 15 May 2025 08:24:36 +0900

React v19

React 19는 단순한 기능 추가를 넘어, React 개발 방식에 큰 변화를 가져올 여러 실험적 기능들을 공식화했습니다.

서버 중심의 렌더링 철학, 자동화된 성능 최적화, 간결한 API 설계로 한 단계 도약한 모습을 보여줍니다.

개인적으로 저는 커스텀 훅을 사내에서 자주 만들어 사용하는 편이라 익숙하게 Migration 가능할 것 같은데요.

이번 포스트에서는 그중 가장 주목할 만한 기능들을 정리해보겠습니다.

React Compiler

React 컴파일러는 자동으로 useMemo, useCallback 최적화를 수행해주는 새로운 도구입니다.
더 이상 불필요한 메모이제이션에 신경 쓰지 않아도 되는 시대가 왔습니다.

function ProductPage({ productId }) {
  const product = useProduct(productId); // 내부적으로 캐시 최적화됨
  return <Product {...product} />;
}

use() Hooks

use()는 비동기 데이터를 컴포넌트 안에서 직접 await할 수 있도록 도와주는 새로운 hook입니다.

Server Component에서만 사용 가능합니다.

function ProductPage() {
  const product = use(fetchProduct());
  return <Product {...product} />;
}

⚡ Actions

React의 새로운 폼 액션 핸들링 방식입니다. 서버 함수와 클라이언트가 자연스럽게 연결됩니다.

'use server';

export async function createTodo(data) {
  await db.insert(data);
}

<form action={createTodo}>
  <input name="task" />
  <button type="submit">Create</button>
</form>

use client & use server

React 19에서는 컴포넌트 파일 최상단에 'use client' 또는 'use server'를 선언하여 렌더링 위치를 명시할 수 있습니다.

이를 통해 서버 컴포넌트와 클라이언트 컴포넌트 간 역할을 명확히 구분할 수 있습니다.

useFormStatus & useActionState

React의 새로운 form 관련 Hook들입니다.

useFormStatus → submit 중인지 여부를 알려줍니다.
useActionState → 서버 액션의 상태를 관리합니다.

const [state, formAction] = useActionState(createTodo, initialState);

<form action={formAction}>
  <SubmitButton />
</form>

useOptimistic

낙관적 UI 업데이트를 위한 Hook입니다. 사용자 인터랙션에 대해 빠른 피드백을 줄 수 있습니다.

const [todos, addTodo] = useOptimistic([], (state, newTodo) => [...state, newTodo]);

Document Metadata

React에서 title, meta, viewport 등을 구성하는 새로운 API가 도입됩니다.

import { Metadata } from 'next';

export const metadata: Metadata = {
  title: 'My Page',
  description: 'Awesome page',
};

⛓️ ForwardRef

React 19에서는 forwardRef 없이도 자동 ref 전달이 가능해질 예정입니다.
보다 간단한 컴포넌트 작성이 가능해집니다.

function Button(props, ref) {
  return <button ref={ref} {...props} />;
}

React.Lazy

React.lazy()는 여전히 존재하지만, React 19에서는 Server Component 기반으로 더 나은 lazy-loading 전략이 가능해졌습니다.
대부분의 경우 서버 렌더링이 더 나은 UX를 제공합니다.

<Context.Provider> => <Context>

Context API도 더욱 간단하게 사용할 수 있게 되었습니다.

// 기존
<MyContext.Provider value={value}>
  <App />
</MyContext.Provider>

// React 19
<Context value={value}>
  <App />
</Context>

리액트 18: 무엇이 달라졌나? 요약 및 간략 후기

이안92 — Mon, 28 Apr 2025 22:44:19 +0900

React v18 후기

2022년 3월 출시된 리액트 18의 기존 버전과의 가장 큰 차이점은 바로 동시성(Councurrency) 지원이다.

동시에 여러 작업을 효율적으로 처리하여 앱의 응답성을 개선한 점이 눈여겨볼만 하다.

코드를 크게 바꾸지 않고도 성능 개선을 느낄 수 있고 필요하면 점진적으로 적용할 수 있어 업데이트 부담도 적었다.

Automatic Batching

Batching은 업데이트 대상이 되는 상태값들을 하나의 그룹으로 묶어 한번의 리렌더링에 업데이트가 모두 진행될 수 있게 해주는 것이다.

한 함수 안에서 setState를 아무리 많이 호출시키더라도 리렌더링은 단 한번만 발생하고 여러번 리렌더링 하는것을 막아 성능이 향상된다.

// React 17에서는 각각 렌더링 됨
setTimeout(() => {
  setCount(count => count + 1);
  setFlag(flag => !flag);
}, 1000);

// React 18에서는 한 번에 렌더링됨

batch 처리하기 싫은 경우의 경우에는 ReactDOM.flushSync()를 사용하여 동기적으로 즉시 렌더링시킬 수 있다.

예를 들어, UI가 지금 당장 반영돼야 하는 중요 이벤트 처리나 애니메이션 프레임 맞출 때 등등 사용할 수 있다.

useTransition, startTransition

중요하지 않은 업데이트(예: 검색어 입력 시 필터링)를 부드럽게 처리할 수 있다.

특정 업데이트를 Transition으로 표시하여 사용자 상호 작용을 크게 개선했다.

상태 전환 중에 시각적 피드백을 제공하고 전환이 발생하는 동안 브라우저의 응답성을 유지하고,

어떠한 업데이트가 우선순위가 높은지 알려줄 수 있다.

예를 들어, 검색창과 결과창 두 부분으로 나눠 유저가 타이핑하는 것에 따라 즉각 반영되기를 기대하는 검색창과

검색창보다는 UI 업데이트가 느린 것에 자연스럽게 받아들여질 수 있는 결과창으로 나누면

검색창은 Urgent Update, 결과창은 Transition Update로 나눌 수 있다.

const [isPending, startTransition] = useTransition();

const handleChange = (e) => {
  startTransition(() => {
    setInputValue(e.target.value);
  });
};

위 코드에서 isPending을 이용해 로딩 스피너를 띄우거나 하면 편하게 UI를 구현할 수 있다.

Suspense

React 16.6 때 나온 초기 버전은 코드스플리팅 (lazy-loading)을 위해 사용했었는데,

이때 Suspense는 컴포넌트 단위에서만 쓸 수 있었고 데이터 페칭에는 쓰지 못했다.

const Profile = React.lazy(() => import('./Profile'));

<Suspense fallback={<div>Loading...</div>}>
  <Profile />
</Suspense>

React 18에서 확장된 Suspense는 데이터 페칭도 다룰 수 있게 됐고 서버 사이드 렌더링에서도 지원하며

React Query, SWR 등의 라이브러리에서도 Suspense를 지원하기 시작했다.

<Suspense fallback={<Loading />}>
  <UserProfile />
</Suspense>

UserProfile 컴포넌트 내부에서 데이터를 비동기로 불러오고 있다면 데이터가 준비될 때까지 fallback UI를 보여준다.

useId

SSR(서버 사이드 렌더링)에서도 고유 ID를 안정적으로 생성할 수 있고 접근성(ARIA) 작업할 때 필수다.

const id = useId();

return <input id={id} />;

useDefferedValue

값 자체를 지연시켜 부드러운 렌더링을 유도할 수 있다.

const deferredValue = useDeferredValue(value);

복잡한 리스트를 필터링할 때 깜빡임이나 멈춤 현상을 줄이거나하여 단순하지만 꽤 큰 체감 개선이 가능하다.

기타 변경사항

ReactDOM.render는 Deprecated되어 ReactDOM.createRoot를 사용해야 한다.

https://ko.react.dev/blog/2022/03/29/react-v18

[SOLID] React에 개방폐쇄원칙 적용하기

이안92 — Sun, 11 Feb 2024 18:06:54 +0900

컴퓨터 프로그래밍에서 SOLID란 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것이다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다.

단일 책임 원칙 (SRP: Single Responsibility Principle)

"모든 함수/모듈/컴포넌트는 정확히 한 가지 작업을 수행해야 한다"라는 정의라고 해석할 수 있는 원칙.

✍ 개방 폐쇄 원칙 (OCP: Open Close Principle)

OCP는 "소프트웨어의 구성요소(컴포넌트, 클래스, 모듈, 함수)는 확장에는 열려있고, 수정은 닫혀 있어야 한다"라고 말합니다. 새로운 기능의 추가가 일어 났을때에는 기존코드의 수정 없이 추가가 되어야 하고, 내부 매커니즘이 변경이 되어야 할때에는 외부의 코드 변화가 없어야 한다 라는 것입니다.

트럭이라는 운송수단과 뒤에 달리는 기구를 분리/결합 할 수 있는 구조를 만들어 두면 새로운 목적이 필요한 도구를 만들어야 할때 트럭 전체를 다시 만들지 않고서 뒤에 달리는 장치만 새롭게 만들어서 붙일 수 있게 됩니다.

함수형 프로그래밍에서 이 OCP를 가장 잘 느낄 수 있는 것은 바로 map, filter, reduce와 같은 Higher order Function(고차함수)와 webpack loader와 같은 플러그인 또는 middleware 개념입니다.

(고차함수: 일반적인 함수인데 함수를 인자로 받고 함수를 반환할 수 있는 추가적인 기능을 가진 것.)

Bad:

function getMutipledArray(array, option) {
  const result = []
  for (let i = 0; i < array.length; i++) {
    if (option === "doubled") {
      result[i] = array[i] * 2 // 새로운 방식으로 만들기 위해서는 수정이 필요하다.
    }
    if (option === "tripled") {
      result[i] = array[i] * 3 // 옵션으로 분기는 가능하나
    }
    if (option === "half") {
      result[i] = array[i] / 2 // 새로운 기능을 추가하려면 함수 내에서 변경이 되어야 한다.
    }
  }
  return result
}

Good:

// option을 받는게 아니라 fn을 받아보자.
// 이제 새로운 array를 만든다는 매커니즘은 닫혀있으나 방식에 대해서는 열려있다.
function map(array, fn) {
  const result = []
  for (let i = 0; i < array.length; i++) {
    result[i] = fn(array[i], i, array) // 내부 값을 외부로 전달하고 결과를 받아서 사용한다.
  }
  return result
}

// 얼마든지 새로운 기능을 만들어도 map코드에는 영향이 없다.
const getDoubledArray = (array) => map(array, (x) => x * 2)
const getTripledArray = (array) => map(array, (x) => x * 3)
const getHalfArray = (array) => map(array, (x) => x / 2)

하나의 함수의 기능이 여러가지 옵션들로 인해 내부에서 분기가 많이 발생하고 있다면 OCP와 SRP의 원칙에 맞게 함수를 매개 변수로 받는 방법을 통해서 공통 매커니즘의 코드와 새로운 기능에 대한 코드를 분리해서 다룰 수 있게 할 수 있습니다.

본인이 작성한 덩치가 큰 함수가 params에 option이나 flag가 많은 코드가 있다면 한번 SRP와 OCP 원칙을 기반으로 함수를 한번 점검 해보시기 바랍니다. 버그 수정이 아닌 새로운 기능을 개발할때 기존에 개발된 함수를 수정하면서 코드를 개발하고 있다면 OCP 원칙을 위배한 코드를 작성하고 있을 확률이 엄청 높습니다!

‍ React에 적용해보자!

리액트에서는 컴포넌트 합성을 활용해서 OCP 원칙을 적용할 수 있습니다.

실제로 작동하는 모습을 보기 위해 다음 시나리오를 살펴보겠습니다.

const Header = () => {
  const { pathname } = useRouter();

  return (
    <header>
      <Logo />
      <Actions>
        {pathname === "/dashboard" && (
          <Link to="/events/new">Create event</Link>
        )}
        {pathname === "/" && <Link to="/dashboard">Go to dashboard</Link>}
      </Actions>
    </header>
  );
};

const HomePage = () => (
  <>
    <Header />
    <OtherHomeStuff />
  </>
);

const DashboardPage = () => (
  <>
    <Header />
    <OtherDashboardStuff />
  </>
);

여기에서 현재 페이지에 따라 다른 페이지 컴포넌트를 위한 링크를 렌더링합니다. 더 많은 페이지를 추가하기 시작할 때 어떤 일이 일어날지 생각하면 이 구현이 나쁘다는 것을 쉽게 알 수 있습니다. 새 페이지가 생성될 때마다 Header 컴포넌트로 돌아가서 렌더링할 작업 링크를 알 수 있도록 구현을 조정해야 합니다. 이러한 접근 방식은 Header 컴포넌트는 취약해지고 사용되는 컨텍스트와 긴밀하게 결합되어, 개방-폐쇄 원칙에 위배됩니다.

이 문제를 해결하기 위해 컴포넌트 합성(component composition)을 사용할 수 있습니다. Header 컴포넌트는 내부에서 무엇을 렌더링할지 신경 쓸 필요가 없으며 대신 children prop을 사용해서 Header를 사용할 컴포넌트에게 이 책임을 위임할 수 있습니다.

const Header = ({ children }) => (
  <header>
    <Logo />
    <Actions>{children}</Actions>
  </header>
);

const HomePage = () => (
  <>
    <Header>
      <Link to="/dashboard">Go to dashboard</Link>
    </Header>
    <OtherHomeStuff />
  </>
);

const DashboardPage = () => (
  <>
    <Header>
      <Link to="/events/new">Create event</Link>
    </Header>
    <OtherDashboardStuff />
  </>
);

이 접근 방식을 사용하면 Header 내부에 있던 변수 로직을 완전히 제거하고 이제 컴포넌트 자체를 수정하지 않고도 문자 그대로 원하는 모든 것을 입력할 수 있도록 합성(composition)을 사용할 수 있습니다.

✨✨개방-폐쇄 원칙에 따르면 컴포넌트 간의 결합을 줄이고 확장성과 재사용성을 높일 수 있습니다.✨✨

참고한 사이트 링크

Applying SOLID principles in React

Javascript에서도 SOLID 원칙이 통할까?

[SOLID] React에 단일책임원칙 적용하기

이안92 — Sun, 11 Feb 2024 18:02:19 +0900

✍ 단일 책임 원칙 (SRP)

원래 정의는 "모든 클래스는 단 하나의 책임만 가져야 한다"라고 명시되어 있습니다. 이 원칙은 해석하기 가장 쉽습니다. "모든 함수/모듈/컴포넌트는 정확히 한 가지 작업을 수행해야 한다"라는 정의라고 해석할 수 있기 때문입니다.

5가지 원칙 중 SRP는 가장 따르기 쉽지만 코드 품질이 크게 향상하기 때문에 가장 영향력 있는 원칙이기도 합니다. 컴포넌트가 한 가지 작업을 수행하도록 하기 위해 다음을 수행할 수 있습니다.

너무 많은 작업을 수행하는 큰 컴포넌트를 더 작은 컴포넌트로 나눔
주요 컴포넌트 기능과 관련 없는 코드를 별도의 유틸리티 함수로 추출
관련 있는 기능들을 커스텀 hook으로 캡슐화

‍ React에 적용해보자!

이제 이 원칙을 적용하는 방법을 살펴보겠습니다. 먼저 활성 사용자 목록을 표시하는 다음 예제 컴포넌트를 고려해서 시작해보겠습니다.

const ActiveUsersList = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const loadUsers = async () => {
      const response = await fetch("/some-api");
      const data = await response.json();
      setUsers(data);
    };

    loadUsers();
  }, []);

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <li key={user.id}>
            <img src={user.avatarUrl} />
            <p>{user.fullName}</p>
            <small>{user.role}</small>
          </li>
        ))}
    </ul>
  );
};

이 컴포넌트는 현재 비교적 짧지만 데이터를 가져오고, 필터링하고, 컴포넌트 자체와 목록의 각 항목을 렌더링하는 등 이미 많은 작업을 수행하고 있습니다. 어떻게 나눌 수 있는지 봅시다.

우선 서로 연관된 useState와 useEffect가 있을 때는 언제든지 커스텀 hook으로 추출할 수 있습니다.

const useUsers = () => {
  const [users, setUsers] = useState([]);

  useEffect(() => {
    const loadUsers = async () => {
      const response = await fetch("/some-api");
      const data = await response.json();
      setUsers(data);
    };

    loadUsers();
  }, []);

  return { users };
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <li key={user.id}>
            <img src={user.avatarUrl} />
            <p>{user.fullName}</p>
            <small>{user.role}</small>
          </li>
        ))}
    </ul>
  );
};

이제 useUsers hook은 오직 API에서 사용자를 가져오는 것 하나에만 관련되어 있습니다. 또한 메인 컴포넌트 코드가 더 짧아졌을 뿐만 아니라 용도를 파악해야 하는 구조적인 hook을 이름에서 용도를 바로 알 수 있는 도메인 hook으로 대체했기 때문에 보다 읽기 쉬워졌습니다.

다음으로 컴포넌트가 렌더링하는 JSX를 살펴보겠습니다. 객체 배열을 순회하며 매핑하는 경우 배열의 각 항목에 대해 생성하는 JSX의 복잡성에 주의를 기울여야 합니다. 이벤트 핸들러가 연결되지 않은 한 줄짜리 마크업인 경우 인라인으로 유지하는 것이 좋지만 더 복잡한 마크업의 경우 별도의 컴포넌트로 추출하는 것이 좋습니다.

const UserItem = ({ user }) => {
  return (
    <li>
      <img src={user.avatarUrl} />
      <p>{user.fullName}</p>
      <small>{user.role}</small>
    </li>
  );
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return (
    <ul>
      {users
        .filter((user) => !user.isBanned && user.lastActivityAt >= weekAgo)
        .map((user) => (
          <UserItem key={user.id} user={user} />
        ))}
    </ul>
  );
};

이전 변경과 마찬가지로 사용자 항목을 렌더링하는 로직을 별도의 컴포넌트로 추출하여 메인 컴포넌트를 더 작고 읽기 쉽게 만들었습니다.

마지막으로 API로부터 얻은 전체 사용자 목록에서 비활성 사용자를 필터링하는 로직이 있습니다. 이 로직은 비교적 독립되어 있고 애플리케이션의 다른 부분에서 재사용될 수 있으므로 유틸리티 함수로 쉽게 추출할 수 있습니다.

const getOnlyActive = (users) => {
  const weekAgo = new Date();
  weekAgo.setDate(weekAgo.getDate() - 7);

  return users.filter(
    (user) => !user.isBanned && user.lastActivityAt >= weekAgo
  );
};

const ActiveUsersList = () => {
  const { users } = useUsers();

  return (
    <ul>
      {getOnlyActive(users).map((user) => (
        <UserItem key={user.id} user={user} />
      ))}
    </ul>
  );
};

이 시점에서 메인 컴포넌트는 더 이상 나누지 않아도 될 만큼 짧고 간단합니다. 그러나 조금 더 자세히 살펴보면 여전히 해야 할 것보다 더 많은 일을 하고 있음을 알 수 있습니다. 현재 컴포넌트는 데이터를 페칭한 다음 필터링을 적용하고 있지만 추가 조작 없이 데이터를 가져와 렌더링하기만 하는 것이 이상적입니다. 따라서 마지막 개선 사항으로 이 로직을 새로운 커스텀 hook으로 캡슐화할 수 있습니다.

const useActiveUsers = () => {
  const { users } = useUsers();

  const activeUsers = useMemo(() => {
    return getOnlyActive(users);
  }, [users]);

  return { activeUsers };
};

const ActiveUsersList = () => {
  const { activeUsers } = useActiveUsers();

  return (
    <ul>
      {activeUsers.map((user) => (
        <UserItem key={user.id} user={user} />
      ))}
    </ul>
  );
};

여기서는 페칭하고 필터링하는 로직을 처리하기 위해 useActiveUsers hook을 만들어 메인 컴포넌트에는 hook에서 가져온 데이터를 렌더링하는 최소한의 작업만 남겨둡니다. (좋은 성능을 위해 필터링된 데이터를 메모이제이션했습니다)

이제 "한 가지"를 어떻게 해석하는지에 따라 컴포넌트가 여전히 먼저 데이터를 얻은 다음 렌더링하기 때문에 "한 가지"가 아니라고 주장할 수 있습니다. 한 컴포넌트에서 hook을 호출한 다음 그 결과를 다른 컴포넌트에 props로 전달해서 더 나눌 수 있지만 실제 애플리케이션에서 이것이 실제로 이로운 경우는 거의 없었습니다. 때문에 정의를 "컴포넌트가 얻은 렌더링 데이터"를 "한 가지"로 너그럽게 받아들이도록 합시다.

요약하자면, 단일 책임 원칙에 따라 우리는 큰 모놀리식 코드 덩어리를 효과적으로 가져와 더 모듈화합니다. ✨✨✨모듈화하면 코드를 파악하기 쉬워지고, 의도치 않은 중복 코드를 작성할 가능성이 줄어듭니다. 또한 작은 모듈은 테스트 및 수정하기 더 쉽기 때문에 결과적으로 코드를 보다 쉽게 유지 관리할 수 있어 좋습니다. ✨✨✨

여기에서 본 것은 인위적인 예이며, 여러분의 컴포넌트는 서로 다른 가동부들 사이에 의존성이 훨씬 더 얽혀 있다는 것을 알 수 있습니다. 대부분의 경우 이는 적절하지 못한 추상화, 다재다능한 전역 컴포넌트 생성, 데이터의 잘못된 스코프 설정 등 잘못된 설계를 선택했기 때문입니다. 그리고 이는 광범위한 리팩토링으로 해결할 수 있습니다.

출처 링크

Applying SOLID principles in React

[번역] React에 SOLID 원칙 적용하기

any와 unknown

이안92 — Sun, 11 Feb 2024 17:55:27 +0900

anyscript

타입스크립트 프로젝트의 tsconfig에서 strict를 true로 설정하거나, noImplicitAny를 true로 설정하면, 각종 변수에 타입을 지정하지 않았을 때 에러가 발생합니다. 타입스크립트에서 기본적으로 타입 추론이라는 것을 하는데, 추론한 근거가 없으면 암시적으로 any로 할당됩니다. 이러한 것을 못하게 하는 옵션이 noImplicitAny(말 그대로, no implicit any – 암시적인 any는 no)를 true로 설정하는 것이고, strict를 true로 설정하면 noImplicitAny도 true로 설정되죠. 타입스크립트 프로젝트에서 strict 모드를 설정하는 것은, 프로젝트에 엄격한 룰을 강제해서 추후에 코드를 수정하기 쉽게 만들어주는데, 이러한 프로젝트에서 막상 타입 지정하기가 귀찮아서 any로 일단 선언해두고 사용하는 경우가 있습니다. 이런 게 반복되고 도배되기 시작하면, 이건 타입스크립트가 아니라 anyscript라고 부를 수도 있을 만한 상황이 될 수도 있겠죠. 즉, 귀찮아서 잠시 사용할 수 있을지는 몰라도, any는 어떤 타입이든 모두 올 수 있음을 말하기 때문에 자바스크립트를 쓰는 것과 다름이 없어지는 상황이 되어서 권장하지 않습니다.

‍ ️ unknown?

비슷한 것으로 unknown도 있는데, any와의 차이는 뭘까요? any는 아무거나 다 올 수 있고, 그 이후 어떤 동작을 해도 되는 것에 비해, unknown도 아무거나 다 올 수 있지만, 그 이후는 어떤 동작도 허용하지 않습니다. 말이 어려운데 코드를 통해서 살펴보겠습니다.

const sayNumber = (num: number) => {
  console.log('num: ', num)
}

const sum = (a: any, b: any): any => a + b
const three = sum(1, 2)
sayNumber(three)

const minus = (a: any, b: any): unknown => a - b
const five = minus(7, 2)
sayNumber(five) // 'unknown' 형식의 인수는 'number' 형식의 매개 변수에 할당될 수 없습니다.

sayNumber라는 함수가 있습니다. 이 함수는 number 형식의 num이라는 값을 입력받아서, 콘솔에 출력해주는 함수입니다. 다음으로 sum이라는 함수는 a, b를 입력 받아서 a+b를 리턴해주는 함수입니다. 이 함수의 return type을 보면 any로 명시하였죠. 변수 three는 sum 함수에 1, 2를 전달해서 3이라는 return 값을 받았지만 이 변수의 type은 any입니다. minus라는 함수는 a, b를 입력 받아서 a-b를 리턴해주는 함수입니다. 이 함수의 return type은 unknown으로 명시하였습니다. 변수 five는 minus 함수에 7, 2를 전달해서 5라는 return 값을 받았지만 이 변수의 type은 unknown입니다.

⇒ sayNumber함수에 any type의 three를 전달하면, 아무런 에러 없이 "num: 3"이 출력됩니다. 하지만 sayNumber함수에 unknown type의 five를 전달하면 ‘unknown’ 형식의 인수는 ‘number’ 형식의 매개 변수에 할당될 수 없습니다. 라는 에러 메시지가 나오게 됩니다. 타입을 unknown으로 지정은 할 수 있지만, 해당 타입으로 지정된 값을 사용할 때가 되면 그 타입이 어떤 타입인지 명확히 알아야 사용할 수 있게 막아주는 역할을 한다고 보면 됩니다.

위 코드의 경우 minus 함수의 return type을 명시적으로 지정해주거나 five 변수의 type을 number라고 타입 단언을 해주면 사용할 수 있게 됩니다.

const minus = (a: any, b: any): unknown => a - b
const five = minus(7, 2) as number
sayNumber(five)

물론 위의 예제처럼 타입 단언을 이용하기보다는 minus 함수의 타입을 명확하게 지정해주거나 generic을 사용하는 게 일반적이긴 하겠지만, unknown을 설명하기 위해 만든 예제입니다.

다시 정리해보면 any, unknown 둘 다 ‘아무거나’에 들어갈 수 있지만 unknown은 그것을 사용하는 쪽에서 특별한 처리를 강제하게 해서, 안전하게 사용할 수 있게 해줍니다.

unknown을 사용해야 할 상황

위에서 unknown에 대해서 알아보았는데, any와 같이 사용하지 말아야만 할까요? 적은 상황이지만, unknown은 아래의 예제와 같이 사용할 케이스가 있습니다.

const isNil = (param: unknown): boolean => param === null || param === undefined

isNil이라는 함수는 param을 입력받아서, 해당 param이 null이나 undefined인지를 체크해서 true/false를 리턴해줍니다. 이 경우, param은 단순히 null, undefined인지에 대한 체크만 하기 때문에, 어떠한 타입이 들어올지 몰라도 됩니다. 이때 unknown을 사용할 수 있습니다. 물론 이때 any를 사용할 수도 있지요. 프로젝트의 설정에 따라서 any를 아예 사용하지 못하게 하는 경우도 있는데, isNil의 param 같은 경우 unknown 타입이 적절하다고 생각합니다.

하나의 예시를 더 들어보겠습니다.

function prettyPrint(x: unknown): string {
  if (Array.isArray(x)) {
    return "[" + x.map(prettyPrint).join(", ") + "]"
  }
  if (typeof x === "string") {
    return `"${x}"`}
  if (typeof x === "number") {
    return String(x)
  }
  return "etc."
}

위 prettyPrint 함수는 x라는 param을 입력받는데, 그 param이 array, string, number일 때와 그 밖의 상황에 대해서 처리를 하고 있는데, 3번째 줄에 있는 map(), join()은 array에서 사용할 수 있는 javascript 내장함수입니다. x가 any일 때는, x가 어떤 것이라고 하더라도 map(), join()을 사용할 수 있는데, x가 unknown일 때는, x가 array일 때만 map(), join()을 사용할 수 있게 강제해줍니다. (그냥 사용한다면, ‘x’ is of type ‘unknown’. 이라는 에러 메시지를 보여줍니다) 따라서, any 대신 unknown을 사용해서 더 안전한 코드를 작성할 수 있게 됩니다.

any, unknown 결론

any: 아무때나 쓸 수 있지만, typescript를 쓰는 의미가 사라짐
unknown: 어쩔 수 없이 써야하는 상황이 있을 때, 방어처리를 통해 안전하게 사용가능함

Jira 이슈 링킹이란? (Issue Linking)

이안92 — Sun, 11 Feb 2024 16:24:53 +0900

이슈 링킹이란?

이슈들의 관계를 정의하는 필드로써 하나의 관계에는 자동태와 수동태로 관계를 설정할 수 있다.

장점은?

해당 이슈 담당자로 하여금 이 이슈가 어디서 파생된 이슈인지 혹은 어떤 작업이 선행되어야 하는지 명시적으로 알려줄 수 있는 기능이므로 잘 사용하면 커뮤니케이션 비용을 상당히 아낄 수 있다.

사용법은?

링크 아이콘 - 이슈 연결을 클릭하면 아래와 같이 연결할 수 있는 필드가 나타난다.

Blocks(병목) - is blocked by, blocks
Cloners(복제) - is cloned by, clones
Duplicate(중복) - is duplicated by, duplicates
Relates(관계됨) - relates to

만약 A 이슈와 B 이슈가 있을 때 A 이슈가 반드시 먼저 끝나야 B 이슈를 작업할 수 있는 상황인 경우

⇒ A blocks B 또는 B is blocked by A 로 표현할 수 있다.

참고 사이트

JIRA 프로젝트 이슈 커스터마이징하기

[오류해결] npm ERR! Cannot read properties of null (reading 'pickAlgorithm')

이안92 — Wed, 4 Jan 2023 15:56:02 +0900

새로운 프로젝트의 repo를 npm install로 설치하는데 이와 같은 에러가 떴다.

해결방안

0. node-modules 폴더가 있다면 삭제. (없으면 다음 단계로 바로 넘어가도 된다)

1. 터미널에 아래와 같이 입력.

npm cache clear --force

2. 다시 설치해주면 에러없이 설치가 완료된다.

npm install

완료! ✨

[React] 글자 수 이상일 때 '...' 처리하기

이안92 — Wed, 3 Aug 2022 22:41:56 +0900

글자 수 초과 시 ... 처리하는 방법

조건을 줘서 substr 메서드를 이용하면 간단하게 처리할 수 있다.

const truncate = (str, n) => {
  return str?.length > n ? str.substr(0, n - 1) + "..." : str;
};

위와 같이 truncate라는 함수를 만든 후 jsx, tsx에서 가져다 쓰면 된다.

<span>{truncate(movie.overview, 100)}</span>

그럼 100자 초과 시 나머지 글자를 자르고 "..."가 붙어서 원하는 대로 처리된다.

[React] 리액트 Hooks 총 정리

이안92 — Sun, 31 Jul 2022 21:35:37 +0900

React Hooks

React Hooks는 ReactConf 2018에서 발표된 class없이 state를 사용할 수 있는 새로운 기능이다.

Class Component로 사용되어온 React에서 느껴왔던 불편함이나 문제점들을 해결하기 위해서 개발되었다.

원래 React는 주로 Class Component를 사용하고 React Hooks는 Functional Component를 사용한다.

위와 같이, Class 컴포넌트와 비교했을 때 함수형 컴포넌트를 이용하면 더 간결한 코드, 더 빠른 성능, 더 나은 가독성을 가진다.

함수형 컴포넌트에서는 클래스 컴포넌트에서 사용하던 리액트의 생명주기를 사용하기 못했기 때문에,

함수형 컴포넌트가 더 간결하고 빠르더라도 클래스형 컴포넌트를 써왔지만, 이것은 React 16.8 Hooks 업데이트로 변경되었다.

이로 인해 함수형 컴포넌트에서도 생명주기를 사용할 수 있기에 데이터를 가져오고 컴포넌트를 시작하자마자 API도 호출할 수 있게 되었다.

Class Component에서는 생명주기를 이용할 때 componentDidMount와 componentDidUpdate 그리고 componentWillUnmount를 다르게 처리를 해주지만 리액트 훅을 사용할 때는 useEffect 안에서 다 처리해줄 수 있다.

즉, componentDidMount, componentDidUpdate, componentWillUnmount 모두를 Hooks에서는 usEffect를 이용해 처리한다.

React State

리액트에서 데이터가 변할 때 화면을 다시 렌더링 해주기 위해서는 React State를 사용해야 한다.

React State란 컴포넌트의 렌더링 결과물에 영향을 주는 데이터를 갖고 있는 객체이다.

State가 변경되면 컴포넌트는 리렌더링(Re-rendering)된다. 또한 State는 컴포넌트 안에서 관리된다.

Hooks에서는 state를 정의하고 위의 setValue와 같이 이용해 state를 업데이트한다.

Props는 Properties의 줄임말로 상속하는 부모 컴포넌트로부터 자녀 컴포넌트에 데이터를 전달하는 방법으로 쓰이고, 읽기 전용(immutable)로 자녀 컴포넌트 입장에서는 변하지 않는다. (변하게 하고자 하면 부모 컴포넌트에서 state를 변경시켜줘야 한다.

State는 부모 컴포넌트에서 자녀 컴포넌트로 데이터를 보내는게 아닌 해당 컴포넌트 내부에서 데이터를 전달하고, 변경이 가능(mutable)하며 state가 변하면 Re-render된다.

HOC(Higher Order Component)

HOC란 컴포넌트를 인자로 받아서 새로운 리액트 컴포넌트를 리턴하는 함수다.

화면에서 재사용 가능한 로직만을 분리해서 component로 만들고,

재사용 불가능한 UI와 같은 다른 부분들은 parameter로 받아서 처리하는 방법이다.

위의 A 페이지와 B 페이지는 같은 소스를 사용하고 있는 부분이 있는데 그 부분은 유저 리스트를 가져오는 부분이다.

어떠한 페이지에서든 유저 리스트를 가져와야 하는 애플리케이션을 만드려고 한다.

하지만 모든 페이지에서 유저 리스트를 가져오기 위해서 똑같은 소스를 넣어준다면 너무 많은 중복이 되기 때문에

중복이 되는 부분은 따로 HOC컴포넌트를 만들어 준다.

유저 리스트를 가져오는 공통적인 부분은 HOC 컴포넌트에 넣어주고 그 HOC 컴포넌트로 각각의 컴포넌트를 감싸주면 모든 컴포넌트에 따로 인증을 위한 부분은 넣어주지 않아도 된다.

Hooks가 나오기 전에는 이 방법이 추천되는 방법이었지만 여기도 문제가 있다.

바로 너무나 많은 Wrapper 컴포넌트가 생길 수 있다는 것이다.

이와 같은 문제는 Custom React Hooks를 이용해서 해결할 수 있다.

React Hooks에서는 HOC 대신 Custom Hooks를 이용해 컴포넌트를 만들어 처리해준다. Wrapper가 너무 많아지는 일을 방지한다.

React.memo (컴포넌트 렌더링 최적화)

리액트앱에서 여러 컴포넌트로 나누는 이유는 재사용성을 위해서도 이지만 각 컴포넌트의 렌더링의 최적화를 위해서 이기도 하다.

예를 들어 Form에서 글을 타이핑을 할 때 원래는 Form 컴포넌트와 그 State 값을 가지고 있는 App 컴포넌트만 렌더링이 되어야 한다.

한 글자 입력 시마다 props가 바뀌지 않아서 렌더링 하지 않아도 되는 Form 이외의 리스트를 출력하는 List, Lists 컴포넌트가 있다고 하면 그 컴포넌트들까지 다시 렌더링 되는 걸 볼 수 있다.

이럴 때 React.memo를 적용하면 간단하게 문제를 해결할 수 있다.

이제는 렌더링이 필요치 않은 Lists, List 컴포넌트가 없는 것을 확인할 수 있다.

useCallback (함수 최적화)

원래 컴포넌트가 렌더링 될 때 그 안에 있는 함수도 다시 만들게 된다.

하지만 똑같은 함수를 컴포넌트가 리렌더링 된다고 해서 계속 다시 만드는 것은 좋은 현상이 아니다.

그리고 이렇게 컴포넌트가 리렌더링될 때마다 함수를 계속 다시 만든다고 하면 만약이 함수가 자식 컴포넌트에 props로 내려준다면

함수를 포함하고 있는 컴포넌트가 리렌더링될 때마다 자식 컴포넌트도 함수가 새롭게 만들어지니 계속 리렌더링하게 된다.

함수를 만들어 props로 함수를 넘겨주면 React.memo로 감싸줘서 리렌더링되지 않던 컴포넌트들이 다시 한 글자 입력 시마다

Lists 컴포넌트와 List 컴포넌트까지 다시 리렌더링 되는 것을 볼 수있다.

useCallback 적용은 useCallback 안에 콜백함수와 의존성 배열을 순서대로 넣어주면 된다.

함수 내에서 참조하는 state, props가 있다면 의존성 배열에 추가해주면 된다.

useCallback으로 인해서 data가 변하지 않는 다면 함수는 새로 생성되지 않는다.

새로 생성되지 않기에 메모리에 새로 할당되지 않고 동일 참조 값을 사용하게 된다.

의존성 배열에 아무것도 없다면 컴포넌트가 최초 렌더링 시에만 함수가 생성되며 그 이후에는 동일한 참조 값을 사용하는 함수가 된다.

useMemo (결과 값 최적화)

Memoization(메모이제이션)은 비용이 많이 드는 함수 호출의 결과를 저장하고 동일한 입력이 다시 발생할 때 캐시된 결과를 반환하여 컴퓨터 프로그램의 속도를 높이는 데 주로 사용되는 최적화 기술이다.

Component 내의 compute 함수가 만약 복잡한 연산을 수행하면 결과 값을 리턴하는데 오랜 시간이 걸리게 된다.

이럴 시에 컴포넌트가 계속 리렌더링 된다면 연산을 계속 수행하는데 오랜 시간이 걸려서 성능에 안좋은 영향을 미치게 되며,

UI 지연 현상도 일어나게 된다.

이러한 현상을 해결해주기 위해서 사용하는 것이 useMemo다.

compute 함수에 넘겨주는 a, b의 값이 이전과 동일하다면 컴포넌트가 리렌더링 되더라도 연산을 다시 하지않고 이전 렌더링 때 저장해두었던 값을 재활용하게 된다.

useMemo로 감싸준 후에 첫번째 인수에 의존성 배열에 compute 함수에서 사용하는 값을 넣어준다.

크롬 확장 프로그램 - React Developer Tools

https://chrome.google.com/webstore/detail/react-developer-tools/fmkadmapgofadopljbjfkapdkoienihi?hl=ko

React Developer Tools

Adds React debugging tools to the Chrome Developer Tools. Created from revision 336ac8ceb on 7/13/2022.

chrome.google.com

위에서 렌더링되는 것을 확인하기 위해 리액트 확장 프로그램을 크롬 익스텐션으로 다운로드 받아 설정해주면 쉽게 확인할 수 있다.

Components 탭에서 Highligh updates... 부분을 체크해주면 쉽게 컴포넌트가 렌더링 되는 것을 확인할 수 있다.

[React] localStorage 값 저장하고 불러오기

이안92 — Sun, 31 Jul 2022 18:29:51 +0900

localStorage 값 저장하기

localStorage에 데이터 값을 담으면 페이지를 refresh 해도 데이터가 계속 남아 있다.

https://developer.mozilla.org/ko/docs/Web/API/Window/localStorage

Window.localStorage - Web API | MDN

localStorage 읽기 전용 속성을 사용하면 Document 출처의 Storage 객체에 접근할 수 있습니다. 저장한 데이터는 브라우저 세션 간에 공유됩니다.

developer.mozilla.org

리액트의 이벤트핸들러에서 setData시 localStorage.setItem을 이용해 동일하게 값을 담아주면 된다.

객체나 배열을 저장해줄시에는 JSON.stringify를 이용해서 텍스트로 변환시켜준 후에 저장해주면 된다.

Application-Storage-Local Storage를 확인해보면 JSON.stringify없이 저장해둔 데이터는 [Object Object]와 같이 저장되는 것을 확인할 수 있다.

localStorage 값 불러오기

값을 불러올 때는 useState 기본값에 넣어주면 된다. 이때 JSON.stringify로 객체를 string으로 변환해준 것을 다시 객체로 변환해주기 위해 JSON.parse를 이용한다.