2023.12.24 ~ 2023.1.2
Pair-2: Kimi - Levi - Ann
- RHF를 활용하여 회원가입 토이 프로젝트 만들기 + 생각해보기 정리하기
- 나만의 보일러 템플릿 만들기
- 느슨한 관계와 의존성 주입에 대한 관계에 대한 사례 만들기
- 스파게티 코드 리팩터링 하기
[2023.12.26(화)]
나만의 보일러 템플릿 만들기를 해보았습니다.
mui 설치 후 useContext error가 나서 mui library를 사용하지 못하였습니다. 공식문서를 읽어보고, 구글링도 해보았지만 해결을 하지 못했습니다. 전에 프로젝트 진행할 때도 같은 issue가 있어서 chakra library를 사용했었는데, 왜 이런 오류가 나는지 아직 모르겠습니다ㅠㅠ
Kimi 회고록)
나만의 보일러 템플릿을 만들면서, 내가 왜 이런 폴더를 만들었었는지
이런 파일명을 사용했는지 다시 한 번 되돌아보는 기회가 되었습니다.
ex.그 전까지는 consts폴더도 아무런 생각 없이 만들었는데,
이번에는 파일을 만들 때 어디에 넣을지, ui 라이브러리를 추가하면서도
왜 이 폴더의 이 파일명으로 작명해야하는지 생각을 하면서 했습니다.
eslint와 prettier 파일을 설정하면서 그 안의 속성들에 대해서
다시 공부하였습니다.
mui를 깔면서 저번에 mmm 프로젝트 할때도 만났던 오류를 만났는데,
이번에도 해결을 하지 못해서 무지 화났습니다...
Ann 회고록)
금일 보일러 템플릿 만들기 과제중에서 파일만들기와 설치를 하였습니다.
그간 사용하지 않았던 eslint, pettier를 해보려니 기억이 가물가물했습니다.
이번 과제를 통해 다시 짚어가는 계기가 되었습니다.
또한 보일러 템플릿을 처음에 들었을때는 어떤 의미 일까 고민을 많이 했는데
페어분들과 하나씩 만들어가면서 쉽게 이해할 수 있었습니다.
진행 과정 중 mui에서 진짜 생각치 못한 오류를 만났는데 해결이 안되더라구요..
바로 전 주에 썼는데 같은 내용인데 사용한 적 없는 오류가 생겼고,
구글링과 여러 방법을 사용했지만 쉽게 해결 되지 못하고 결국 다른 라이브러리로 사용하게되었습니다.
Levi 회고록)
평소에 코드를 작성할때 eslint와 prettier를 사용하지 않았는데 이번에
보일러 템플릿을 만들면서 eslint, prettier를 사용해볼수 있어서 좋았습니다.
[2023.12.27(수)]
---프로젝트.....🥹---
[2023.12.28(목)]
리액트 훅 폼을 사용하여 보다 편리하게 회원가입 로직을 만들수 있었던거 같습니다.
kimi 회고록)
하나 해결하면 하나가 에러가나...
useState와 연동을해야 될 거 같은데 모르겠다..
다음페이지 랜더가되면 뒤로가기가안되고 뒤로가기가 되면 랜더가 된다 ^^
useSearchParam 과 useEffect useState를 더 알아봐야겠다.
onClick 이벤트 때문에 애먹었는데 ...rest로 내려줄수 없었다니 충격...(rin님이 알려주셨다😍)
Ann 회고록)
금일 RHF과 YUP 이 두가지 라이브러리를 사용해보았습니다
유효성 검사하는 부분이 어렵지 않게 되어있어서 사용하기 어렵지 않았습니다.
사용하면서 공식홈페이지에도 정리가 잘 되어있어서 보고 따라하기 쉬웠습니다.
RHF과 YUP를 써보면서 YUP이 좀 더 가독성도 좋고 파일을 따로 분리해서 유지보수도
용이 할 것 같다 생각했습니다.
하지만 문제는 useSearchParam 부터 많이 막혔던 것 같습니다 오류도 많이나고
계획했던대로 이벤트가 일어나지 않아서 조금 혼란...
Levi 회고록)
[2023.12.28(금)]
(1) RHF를 사용했을 때의 장점에 대하여 정의하기 (2) 만약 유효성 검사를 하지 않는 곳에서 RHF를 사용하는 것은 올바른 행위일까? (3) RHF에는 register 말고 contoller를 활용하는 방법이 있습니다. 두 방법의 차이는 무엇일까?
* react-hook-form 의 지속적인 업데이트와 더욱 빠른 마운트 속도 차이가 현재의 차이를 만들지 않았나 싶습니다.
mode 옵션은 validation 전략을 설정하는 데 활용합니다. onSubmit, onChange, onBlur, all 등의 옵션이 있습니다. 주의해야 할 점은 mode 를 onChange(실시간) 에 놨을 때 다수의 리렌더링이 발생할 수 있어 성능에 영향을 끼칠 수 있다고 합니다.
제어 컴포넌트로 폼을 다루기 위해서 하나하나 state 를 선언해주고, 해당 state 를 다루기 위해서 또 핸들링 함수를 만들어야 하고, 에러를 위한 state, 또 검증을 위한 함수.. 지금은 아주 단순한 validation check 만 했기 때문에 코드가 간소화 되었지만, 모든 유효성 검증을 한다면 코드는 더더욱 길어질 것입니다.
rhf를 사용하지않을 시 코드의 길이도 문제지만, 또 다른 문제점이 있습니다. React 에서 컴포넌트 리랜더링이 발생하는 조건 중 하나는 state 의 값이 변했을 때 입니다. 현재 폼에선 모든 값이 state 로 연결되어 있으며 하나의 값이 변할때 마다 여러개의 자식 컴포넌트 들에서 무수히 많은 리랜더링이 발생합니다. 이는 개발자가 예측한 랜더링이 아닌, 불필요한 랜더링으로서 불필요한 연산으로 생각할 수 있습니다.
여러분들은 이 단순한 폼을 처리하기 위해서 너무 많은 state 와 함수가 담겨져 있다고 생각하지 않나요?
input 의 초기값은 undefined */
kimi 회고록)
리팩토링이라는 것을 어떻게 하는지에 대해서 알게 되었습니다.
어떻게 하면 데이터를 유지보수할 때 편한지(마지막 값 length주기)
consts폴더에서 data값을 배열로 관리하여서 map돌리는 거도
가독성도 좋고, 재사용할 수 있다는 장점을 알게 되었습니다.
제가 pagination 할 때, 이상하게 시간을 쏟았던
number나 string타입에 대한 정의들,(typeof 찍어서 알아보기..)
useSearchParams에 대해서 제대로 알게되었습니다.
제일 좋은 것은 직접 코드 쳐보기^^..!
각 함수의 상세를 들어가서 객체의 타입을 어떻게 가져오면 좋은지
참고하면서 진행하고 있는데, 좋은 거 같습니다.
rhf와 yup에 대해서 알아보고 들어갔어야했는데,
바빠서..진짜 바쁘했는데 아침에 시간을 낼 수 있었는데.. 잤습니다.
잠을 줄여서 라이브러리 공부를 더 해야겠습니다.
라이브러리 공식문서와 친해지기..ㅜㅜ!!
=> 내일 무조건 라이브러리 공부에 2시간 쏟기..!
Ann 회고록)
useSearchParam에 대한 학습을 미리 하지 못해서 다른 페어분들이 먼저 사용한 로직을 이해하는데
조금 어려웠던 것 같습니다 얼른 파악하고 오는걸로... 피넛님 덕분에 1:1 코칭 받아서 저희 로직은
이해되었지만 앞으로 제가 사용하려면 제가 사용하면서 파악하는 걸로....
아직 뒤로가기 데이터 유지가 남았는데 오늘 해결하지 못했습니다..
내일은 꼭 마무리 되고 다음 과제로 넘어가면 되겠ㅠ
Levi 회고록)
[2023.12.28(토)]
kimi회고록)