2018년 회고

살면서 가장 빠르게 1년이 지난 것 같다.

학원에서 살다시피 3개월을 보냈고, 구직에 스트레스 받으면서 한달정도 보냈고, 남은 8개월은 회사에 다니면서 보냈다.

올해 뭘했냐 생각해보면 꽤나 많은 변화가 있었던 것 같은데, 누구나 그렇듯이 모든게 만족스럽게 되고있지는 않은 것 같다.

개발 공부를 하면서 스스로 만족이 안될 때 마다 공부를 더하고 싶다 라는 생각이 문득 드는데

작년에 이런 생각이 들어서 학원을 다녔던 것 같고, 올해가 끝나갈 때도 비슷한 생각이 들었다.

마침 학교로 돌아가라는 시그널 여러개가 동시에 들어와서 좀 찾아보니까 힘들긴 해도 준비만 잘 하면 될 것 같다.

사실 학교로 돌아갈 생각이 전혀 없었는데, 왜인지 다시 가보고 싶단 생각이 조금씩 생겨나고 있다.

계획을 세워보면 당장 내년에 복학하기엔 조금 무리가 있을 것 같고, 내후년 정도로 계획해서 준비하면 좋을 것 같다.

한게 없어서 회고랍시고 하나하나 찝어서 돌아볼 수 없는게 아쉽긴하지만, 후회는 없음.

목표를 세우자면

우선 내년엔 타입스크립트, 스토리북 등 안써본 것들을 많이 시도해 볼 예정이고

블로그 주에 최소 3회정도는 포스팅하면서 정리하는 습관을 만들어야겠다.

운동도 꾸준히하고, 영어공부, 개발공부도 열심히해야겠다.

쓸말이없넹, 끝!

redux-saga란?

우선 redux-saga에 대한 설명은 과감히 생략..ㅋㅎㅋ

사가를 써보기로 한 사람중 대부분은 공식 문서를 읽고 왔을 것이라 생각하고
어느정도 돌아가는 흐름은 알 것이라 생각해 따로 적지 않음.

흐름은 어느정도 알겠지만 코드에 적용하기 힘들어서 구글링 하다가 이 블로그까지 오게 되셨을거라고도 생각하니
리덕스 사가를 왜 어떻게 사용하는지 아주 짧은 경험을 바탕으로 적을 예정.

당연히 틀린 부분이 있을 수 있으니 항상 의심하면서 읽으시고
내 생각과 다른 부분이 있다면과감하게 지적 부탁드립니다.,ㅎㅎ

redux-saga를 사용하기로 한 이유

이전엔 리덕스 redux-thunk를 쓰면서 액션쪽에 비동기통신 코드가 번잡하게 들어감에 따라 파악하기 힘들다.
물론 모듈화를 제대로 안한 문제도 있긴 하지만..

사실 다른 프로젝트를 개발할 때 충분히 thunk를 사용할 수 있기야 하겠지만,
만들면서 맘에 들지 않았던 부분은 action이 dispatch만 하는것이 아니라 로직을 담고 작업을 수행한다는 점이였다.

결국 위아래 두가지 이유가 같은 맥락이긴 한데
정리하면 action이 본인의 역할 이외에 다른 영역까지 넘어간 부분이 뭔가 찝찝하고도 구린듯한 느낌
thunk의 다른 단점도 있겠지만 종합하면 redux의 철학을 보존하면서 사용하지 못한 것 같다.

그 다음부턴 뻔한 스토리, 이를 해결해주는 saga를 알게됐고 사용해보려 했다

redux-saga의 흐름

예를통해 설명해보면,
버튼을 클릭하면 1초뒤에 카운터가 1만큼 늘어나는 로직을 짜고싶을 때
redux-thunk와 redux-saga의 흐름을 비교해보자.

구성
버튼을 클릭하면 숫자가 1이 늘어나는 AddToCounter액션이 있고,
여기서 액션은 request, success, failure로 구분지어 있다. (효율적인 디버깅을 위해 구분지음 )
추가로 위에 설명한 프로세스를 진행하는 액션을 AsyncAddToCounter라 하자.

추가적으로 미들웨어 없이는 비동기 처리가 안되는걸로 알고있는데 확실하지 않은 정보임.
정확하게 아시는 분이 있으시다면 댓글 부탁드립니다..

redux-thunk

• 뷰에서 버튼을 클릭
• AsyncAddToCounter 액션을 props로 내린 이벤트를 실행
• AsyncAddToCounter 액션의 프로세스를 실행
• requestAddToCounter을 리듀서로 디스패치
• setTimeOut으로 1초뒤에 현재 count state에 1을 더한 값을 담아 successAddToCounter을 리듀서로 디스패치
  • “액션”에서 비동기 처리를 실행, setTimeOut의 경우 failure가 안나오기 때문에 현재 설명에선 패스
  • 일반적으로 Promise의 then, catch로 success와 failure을 나눈다.
• 리듀서에서 증가한 count state 값을 스토어에 업데이트
• 업데이트 된 스토어의 count state 값으로 뷰 업데이트

redux-saga

redux-saga에서는 위에서와 같이 프로세스를 담은 AsyncAddToCounter를 따로 만들지 않고,
바로 request를 디스패치하는 방식으로 진행.

• 뷰에서 버튼을 클릭
• `requestAddToCounter’ 액션을 props로 내린 이벤트를 실행
• 이벤트가 실행됨과 동시에 사가의 watcher가 디스패치된 액션을 take로 인지함.
  • 이 때 파라미터를 액션과 동시에 같이 넘겨줄 수 있으며, 이를 흔히 “payload”라 부른다.
• 사가에서 delay를 통해 1초 지연
  • 액션은 타입과 payload만 넘겨주는 용도로만 사용되고, 실질적인 비동기 로직은 “사가”를 통해 실행 된다.
• count state를 1 증가시킴
• 1초 뒤 put을 통해 업데이트된 count state를 담은 successAddToCounter 액션을 디스패치
  • 일반적으로 try, catch문으로 success와 failure을 나눈다.
• 리듀서에서 증가한 count state 값을 스토어에 업데이트
• 업데이트 된 스토어의 count state 값으로 뷰 업데이트

둘을 비교했을 때 시작과 끝은 같지만, 실질적으로 로직을 수행하는 부분은 액션과 사가로 명확하게 구분되어 있다.
리덕스 사가를 사용함으로써 리덕스를 구성하는 각자의 롤이 명확하게 구분되어 깔끔하게 코드가 정리됨.

나름대로 이해한 내용을 코드 없이 말로 쓰려니 더 어려웠는데,
틀린부분이 있을 수 있으니 피드백 부탁드립니다. 제발!

언젠가 코드를 추가할 예정..

redux-saga folder structure

프로젝트를 구성할 때 가장 고민되는 폴더구조

특히 리덕스 사가는 명확한 Best Practice가 없어 더욱 결정하기가 힘들었다.

가장 일반적으로 redux를 사용할 때 잡는 폴더 구조는 다음과 같다

src

• actions
• components
• containers
• reducers
• store

여기서 store 폴더를 없애고 상단의 엔트리인 index.js에 집어넣을 수 도 있다.

redux-saga를 사용하기 위해 사가들이 들어갈 sagas
Sass가 들어갈 폴더 styles
이미지, 폰트가 들어가는 폴더 assets
서버와의 통신을 위한 api가 들어가는 폴더 api
constant와 lib가 들어가는 폴더 utils를 추가해 아래 이미지와 같이 세팅했다.

이 구조가 베스트는 아니겠지만, 현재의 정보에서는 최선이라 생각했고,
그대로 프로젝트를 진행하려 한다.

추가로 더 나은 방법이나 구조가 있으면, 댓글 부탁드립니다.