Feature/#67: 로그인 폼 이메일 기억하기 추가 by SwimmingRiver · Pull Request #186 · we-write/frontend

SwimmingRiver · 2025-06-30T08:36:07Z

변경 사항

이메일 기억하기 체크 후 로그인 완료시 로컬 스토리지에 해당 이메일을 저장합니다.
로그아웃후에 저장된 이메일이 있다면 입력 필드에 자동으로 추가됩니다.

구현결과(사진첨부 선택)

(내용)

netlify · 2025-06-30T08:36:15Z

✅ Deploy Preview for we-write ready!

Name	Link
🔨 Latest commit	`3f4c013`
🔍 Latest deploy log	https://app.netlify.com/projects/we-write/deploys/68654bb6b812330008e22af2
😎 Deploy Preview	https://deploy-preview-186--we-write.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify project configuration.

juyesu

수고하셨습니다~! 매번 새로 로그인해야되서 필요하다고 느낀 기능이었는데 추가되서 좋네요!
리뷰들 가볍게 한번씩만 확인해주시면 감사하겠습니다~!

juyesu · 2025-06-30T12:02:20Z

src/api/auth/type.ts

+export interface SigninFormData extends SigninRequest {
+  rememberEmail: boolean;
+}


로그인 폼 데이터 타입과 로그인 리케스트 타입이 있을 때
어떤 타입을 기준으로 종속, 의존관계를 설정하는게 좋을지 고민되게 하는 부분이 있네요

리퀘스트 타입을 확장해서 폼 데이터 타입을 사용 (현재 방식)

폼 데이터 타입을 선언하고, 해당 타입을 Omit, Pick 등으로 의존해서 리퀘스트 타입 사용

중복을 감수하고, 두 타입을 의존 관계없이 별개의 타입으로 선언

혹시 이 타입을 생성하면서 고민하신게 있거나 하면 공유해주시면 감사할 것 같습니다!
(특별히 고민하지 않으셨다면 그대로 말씀해주셔도 됩니다!)

기존 코드 변경없이 중복을 피하고싶어서 현재같은 구조로 만들었는데 더 좋은 방법이 있을까요?

더 좋은 방법이 있다기 보다는 이러한 중복 타입 선언이 발생하는 상황을 대처할 때
제가 적은 것처럼 여러가지 방법이 있을 것 같은데 혹시 여러가지 방법 중에 고민을 해서 한 가지 방법을 선택하신 것인지?
질문드린거였습니다! 현재의 SigninFormData extends SigninRequest 구조는 좋다고 생각해요!

juyesu · 2025-06-30T12:08:29Z

src/app/auths/signin/_components/SignInForm.tsx

+  useEffect(() => {
+    const email = localStorage.getItem('rememberEmail');
+    if (email) {
+      setValue('email', email);
+      setValue('rememberEmail', true);
+    }
+  }, [setValue]);


const email = localStorage.getItem('rememberEmail') ?? ''; const rememberEmail = !!email; const { register } = useForm({ defaultValues: { email, rememberEmail, }, });

useEffect를 사용하지 않고 defaultValues를 사용하는 방법도 있을 것 같아요
어떤 방식이 더 낫다보다는 각각의 장점과 단점이 있을 것 같습니다.
저도 궁금해서 사소한거지만 차이점?같은거 정리해봐도 좋을 것 같네요!

useEffect가 부수적인 영향이 발생할 수 있어서 사용을 자제하는 게 좋다는 피드백을 받은 적이 있어서
말씀해주신 방법이 더 좋을 것 같네요 👍
정확한 비교는 좀 더 조사해봐야할 것 같습니다

juyesu · 2025-06-30T12:16:44Z

src/app/auths/signin/_components/SignInForm.tsx

+      <div className="flex items-center gap-2">
+        <input
+          type="checkbox"
+          aria-label="이메일 기억하기"
+          className="h-4 w-4"
+          {...register('rememberEmail')}
+        />
+        <span className="text-sm">이메일 기억하기</span>
+      </div>


아이디 기억하기 체크박스 위치가 비밀번호 인풋 아래에 있는게 UI 흐름상 더 자연스러운 것 같아요!

<span>대신에 <label htmlFor=''> 사용하면 시맨틱 구조와 접근성 측면에서 이점이 있을 것 같습니다. (<label>을 사용하게 될 경우 aria-label은 사용하지 않아도 될 것 같습니다)

위치는 말씀하신대로 수정했습니다.

말씀하신 부분 이렇게 수정하는게 맞을까요?

<div className="flex items-center gap-2"> <input type="checkbox" aria-label="이메일 기억하기" className="h-4 w-4" {...register('rememberEmail')} /> <label htmlFor="rememberEmail" className="text-sm"> 이메일 기억하기 </label> </div>

네 적어주신 코드가 거의 맞는데 <label>의 htmlFor은 같은 이름으로 매칭되는 <input>의 id가 존재해야 합니다.
따라서 <input>에 id속성만 추가해주시면 될 것 같습니다.
그리고 label태그가 시맨틱하게 input에 대한 설명을 제공하므로 aria-label 속성은 제거하는 것이 일반적입니다.

<div className="flex items-center gap-2"> <input id="rememberEmail" type="checkbox" className="h-4 w-4" {...register('rememberEmail')} /> <label htmlFor="rememberEmail" className="text-sm"> 이메일 기억하기 </label> </div>

juyesu · 2025-06-30T12:26:35Z

src/hooks/api/auth/useSignInForm.ts

+    if (data.rememberEmail) {
+      localStorage.setItem('rememberEmail', data.email);
+    } else {
+      localStorage.removeItem('rememberEmail');
+    }


react hook form의 rememberEmail필드는 체크박스 선택 유무에 따라 달라지는 boolean타입인데,
localStorage에는 rememberEmail에 이메일 자체가 string타입으로 담기다보니 네이밍이 헷갈리는 부분이 있는 것 같아요

juyesu · 2025-06-30T12:31:06Z

src/hooks/api/auth/useSignInForm.ts

+            setError('email', { type: 'manual', message: errorData.message });
+          }
+          if (errorData.code === 'INVALID_CREDENTIALS') {
+            setError('password', {
+              type: 'manual',
+              message: errorData.message,
+            });


react hook form의 setError은 사용해본적이 없는데 setError하면 register내부에 유효성 검사에 걸린 것과 마찬가지로
폼 에러 메시지가 출력되나요? (errorData.message가 어떤식으로 출력되는지 텍스트나 스크린샷 첨부해주시면 감사할 것 같습니다!)

단순 입력 규격에 관한 유효성 검사이외에 서버 요청에 반환되는 에러를 필드에 보여주려고 setError 썼습니다!

오호 그렇군요 스크린샷 감사합니다! 지금은 서버에서 반환되는 메시지가 한글인데 나중에 Supabase 인증으로 변경되면
영어로 된 메시지가 출력될까요? 서버에서 한글 메시지를 반환하도록 변경하거나, 반환하는 메시지를 우리가 커스텀할 수 있는 지 확인해보면 좋을 것 같네요!

hoxey2Front

label을 아이디로 하고, 아이디 기억하기로 명칭을 사용해도 괜찮을 거 같아요.
보통은 아이디, 비밀번호를 입력해서 로그인하기 때문에 UX상 더 적합할 거 같아요!

juyesu · 2025-07-03T12:37:57Z

@hoxey2Front
언제였는지 정확히는 모르겠는데 제가 기억하기로는 실제로 입력되는 값은 이메일인데 레이블은 '아이디'라서 혼동을 줄 수 있다는
피드백이 있었던 것 같아요
지금처럼 반드시 이메일만 입력 가능한 상황에서 레이블이 '아이디'로만 적혀있으면 확실히 헷갈릴 수 있을 것 같습니다.
만약 레이블을 '아이디'로 하는게 좋다면 회원가입 시에 '이메일'과 '아이디' 입력란을 분리하거나,
'아이디' input에 이메일만 입력가능하다는 것을 알릴 수 있는 placeholder 또는 helper message 등이 필요할 것 같아요

SwimmingRiver added 3 commits June 29, 2025 23:32

feat: 이메일 로컬 저장소에 저장하기

b0f6303

feat: 저장된 이메일 불러오기

6182ea2

feat: 테스트 코드 추가

e9301c3

SwimmingRiver requested review from hoxey2Front and juyesu June 30, 2025 08:36

SwimmingRiver self-assigned this Jun 30, 2025

juyesu reviewed Jun 30, 2025

View reviewed changes

hoxey2Front requested changes Jul 2, 2025

View reviewed changes

SwimmingRiver added 2 commits July 2, 2025 23:58

feat: useEffect 대체 defaultValues 설정

81fbf0c

refactor: remeberEmail 폼 내부에서 isRememberEmail 로 변수명 변경

3f4c013

juyesu added the LGTM(지혁) label Jul 3, 2025

juyesu approved these changes Jul 3, 2025

View reviewed changes

hoxey2Front approved these changes Jul 4, 2025

View reviewed changes

SwimmingRiver merged commit 3be127a into develop Jul 7, 2025
5 checks passed

SwimmingRiver deleted the feature/#67-login-remember-id branch July 7, 2025 05:08

juyesu mentioned this pull request Jul 28, 2025

Fix/#302: SigninForm 테스트 코드 내 필드명 불일치 수정 #194

Merged

Comments

Conversation

SwimmingRiver commented Jun 30, 2025

변경 사항

구현결과(사진첨부 선택)

Uh oh!

netlify bot commented Jun 30, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

✅ Deploy Preview for we-write ready!

Uh oh!

juyesu left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

hoxey2Front left a comment

Choose a reason for hiding this comment

Uh oh!

juyesu commented Jul 3, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

netlify bot commented Jun 30, 2025 •

edited

Loading