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를 추가해 아래 이미지와 같이 세팅했다.

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

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

일일이 웹팩, 바벨을 손보는 시간을 아껴서 개발에 투자하기 위해 react CLI인 create-react-app을 사용해 프로젝트를 생성

현재 18년 11월 기준으로 create-react-app은 version 2로 업데이트 되면서
Webpack 4, Babel7 , PostCSS, Sass 등을 기본적으로 지원하게 되었고
v1과 비교했을 때 추가적인 기능을 사용하기 위해서 웹팩에 따로 세팅한 부분이 없었다.

create-react-app (프로젝트명) 으로 프로젝트를 생성하면 간단하게 최신버전으로 프로젝트가 만들어지고,
yarn start 명령어를 통해 3000포트로 리액트 앱을 띄울 수 있다.

현재 토이 프로젝트로 진행중인 쇼핑몰 프로젝트의 package.json은 다음과 같다.

{
  "name": "mall-front",
  "version": "0.1.0",
  "private": true,
  "dependencies": {
    "axios": "^0.18.0",
    "classnames": "^2.2.6",
    "cross-env": "^5.2.0",
    "i18next": "^11.9.1",
    "i18next-browser-languagedetector": "^2.2.3",
    "node-sass": "^4.9.3",
    "react": "^16.5.2",
    "react-dom": "^16.5.2",
    "react-i18next": "^8.0.8",
    "react-redux": "^5.0.7",
    "react-router-dom": "^4.3.1",
    "react-scripts": "2.0.4",
    "redux": "^4.0.0",
    "redux-saga": "^0.16.0"
  },
  "scripts": {
    "start": "cross-env NODE_PATH=src react-scripts start",
    "build": "cross-env NODE_PATH=src react-scripts build",
    "test": "cross-env NODE_PATH=src react-scripts test",
    "precommit": "lint-staged",
    "eject": "react-scripts eject"
  },
  "eslintConfig": {
    "extends": "react-app"
  },
  "browserslist": [
    ">0.2%",
    "not dead",
    "not ie <= 11",
    "not op_mini all"
  ],
  "lint-staged": {
    "*.js": [
      "prettier --trailing-comma es5 --double-quote --write",
      "git add"
    ]
  },
  "devDependencies": {
    "husky": "^1.1.0",
    "lint-staged": "^7.3.0",
    "prettier": "^1.14.3",
    "redux-logger": "^3.0.6"
  }
}

패키지 각각에 대한 용도는 다음과 같다.

1. dependencies

• axios - 비동기 통신
• classnames - react의 className을 편하게 사용하기 위함
• cross-env - 프로젝트의 환경변수 및 경로 시작점을 정하기 위함 / src 폴더를 기준으로 절대경로를 작성해 import 시 상대경로 위치를 고민할 비용을 줄임
• i18next - 페이지 번역을 위한 라이브러리 ( 한/영 페이지 구성 )
• node-sass - Sass 사용
• react-router-dom - 리액트 라우터 v4
• redux, react-redux, redux-saga - 리덕스, 리덕스 사가
• redux-logger - redux 흐름 파악
• husky, lint-staged, prettier - 커밋이 되기 전 코드 스타일을 통일 시키기 위함

1. scripts

• src를 기준점으로 스크립트 시작, 빌드, 테스트를 실행 할 수 있도록 변경
• 프리커밋을 통해 lint-staged의 내용대로 코드 스타일 자동 변경
• eject - 안할예정..

1. lint-staged

• —trailing comma es5 - 객체나 함수, 배열 등의 마지막 인자 뒤에 콤마를 붙임
• —double-quote - 쌍따옴표 사용
• git add - 커밋 전에 lint-staged를 실행

나머지는 기본값을 그대로 유지

번역 라이브러리를 제외하고 위와 같은 세팅값을 가지기 위한 커맨드
yarn add axios classnames cross-env node-sass react-redux react-router-dom redux redux-saga
yarn add --dev husky lint-staged prettier redux-logged

이렇게 프로젝트는 세팅 완료.

React 설치

패키지 매니저 npm 또는 yarn을 통해 설치

yarn이 더 빨라서 yarn을 통한 설치방법을 알아보자.

yarn 설치

우선 npm이 설치되어 있다는 가정하에 순서를 적어보면,

npm install --global yarn, homebrew가 깔려있다면 brew install yarn을 통해 yarn 설치 ( 자세히는 모르지만 후자로 설치하는것이 이슈가 덜 발생하는것으로 알고잇음 )

yarn 업데이트 방법은 yarn self-update이다.

yarn init

터미널에서 프로젝트 파일로 들어간 뒤 yarn init으로 package.json 파일을 생성한다.

npm과 같이 이 파일은 프로젝트에 관한 정보를 담고있다.

그 다음으로 yarn add react 를 통해 프로젝트에 리액트를 추가할 수 있다.

이 때 yarn.lock 파일은 현재 프로젝트에 설치된 패키지의 일관성을 보장하기 위해 버전과, 종속성을 적어두는 역할을 한다.

패키지를 삭제할 땐 yarn remove (패키지명)

패키지를 업데이트할 땐 yarn upgrade (패키지명)를 사용

react 설치 라는 말이 어색한데 붙일말이 딱히없음.,

React??

앞으로 쓰게될 React.js에 대해 아주 늦게 첫 발을 디뎠다

새로운 스택을 익히려 하는데 아무리 글을봐도 이해가 안되는 나의 머리를 탓하며 아주 쉽게 정리해보려 함

혹시라도 이 글을 보시게 된다면, 틀린부분이 있을 수 있으니 한번쯤 의심하면서 보시고

틀린부분은 바로바로 지적해주시면 감사하겠습니다

정리하는 글이기에 반말로 적겠습니다.

리액트란?

페이스북에서 만든 사용자 인터페이스 라이브러리

절대적으로 View단을 구성하기 위한 라이브러리이다.

리액트를 만든 이유?

기존 MVC패턴은 확장이 어렵고 거대한 시스템에 어울리지 않는다는 생각을 하게된 페이스북은 새로운 대안으로 Flux라는 데이터 흐름이 단방향인 시스템 아키텍쳐를 만들었다.

이 Flux는 “새로운 패턴이 아니라 MVC의 새로운 이름일 뿐이다” 라는 논란도 일었지만,

둘의 가장 큰 차이는 데이터 흐름이 단방향이라 더욱 직관적이고, 관리하기가 쉽다는 점이다.

리액트의 특징

1.JSX

템플릿을 사용하지 않고 고유의 XML확장 문법인 JSX를 사용한다.

쉽게 이해해 자바스크립트에서 HTML코드를 쓸 수 있게하는 문법이다.

이렇게 작성한 코드는 Babel을 통해 별도의 컴파일 없이 사용 가능하다.

2.Virtual DOM

기존에 DOM을 직접 핸들링하는 제이쿼리는 페이지를 새로고침하면 페이지의 모든 요소를 새로 렌더링하는 반면에,

리액트는 Virtual DOM(가상돔)을 사용해 변화가 있는 부분을 비교해 최소한의 요소만 다시 렌더링하게되어,

보다 빠른 속도로 화면을 보여줄 수 있다.

3.One Way Data Flow

데이터는 위에서 아래로만 흐르기 때문에 구조가 커졌을 때 양방향 바인딩에 비해 데이터의 흐름을 파악하기가 쉽다.

4.Server Side Rendering

클라이언트에서만 렌더링을 하면 HTML, JavaScript, Data, View 순으로 진행하는 시간 소요로 초기구동 속도가 느리고,

자바스크립트를 실행못하는 검색 엔진 봇들은 처음 렌더링 된 빈 HTML만 수집하기 때문에 콘텐츠가 없다고 판단되어 SEO에 취약하므로, 서버 렌더링을 지원한다.