하루종일 Formik 라이브러리를 참고하면서 context api를 기반으로 한 Form 컴포넌트를 만들어봤다. context api로 Form을 관리하게 되면 필요한 메서드들을 받아서 사용할 수 있기 때문에 가독성도 좋아지고, 사용도 편리해지는 장점이 있다고 리뷰어님께 들었다. 게다가 하면서 느낀 것은 기존에는 form 관련 상태를 해당 페이지에서 가지고 있었기 때문에 해당 페이지가 계속 리렌더링 되었었는데, context로 바꾸고 나서는 form 내부만 리렌더링되기 때문에 이전보다 성능도 더 좋아졌을 것 같다. (성능은 그렇게 신경쓰지 않으려고 한다.)
사실 이 context Form을 2~3일 전부터 생각하면서 만들고 있었는데, 처음 해보는 것이기도 하고 너무 어려워서 생각만 하면서 시간을 보냈다. 그러다가 한 크루가 이것을 만들었다는 얘기를 듣고, 해당 크루 것과 Formik 라이브러리를 참고하면서 만들었는데, 참고를 많이 하긴 했지만 그래도 기분은 좋다.
이것을 하기 전에 context로 관리하는 것이 왜 좋은지 알지 못했기 때문에 꺼려졌었다. 그냥 useForm같은 훅을 만들어서 사용해도 똑같이 가독성을 챙기면서 구현할 수 있을 것 같았다. 하지만 분명한 차이점을 깨달았다. context로 만든 Form은 자식 컴포넌트를 두어도 그 자식 컴포넌트 안에서 이 메서드를 사용할 수 있다. 하지만 useForm으로 하게 되면 props로 모두 내려줘야 한다. 이러한 차이점이 존재하기 때문에 context가 더 좋다는 생각을 하게 되었다. 하지만 자식 컴포넌트를 만들지 않는다면 굳이 context로 관리할 필요는 없어보인다.
현재 만든 Form에서는 onChange 이벤트가 발생할 때마다 setValue를 하고, validator가 존재하면 validator도 호출하면서 해당 인풋에 에러가 발생했는지 검사한다. 그래서 setErrorMessage도 같이 하고 있다.
하지만 setErrorMessage를 하는 부분과 setValue를 하는 부분의 함수를 분리해야겠다고 생각을 했고, 분리를 했더니 서로 가지고 있는 값이 달라서 한 박자 느리게 에러 메시지가 업데이트되는 것을 발견했다.
onChange는 이벤트이기 때문에 event.target.value로 값을 곧바로 받아올 수 있지만 setErrorMessage는 다른 함수이기 때문에 onChange에서 가지고 있는 value를 넘겨받아야 한다. 하지만 뭔가 좋아보이지는 않았다. 왜냐하면 onChange에서는 이미 setValue를 하고 있기 때문이다.
setValue를 했기 때문에 업데이트 된 value로 하고 싶었는데, setValue가 비동기이기 때문에 불가능한 것 같았다. 그래서 useRef를 써서 어떻게 해보려고 했는데 더 안좋은 방법 같아서 다시 돌렸다.
아직 이 부분은 많이 고민을 해봐야 할 것 같다. 사실 setErrorMessage를 할 때 value를 넘겨주기만 하면 끝난다.
context api를 사용해서 여러 컴포넌트를 만들고 있는데, 알면 알수록 더 어려운 것 같다. 엄청난 장점이 있어서 사용하는 것은 아니고, 경험을 해보고 있다. 지금 아니면 언제 해보겠냐는 생각으로 하고 있는데 얻는 것에 비해 너무 시간을 많이 쏟는 것 같다. 내일부터는 면접 준비를 하려고 한다.
