Final Project도 끝이 나가고, 정리를 해볼 겸, 스택을 사용했던 이유에 대해 블로깅해보려 한다!
JS, React
6개월 간 코드스테이츠 학습으로 익숙해진 스택을 그대로 사용하여 생산성을 높이고자 함, 초기 프로젝트의 기획은 TS를 이용할 예정이었으나, 기획 내용을 보고 제한된 기간 안에 새로운 스택을 공부하여 프로젝트를 진행하기엔 무리인 것 같다는 피드백을 받아들임. 확실히 익숙한 상태라 그런지 상당히 빠른 속도로 기획된 내용을 진행할 수 있었고, 추가적인 기능 부여도 고민할 수 있는 시간적 여유가 생겼었음.
프로젝트 기한이 없이 혼자할 때나, 사이드 프로젝트를 진행할 때는 안배웠던 스택들을 진행해봐도 좋을 듯
Axios
HTTP Ajax요청을 위해 사용한 라이브러리
위와 비슷한 이유인 듯하다, 아무래도 스프린트를 진행하면서 Axios를 자주 사용해왔고, fetch API 보다는 조금이라도 더 익숙한 axios를 사용했던 것 같다, 또 편리함 때문에 많은 이들이 사용한다고들 한다.
비교되어 있는 자료를 찾아보았다
| fetch API | axios | |
|---|---|---|
| 호환성 | 거의 모든 브라우저 지원 | 한정된 브라우저 지원 |
| Response TimeOut | 간단 | 복잡 |
| AutomaticJSON Data transfrom | 가능 | 불가능 |
어쨌든 결론을 보자면, 간단한 사용법으로 코드가 복잡해지는 것을 막아주고, 생산성을 높이기 위함이 이유인듯! 지금 시점에서 보면 fetch API가 IE를 미지원하는 것은 그렇게 큰 단점은 아닌듯 하나 사용법은 확실히 axios가 간편.
Redux
isLogin, user 정보 등 전역상태 관리가 필요한 정보들을 관리하기 위해 사용한 라이브러리, first project 때 엄청난 prop drilling을 겪으면서, state 중 하나만 수정해도 일일이 다 바꿔줘야하는 불편함이 있어 버그 픽스 등 유지보수가 힘들었고, Final project에서는 꼭 Redux를 사용해 전역관리를 함으로써 이를 피하고자 했음. 그런데 전역상태가 바뀌면 컴포넌트가 리렌더링되는 점이 있는 것 같은데, 이는 해결법을 찾아보려함.
Styled-Components
CSS-in-JS 라이브러리
파일의 부피가 커지는 것을 방지할 수 있고, 유니크한 클래스 이름을 생성해 오탈자로 인한 버그를 줄일 수 있고, 클래스 이름을 찾아다니며 스타일을 지정하지 않고, 컴포넌트로 관리하기 때문에 React에서 사용하기에 편리하다는 점 등의 장점이 잘 알려져있지만, 이번에 가장 크게 느낀 장점과 필요성은 props를 내려 사용해줄 수 있다는 점이다! 이 점을 통해 사용자 입력에 따른 색상 지정이라던지 비율의 변화 등의 기능을 추가할 수 있었다. 또 반응형 디자인을 위한 CSS 작성에서도 종종 사용되었다.
다른 CSS-in-JS와 장단점을 비교해봤을 때, 마냥 장점만 있는 것은 아닌 듯 하다, 다음 사이드 프로젝트를 진행한다면 sass나 material ui등 도 사용해보는 것도 좋을 듯 함! 하지만 이번 프로젝트에서 필요했던 기능은 Styled-Components가 갖추고 있었다!
rc-slider
색상의 비율을 선택할 수 있는 기능 구현을 위해 사용한 라이브러리, React-dnd로 드래그 앤 드롭으로 직접 controller를 만들어 보려했으나, redux와 흡사한 사용법... 꽤나 복잡했고 프로젝트 기한이 임박하였기에 다른 방법을 찾아보았다.
Slider를 주로 찾아보았는데, 대부분 handle이 하나인 형태였다. 프로젝트에 필요했던 것은 여러개의 핸들로 각각의 값을 가질 수 있는 것이어야 했고, 계속해서 구글링 하던 중 rc-slider를 발견했고 range는 정확히 원하던 기능을 가진 라이브러리였다.
