오랜만에 wil을 쓰는 것 같다.
면접준비를 한다고 쓰고 얼마지나지 않아 정말 면접을 봤고, 합격 소식을 듣게 됐다.
그후 입사를 했고 아직은 부족하지만, 곧 1인분을 해내는 개발자가 되고 싶어서 매일매일 공부중이다.
회사 프로젝트의 일부분이라 예시를 조목조목 들순 없겠지만,
써보지 않았던 라이브러리를 사용해봤고, 아직 완전 걸음마 단계인 typescript도 부딪쳐가면서 익숙해진 기간이었다.
이쯤하면 wil이 아니라... Mil이 되어야 하는거 아닌가 싶지만;
이제 어느정도 분위기 적응이 되었으니 wil로 밀리지 않고 써봐야겠다.
과거 항해 99에서 프로젝트를 진행했을 때는 왠만하면 라이브러리를 쓰지 않고 하드코딩으로 프로그래밍을 했었다.
하드코딩을 하면, 라이브러리를 쓸 때보다 훨씬 많은 고민을 하게 되고, 초보자의 단계에서는 어떤 기능을 잘 사용하는 것도 중요하지만 나름대로 해결 방법을 고민해 보는 것이 필요하다고 생각했기 때문이었다.
그래서 인풋창에 validation을 넣고 싶을때는, 함수를 일일이 만들어 정규식을 짜넣고 state를 여러개 관리하면서 폼형식을 구현하곤 했었다.
현업으로 넘어오니 그렇게 하기는 어려웠다. 일단 코드가 너무 길어지면 다른 작업자들과의 유기적인 협업에도 어려움이 있지만 추후 서비스를 보완하기 위해 유지보수를 할때 만약 내가 아닌 다른 작업자가 작업을 해야 한다면 어려움이 있을 것이기 때문이었다.
그래서 코드는 200자를 넘지 않는 선에서 최대한 간결하게 컴포넌트화해서 관리하는 것이 좋다고 들었다.
그렇다면 맞춰야지.
인풋창이 두세개면 사실 하드코딩으로 구상을 해도 크게 문제될 것이 없지만, 조금 많아지면 react-hook-form 라이브러리의 사용을 고려해봐도 좋다는 말에 한번 사용을 해보았다.
공식문서에 나와있는대로 공부해서 썼고, 특별히 정규식을 쓰지 않고 yup 라이브러리를 함께 쓰면서 validation을 한번에 해결할 수 있어서 편하긴 했다.
물론, 그 폼에는 라디오 버튼과 체크박스가 있어서 전체 폼데이터를 넘겨 주기 위해 고민을 했었다.
유저의 입장에서 빈 체크박스를 클릭하면 약관 모달을 띄우고, 확인버튼을 누르면 체크가 자동으로 되며, 체크가 되어있는 체크박스를 클릭하면 모달이 뜨지 않고 그냥 체크가 해제되는 형태로 구현되길 바랬기 때문에 그 로직을 구상하느라 조금 오래 걸렸고 도움도 받아야 했다 ㅠ
그 후 코드 리팩토링을 하게 되면서 400자가 넘는 코드를 줄이기 위해 각 인풋창마다 컴포넌트화 시키고, 라디오 버튼, 체크박스 등을 컴포넌트로 빼서 페이지를 만들었다.
이때 typescript의 props를 새로 배우게 되었다.
interface 나 type으로 뭔가를 선언해주고 그 양식을 이쪽 저쪽 컴포넌트에서 꺼내어 쓰기 위해서는 props를 적절히 사용할 수 있어야 했는데, 서툴렀다. useformregister를 통해 폼양식을 꺼내어 썼다.
함수나 state들은 전부 메인페이지에 두고 그걸 컴포넌트마다 props로 받아서 꺼내어 쓰니 훨씬 간결해졌던 것 같다.
이게 코드를 보면서 설명을 해야 하는 것인디...
결론적으로 코드의 양은 많이 간결해졌고, 원하던 대로 데이터를 담을 수 있었다. 이제 뷰를 짠것이지만, 여기에 react-query로 데이터베이스와 요청 응답을 주고 받게 된다면 일단 기능까지도 완료 되는 거겠지. 아직 api가 없다...
typescript는 event의 타입도 알아야 하고, 내가만든 state의 타입도 알아야 하고, props로 보냈으면 props안의 항목하나하나의 타입도 알아야 하는데 이렇게 지정해주는 것들을 잊어버리지만 않으면 어떻게든 헤쳐나갈수 있을 듯 하다.
함수형의 props를 받아오는 것도 처음엔 몰라서 쩔쩔 매었다는 것이...
후...
실전에서 부딪쳐가며 익히니 필사적으로 머리에 꾹꾹 눌러담게 된다. 듣다만 강의를 마저 들어야 겠다.
