[1단계 - 페이먼츠] - 소파(차승하) 미션 제출합니다.

[ss0526100]

서비스 배포 주소

스토리북 배포 주소

안녕하세요~ 피터

연속으로 만나게 되었군요~ 다시 만나게 되어서 반갑습니다.

이번 프로젝트를 하면서 처음으로 리액트를 사용하게 되었는데요

아쉬운점과 궁금한 점을 남겨두겠습니다. 참고하셔서 리뷰하시면 리뷰하실 때 도움이 될 것 같아요.

아쉬운 점

• css가 js에 섞여 있어 가독성이 떨어집니다. 물론 emotion을 사용했기 때문에 어쩔 수 없지만, 스타일을 조금 더 분리할 수 있지 않을까하는 아쉬움이 듭니다.
• view를 담당하는 컴포넌트를 제대로 분리하지 못했다는 것을 깨달았습니다. 특히 로직이 잘 분리되지 않아 스토리북을 제대로 활용하지 못했다는 생각이 들어 아쉬웠습니다.
• 중간에 커스텀 훅을 추가해 반복되는 input과 에러를 나타내는 로직을 추가로 분리해보려고 하였으나 시간이 없어 제대로 분리하지 못했습니다.

궁금한 점

error 처리를 하다가 타입 스크립트에서 catch뒤의 괄호?에 들어가는 값이 unknown으로 들어가는 것을 확인하였습니다. 제 생각으로는 catch뒤에 들어가는 값은 무조건 error일 것 이라고 생각이 들었는데요. 왜 unknown으로 나오는 지 알고 싶습니다.

그리고 UX적인 부분도 궁금한데요, 카드 번호 뒷 8자리를 preview에서는 별표처리를 하였지만, 입력창에서는 별표 처리를 하지 않았습니다. 이는 사용자가 잘못 친 부분을 확인할 수 없을 것이라고 생각했기 때문입니다. 이에 대한 피터의 생각을 알고 싶습니다.

[ss0526100]

안녕하세요 피터 고생많으셨습니다.

말씀해주신대로 추가적으로 리팩토링을 해보았습니다.

리팩토링을 하면서 궁금한 점이 추가로 생겼는데요.

궁금한 점과 아쉬운 점 추가로 정리해보았습니다.

궁금한 점

• 현재 cardInfo과 관련된 훅들을 최상단에서 모든 컴포넌트로 주입하고 있고, 해당 cardInfo를 변경하기 위해 하단(폼 부분)에서 따로 상태를 생성해 useEffect로 값을 업데이트 해주고 있습니다. validation도 cardInfo를 다루는 훅이 아닌 하단의 입력을 담당하는 훅에서 검증을 진행후, cardInfo의 값을 바꿀 때에는 별도의 검증없이 업데이트 하고 있습니다.
  이 부분을 하나로 통합시키는 것이 좋을지(통합된다면 아마 validaton도 cardInfo를 다루는 훅에서 진행해야겠지요..) 아니면 이 상태로 놔두는 것이 좋을지 피터의 의견이 궁금합니다. 이 상태로 프로젝트 규모가 커지게 된다면 어떤 방향을 택하는 것이 좋을까요...?

• 현재 invalid한 input을 사용자에게 보여줄 때 문제가 생긴 input을 빨간색으로 표시하고 있습니다. 그런데, html의 invalid라는 상태를 사용하지 않고 단순히 시각적으로 빨간색으로 표시하는 것이 웹 접근성 측면에서 괜찮은지 알고 싶습니다. 아니면 아예 event.target.setCustomValidity를 이용해 html의 상태도 변경해야할지 궁금합니다.(이렇게 된다면 props만을 통해 시각적인 요소를 다루려고 했던 저의 의도가 깨지게 되서 아쉬울 것 같습니다... 왜냐하면 시각적으로 보이는 에러 강조효과를 해제하려면 추가적인 이벤트리스너를 활용해 props가 아닌 방식으로 에러를 해제해야 하는 상황에 놓이기 때문입니다. )

• 이 질문은 상대적으로 가벼운 질문입니다. ㅎㅎ 현재보다 과거의 년도(ex:10월12년)를 예외로 처리하는 크루들이 있는 것 같은데요, 저는 혹시 몰라(조금 과하지만 2100년 이후의 카드 한도가 나올수도 있다는 생각에ㅋㅋ) 예외처리를 하지 않았습니다. 이에 대한 피터의 생각이 궁금합니다.

아쉬운 점

• pc에서 한글 입력 시 값이 지워지는 현상이 발생하고 있습니다.(모바일은 잘 됨) 아마 onChange 이벤트를 통해 입력된 값을 state를 넣고 이를 input에 바로 업데이트 하면서 isComposing 중인 상태가 끊겨서 그런 것 같습니다.(ex: holder의 경우 마를 입력하면 ㅁ=>상태 업데이트=>ㅁㅏ=>상태 업데이트)
• emotion 라이브러리의 오류로 추측되는 부분인데요. 객체형으로 스타일을 지정해주는 방식에서 flexDirection:column이 타입 에러를 내뱉아서 강제로 tsignore을 사용했습니다(코멘트 달아놓은 부분) 이 부분에 대한 추가적인 탐구를 해보려고 합니다.(현재 emotion의 github issue에도 관련 issue가 없는 것으로 보입니다.)

아쉽고 궁금한 점을 이것저것 적다보니 역대급으로 긴 코멘트가 되었네요...

그럼 잘부탁드립니다!

[ss0526100]

문제가 되는 부분입니다. 아래 77번째 줄에서 ts-ignore을 사용하고 있습니다. 아직까지는 관련하여 문제되고 있는 사항은 없습니다.

[iborymagic]

안녕하세요 소파! 미션 진행하시느라 고생 너무 많았습니다 👏👏👏
미리 말씀을 드리긴 했지만, 그래도 생각한 것보다 더 늦어져서 너무 죄송하다는 말씀 드립니다.

전체적으로 useEffect를 많이 사용하셨는데, 사실 그냥 이벤트 핸들러만 사용해도 해결할 수 있는 부분이 많아보여서, 불필요한 useEffect를 줄이는 방향으로 리팩토링을 진행해보면 좋을 것 같아요! useEffect가 많으면 의존성도 꼬이기 쉽고, 데이터의 흐름을 파악하기가 힘들어지더라구요. 지금 당장 고치지는 않더라도, 다음 단계들에서 차츰차츰 개선해나가보면 좋을 것 같습니다!

몇 가지 피드백 달아놓았으니, 확인해보시고 반영 완료되면 리뷰 재요청 부탁드립니다~
다음은 질문에 대한 답변입니다!

error 처리를 하다가 타입 스크립트에서 ... 왜 unknown으로 나오는 지 알고 싶습니다.

흠 사실 정확한 이유까지는 저도 파악을 하지 못했습니다만.. 😅 아마 런타임에서는 어떤 에러가 발생할지 알 수 없기 때문에, unknown으로 타입을 열어놓고 사용자가 직접 대비할 수 있게 해놓은 것 같습니다. 제 기억으로는 예전에는 심지어 any 타입이었어서, 어떻게 작성해도 타입 에러가 전혀 발생하지 않았는데 unknown으로 수정된 걸로 알고있어요.

그리고 UX적인 부분도 궁금한데요, ... 이에 대한 피터의 생각을 알고 싶습니다.

UX에 대해 세심하게 고민하시는 모습이 아주 보기 좋네요! 충분히 고민 될만한 부분인 것 같은데, 이럴 때는 보안이 중요한 다른 서비스에서 어떻게 문제를 해결하고 있는지 참고해보면 좋습니다. 제 기억으로는 몇몇 은행 앱들에서는 기본적으로는 카드 뒷번호를 가려주되, 눈 모양 아이콘을 선택하면 사용자가 확인할 수 있게 숫자로 바꿔주는 형태를 종종 봤던 것 같아요. 반면에 카카오페이에서는 카드 등록할 때 아예 안보여주네요. 보안과 UX 중 어디에 중점을 두느냐에 따라 선택이 달라질 것 같습니다.

오 밑에도 질문이 따로 있었네요..! 관련해서 추가로 답변 드리겠습니다.

현재 cardInfo과 관련된 훅들을 최상단에서 ... 어떤 방향을 택하는 것이 좋을까요...?

흠 사실 이건 코멘트에도 달아놓았지만, 굳이 useEffect가 필요없어보이는 부분이긴 합니다. 제 생각에는 구조를 조금만 바꾸면 input의 onChange 핸들러에서 set이건 validation이건 전부 해줄 수 있을 것 같아요! (고민하시는 통합 관련된 부분도 핸들러에서 쉽게 해결이 가능해질 것 같네요)
관련해서, 좀 길더라도 꼭 읽어보셨으면 하는 아티클을 첨부해드립니다.

현재 invalid한 input을 사용자에게 보여줄 때 ... 해제해야 하는 상황에 놓이기 때문입니다. )

단순히 시각적으로만 표시해주면 당연히 앞이 보이지 않는 분들은 해당 변화를 인지하기가 어려울거라고 생각해요. 그래서 힘들겠지만 질문을 주셨으니, 지킬 수 있는 부분에 대해서는 최대한 지키려고 노력해보면 좋을 것 같네요! (제가 질문을 제대로 이해한건지 모르겠는데, 사실 props로 isValid같은 상태를 넘겨주면 거기에 따라서 스타일, 접근성 모두 적용해줄 수 있을 것 같은데 혹시 소파가 생각하시는 방향이 있는걸까요?)

이 질문은 상대적으로 가벼운 질문입니다. ... 이에 대한 피터의 생각이 궁금합니다.

안그래도 다른 크루한테 요것 관련해서 리뷰를 달아드렸는데, 사실 은행 어플들에서는 해당 부분을 예외로 처리해주고 있긴 하더라구요. 개인적으로도 2100년 이후를 고려하기보다는(ㅋㅋ) 과거의 년도를 막아주는 것이 더 괜찮아보여요!

[iborymagic]

와우..! base64를 직접 넣는 방법을 선택하신 이유가 궁금해요!

[iborymagic]

그리고 요 파일도 emotion을 사용하도록 통일해주면 더 일관성 있지 않을까요?

[ss0526100]

App이 아닌 App 외부의 body에 배경 이미지를 적용하고 싶었습니다. 그래서 emotion이 아닌 별도의 css에 넣어줬습니다.
App.css에 있을 스타일이 아니어서 index.html에 넣어주려고 합니다.
혹시 다른 깔끔한 방법이 있다면 알려주시면 감사드리겠습니다!!

그리고 base64는 굳이 넣어줄 필요가 없었다는 생각이 드네요. 이미지파일을 첨부하겠습니다.

[iborymagic]

오 이미지 파일을 첨부한 버전으로 새로 배포해주신건가요? background image 관련 코드를 못찾겠어요!

[iborymagic]

EOF도 신경써주세요! 호호

[ss0526100]

css를 보기좋게 정렬해주는 확장프로그램을 사용하는데, eof 설정이 안되네요.. 방법을 찾아보겠습니다!!

[iborymagic]

만약 요걸 매번 작성하기 귀찮으시다면, Babel 플러그인을 활용하는 방법도 있고, 아니면 @emotion/styled 를 사용하면 안써줘도 되긴 합니다. 대안을 알려드리는 것이지, 고치라는 뜻은 아닙니다!

[iborymagic]

말씀해주신 스타일을 분리하는 문제는, 보통 스타일용 파일을 따로 만들어서 보관하는 경우도 많습니다. 그걸 말씀하시는 게 아니라 css={...} 형태로 인라인으로 들어가는 것이 거슬리시는 거라면, 역시나 @emotion/styled를 고려해봐도 좋겠네요! (뭔가 자꾸 강요하는 것 같은데.. 소파가 고민하시는 문제의 해결책이 될 수 있을까 싶어 권유하는 것이지, 절대 이걸 사용하라고 유도하는 건 아니에요 😅)

[iborymagic]

혹시 요 친구들은 왜 사용하신걸까요? (언뜻 보기엔 지워도 문제가 없을 것 같아서요!)

[ss0526100]

이 부분을 안쓰면 emotion의 오류가 있는지 ts 오류가 나더라고요(flexDirection가 있는 객체형 스타일 지정 시)
@emotion/styled를 사용해보고 지울 수 있으면 지우겠습니다!

[iborymagic]

요 card info 형태들([string, string, string, string] 같은)은 useCardInfo에서도 사용되는 것 같아서 별도의 타입으로 선언해두면 편할 것 같네요!

[iborymagic]

요 border-color는 갑자기 kebab case가 적용됐네요! 혹시 이유가 있을까요?

[ss0526100]

borderColor로 사용하니 eslint 에러가 나서 케밥 케이스로 바꿨는데 지금은 또 잘 적용되네요.. 수정하겠습니다!

[iborymagic]

요 네이밍도 좀 더 명시적으로 바꿔보면 좋을 것 같네요! 혹시 뭔가 의미가 있는 네이밍일까요?

[iborymagic]

그냥 Visa와 MasterCard만 적어줘도 될 것 같네요!

[iborymagic]

전체적으로 불필요한 useEffect가 많아서 데이터의 흐름을 파악하기가 힘드네요! useEffect를 거치지 않고 handler만을 사용해서 해결하도록 수정해보면 좋을 것 같습니다. (요번 단계에서 당장 고치자는 뜻은 아니에요! 차근차근 고쳐보면 좋을 것 같습니다)

[ss0526100]

안녕하세요 피터

피드백을 반영해 보았습니다.

참고하실 만한 부분을 작성해보았으니 리뷰하는데 도움이 되셨으면 좋겠습니다.

그럼 잘부탁드려요!

반영한 부분

aria-invalid 활용해 접근성 향상(invalid한 input에 대한 접근성 향상)
@emotion/styled 사용(css 통일 및 flexDirection 버그 우회,border-color 케밥 케이스 수정)
CardInfo 타입 설정
useEffect 제거
기타 피드백 받은 코드 가독성 향상

궁금한 점

현재 useCardInfo에서 set을 CardForm으로 내려주고 있고, validation은 CardForm 내부의 컴포넌트(CardNumbers,CardExpiredDate,CardHolder)에서 진행하고 있습니다.
CardInfo에서 Validation을 진행하지 않는 것이 어색하지는 않는지, 이대로 하단의 Input에서만 validation을 진행하는 것이 좋을지 궁금합니다.

useEffect를 제거하면서 useRef로 바꾼 부분이 많은데, 해당 부분이 어색하지는 않은지 궁금합니다.

반영 못한 부분

카드 뒷자리 눈모양 누르면 번호 보이게 하기

##아쉬운 부분
useEffect를 없애면서 가독성이 많이 안좋아졌습니다.
useEffect를 useRef로 바꾸었는데 useRef 사용법이 많이 어색해 바르게 사용했는지 모르겠습니다.
추천해주신 아티클을 읽어보았지만, 리액트 기초체력이 약해서(렌더링 개념 부족 등...) 완벽히 소화를 못했습니다.

[iborymagic]

안녕하세요 소파~ 리뷰 반영하시느라 고생 많았습니다.
코드를 보면서 이해가 어려운 부분이나 궁금한 내용들 질문 달아놨으니, 슥 훑어보시고 답변 달아주시면 좋을 것 같아요! 일단 1단계 PR은 여기서 마무리하고, 2단계에서 관련 내용들 챙겨서 같이 진행해보면 좋을 것 같습니다. 고생하셨어요~

[iborymagic]

요 훅은 사실 하는 역할이 cardInfo로 묶어서 상태값을 내보내는 것밖에 없는 것 같아요!
matchCardIssuer의 return값은 굳이 상태값으로 보관하지 않아도 될 값이고, 그냥 CardPreview 컴포넌트 내부에서 사용하기만 해줘도 될 것 같습니다. 오히려 이 훅에서 props를 통해 CardPreview 컴포넌트로 내려줌으로써, 데이터의 흐름을 파악하기가 더 어려워진 것 같아요.

1. 이 hook을 만들어야겠다고 생각한 이유가 뭘까요?
2. cardIssuer를 ref로 보관해야겠다고 생각한 이유는 무엇일까요?

[ss0526100]

1. CardInfo의 값들(cardNumbers,cardHolder,expiredDate)을 사용하는 곳에서 일일이 선언하는 것이 보기 안좋아 보일 것 같았기 때문입니다.
2. 이 코드를 작성할 당시에는 최대한 많은 값을 훅으로 사용하면 좋을 것 같다는 생각이 들었던 것 같습니다.
   요즘 공식문서를 찬찬히 읽어보고 있는데 계산할 수 있는 값이나 변하지 않는 값을 state로 사용하는 것은 부적절하다는 것을 알았습니다. 다시보니 피터의 말씀대로 Issuer의 사용처에서 CardNumber를 통해 계산해서 사용하는 것이 적절할 것 같네요.

[iborymagic]

어차피 여러 곳에서 하나의 상태값을 사용해야하는 경우라면, 최상단에서 여러 곳에 props로 내려주는 형태일 것이므로 훅으로 묶어놓던 아니던 최상단에 한 번만 선언하는 건 같지 않을까요? 덧붙여, 커스텀 훅도 결국 만들어놓으면 새로운 사람의 입장에서는 진입 장벽이 되기 때문에 최대한 필요한 훅만 만드는 게 좋다는 것이 저의 생각입니다.

[iborymagic]

Controlled input을 쓰고 있는데다가 어차피 input의 내용이 그대로 preview에 드러나는거면, 그냥 하나의 상태값으로 CardPreview, 그리고 input에서 같이 사용하면 hook도 훨씬 간단하게 압축할 수 있을 것 같고 불필요한 상태도 줄어들 것 같습니다.
input의 value와 cardInfo 데이터를 별도의 상태로 관리해야겠다고 생각한 이유가 무엇인지 궁금하네요!

[ss0526100]

이 훅을 통해 만들어진 Input이라는 state가 CardInfo에서 만든 훅만을 담당할 것이라고 생각하지 않았기 때문입니다.
그래서 에 렌더링 될 state인 Input과 CardInfo의 state를 분리했습니다.

그런데 피터의 말씀을 듣고나니 (부적절한 이름이긴 하지만) setHook이 있으니 굳이 상태를 별도로 관리했어야 했나라는 생각이 드네요.

좋은 지적 감사합니다!!

[iborymagic]

맞아요. useInput과 useCardInfo를 합치자는 뜻은 아니고, 지금 어차피 외부에서 value와 setHook을 받고 있으니 그걸 활용하면 좋을 것 같다는 뜻이었습니다!

[iborymagic]

요 setHook이라는 네이밍은 무엇을 의미하는지 궁금합니다! 언뜻 보면 그냥 set state를 해주는 함수인 것 같은데, 왜 hook이라는 이름이 붙은걸까요?

[ss0526100]

그러네요.. setState는 이름이 더 적절한 것 같네요. 수정하겠습니다!!

[iborymagic]

useInput의 decorateValue가 뭐하는 함수인지 알고 싶음
-> props로 주어지는 값이므로 useInput이 사용되는 곳을 찾아야함
-> useValidateInput으로 이동
-> useValidateInput에서도 props로 주입되는 값이라, useValidateInput의 사용처를 찾아야 함
-> useValidateInput의 사용처로 이동
-> useValidateInputProps라는 객체를 또 찾아가야함

전체적으로, 너무 거대한 재사용을 생각하다보니 프로젝트 사이즈에 비해 역할을 너무 잘게 쪼개게 되고, 추상화가 과해지고, 그래서 코드를 쉽게 파악하기가 힘들어진 것 같습니다. useInput, useCardInfo, useValidateInput, useValidator 등의 훅들은 어느정도 선택과 집중을 통해 간소화가 가능할 것 같아요. 코드를 최대한 간단하게 유지하는 연습을 해보면 좋을 것 같습니다!

[iborymagic]

useValidateInput에서 useState, 여기서 useRef로 에러메시지를 두 벌로 관리하는 이유가 무엇인지 궁금해요.

[ss0526100]

이 부분도 제가 많은 값을 훅으로 사용하는 것이 좋다라는 편견 때문에 만들어 진 것 같습니다.
이 훅은 밖에서도 계산이 가능하므로 훅으로 관리하는 것이 부적절해 보입니다.

좋은 지적 감사합니다!!

[iborymagic]

요 훅은 무슨 역할을 하는지 설명이 필요합니다. reflect같은 용어도 설명해주시면 좋을 것 같아요!

[ss0526100]

이 훅은 어떻게 보면 useInput과 is-A 관계에 있는 훅인데요
오류 상태를 관리하는 Input이라고 생각하시면 편할 듯 합니다.

정확하게는
1)사용자가 입력한 input을 바탕으로 Validation을 진행하고
2)그 값을 Input에 반영할 지 정하고
3)Input의 에러 메시지를 관리
이 세 가지 역할을 하게 됩니다.

validatorProps 같은 경우
checkIsValid: 사용자가 입력한 값이 유효한지 판단
shouldReflect: 사용자가 입력한 값이 유효하지 않더라도, Input에 업데이트 하고 싶으면 true(상태에 반영함), 사용자가 입력한 값이 유효하지 않않을 때 상태를 업데이트 하고 싶지 않으면 false(상태에 반영하지 않음),
errorMessage: 해당 에러가 발생했을 때 나타낼 메시지
를 나타냅니다.

shouldReflect에 대해 더 쉽게 설명하자면,
해당 값을 통해 에러에 대해 사용자의 입력을 제한할 지 여부를 설정할 수 있도록 하였습니다.

예를들어
사용자가 CardHolder에 숫자를 입력할 경우
사용자로부터 입력을 제한하고 싶었습니다.
그래서 sholdReflect를 false로 두었습니다.

그리고 사용자가 ExpiredDate에 현재 달 이전의 값을 입력할 경우
에러는 발생하지만 사용자로부터 입력을 제한하고 싶지 않았습니다.
그래서 sholdReflect를 true로 두었습니다.

만약 상태에 반영되지 않을 에러가 발생한 경우(shouldReflect가 false)인 경우 가장 사용자가 먼저 알아야 할 에러라고 판단했기 때문에, 먼저 반영되지 않는 유효성을 우선적으로 확인합니다.

해당 훅에 대한 설명을 정리하며 다음과 같은 생각이 들었습니다.

1. 해당 훅이 하고 있는 일이 너무 많은 것이 아닌가
2. errorMessage의 경우 계산되는 값이므로 상태가 아니라 변수로 관리해야 한다.
3. reduce보다는 find를 사용하는 것이 조금 더 가독성을 높일 수 있었다.
4. shouldReflect 가 true여도 (사용자의 입력을 허용하더라도) state를 업데이트 하지 않는 것이 좋지 않았을까(아마 피터께서 말씀해주신 controlled component가 아닌 방식으로 만들어야 하지 않을까 싶습니다. 이와 관련해서는 추가적인 학습이 필요해 보입니다.)

[iborymagic]

사실 훅 로직 자체는 괜찮다고 생각했어요. 다만 여러가지가 복합적으로 훅의 가독성을 떨어뜨린 것 같습니다.

• 일단 reflect라는 용어가 이해가 안됐습니다. 로직 자체는 대충 짐작을 했는데, reflect 한 단어로 인해 코드 전체가 읽기 어려워지는 느낌이었어요! 그래서 확인을 위해 설명을 부탁드렸던거구요.
• willChange = shouldReflect인거겠죠?
• useValidateInputProps 를 각 컴포넌트 맨 아래쪽에 두지 말고, 위에 뒀더라면 눈에 더 잘 띄어서 코드를 읽기가 훨씬 수월했을 것 같기도 합니다.
• maxLength도 결국 validation이니 Props로 받는 것이 개인적으로는 더 통일성 있을 것 같네요!
• 일부 props의 역할을 확인하려면 useInput으로 한 번 더 들어가야되는 것도 번거로웠습니다. 사실 useInput도 로직이 복잡하지 않아서, '여기다 풀어 써도 충분할 것 같은데?' 하는 생각이 들긴 했어요.
• reflect 안시키는 에러를 우선 처리해주기 위해 정렬하는 로직은 꼭 필요한 로직일까요? 요 로직들을 정렬해주는 작업이 왜 필요한지 궁금해요!

useValidateInputProps를 내려받는 컨셉 자체는 디자인을 잘 하신 것 같아요. antd form에서도 validation rules를 객체의 배열로 내려받는 형태를 채용했던 걸로 기억합니다. 그런 rules를 따로 모아서 관리하는 파일을 만들면 더 보기 편할 것 같네요!

+) 저는 find보다는 reduce가 나은 것 같습니다. 아니면 map을 사용해도 될 것 같구요.
++) 사실 shouldReflect가 true일 때 사용자에게 보여지지 않게 하려면 controlled를 쓰는 게 일단은 맞긴 합니다. shouldReflect에 따라 실시간으로 input value를 조절하는건데, uncontrolled를 쓰면 실시간 통제가 어려우니까요. 결국 나중에 요구사항이 복잡해지면 막 섞어쓰기도 하고 할텐데, 일단은 그렇게 생각하시면 개념 정립에 도움이 될 것 같아요.

[iborymagic]

요 훅에 대해서도 역할 설명을 들어보고 싶습니다. 가장 최근에 업데이트 된 유효한 값을 구해야하는 이유가 무엇인가요?

[ss0526100]

여러 Input에서 발생 한 에러 중 마지막으로 나온 에러에 대해서 알고 싶었기 때문입니다.

제가 해결하고 싶었던 상황은 다음과 같습니다.

카드 넘버를 관리할 때
현재
A,B,C,D라는 4개의 칸이 있습니다.
그리고 이 4개의 칸에서 발생한 에러메시지는 하나의 span에서 출력되고 있습니다.

문제는 여러 칸에서 에러메시지가 발생했을 때 생깁니다.

다음 순서대로의 상황이 일어난다고 가정해 보았습니다.
1-0 사용자가 A에서 텍스트 작성
1-1.A에서 에러 메시지가 발생

2-0.A의 에러메시지가 유지된 채, B로 포커스를 옮김
2-1.B에서 에러 메시지가 발생
2-2.B에서 에러가 해결되어 에러메시지가 없어진 경우

이 경우를 다룰 때 가장 최근에 발생한 유효한(''이 아닌 에러 메시지) 값을 구해서 출력하는 것이 UX적으로 가장 좋다고 생각했기 때문입니다.

이 경우 앞에서부터 발생한 에러메시지를 순차적으로 확인 후 출력하게 되면
2-1(B에서 에러가 발생)에서 에러가 발생하여도 사용자는 A에서 나타난 에러만 확인할 수 있습니다.

만약 가장 마지막에 입력한 input의 에러메시지를 span에 출력할 경우
2-2에서 B의 에러메시지가 없어졌을때, span에는 빈 값이 출력되어 A의 에러메시지가 출력되지 않습니다.

이런 점을 보완하기 위해 이 훅을 만들게 되었습니다.

돌이켜 생각해보면 이러한 생각이 너무 과한 UX를 고려하지 않았을까, 혹은 다른 방법으로 UX를 개선할 수는 없었을까라는 생각이 드네요..

이런 사고 흐름 혹은 문제 설정에 대한 피터의 생각이 궁금합니다..!

[iborymagic]

오 UX에 대한 세심한 고민의 결과물이었네요! 사실 이건 미션에서 정책이 명확하게 세워지지 않은 부분인 것 같아서, 소파가 충분히 고민해볼 만한 부분이었다고 생각이 듭니다.

문제 해결 방법에 정답은 없는 것 같고, 오히려 input과 error message를 위주로 상태를 구성하고 로직을 풀어나간다던가, 네이밍을 좀 더 가장 최근에 발생한 error message를 return한다라는 역할에 맞게 짓는다면 훅의 의도가 좀 더 명확해질 수 있겠다는 생각은 드네요. 설명을 들으니 이해가 되는데, 사실 이 훅의 이름과 주석, 코드를 처음 봤을 때는 어디에 사용되는 훅인지 파악하기가 어려웠어요.

[ss0526100]

저의 생각을 작성하다보니 부족한 점들과 나오게 된 이유를 너무 길게 나열한 것 같네요. 피터의 좋은 지적을 통해 생각할 부분과 부족한 부분을 잘 알게 된 것 같습니다. 좋은 리뷰 감사드립니다. 덕분에 성장에 많은 도움이 되었어요.

혹시 저의 의견에 대해 새로운 생각이 있으시다면 적극적으로 말씀해주세요. 리액트를 시작하는 저의 첫 발돋움에 큰 도움이 될 것 같습니다.

다시 한 번 감사드립니다.

[ss0526100]

1. CardInfo의 값들(cardNumbers,cardHolder,expiredDate)을 사용하는 곳에서 일일이 선언하는 것이 보기 안좋아 보일 것 같았기 때문입니다.
2. 이 코드를 작성할 당시에는 최대한 많은 값을 훅으로 사용하면 좋을 것 같다는 생각이 들었던 것 같습니다.
   요즘 공식문서를 찬찬히 읽어보고 있는데 계산할 수 있는 값이나 변하지 않는 값을 state로 사용하는 것은 부적절하다는 것을 알았습니다. 다시보니 피터의 말씀대로 Issuer의 사용처에서 CardNumber를 통해 계산해서 사용하는 것이 적절할 것 같네요.

[ss0526100]

이 훅을 통해 만들어진 Input이라는 state가 CardInfo에서 만든 훅만을 담당할 것이라고 생각하지 않았기 때문입니다.
그래서 에 렌더링 될 state인 Input과 CardInfo의 state를 분리했습니다.

그런데 피터의 말씀을 듣고나니 (부적절한 이름이긴 하지만) setHook이 있으니 굳이 상태를 별도로 관리했어야 했나라는 생각이 드네요.

좋은 지적 감사합니다!!

[ss0526100]

그러네요.. setState는 이름이 더 적절한 것 같네요. 수정하겠습니다!!

[ss0526100]

여러 Input에서 발생 한 에러 중 마지막으로 나온 에러에 대해서 알고 싶었기 때문입니다.

제가 해결하고 싶었던 상황은 다음과 같습니다.

카드 넘버를 관리할 때
현재
A,B,C,D라는 4개의 칸이 있습니다.
그리고 이 4개의 칸에서 발생한 에러메시지는 하나의 span에서 출력되고 있습니다.

문제는 여러 칸에서 에러메시지가 발생했을 때 생깁니다.

다음 순서대로의 상황이 일어난다고 가정해 보았습니다.
1-0 사용자가 A에서 텍스트 작성
1-1.A에서 에러 메시지가 발생

2-0.A의 에러메시지가 유지된 채, B로 포커스를 옮김
2-1.B에서 에러 메시지가 발생
2-2.B에서 에러가 해결되어 에러메시지가 없어진 경우

이 경우를 다룰 때 가장 최근에 발생한 유효한(''이 아닌 에러 메시지) 값을 구해서 출력하는 것이 UX적으로 가장 좋다고 생각했기 때문입니다.

이 경우 앞에서부터 발생한 에러메시지를 순차적으로 확인 후 출력하게 되면
2-1(B에서 에러가 발생)에서 에러가 발생하여도 사용자는 A에서 나타난 에러만 확인할 수 있습니다.

만약 가장 마지막에 입력한 input의 에러메시지를 span에 출력할 경우
2-2에서 B의 에러메시지가 없어졌을때, span에는 빈 값이 출력되어 A의 에러메시지가 출력되지 않습니다.

이런 점을 보완하기 위해 이 훅을 만들게 되었습니다.

돌이켜 생각해보면 이러한 생각이 너무 과한 UX를 고려하지 않았을까, 혹은 다른 방법으로 UX를 개선할 수는 없었을까라는 생각이 드네요..

이런 사고 흐름 혹은 문제 설정에 대한 피터의 생각이 궁금합니다..!

[ss0526100]

이 훅은 어떻게 보면 useInput과 is-A 관계에 있는 훅인데요
오류 상태를 관리하는 Input이라고 생각하시면 편할 듯 합니다.

정확하게는
1)사용자가 입력한 input을 바탕으로 Validation을 진행하고
2)그 값을 Input에 반영할 지 정하고
3)Input의 에러 메시지를 관리
이 세 가지 역할을 하게 됩니다.

validatorProps 같은 경우
checkIsValid: 사용자가 입력한 값이 유효한지 판단
shouldReflect: 사용자가 입력한 값이 유효하지 않더라도, Input에 업데이트 하고 싶으면 true(상태에 반영함), 사용자가 입력한 값이 유효하지 않않을 때 상태를 업데이트 하고 싶지 않으면 false(상태에 반영하지 않음),
errorMessage: 해당 에러가 발생했을 때 나타낼 메시지
를 나타냅니다.

shouldReflect에 대해 더 쉽게 설명하자면,
해당 값을 통해 에러에 대해 사용자의 입력을 제한할 지 여부를 설정할 수 있도록 하였습니다.

예를들어
사용자가 CardHolder에 숫자를 입력할 경우
사용자로부터 입력을 제한하고 싶었습니다.
그래서 sholdReflect를 false로 두었습니다.

그리고 사용자가 ExpiredDate에 현재 달 이전의 값을 입력할 경우
에러는 발생하지만 사용자로부터 입력을 제한하고 싶지 않았습니다.
그래서 sholdReflect를 true로 두었습니다.

만약 상태에 반영되지 않을 에러가 발생한 경우(shouldReflect가 false)인 경우 가장 사용자가 먼저 알아야 할 에러라고 판단했기 때문에, 먼저 반영되지 않는 유효성을 우선적으로 확인합니다.

해당 훅에 대한 설명을 정리하며 다음과 같은 생각이 들었습니다.

1. 해당 훅이 하고 있는 일이 너무 많은 것이 아닌가
2. errorMessage의 경우 계산되는 값이므로 상태가 아니라 변수로 관리해야 한다.
3. reduce보다는 find를 사용하는 것이 조금 더 가독성을 높일 수 있었다.
4. shouldReflect 가 true여도 (사용자의 입력을 허용하더라도) state를 업데이트 하지 않는 것이 좋지 않았을까(아마 피터께서 말씀해주신 controlled component가 아닌 방식으로 만들어야 하지 않을까 싶습니다. 이와 관련해서는 추가적인 학습이 필요해 보입니다.)

[ss0526100]

이 부분도 제가 많은 값을 훅으로 사용하는 것이 좋다라는 편견 때문에 만들어 진 것 같습니다.
이 훅은 밖에서도 계산이 가능하므로 훅으로 관리하는 것이 부적절해 보입니다.

좋은 지적 감사합니다!!

[iborymagic]

소파가 열정적으로 답변을 달아주셔서, 추가로 몇 가지 코멘트 달아놓았으니 시간 나시면 확인해주세요!