이번에 서비스에 가입하는 과정에서 기획상 변경해야하는 부분이 생겨 업무를 담당하게 되었습니다
일단 간단한 플로우를 설명하면
기존 | 변경 |
나이를 입력받음 | 생년월일을 입력받음 |
ex) 25 | ex ) 2024-05-01 |
기존에는 나이를 입력받아 전달하면 되는 플로우지만, 변경해야하는 부분은 생년월일을 입력받아야합니다.
간단하죠?
저도 간단할 줄 알았습니다
문제가 됐던 부분들을 먼저 정리해보겠습니다.
타입과 DB구조
가장 많은 에러를 마주했던 부분입니다. 기존에 회원가입에 필요한 정보들을 정의해둔 ts 파일이 있었습니다. 해당 파일에는 나이를 string으로 입력받아 DB에 전달하고 있었습니다. 여기서 전 두가지 분기점을 생각했습니다.
- 생년월일을 입력받아야하면 필요한 input은 3개입니다. (연도, 월, 일) string으로 변경하기보단 객체로 관리하는게 데이터 구조상 더 자연스럽지않을까 하는 생각을 했습니다. 회원가입-나이 의 타입을 변경하며 개발했지만, 해당 방법은 생년월일을 저장하기위한 DB 수정의 공수를 통해 완성할 수 있습니다. 사수분과 이야기를 나눠보니 어떤 사이드이펙트가 발생할지 모르고, 해당 공수를 감수하기엔 어려울 것 같다는 답변을 받았습니다.
- 때문에 저는 클라이언트 측에서 생년월일로 입력받되, 입력받은 생년월일을 나이로 계산하는 로직을 통해 기존 데이터 타입을 헤치지않고 가입이 이루어지도록 구성하도록 만들기로 했습니다.
사실 이 부분을 업무를 진행하기 전에 고려했었다면 좀 더 빠른 진행이 가능했을 것입니다. DB의 구조를 바꾸는 것, 기존에 만들어져있던 타입구조를 변경하는 것은 어떤 효과를 불러올지 모르고, 많은 공수가 들어간다는 것을 일찍 알아차리지 못했다는 것이 첫 번째 문제점이라 할 수 있겠습니다. 처음부터 만드는 서비스, 기능이라면 추가하는 입장이라 이러한 부분을 좀 더 자유롭게 구조를 꾸려나갈 수 있겠지만, 이미 서비스 중인, 개발이 되어있는 부분을 수정하는 것은 최대한 뼈대(타입구조)를 건들지 말고 유연하게 대처하는 개발을 해야겠다는 회고를 해보게 되었습니다.
이게 맞을까?
제 현재 상태를 이렇게 정의할 수 있을 것 같습니다. "알고 코딩하는게, 모르고 코딩하는 것보다 손이 느리다." 사실 전 이 업무를 담당하기 전에, 자바스크립트 공부를 진행하고 업무에 투입되었습니다. 물론 아직 지식이 부족하고 사고력도 주니어 수준입니다. 하지만 메타인지를 제대로 경험하고 있습니다. '내가 공부했던 부분에서는 여기서 useState를 사용하면 의미없는 재렌더링이 일어날 것 같은데.. 커스텀 훅으로 빼는게 맞겠지..? 추상화 단계는 맞춰진 걸까..? useEffect를 사용해도 될까.." 물음표가 굉장히 많아졌습니다. 분명 예전엔 아무런 생각없이 작성했을 코드들도 의문점들로 인해 손가락을 멈칫하게 만든적도 많습니다.
이 부분은 아직 제가 부족하다는 것을 반증하는 부분이긴 합니다. 다만, 이 의문점들은 제게 계단으로 느껴집니다. 정복할 지식이 많이 남아있다는 뜻이죠. 이런 문제들이 제게 또 코딩을 할 수 있는 동력으로 작용하는 것이 참 좋은 것 같습니다.
그럼 이제 실제 코드가 어떻게 수정되어 갔는지 확인해보겠습니다.
먼저 생년월일의 각 input에는 조건이 있었습니다. 해당 조건에 부합하게 되면 다음 input으로 자동으로 focus가 이동해야합니다.
연도 | 1900년도 이상만 허용, 4자리가 입력되면 month input으로 이동합니다. |
월 | 1~12만 허용, 첫번째 숫자로 2~9가 입력되면 바로 day input으로 이동합니다. |
일 | 1~31일까지 입력되어야 하며, 실제로 존재하는 날짜인지 확인해야합니다. |
이 모든 조건이 부합되어야 다음 단계로 넘어갈 수 있는 버튼이 활성화됩니다.
여기서 각 input의 상태를 관리해야하는 부분들이 몇가지 있습니다.
- 조건문 통과 상태
- input내의 값
- 다음 input으로 넘어가기 위한 ref
useBirthdayInputHandler 커스텀 훅을 생성하여 input관련 로직을 담당하게 구성하였습니다.
이 커스텀 훅에서 각 input의 값이 조건문을 통과하는지 확인합니다. 마지막 input인 day의 값이 들어오면 momentJs 라이브러리를 통해 완성된 날짜가 실제로 존재하는 날짜인지 확인합니다. 이를 통해 윤달과 같은 특이점을 잡아낼 수 있습니다. 각 input이 조건문을 통과했는지 useState를 통해 관리하며, 조건문을 통과하지 못한 input의 스타일을 변경하여 잘못된 지점을 사용자가 인지할 수 있도록 하였습니다. 또한, 모든 input 중 하나라도 조건문을 통과하지 못하면 재확인을 부탁하는 안내 문구도 출력하도록 구성했습니다.
useEffect를 사용한 이유
useState의 업데이트가 비동기로 처리되기 때문에 상태가 업데이트되고 그 결과가 반영되기까지는 컴포넌트의 다음 렌더 사이클을 기다려야 합니다. 즉 에러가 발생해야하는 렌더사이클에 에러가 발생하지 않고 한텀씩 밀려 에러 처리가 반응하게 되는 트러블이 있었습니다.
이를 해결하기 위해 useEffect 의존성 배열에 상태인자를 추가하여 관리하게 만들었습니다. 상태를 확실하게 반영하기 위한 방법으로 채택했습니다
이미 배포중인 서비스를 수정할 땐 어떤 것을 고려해야하는지, 어떻게 구성해야할지 생각해야할 필요성에 대해 배웠습니다.
많이 배웠습니다!
'Project' 카테고리의 다른 글
[트러블 슈팅] Firebase 한계 부숴보기 (0) | 2024.02.23 |
---|---|
[Project] clientX,Y와 offsetX,Y의 차이점 (0) | 2024.01.04 |
[ThreeJs] 개인 포트폴리오 제작기 #1 (2) | 2023.12.21 |
[EmailJS] Contact 컴포넌트 제작 (0) | 2023.12.05 |
[OMS] 네이버 로그인 문제해결 (0) | 2023.06.17 |