🔨 refactor: 온보딩 페이지 상태관리 리팩토링 #96

bbearcookie · 2024-02-11T17:18:23Z

🧩 이슈 번호

close 온보딩 페이지 상태관리 리팩토링 #95

✅ 작업 사항

실행 화면

GOMCAM.20240212_0132560725.mp4

https://dnd-10th-4-frontend-ne5k21wv6-bbearcookie.vercel.app/onboarding Preview 주소에서 실행 확인 가능합니다!

#64 에서 작업했던 기존 온보딩 페이지의 폼 상태는 각 스텝에서 지역 상태로 다뤄지고, 다음 스텝으로 넘어가기 전에 각각 API 호출이 발생하고 있었는데요. API 호출이 방식이 마지막 완료 스텝에서 한 번만 일어나도록 명세가 변경될 예정이기에 스텝간의 폼 데이터의 상태 공유가 필요해졌어요.

그래서 react-hook-form 으로 폼 데이터를 관리하고, 상위의 FormProvider 에서 뿌려주는 방식으로 변경했어요.

추가로, 마이 페이지에서도 온보딩 페이지와 동일한 로직이 존재하는데요. (성별 변경, 생년월일 변경 등), 그래서 온보딩 페이지의 컴포넌트와 결합되어 있는 로직을 분리할 필요성을 느꼈어요. 사실 처음 작성할 땐 이런 로직이 비즈니스 로직이라고 생각했었는데, 도메인 맥락을 제거하다보니 생각보다 유틸성에 가까울 수 있겠다는 생각이 들었어요. 그래서 도메인 맥락을 최대한 제거해서 재활용 가능한 유틸 함수로 분리했어요.

마이 페이지 설계 화면

주로 상태 관리 및 상태 공유에 대한 고민이 들었는데.. @seokzin 님! 혹시 코드리뷰를 요청드려도 괜찮을까요??

👩‍💻 궁금 사항

react-hook-form vs zustand

스텝 간 폼 상태를 공유해야 하는데.. 현업에서 이런 상황에 보통 어떤 방식을 채택하실지 궁금해요.

저는 각 스텝에서 지역적으로 다뤄지던 폼 관련 상태를 어떻게 전역적으로 관리할 것인지를 고민했는데요.. 생각해 본 결과 2가지로 추려볼 수 있었어요.

상위 컴포넌트에서 react-hook-form을 Provider로 뿌리는 방법 (상위 컴포넌트에 상태를 위임)
Zustand같은 외부 스토어를 사용하는 방법 (리액트 바깥 영역으로 상태를 위임)

각각을 선택했을 때 장단점은 다음과 같다고 생각했는데요:

react-hook-form

장점: 폼을 다루는 데 필요한 기본적인 로직을 작성하지 않아도 되고, 폼 데이터에 대한 유효성 검사를 손쉽게 할 수 있음. (zod와 같은 유효성 검증 라이브러리와의 간편한 결합)
단점: FormProvider로 하위 트리에 공유하는 형태로 작성해야 하는데, selector의 개념이 없다 보니 watch로 상태를 구독하는 컴포넌트가 있다면 그 값이 변경될 때 FormProvider 하위의 모든 컴포넌트가 리렌더링 됨.

zustand

장점: persist 미들웨어로 브라우저 스토리지를 손쉽게 활용할 수 있음. (새로고침시 상태 유지) 또한 상태를 구독하고 있는 컴포넌트만 리렌더링하도록 할 수 있음. (selector)
단점: 화면에 유효성 검사 메시지를 보여줘야 하는 요구사항이 발생할 가능성을 염두 한다면, 폼 로직을 스토어에 직접 구현해야 하는 형태가 됨.

결국에는 react-hook-form 을 사용하는 방향으로 구현하게 되었는데, 사실 HTML의 전통적인 input이 아닌 요소도 존재해서 setValue로 imperative하게 값을 변경해야 하긴 하지만, 주 관심사가 사용자의 입력을 받는 폼에 가깝다는 생각 때문이었어요. (사용자 입력에 대한 유효성 검사 등 새로운 요구사항이 들어와도 빠르게 대응할 수 있다고 생각해서?)

그런데.. 괜찮은 접근이었을지? 더 좋은 방법은 없었을지? 궁금해요

Compound 패턴

const Page = () => {
  return (
    <Tabs.Root>
      <Tabs.Item>아이템 1은 Tabs.Root의 상태를 사용할 수 있어요</Tabs.Item>
      <Tabs.Item>아이템 2는 Tabs.Root의 상태를 사용할 수 있어요</Tabs.Item>
    </Tabs.Root>
  );
}

Tabs 컴포넌트같이, 재활용되기 좋은 컴포넌트를 Headless UI로 구성한다고 할 때 상태를 캡슐화해서 외부로 들어내지 않으면서도 하위 컴포넌트가 이를 받아서 활용할 수 있도록 Context API로 의존성 주입을 해주는 방식이 자주 사용된다고 들었는데요!

이 경우에도 Tabs.Root 컴포넌트에서 주입한 value 중에서 하나라도 변경되면 모든 하위 트리가 리렌더링되기 때문에.. 렌더링 최적화를 어떤 방식으로 하면 좋을지? 궁금해요!

(Tabs.Root 컴포넌트를 선언하는 곳마다 새로운 상태를 갖고 하위 자식들에게 뿌려줘야 하기 때문에 zustand같은 전역 스토어를 하나만 생성하는 방식으로는 어려울 것 같고.. Tabs.Root가 상태를 갖는 방식으로 구현해야 할 것 같은데.. 혹시 https://docs.pmnd.rs/zustand/guides/initialize-state-with-props 이런 방식으로 selector를 지원하는 외부 스토어를 ref로 담아서 뿌리는 방식도 주로 사용될까요..? 사용해보니 보일러 플레이트가 커지는 느낌도 받았었어서..)

마무리

결론적으로는.. 전역 상태 관리 라이브러리를 어떻게 사용하는 것이 잘 활용하는 것일지 궁금해요.
API 통신으로 가져온 데이터에는 TanStack Query를, 폼 데이터에 대해서는 react-hook-form을, Compound 패턴에서 의존성 주입에는 Context API 를 사용하다보니.. 늘 클라이언트 사이드 상태 관리 도구를 활용해보자 싶어도 잘 못했었거든요.. 😂

또한, 동일한 데이터를 가리키는 상태를 여러 곳에 분산해서 관리하는 방식은 어떨지..? 궁금해요.
(ex. 로그인한 사용자 정보가 TanStack Query에 의해 관리되고 있는데, 이 걸 Zustand와 같은 다른 스토어에 추가 관리하는 방법)

이런 방식이 single source of truth에 위배되는 걸지, 아니면 나름대로 편하게 사용할 수 있는 예시가 있을지 궁금해요!!

This reverts commit d441d7d.

github-actions · 2024-02-11T17:20:24Z

🚀 Storybook Preview 보러가기: https://65a6c73d536a3c43b7c5c9bb-saqtcazota.chromatic.com/
🚀 React Preview 보러가기: https://dnd-10th-4-frontend-kni5td9nf-bbearcookie.vercel.app

bbearcookie · 2024-02-11T17:25:24Z

src/pages/OnboardingPage/hooks/useOnboardingForm.ts

+        year: '' as unknown as number,
+        month: '' as unknown as number,
+        day: '' as unknown as number,


이 부분은 react-hook-form을 제어 컴포넌트 방식으로 사용할 경우에는 반드시 defaultValue가 들어가야 해서 작성한 부분인데요,
submit 동작에서의 유효성 검사 로직은 zod 스키마대로 동작하고 싶은데, 사용자가 Input을 봤을 때 기본 값은 비어있도록 하고 싶어서 작성한 부분입니다.. (타입이 원래 number여야 하는데, 0으로 하면 Input에 기본 값 0이 들어가 있는 문제)

이 부분에서 드는 고민이 defaultValue 값의 타입은 zod 스키마와는 다르게 하고 싶은데 방법이 있을지? 고민되었어요

P3

그런 고민이라면 타입 단언을 활용하지 않는 조금 더 좋은 해결책이 있겠네요.
특히 as unknown은 TS를 사용할 때도 raw 데이터의 타입 파악이 어려울 때 정말 최후의 수단으로 사용하는 그런 테크닉이니까요.

상훈님이 가진 동일한 상황에 대해 discussion이 있는데

useForm<{ price: number | string }, void, { price: number }>

~~제네릭~~ 유니온을 활용하고 3번째 인자를 통해 submit되는 값을 변형하는 아이디어도 좋다고 생각이 들어요.
저는 직접 트라이 하진 못했지만 이거 한번 참고해보세요!

헉.. 제네릭 인자를 전달하는 방법이 있었군요.. 디스커션 링크까지.. 감사합니다!!

앗ㅎㅎ 쏘리쏘리,, 저 솔루션은 제네릭 말고 유니온 타입 얘기였네요~~

bbearcookie · 2024-02-11T17:29:22Z

src/pages/OnboardingPage/steps/InputBirthdayStep.tsx

+              onChange={async (e) => {
+                e.target.value = clampValue(
+                  e.target.value,
+                  formLiteral.year.max,
+                );
+                field.onChange(e);
+                trigger('birthday.year');
+              }}


RHF의 onChange 콜백이 동작하기 전에 미리 intercept 동작을 부여하기 위해서(Input에서 숫자만 필터링하는 로직) Controller로 제어 컴포넌트 방식을 사용했습니다.

as unknwon as 를 사용한 default value 로직이 해결된다면 이 부분도 추후에 개선될 수 있겠네요!

seokzin

잘 봤습니다!
리뷰 요청 주셔서 감사해요.

코멘트 달면서도 명쾌한 답변이 아닌 것 같아 개인적인 아쉬움이 있는데
의견을 가볍게 참고만 해주세요 ㅎㅎ 제가 반드시 옳지는 않아요!!
궁금한 점이 있다면 재댓글이나 슬랙으로 편하게 질문 주세요~!

seokzin · 2024-02-12T05:13:21Z

src/pages/OnboardingPage/hooks/useOnboardingForm.ts

결국에는 react-hook-form 을 사용하는 방향으로 구현하게 되었는데, 사실 HTML의 전통적인 input이 아닌 요소도 존재해서 setValue로 imperative하게 값을 변경해야 하긴 하지만, 주 관심사가 사용자의 입력을 받는 폼에 가깝다는 생각 때문이었어요. (사용자 입력에 대한 유효성 검사 등 새로운 요구사항이 들어와도 빠르게 대응할 수 있다고 생각해서?)

네 zustand를 사용하는 방법은 초기 상태를 개선한 해결책이 될 수 있지만
지금처럼 form만을 제어하는 현재의 환경에서는 react-hook-form이 더 적합하네요.
(= hook form을 기반으로 리렌더링을 최적화를 고민하는 방향이 더 적합하다)
그래서 react-hook-form으로 최종 결정한 것은 좋은 선택이에요

다만 input이 아닌 요소도 존재가 정확히 어떤 케이스일까 궁금해지는데
현재의 디자인 가이드로 봤을 떄는
제공되는 UI만 다를 뿐, radio, checkbox의 개념은 가지고 있기 때문에
디자인시스템 상에서 충분히 'input 태그'를 중심으로 구현할 수 있겠다는 생각은 들었어요!

그렇다면, react-hook-form의 렌더링 최적화가 관건인데,
지금 상훈님이 직면한 이슈는 react-hook-form을 도입하는 개발자들이 한번쯤은 겪었을 보편적 이슈로 보여서 충분히 솔루션이 많겠다는 생각은 들었어요!

혹시 useWatch를 사용하여 트러블 슈팅 해보셨을까요?
watch의 전체 렌더링 단점을 보완한 API 인데 참고로 저는 실제 사용 경험이 없어서 확답으로는 못 드린다는 점 😭

Tabs -> compound 패턴

이 경우에도 Tabs.Root 컴포넌트에서 주입한 value 중에서 하나라도 변경되면 모든 하위 트리가 리렌더링되기 때문에.. 렌더링 최적화를 어떤 방식으로 하면 좋을지? 궁금해요!

Tabs 같이 atomic 보다는 molecule에 가까운 복잡한 컴포넌트는 상훈님 말씀대로 Context API를 통해 state를 component scope로 사용하는 것이 좋은 테크닉이죠!

다만 'value 중에서 하나라도 변경되면 모든 하위 트리가 리렌더링되기 때문에' 라는 이슈가 자세히 궁금해져요.

보편적인 Tabs라면 최초 렌더링된 Tab label은 불변할 것이고,
Tab을 변경했을 때 content가 리렌더링 되는 것은 불가피한 렌더링일텐데
그 외에 렌더링 최적화를 한다면 어느 부분이 있을까요?

Tabs.Root 컴포넌트를 선언하는 곳마다 새로운 상태를 갖고 하위 자식들에게 뿌려줘야 하기 때문에 zustand같은 전역 스토어를 하나만 생성하는 방식으로는 어려울 것 같고.. 이런 방식으로 selector를 지원하는 외부 스토어를 ref로 담아서 뿌리는 방식도 주로 사용될까요..?

복잡한 서비스에선 Tabs를 루트에서 조건부 렌더링 하면
오히려 조건 처리하는 것이 불편하고 사이드 이펙트가 크게 돼요.
그래서 저는 개별 페이지 단에서 Tabs를 매번 import 하는 방식을 선택했어서, store에 대한 니즈는 다행히 없었어요.
(저는 루트에서 관리하는 Toast, Popup, Header 등에서 store를 사용하고 있죠!)

혹시 현재 서비스는 Tabs를 Root에서 취급하나요? 그렇다면 전역 store에 대한 니즈가 있을 것이고, 저는 이런 ui를 위한 store를 과감히 만들어요. (어차피 store들을 단일 책임에 맞게 나누면 파일은 커질 수 밖에 없지만, 이를 폴더 구조로 잘 정리한다면 사용에 불편함은 크게 없으므로)

+) 다만 저는 root 단에서 ui store를 사용했기 때문에 provider의 니즈까지는 없었어요!
ref & provider를 사용하는 것은 한 단계 더 고민이 되겠지만, 제가 생각하는 디자인시스템의 Tabs는 store가 불필요한 설계 방식이 더 보편적이라 생각해서, 이 부분에 대해 큰 고민을 안 해봤던 것 같아요.

마무리

전역 상태 관리 라이브러리를 어떻게 사용하는 것이 잘 활용하는 것일지 궁금해요

전역 상태는 '여러 해결책을 고민한 뒤 그럼에도 불가피할 때 도입'한다면 대부분은 좋은 결정이더라구요.
(개인적으로 prop drilling을 지양하는 성향이 있어서, 웬만하면 store나 context를 사용하는 편!)

서버 관련 로직은 Tanstack query를 통해 철저히 원격으로 상태 관리하는 것은 요즘 트렌드에 적합해요.

form 관련 데이터는 react-hook-form + provider를 사용한 것 또한 react-hook-form의 자체 기능을 활용하기 용이하고, 전역 상태관리의 단점을 보완할 수 있으므로 좋은 선택이에요.

Compound UI에서 context 사용 또한 적합해요. UI에 전역 상태를 도입하지 않으면, 상태 의존성이 없어져 디자인시스템의 재사용성을 극대화 할 수 있거든요.

결론적으로 전역 상태관리를 도입하는 대부분의 고민은 비즈니스 로직을 개발하면서 많이 하게 되죠. 위 케이스들처럼 특정 scope(form, ui)에서의 상태 관리나, 서버와의 상태 관리는 상훈님의 생각이 더 적합하므로 추후 서비스 고도화 하면서 전역 상태들 만들면 될 것 같아요.

디자인시스템 상에서 충분히 'input 태그'를 중심으로 구현

앗.. UI가 달라서 Input이라는 생각을 못했었는데
동작의 관점에서 충분히 input의 radio, checkbox로도 구현이 가능하겠군요 😂

useWatch를 사용하여 트러블 슈팅

useWatch와 watch의 차이점이 단순히 control 객체를 인자로 받는지의 차이인줄 알았는데..
렌더링 최적화라는 중요한 포인트에서 차이가 있었군요!! 테스트 해보니 잘 되는 것 같습니다 감사합니다!!

Tab을 변경했을 때 content가 리렌더링 되는 것은 불가피한 렌더링

아하.. Tab이 변경되면 Tabs의 Content가 리렌더링 되는 것이 맞기 때문에 최적화를 고려해볼 수 있는 부분이 없겠군요!!
사실 예시와 유사한 상황이 Funnel 스텝을 조작하는 핸들러 (toNext, toPrev) 를 하위 트리에 공유하고 싶었을 때 였는데요..

당시 결론은 사실 핸들러 함수의 값이 최초 마운트 시점 이후에는 변경되지 않기도 하고, Provider가 감싸고 있는 스텝 영역이 변화가 일어나면 어차피 다른 스텝을 보여 줘야 하는 등 Content가 리렌더링 되는 것이 맞기 때문에 상위 컴포넌트의 Provider에서 Context API로 뿌려주는 방식을 선택했었는데, 이 과정에 렌더링 최적화가 필요하려나 싶은 생각에 막연하게 떠오른 고민이었습니다 😂

(지금은 핸들러만 공유하고 있기에 문제될 부분은 없지만.. 만약 Compound Pattern에서 값이 자주 변경되는 state를 Provider에서 뿌려준다면 렌더링 최적화가 필요한 경우에는 어떻게 해결할까? 하는 고민)

원래 상태 관리 및 렌더링 최적화에 대해서 막연한 고민으로만 가지고 있었는데, 오늘 리뷰 해주신 덕분에 렌더링 최적화가 정말 필요한 부분일지, 혹은 상태가 특정 scope를 가져야 하는지 혹은 앱 전체에서 하나만 존재해도 되는지 등을 먼저 생각해보는 것도 좋겠다는 생각이 들었어요!! 감사합니다!

Compound, Composition

제가 Compound 패턴과, Composition 컴포넌트의 정의에서 헷갈리는 부분이 있는데요.. 😂
Compound 패턴이 Composition 컴포넌트를 활용하면서도 상태를 하위 트리에 공유하는 더 좁은 집합의 개념으로 이해하는 것이 맞을까요??
(Compound 패턴을 구현하기 위해서는 Composition 컴포넌트를 사용?)

@bbearcookie

compound, composition

저도 작성하고 보니까 제가 정의하는 두 단어의 개념이 상훈님과 다른 것을 인지했어요.
이거 짚어주셔서 넘 감사해요~!

"Tabs 컴포넌트같이, 재활용되기 좋은 컴포넌트를 Headless UI로 구성한다고 할 때 상태를 캡슐화해서 외부로 들어내지 않으면서도 하위 컴포넌트가 이를 받아서 활용할 수 있도록 Context API로 의존성 주입을 해주는 방식이 자주 사용된다고 들었는데요!"

여기서 '아하~ 컴포넌트 디자인 패턴인 compound pattern을 context API를 통해 설계' 한다는 말이구나
라고 생각 했었고

const Page = () => { return ( <Tabs.Root> <Tabs.Item>아이템 1은 Tabs.Root의 상태를 사용할 수 있어요</Tabs.Item> <Tabs.Item>아이템 2는 Tabs.Root의 상태를 사용할 수 있어요</Tabs.Item> </Tabs.Root> ); }

다음으로 수도 코드로? 보이는 이 예시를 보았을 땐
'Tabs는 하위 컴포넌트들을 조립해서 다양한 케이스를 정의해야 할 니즈가 있는 UI가 아닌 것 같아
compound pattern + Context API를 사용하기에는 적합하지 않겠군" 이라고 생각했네요

composition은 디자인 패턴보다는 '컴포넌트를 합성한다'는 더 포괄적인 의미에 가까워서
사실 children으로 ReactNode를 받는 것이나 compound pattern 등은 넓게 보면 다 composition이 아닐까 생각이 들어요.

정리하자면 제 의도는

"Tabs는 Context API를 활용한 compound pattern으로 구현하기에는 잘 어울리는 UI는 아닐 것으로 보여, 단순히 property를 통해 component composition 하여도 괜찮겠다" 라는 의미었습니다ㅎㅎ

Compound 패턴이 Composition 컴포넌트를 활용하면서도 상태를 하위 트리에 공유하는 더 좁은 집합의 개념

타당하죠!

다만 집합으로 비유한기엔 둘의 성격이 다를 수 있다 생각해서
compound pattern은 컴포넌트 디자인 패턴에 가깝고
composition은 넓은 의미의 '컴포넌트를 합성한다'라는 하나의 방법론으로 구분하는 것도 좋아보여요~!

아하!! 완벽히 이해했습니다 😁

compound pattern은 디자인 패턴의 일종이고, composition은 그보다 훨씬 포괄적인 의미의 방법론 중 하나인 것이군요!!

Tabs의 예시의 경우에는 확실히 하위 컴포넌트를 조합해서 상태를 공유해야 할 케이스가 다양하지 않기에 compound 패턴을 적용하기에는 적합하지 않겠네요..

평소에 혼동되던 개념이었는데.. 상세하게 정리해주신 덕분에 명확하게 이해가 되었어요! 정말 너무너무 감사드립니다!! 😊👍👍

seokzin · 2024-02-12T06:06:10Z

src/pages/OnboardingPage/hooks/useOnboardingForm.ts

+        year: '' as unknown as number,
+        month: '' as unknown as number,
+        day: '' as unknown as number,


P3

그런 고민이라면 타입 단언을 활용하지 않는 조금 더 좋은 해결책이 있겠네요.
특히 as unknown은 TS를 사용할 때도 raw 데이터의 타입 파악이 어려울 때 정말 최후의 수단으로 사용하는 그런 테크닉이니까요.

상훈님이 가진 동일한 상황에 대해 discussion이 있는데

useForm<{ price: number | string }, void, { price: number }>

~~제네릭~~ 유니온을 활용하고 3번째 인자를 통해 submit되는 값을 변형하는 아이디어도 좋다고 생각이 들어요.
저는 직접 트라이 하진 못했지만 이거 한번 참고해보세요!

seokzin · 2024-02-12T06:07:51Z

src/pages/OnboardingPage/steps/InputBirthdayStep.tsx

+              onChange={async (e) => {
+                e.target.value = clampValue(
+                  e.target.value,
+                  formLiteral.year.max,
+                );
+                field.onChange(e);
+                trigger('birthday.year');
+              }}


as unknwon as 를 사용한 default value 로직이 해결된다면 이 부분도 추후에 개선될 수 있겠네요!

seokzin · 2024-02-12T06:10:10Z

src/utils/arrayUtils.ts

순수한 함수들이 util로 잘 분리되었고
테스트 코드도 잘 갖춰져 있어서
이런 부분의 리팩터링은 참 의미 있네요 👍

easyhyun00 · 2024-02-12T06:38:36Z

seokzin 님이 너무 좋은 리뷰를 남겨주셨네요..! 감사합니다 👍 보면서 저도 많이 알아가고 배워갑니다!

bbearcookie added 13 commits February 11, 2024 21:44

✨ feat: useOnboardingForm 훅 작성

7cbd0d5

📝 style: ChipVariant 로 타입 이름 변경

d441d7d

✨ feat: userUtil 작성

4ea5cb0

🔨 refactor: 닉네임 변경에 훅폼 적용

27b9977

🔨 refactor: 생년월일 변경에 컨텍스트 훅폼 적용

42b3565

🔨 refactor: 성별 선택에 훅폼 적용

45b6938

🔨 refactor: 고민 선택에 훅폼 적용

4484234

🔨 refactor: 온보딩 페이지 컴포넌트에 훅폼 적용

58b60a1

🔨 refactor: 유틸 함수에서 도메인 맥락 제거

d93368f

✅ test: 유틸 함수 테스트 코드 작성

7e74576

📦 chore: 페이지 이동 및 임시 alert 출력

7abea95

Revert "📝 style: ChipVariant 로 타입 이름 변경"

70f2a78

This reverts commit d441d7d.

🚑 fix: MusicButton type을 button으로 변경

354c1a0

bbearcookie added the 🔨 Refactor 리팩토링 작업 label Feb 11, 2024

bbearcookie self-assigned this Feb 11, 2024

bbearcookie requested a review from easyhyun00 as a code owner February 11, 2024 17:18

bbearcookie commented Feb 11, 2024

View reviewed changes

seokzin reviewed Feb 12, 2024

View reviewed changes

bbearcookie added 3 commits February 12, 2024 19:49

🔨 refactor: initialSchema 타입 지정

69b8a22

🔨 refactor: useWatch 적용

8536627

🔨 refactor: GenderCard를 input radio 태그로 리팩토링

2c0d8be

easyhyun00 approved these changes Feb 13, 2024

View reviewed changes

Merge branch 'main' into refactor/#95/onboarding-state

90f54bf

bbearcookie merged commit 3de2f48 into main Feb 13, 2024
7 checks passed

bbearcookie deleted the refactor/#95/onboarding-state branch February 13, 2024 10:11

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

🔨 refactor: 온보딩 페이지 상태관리 리팩토링 #96

🔨 refactor: 온보딩 페이지 상태관리 리팩토링 #96

bbearcookie commented Feb 11, 2024 •

edited

Loading

github-actions bot commented Feb 11, 2024 •

edited

Loading

bbearcookie Feb 11, 2024

seokzin Feb 12, 2024 •

edited

Loading

bbearcookie Feb 12, 2024

seokzin Feb 12, 2024 •

edited

Loading

bbearcookie Feb 11, 2024

seokzin Feb 12, 2024

seokzin left a comment •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

bbearcookie Feb 12, 2024 •

edited

Loading

bbearcookie Feb 12, 2024

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

bbearcookie Feb 12, 2024

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024

seokzin Feb 12, 2024

easyhyun00 commented Feb 12, 2024

🔨 refactor: 온보딩 페이지 상태관리 리팩토링 #96

🔨 refactor: 온보딩 페이지 상태관리 리팩토링 #96

Conversation

bbearcookie commented Feb 11, 2024 • edited Loading

🧩 이슈 번호

✅ 작업 사항

실행 화면

마이 페이지 설계 화면

👩‍💻 궁금 사항

react-hook-form vs zustand

Compound 패턴

마무리

github-actions bot commented Feb 11, 2024 • edited Loading

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seokzin left a comment • edited Loading

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Tabs -> compound 패턴

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

마무리

bbearcookie Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

디자인시스템 상에서 충분히 'input 태그'를 중심으로 구현

useWatch를 사용하여 트러블 슈팅

Tab을 변경했을 때 content가 리렌더링 되는 것은 불가피한 렌더링

Choose a reason for hiding this comment

Compound, Composition

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

compound, composition

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

seokzin Feb 12, 2024 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

easyhyun00 commented Feb 12, 2024

bbearcookie commented Feb 11, 2024 •

edited

Loading

github-actions bot commented Feb 11, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin left a comment •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

bbearcookie Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading

seokzin Feb 12, 2024 •

edited

Loading