🎧

원문

https://tkdodo.eu/blog/deriving-client-state-from-server-state

휴가에서 막 돌아왔는데, Zustand를 사용할 때 가장 큰 트레이드오프에 대한 Reddit 질문을 보게 되었다.
코드는 대략 이렇다(최신 문법으로 조금 수정하고, 커스텀 훅 안에 넣었다).

Manual-sync

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  // If the selected user gets deleted from the server,
  // Zustand won't automatically clear selectedUserId
  // You have to manually handle this:
  useEffect(() => {
    if (!users?.some((u) => u.id === selectedUserId)) {
      setSelectedUserId(null) // Manual sync required
    }
  }, [users, selectedUserId])

  return [selectedUserId, selectedUserId]
}

물론, useEffect—특히 그 안에서 setState를 호출하는 경우—를 볼 때마다 나는 더 나은 해결책이 없을까 생각하게 된다.
내 경험상, 거의 항상 더 나은 방법이 존재하며, 보통 그 방법을 찾는 것이 가치 있는 일이다.
그러니 한 걸음 물러서서 우리가 먼저 무엇을 달성하고 싶은지를 먼저 살펴보자.

상태 동기화 유지하기 (Keeping State in Sync)

간단히 말하면, 우리는 클라이언트 상태(Client State)인 selectedUserId를 서버 상태(Server State)인 사용자 목록(users)과 동기화하고 싶다.
이것은 당연한 일이다.

예를 들어, useQuery를 통해 백그라운드에서 다시 데이터를 가져왔는데, 사용자가 목록에서 삭제되었음에도 여전히 상태에 저장되어 있다면, 그 선택은 유효하지 않다.

클라이언트 상태(Client State)

이 접근 방식은 Zustand에만 국한된 것이 아니다.
useUserStore()를 단순히 로컬 상태로 바꿔도 똑같이 적용할 수 있다:

const [selectedUserId, setSelectedUserId] = useState()

또는 URL 상태(nuqs 같은)를 사용해도 된다:

const [selectedUserId, setSelectedUserId] = useQueryState('userId')

중요한 건 상태가 어디에 저장되느냐가 아니라,
서버 상태(Server State)가 바뀔 때 업데이트해야 하는 클라이언트 상태(Client State)라는 점이다.

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()

  const selectedId = users?.some((u) => u.id === selectedUserId)
    ? selectedUserId
    : null

  return [selectedId, setSelectedUserId]
}

이 코드는 매우 간단하다.
스토어 값을 직접 업데이트하는 대신, Selection 자체는 그대로 두고,
서버 상태(Server State)에서 더 이상 해당 id를 찾을 수 없는 경우 커스텀 훅에서 다른 값을 반환하도록 한다.

즉, useSelectedUser()를 호출하는 곳에서는 이전처럼 null을 받게 된다.

그리고 스토어를 건드리지 않기 때문에 추가적인 이점도 있다:

• 사용자가 다시 목록에 추가되면, 선택(selection)이 자동으로 복원된다.
• UX 요구사항이 바뀌어 선택을 제거하고 싶지 않고, 단지 선택이 유효하지 않음을 시각적으로 표시하고 싶을 때도 가능하다.
  → 원래 값을 항상 유지하기 때문에 쉽게 구현할 수 있다.

isSelectionValid

const useSelectedUser = () => {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const { selectedUserId, setSelectedUserId } = useUserStore()
  const isSelectionValid = users?.some((u) => u.id === selectedUserId)

  return [selectedUserId, setSelectedUserId, isSelectionValid]
}

함정은 어디에 있을까요?

"상태 파생 솔루션"의 명백한 단점 중 하나는 사용자 저장소에 저장된 내용을 더 이상 "신뢰"할 수 없다는 것입니다. useUserStore에서 다른 곳의 selectedUserId를 읽어오면 추가 검사를 받지 못하므로 항상 사용자 정의 hook에서 읽어야 합니다.

저는 저장소를 최종 검증된 값의 소스라기보다는 UI에서 실제로 선택된 항목의 기록으로 보기 때문에 이 점에 대해서는 전혀 문제가 없습니다.

또, Reddit 질문에서 Redux Toolkit이 “이 문제를 해결한다”고 언급했지만, 실제로 크게 다르지 않을 것이다.
보통 API 슬라이스와 사용자 선택 슬라이스를 읽어 두 값을 결합하는 selector를 작성하게 되는데,
이것이 바로 우리가 커스텀 훅에서 하고 있는 방식과 동일하다.

오히려 이 방식은 상태를 파생(derive)하도록 유도하므로, 좋은 접근입니다.

다른 예시

서버 상태(Server State)가 바뀌어도 클라이언트 상태(Client State)를 업데이트하지 않는 개념은 여러 경우에 유용하다.
흔한 예시는 서버에서 가져온 기본값으로 폼을 미리 채울 때(prefilling forms)이다.

default-value-effect

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  // use the first value as default selection
  useEffect(() => {
    if (users?.[0]) {
      setSelection(users[0])
    }
  }, [users])

  // return markup
}

이 효과는 장황할 뿐만 아니라, 쿼리에서 새 데이터가 들어올 때 현재 선택 항목을 덮어쓰는 버그도 있습니다. 🐛

이 문제는 다른 검사를 추가하면 쉽게 해결할 수 있지만, 더 나은 해결책은 여전히 ​​상태를 파생하는 것입니다.

derived-default-value

function UserSelection() {
  const { data: users } = useQuery({
    queryKey: ['users'],
    queryFn: fetchUsers,
  })
  const [selection, setSelection] = useState()

  const derivedSelection = selection ?? users?.[0]

  // return markup
}

지금 우리가 해야 할 일은 selection 대신 derivedSelection을 계속 사용하는 것뿐이며, 그렇게 하면 항상 원하는 값을 얻을 수 있습니다. 🚀

https://tkdodo.eu/blog/the-useless-use-callback

원문

메모이제이션(memoization)에 대해서는 이제 충분히 다뤘다고 생각했는데, 요즘 자주 보이는 한 가지 패턴을 보면서 생각이 달라졌다.
그래서 오늘은 useCallback과, 부분적으로는 useMemo에 대해 이야기해보려 한다.
특히 내가 보기엔 정말 불필요하게 사용되는 경우들에 대해 말이다.

왜 메모이제이션을 사용할까?

보통 useCallback으로 함수를, useMemo로 값을 메모이제이션하는 이유는 단 두 가지뿐이다.

function Meh() {
  return (
    <MemoizedComponent
      value={{ hello: 'world' }}
      onChange={(result) => console.log('result')}
    />
  )
}

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <MemoizedComponent value={value} onChange={onChange} />
}

물론 때로는 useMemo 내부의 계산 자체가 느릴 때가 있다.
이럴 땐 불필요한 재계산을 피하기 위해 메모이제이션을 사용하는데, 이런 경우의 useMemo 사용은 전혀 문제 없다.
하지만 솔직히 말하자면, 이런 경우가 대부분은 아니다.

2. Effect가 불필요하게 자주 실행되는 것을 막기 위해

no-memo

function Okay() {
  const value = useMemo(() => ({ hello: 'world' }), [])
  const onChange = useCallback((result) => console.log(result), [])

  return <Component value={value} onChange={onChange} />
}

차이점을 찾을 수 있는가? 맞다 — 이제 value와 onChange를 메모이제이션된 컴포넌트에 전달하지 않는다.
그냥 일반적인 React 함수형 컴포넌트일 뿐이다.

이런 상황은 특히 결국엔 값이 React의 기본(built-in) 컴포넌트로 전달될 때 자주 발생한다:

react-built-ins

function MyButton() {
  const onClick = useCallback(
    (event) => console.log(event.currentTarget.value),
    []
  )

  return <button onClick={onClick} />
}

여기서 onClick을 메모이제이션해도 아무런 효과가 없다.
왜냐하면 버튼 컴포넌트는 onClick이 참조가 안정적인지 여부를 신경 쓰지 않기 때문이다.

“아무 효과가 없다(Achieves nothing)”라고 표현했지만, 엄밀히 말하면 약간 잘못된 표현이다. 사실 내부적으로는 분명 무언가 일이 일어나고 있다.

React는 onClick 함수를 유지하기 위해 캐시를 만들어야 하고, 의존성을 추적하며 매 렌더링마다 비교를 수행한다. useCallback에 전달된 인라인 함수도 매 렌더마다 새로 생성되지만, 캐시된 버전이 반환되면 즉시 버려진다.

결과적으로, 기술적으로는 내부에 약간의 오버헤드가 생긴다. 하지만 나는 이 오버헤드에 너무 집중하고 싶진 않다. 왜냐하면 진짜 문제는 그게 아니기 때문이다.

function OhNo({ onChange }) {
  const handleChange = useCallback((e: React.ChangeEvent) => {
    trackAnalytics('changeEvent', e)
    onChange?.(e)
  }, [onChange])

  return <SomeMemoizedComponent onChange={handleChange} />
}

<OhNo onChange={() => props.doSomething()} />​

이건 무해한 사용 사례다. 전혀 문제될 게 없다.
사실 오히려 좋은 패턴이라고 볼 수 있다.
이벤트 핸들러와 관련된 동작을 한곳에 모아두어, 파일 상단으로 끌어올려서 길게 이름 붙인 handleChange 같은 함수를 만드는 일을 피할 수 있다.

이 코드를 작성한 개발자가 메모이제이션이 깨진다는 사실을 알 수 있는 유일한 방법은, 컴포넌트 내부를 깊이 파고 들어가 props가 어떻게 사용되는지 확인하는 것뿐이다.
솔직히 말해, 그건 끔찍하다.

다른 해결책으로는 “모든 걸 항상 메모이제이션한다”라는 정책을 세우거나,
참조 안정성이 필요한 props에는 mustBeMemoized 같은 엄격한 네이밍 규칙을 적용하는 방법이 있다.
하지만 이 둘 다 좋은 방법은 아니다.

실제 사례(Real Life Example)

지금 나는 Sentry 코드베이스에서 작업하고 있는데, 이건 오픈소스라서 🎉 실제 사용 사례를 쉽게 보여줄 수 있다.

내가 발견한 한 가지 상황은 useHotkeys 커스텀 훅이다.
핵심 부분은 대략 이렇게 생겼다:

useHotkeys

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useCallback(() => ..., [hotkeys])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [onKeyDown])
}

이 커스텀 훅은 hotKeys 배열을 인자로 받고,
그걸 기반으로 onKeyDown 함수를 메모이제이션한 뒤, 해당 함수를 effect에 넘긴다.

함수를 메모이제이션하는 이유는 명백하다: Effect가 너무 자주 실행되는 것을 방지하기 위해서다.

하지만 입력값인 hotkeys가 배열이기 때문에, 사용하는 쪽에서 직접 hotkeys를 메모이제이션해주어야 한다.

그래서 나는 useHotkeys가 실제 코드에서 어떻게 쓰이고 있는지 전수 조사를 해봤다.
놀랍게도 거의 대부분(한 곳을 제외하고)은 입력값을 메모이제이션하고 있었다.

하지만 이야기는 여기서 끝나지 않는다.
더 깊이 들어가 보면, 결국에는 여전히 문제가 생기기 쉬운 구조라는 걸 알 수 있다.
예를 들어, 다음과 같은 사용 사례를 보자.

paginateHotKeys

const paginateHotkeys = useMemo(() => {
  return [
    { match: 'right', callback: () => paginateItems(1) },
    { match: 'left', callback: () => paginateItems(-1) },
  ]
}, [paginateItems])

useHotkeys(paginateHotkeys)

useHotKeys는 메모이제이션된 paginateHotkeys를 전달한다.
그런데 이 paginateHotkeys는 paginateItems에 의존한다.

그럼 paginateItems는 어디서 올까?

바로 또 다른 useCallback이고, 이 콜백은 screenshots와 currentAttachmentIndex에 의존한다.

그렇다면 screenshots는 어디서 오는 걸까?

breaking-memoization

const screenshots = attachments.filter(({ name }) =>
  name.includes('screenshot')
)

screenshots는 메모이제이션되지 않은 attachments.filter 함수에서 생성된다.
이 함수는 매번 새로운 배열(Array)을 생성하므로, downstream에 있는 모든 메모이제이션이 깨진다.

결과적으로 모든 메모이제이션이 무용지물이 된다.

즉, paginateItems, paginateHotkeys, onKeyDown
이 세 가지 메모이제이션이 매 렌더링마다 다시 실행되며,
마치 아예 작성하지 않은 것과 동일한 상황이 된다! (이렇게 되면 우리가 했던 메모이제이션은 전부 무용지물이 된다)

이 예시가 내가 왜 메모이제이션 적용에 반대하는 입장인지 잘 보여줬으면 한다.
내 경험상, 메모이제이션은 너무 자주 깨지고, 그럴 가치가 없다.

게다가 코드 전체에 엄청난 오버헤드와 복잡성을 추가한다.

여기서 해결책이 screenshots까지 메모이제이션하는 것은 아니다.

그렇게 하면 책임이 결국 컴포넌트의 prop인 attachments로 넘어가게 된다.
세 가지 호출 지점(call-side) 모두에서 실제로 메모이제이션이 필요한 useHotkeys와는 최소 두 단계 이상 떨어져 있게 된다.

이건 코드를 탐색하기 악몽 같은 상황을 만들며, 결국 아무도 메모이제이션 하나를 제거하지 못하게 된다.
왜냐하면 그 메모이제이션이 실제로 무엇을 하고 있는지 알 수 없기 때문이다.

실제로는, 이런 문제를 해결하려면 컴파일러에게 모든 걸 맡기는 것이 가장 좋다.

모든 환경에서 잘 작동한다면 정말 훌륭하다.
하지만 그 전까지는, 참조 안정성(referential stability) 필요성의 한계를 우회할 패턴을 찾아야 한다.

최신 Ref 패턴(The Latest Ref Pattern)

이 패턴에 대해서는 이전에 언급한 적이 있다.
핵심 아이디어는, Effect 안에서 즉시 접근하고 싶은 값을 ref 안에 저장해두고,
또 다른 Effect를 통해 의도적으로 매 렌더링마다 값을 업데이트하는 것이다.

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const hotkeysRef = useRef(hotkeys)

  useEffect(() => {
    hotkeysRef.current = hotkeys
  })

  const onKeyDown = useCallback(() => ..., [])

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}

그렇게 하면 hotkeysRef를 Effect 안에서 바로 사용할 수 있다.
의존성 배열에 추가할 필요도 없고, 단순히 린터를 무시하다가 발생할 수 있는 stale closure 문제도 걱정하지 않아도 된다.

실제로 React Query도 이 패턴을 사용한다.

예를 들어 PersistQueryClientProvider나 useMutationState에서 최신 옵션(latest options)을 추적할 때 그렇다.
즉, 검증된(tried-and-true) 패턴이라고 볼 수 있다.
만약 라이브러리가 사용자가 옵션을 직접 메모이제이션하도록 강제한다면 얼마나 귀찮을지 상상해보라.

UseEffectEvent

좋은 소식이 하나 더 있다.
React 팀은 대부분의 경우, 리액티브 Effect 안에서 최신 값을 명령형(imperative)으로 접근할 필요가 있지만, Effect를 명시적으로 다시 실행하고 싶지 않은 상황이 있다는 것을 인식했다.

그래서 이 패턴을 위한 1급 프리미티브(first-class primitive), useEffectEvent를 새로 추가할 예정이다.

이 훅이 도입되면, 기존 코드를 보다 깔끔하고 안전하게 리팩터링할 수 있게 된다:

the-latest-ref

export function useHotkeys(hotkeys: Hotkey[]): {
  const onKeyDown = useEffectEvent(() => ...)

  useEffect(() => {
    document.addEventListener('keydown', onKeyDown)

    return () => {
      document.removeEventListener('keydown', onKeyDown)
    }
  }, [])
}

원문: https://marmelab.com/blog/2024/01/23/react-19-new-hooks.html

일반적인 생각과 달리 React core팀은 리액트 서버 컴포넌트와 Next.js에만 오직 초점을 두진 않는다. 새로운 client-side 훅들이 다음 React 메인 버전인 19버전에 도입된다. 그들은 리액트의 두 가지 주요 문제점, 즉 데이터 가져오기(data fetching)과 폼(form)에 초점을 맞추고 있다. 이 훅들은 싱글 페이지 어플리케이션 작업을 하는 개발자를 포함해 React 개발자들의 생산성을 향상시켜줄 것이다.

더 이상 고민하지 말고, 새로운 훅들을 살펴보자!

• use(Promise)
• use(Context)
• Form actions
• useFormState
• useFormStatus
• useOptimistic
• Bonus: Async transitions

주목: 이 훅들은 React의 Canary와 실험적 채널에서만 사용할 수 있다. 이 훅들은 곧 출시될 리액트 19에 포함되지만, API는 최종 출시 전에 변경될 수 있다.

use(Promise)

이 새로운 훅은 클라이언트의 'suspending'을 위한 공식 API이다. 당신은 그것을 promise로 넘길 수 있고 리액트는 그것이 해결될 때까지 그것을 중단시킬 것이다. React use 문서에서 가져온 기본 구문은 다음과 같다.

import { use } from 'react';

function MessageComponent({ messagePromise }) {
    const message = use(messagePromise);
    // ...
}

좋은 소식은 이 훅이 데이터 패칭에 사용될 수 있다는 것이다. 여기 마운트시와 버튼 클릭시 데이터 패칭을 하는 구체적인 예시가 있다. 이 코드는 단일 useEffect를 사용하지 않는다:

<Suspense> 문서의 이 경고를 기억하는가?

프레임워크의 의견 없는 Suspense 지원 데이터 패칭은 아직 지원되지 않는다.

이는 React19에서는 더 이상 사실이 아니다.

새로운 use 훅은 숨겨진 힘이 있다: 다른 모든 React Hook들과 달리, use는 loop와 if와 같은 조건 절에서 호출할 수 있다.

이 말이 즉, 클라이언트 측에서 데이터를 가져오기 위해 TanStack Query와 같은 서드파티 라이브러리를 더 이상 사용할 필요가 없음을 의미할까? TanStack Query가 단순히 Promise를 해결하는 것 이상의 역할을 하기 때문에 더 두고 봐야 한다.

하지만 그것은 올바른 방향으로 나아가는 훌륭한 단계이며 REST 또는 GraphQL API를 기반으로 한 싱글 페이지 어플리케이션을 쉽게 만들 수 있을 것이다. 나는 이 새로운 훅에 매우 열광한다!

React 문서에서 use(Promise) 훅에 대한 자세한 내용을 읽어보아라.

use(Context)

React Context를 읽는데 같은 use 훅을 사용할 수 있다. 루프 안에서 호출할 수 있으며 if와 같은 조건문을 사용할 수 있다는 점을 제외하면 이는 정확히 useContext와 같다.

import { use } from 'react';

function HorizontalRule({ show }) {
    if (show) {
        const theme = use(ThemeContext);
        return <hr className={theme} />;
    }
    return false;
}

루프 혹은 조건절에서 컨텍스트를 읽는 유일한 방법이 컴포넌트를 둘로 나누는 것이기 때문에 이것은 일부 사용 사례에 대한 컴포넌트 계층 구조를 단순화할 것이다.

컨텍스트가 바뀌었더라도 컴포넌트의 리렌더링을 조건적으로 건너뛸 수 있기 때문에 성능 측면에서도 큰 혁명이 될 수 있다.

React 문서에서 use(Context) 훅에 대한 자세한 내용을 읽어보아라.

Form Actions

이 새로운 기능을 사용하면 함수를 <form>의 액션 프롭에 전달할 수 있다. 폼이 제출되면 React는 이 함수를 호출한다:

만약 당신이 <form action> 프롭을 React18에서 추가한다면 당신은 경고(warning)를 받게 될 것을 기억하라:

Warning: Invalid value for prop action on <form> tag. Either remove it from the element or pass a string or number value to keep it in the DOM.

다음과 같은 form을 작성할 수 있는 React 19에서 이 경고는 더 이상 사실이 아니다.

import { useState } from 'react';

const AddToCartForm = ({ id, title, addToCart }) => {
  const formAction = async (formData) => {
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={cart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

accToCart 함수는 서버 Action이 아니다. 이것은 클라이언트 측에서 호출되며 비동기 기능일 수 있다.

이렇게 하면 리액트에서 검색 폼과 같은 AJAX 폼의 처리가 크게 간단해질 것이다. 그러나 이것은 양식 제출(유효성 확인, 사이드 이펙트 등)을 처리하는 것 이상의 일을 하는 React Hook Form과 같은 서드파티 라이브러리를 없앨만큼 충분하지 않을 수 있다. 

Tip: 당신은 위 예제에서 몇몇 사용성 문제를 발견할 수 있다. (submit을 진행할 때 submit 버튼이 활성화되지 않음, 확인 메세지 누락, 늦은 카트 업데이트). 다행히도 더 많은 훅들이 이러한 사용 사례를 돕기 위해 제공되고 있다. 계속 읽어보길!

React 문서에서 the <form action> prop에 대한 자세한 내용을 읽어보아라.

useFormState

이 새로운 훅은 아래 묘사한 것처럼 비동기 폼 액션을 돕는 역할을 한다. useFormState를 호출해 폼이 제출된 마지막 시점부터 액션의 반환 값에 접근한다.

import { useFormState } from 'react-dom';
import { action } from './action';

function MyComponent() {
    const [state, formAction] = useFormState(action, null);
    // ...
    return <form action={formAction}>{/* ... */}</form>;
}

예를 들어, 이것은 당신이 폼 액션에서 반환된 확인 혹은 에러 메세지를 보여주게 한다.

import { useState } from 'react';
import { useFormState } from 'react-dom';

const AddToCartForm = ({ id, title, addToCart }) => {
  const addToCartAction = async (prevState, formData) => {
    try {
      await addToCart(formData, title);
      return 'Added to cart';
    } catch (e) {
      return "Couldn't add to cart: the item is sold out.";
    }
  };

  const [message, formAction] = useFormState(addToCartAction, null);

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>&nbsp;
      {message}
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    if (id === '1') {
      setCart((cart: Item[]) => [...cart, { id, title }]);
    } else {
      throw new Error('Unavailable');
    }

    return { id };
  };

  return (
    <>
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

주목: useFormState는 react가 아니라 react-dom에서 부터 import되어야 한다.

React 문서에서 useFormState에 대한 자세한 내용을 읽어보아라.

useFormStatus

useFormStatus를 사용하면 부모 <form>이 현재 제출 중이거나 성공적으로 제출했는지 알 수 있다. 폼의 자식에서 호출할 수 있으며 다음 속성을 가진 개체를 반환한다:

const { pending, data, method, action } = useFormStatus();

당신은 데이터 속성을 통해 유저가 제출 중인 데이터를 표시할 수 있다. 폼이 제출되는 동안 버튼이 비활성화된 pending 상태 또한 아래 예시와 같이 표시할 수 있다:

import { useState } from 'react';
import { useFormStatus } from 'react-dom';

const AddToCartForm = ({ id, title, addToCart }) => {
  const formAction = async (formData) => {
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <SubmitButton />
    </form>
  );
};

const SubmitButton = () => {
  const { pending } = useFormStatus();
  return (
    <button disabled={pending} type="submit">
      Add to Cart
    </button>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={cart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
      />
    </>
  );
};

주목: useFormStatus는 react가 아닌 react-dom에서 import해야 한다. 또한 부모 폼이 위에서 설명한 action prop을 사용할 때만 작동한다.

이 훅은 useFormState와 함께 불필요한 컨텍스트 효과로 컴포넌트를 어수선하게 만들지 않고 클라이언트 측 폼의 유저 경험을 향상시킬 것이다. useFormStatus 후크에 대한 자세한 내용은 React 문서에서 확인할 수 있다.

useOptimistic

이 새로운 훅은 actioin이 제출되는 동안 사용자 인터페이스를 최적으로 업데이트할 수 있게 한다. 

import { useOptimistic } from 'react';

function AppContainer() {
    const [optimisticState, addOptimistic] = useOptimistic(
        state,
        // updateFn
        (currentState, optimisticValue) => {
            // merge and return new state
            // with optimistic value
        },
    );
}

위 카트 예제에서 우리는 AJAX 호출이 완료되기 전에 새 항목이 추가된 카트를 표시할 수 있다: 

import { useState, useOptimistic } from 'react';

const AddToCartForm = ({ id, title, addToCart, optimisticAddToCart }) => {
  const formAction = async (formData) => {
    optimisticAddToCart({ id, title });
    try {
      await addToCart(formData, title);
    } catch (e) {
      // show error notification
    }
  };

  return (
    <form action={formAction}>
      <h2>{title}</h2>
      <input type="hidden" name="itemID" value={id} />
      <button type="submit">Add to Cart</button>
    </form>
  );
};

type Item = {
  id: string;
  title: string;
};

const Cart = ({ cart }: { cart: Item[] }) => {
  if (cart.length == 0) {
    return null;
  }
  return (
    <>
      Cart content:
      <ul>
        {cart.map((item, index) => (
          <li key={index}>{item.title}</li>
        ))}
      </ul>
      <hr />
    </>
  );
};

export const App = () => {
  const [cart, setCart] = useState<Item[]>([]);

  const [optimisticCart, optimisticAddToCart] = useOptimistic<Item[], Item>(
    cart,
    (state, item) => [...state, item]
  );

  const addToCart = async (formData: FormData, title) => {
    const id = String(formData.get('itemID'));
    // simulate an AJAX call
    await new Promise((resolve) => setTimeout(resolve, 1000));
    setCart((cart: Item[]) => [...cart, { id, title }]);

    return { id };
  };

  return (
    <>
      <Cart cart={optimisticCart} />
      <AddToCartForm
        id="1"
        title="JavaScript: The Definitive Guide"
        addToCart={addToCart}
        optimisticAddToCart={optimisticAddToCart}
      />
      <AddToCartForm
        id="2"
        title="JavaScript: The Good Parts"
        addToCart={addToCart}
        optimisticAddToCart={optimisticAddToCart}
      />
    </>
  );
};

UI를 최적으로 업데이트하는 것은 웹 앱의 유저 경험을 향상시키는 좋은 방법이다. 이 훅은 이 사용 사례에 많은 도움이 된다. useOptimistic에 대한 자세한 내용은 React 문서에서 읽을 수 있다.

보너스: 비동기 전환

React의 Transition API는 UI 차단없이 상태를 업데이트할 수 있게 한다. 예를 들어, 사용자가 마음을 바꿀 경우 이전 상태 변경을 취소할 수 있다.

이 아이디어는 startTransition를 호출해 상태 변화를 감싼다.

function TabContainer() {
    const [isPending, startTransition] = useTransition();
    const [tab, setTab] = useState('about');

    function selectTab(nextTab) {
        // instead of setTab(nextTab), put the state change in a transition
        startTransition(() => {
            setTab(nextTab);
        });
    }
    // ...
}

다음 예는 이 Transition API를 사용한 탭 네비게이션을 보여준다. "Posts"을 클릭한 다음 즉시 "Contact"를 클릭한다. 이로 인해 "Posts"의 느린 렌더링이 중단된다. "Contact" 탭이 즉시 표시된다. 이 상태 업데이트는 트랜지션으로 표시되기 때문에 느린 리렌더(re-render)는 사용자 인터페이스를 통제하지 않는다.

import { useState, useTransition } from 'react';
import TabButton from './TabButton';
import AboutTab from './AboutTab';
import PostsTab from './PostsTab';
import ContactTab from './ContactTab';

export function App() {
  const [isPending, startTransition] = useTransition();
  const [tab, setTab] = useState('about');

  function selectTab(nextTab) {
    startTransition(() => {
      setTab(nextTab);
    });
  }

  return (
    <>
      <TabButton isActive={tab === 'about'} onClick={() => selectTab('about')}>
        About
      </TabButton>
      <TabButton isActive={tab === 'posts'} onClick={() => selectTab('posts')}>
        Posts (slow)
      </TabButton>
      <TabButton
        isActive={tab === 'contact'}
        onClick={() => selectTab('contact')}
      >
        Contact
      </TabButton>
      <hr />
      {tab === 'about' && <AboutTab />}
      {tab === 'posts' && <PostsTab />}
      {tab === 'contact' && <ContactTab />}
    </>
  );
}

React 18.2에서는 Transition 훅을 사용할 수 있다. React 19의 새로운 점은 이제 비동기 기능을 지나 Transition을 시작할 수 있으며, React는 Transition을 시작하기를 기다리고 있다.

이는 AJAX 호출을 통해 데이터를 제출하고 그 결과를 트랜지션으로 렌더링하는 데 유용하다. 트랜지션의 pending 상태는 비동기 데이터 제출과 함께 시작된다. 이는 위에서 설명한 폼 actions 기능에서 이미 사용되고 있다. React가 startTransition으로 감싸진 <form action> 핸들러를 호출하여 현재 페이지를 차단하지 않는다.

이 기능은 아직 React 설명서에 문서화되어 있지 않지만 pull request에서 이 기능에 대한 자세한 내용을 읽을 수 있다.

결론

이러한 모든 기능들은 클라이언트 전용인 리액트 앱에서 작동하며, Vite와 함께 번들된 앱에서 작동한다. 비록 서버 통합형 리액트 앱에서도 이것이 작동하지만 이것을 사용하기 위해 Next 혹은 Remix와 같은 SSR 프레임워크를 사용할 필요는 없다. 

이러한 기능을 통해 리액트에서 데이터 패칭과 폼을 구현하기가 훨씬 쉬워진다. 하지만 훌륭한 유저 경험을 만들려면 이 모든 훅를 통합해야 하는데, 이는 복잡할 수 있다. 또는 최적의 빌트인 업데이트를 지원하는 사용자 친화적인 폼을 가진 react-admin과 같은 프레임워크를 사용할 수 있다.

이 기능들은 왜 React 18.3이 아닌 React 19에 도입되는 것일까? 이 기능들에는 약간의 변경 사항이 포함되어 있기 때문에 18.3 release에는 없을 것으로 보인다.

React 19는 언제 올 것인가 ? 아직 ETA는 없지만 이 게시물에 언급된 모든 기능은 이미 작동하고 있다. 하지만 아직 사용하는 것을 추천하고 싶지는 않다. (Next.js가 그렇게 한다고 해도) canary release를 프로덕트에 사용하는 것은 좋은 생각이 아니다.

리액트 코어 팀이 SSR 앱에서 일하는 사람들뿐만 아니라 모든 리액트 개발자들의 개발자 경험을 개선하기 위해 노력하고 있다는 것은 정말 기쁜 일이다. 또한 그들은 커뮤니티 피드백에 귀를 기울이고 있는 것 같다 - 데이터 패칭 및 폼 핸들링은 매우 흔한 문제이다.

나는 React의 Stable 릴리즈에 이 기능들이 보이길 기대한다!

🏄‍♀️ input 태그로 파일을 업로드하거나 파일의 url을 가지고 있을 경우 파일의 확장자를 제대로 알 수 있는 방법에 대해 알아보자.

How to: 파일 업로드 후 e.target.files의 name을 활용

<input type="file" id="avatar" name="avatar" accept="*" />

위 파일 객체는 input태그를 통해 파일을 업로드 한 후 얻게 되는 값이다.

그 중 name값에는 파일의 이름이 존재하는데 이를 활용해 확장자 값을 구할 수 있다.

<input
    type="file"
    id="upload"
    onChange={(e) => {
      const files = e.target.files;
      const filename = files[0].name;
      const splitedNameArr = filename.split('.');
      const lastSplitedVal = splitedNameArr.at(-1);

      console.log(lastSplitedVal);
    }}
  />

파일 name에서 split을 통해 . 을 기준으로 나눈 뒤 마지막 . 뒤의 값을 확장자로 인식하는 방법을 활용했다.

이렇게 하면 파일 이름 사이에 . 이 존재하더라도 가장 마지막 . 뒤 값을 확장자로 볼 수 있다.

* Array.prototype.at() 기능이 너무 맘에 들어 링크 남긴다!

https://developer.mozilla.org/ko/docs/Web/JavaScript/Reference/Global_Objects/Array/at