[TIL] 24_0214 세번째 프로젝트를 마치며, prop-drilling-context-redux

-세번째 프로젝트를 마치며, 

휴먼에러로 삽질만 몇 번을 했는 지 모를 2일을 보내고 다른 2일간은 prop-drilling, 1일은 redux로 개선하는 시간을 보냈어.

첫번째 삽질만 아니었어도...하지만 의미있는 삽질이었어. ㅎㅎ

 

prop-drilling-context-redux

처음 prop-drilling할 때 휴먼에러로 고생한 것과 초기 state 데이터 형태가 배열과 객체로 따로 관리되서 setState로 변한 값을 설정해줄 때 데이터 형태를 어떻게 뿌려줄 지 무지 고민했던 것 같아. 

 

contextAPI를 사용해서 state를 공유하니까 정말 세상 편하지 않을 수가 없더라. prop-drilling에서 답답했던가 1차로 싸악 풀렸어. 하지만 최상위 컴포넌트에서 state를 보내주려고 하니까 왔다갔다해야해서 불편했어. 어쨌건 최상위 컴포넌트에 필요한 다량의 데이터들을 죄다 몰아서 놓아야하니까 가독성도 좀 그랬고ㅋㅋ.. 그래도 prop-drilling에서 답답했던 거에 비하면 정말 관대해지지..

 

redux를 사용하면서 필요한 state를 한 번에 불러오니까 정말 편했어. 연산이 간단하고 여러 군데에서 쓰이는 함수도 리듀서에 넣고 한 곳에서 공유해서 쓰니까 편했어. 가독성도 좋아지고. 규칙성있게 설정해줘야하는 게 일관되서 편하긴 해도  왔다갔다 설정해줘야하는 게 많아서 그 부분에선 리듀서와 파일을 잘 분배해야할 것 같아.  

 

 

 

사용하면서 느낀 styled-components의 단점과 장점 그리고 전역 상태 관리

- 사용하면서 느낀 styled-components

장점 : js로 props를 받는 조건을 주기도 하고 해당 프롭스를 받아서 적용시켜서 css를 동적으로 주기 편해.
단점 : js로 표현하는 문장이 있으면 길어져서 가독성이 떨어집니다. 쓸 때마다 태그의 이름을 지어줘야해서 이름짓기가 불편한 것 같아.

 

 

- 전역 상태 관리

prop-drilling으로 전체를 먼저 구현한 다음 context api와 redux로 리팩터링해서 전역 상태 관리를 경험해 봤는데,. 
공통으로 쓰이는 state와 해당 state가 변할 때 같이 변하는 상태들을 관리했어.

 

context, redux를 사용하면서 prop-drilling을 다시 생각해보면,

어디에 어느 props를 줬는 지 잊기도 하고 컴포넌트에 문제가 생기면 어느 props의 문제인 지 부모 컴포넌트들 찾아가서 수정해야하고 자식 컴포넌트에서 필요한 state가 있으면 또 부모 컴포넌트에 가서 끌어와야하는 게 불편했어. 그런데 context, 리덕스는 전역으로 쓸 수 있는 state를 주고 해당 상태값이 변하면 서로 영향을 주도록 상태를 공유가 가능하니까 부모나 자식 컴포넌트나 재사용 컴포넌트에도 필요한 state값을 불러서 쓸 수 있어서 좋았지. 리덕스는 store에서 쓰이는 state값 뿐만 아니라 함수의 기능도 공유할 수 있어서 컴포넌트 별로 쓰기 좋고 가독성도 좋아지게 해주는 것 같아. 

 

 

 

느낀점

- 이상한 휴먼 에러로 쓸데없는 시간을 2일이나 보낸 것 같았는데 그래도 그간에 이런 오류가 왜 나고 왜 생기는 지 살펴볼 수 있었어. 그 휴먼 에러가 단순한 오타가 아니라 다른 곳에 있어야할 코드를 복사해두고 그걸 필요하지 않은 곳에 삽입해놓는 휴먼 에러가 정말 그냥 보통일은 아닌 것 같아ㅋㅋ 그 코드 하나로 어떻게 절대 그럴리 없어!!했던 파일에서 발견해서 찾는데 오래 걸렸지 뭐람..

- 이젠 어디서 휴먼에러 났는 지도 보면 알 것 같아ㅋㅋ..하..