[컴][js] redux-saga

redux-saga / redux saga / 사가 / 리덕스 사가


redux-saga vs await/async

"ref. 2 --> Why not use ES2016/Next async await?" 를 보면 saga 는 await/async keyword 를 대신해서 사용할 만한 방법인듯 싶다. 다만 이글에서도 언급하고 있지만, 글 자체가 최신의 redux-saga 의 내용이 아니기에 일단 정확한 확인은 필요하다.

await/async 보다 나은점

  1. test case 작성에 유리 : ref. 2 에 따르면 await/async 보다 유리한 점 하나는 request 를 시도할 때 await/async 는 직접적으로 request/fetch 함수를 호출하지만, redux-saga 에서는 call 을 호출하고 관련 parameter 만 전달하기 때문에, test case 를 만들 때 그 함수를 mock up 으로 대체할 수 있다 정도인 듯 싶다.
  2. browser 지원 : 브라우저에서 아직 await/async 를 공식적으로 지원하지 않는다. redux-saga 에서 사용하는 generator 에도 문제는 있다. "generator 에 대한 browser 의 지원"도 모든 브라우저에서 완벽하게 지원하지는 않는다.(적어도 IE 는 전혀 지원하지 않는다.) 그래서 이 경우에는 polyfill 을 따로 다운로드 해야 하는데, 그 파일의 용량이 크다.[ref. 3]

Redux Saga chooses generators over async/await

  • https://redux-saga.js.org/ --> Redux Saga chooses generators over async/await
  • redux-saga 가 async/await 를 안쓰고 generator 를 쓰는 이유를 알려준다. 
    • 스케쥴링의 간단함(scheduling simplicity)과 Promise를 사용하는 현재 Saga 개념들의 semantics 를 유지하기가 어려워진다.
    • async/await 은 간단하게 cacellation 같은 것들이 불가능하다.
    • generator 를 쓰면, effect 들이 언제, 어떻게 실행되는지를 통제할 수 있다.

redux-saga examples

Saga

saga 에 대한 설명은 See Also 2, 3 에서 확인을 하자. 

대체로 saga 는 분산시스템에서 쓰이는 transaction 방식을 이야기 하는 듯 하다. 

만약 분산시스템에서 여러개 transaction 를 수행한다고 하면, 이 여러개의 transaction 이 crash 가 났을 때 roll back 하는 법이 (compensate) 있는 것이다. 그래서 만약 1번째 transaction 부터 3번째 transaction 까지는 잘 동작하고, 4번째 transaction 에서 crash 가 나면, 다시 3번째 transaction 이 완료된 시점으로 가서, 다시 4번째 transaction 을 실행하는 것이다.[see also 3]

See Also

  1. Read Me · Redux-Saga
  2. Confusion about Saga pattern - Roman Liutikov - Medium : saga 에 대한 설명
  3. Clarifying the Saga pattern  by kellabyte, 2012-05-30 : saga 에 대한 설명

References

  1. 5. External Resources · Redux-Saga: 여러가지 Redux-Saga 와 관련된 글들을 확인할 수 있다.
  2. Handling async in Redux with Sagas, 2016-01-23
  3. Master Complex Redux Workflows with Sagas, 2016-02-02

댓글 없음:

댓글 쓰기