Help us understand the problem. What is going on with this article?

redux-sagaを利用して良かったこと

前書き

今携わってる案件で初めて redux-saga を使ってみたんですが
思いのほか良かったので前回に引き続き記事化しました。

redux-sagaという言葉は良く聞くけど、結局どう良かったの?と言う部分が伝われば良いかと思います。

redux-sagaの利点

redux-sagaは react redux環境での非同期処理をサポートするライブラリの一つです。
テストのしやすさ、アクションをピュアに保つと言った利点があります。

ただ、Noobな私は説明を読んでもあまりピンときませんでした。
なので私の言葉でredux-sagaを使って良かった点を挙げていければと思います。

今回redux-sagaを利用して良いと思った点
  • 非同期通信処理をAction部分から切り分けられた
  • 非同期通信処理をする際、リクエスト用の値をStoreから簡単に取得できた
  • 非同期通信処理の連打回避やローディング処理を簡単に実装できた

せっかくなので、ひとつひとつ見ていきましょう

非同期通信処理の切り分け

いままで僕はredux-thunkを使っていましたが
redux-thunkを使うとき、actionCreatorに非同期通信処理を書いていました。

ただ、非同期通信部分って処理が増えがちですよね。
例えば

  • リクエスト用に渡す引数の準備
  • ローディングの開始処理
  • APIコール
  • レスポンスの受け取り
  • レスポンスをフロント側で使いやすいような形にする変換処理
  • ローディングの終了処理
  • 失敗時の処理

などなど

非同期通信が少なければまだ良いですが、通信処理が複数になると大変です。
actionCreatorは急速に肥大化し、そこに手を入れる度に微妙な心持ちになるわけです。
非同期通信と同期通信の記述が入り混じり、カオス状態です。

ではredux-sagaを使うとどうなるでしょうか。
今回のファイル構成を軽く見てみましょう。

store
  - modules
      - user
          - actions.ts
          - actionCreators.ts
          - state.ts
          - index.ts
          - sagas.ts
          - reducer.ts
      - hoge
      - huga
  index.ts
components
containers
misc

userストアの中にsagasが確認できますね。
いままでationCreatorsに書いていた非同期通信は全てこの中に書いています。

結果としてactionCreators及びactionsは非同期通信処理から逃れることができ、とてもスリムになりました。

設計次第ではありますが、これでファットなactionCreatorに会うことはほぼ無くなるでしょう。

sagasもある程度肥大化しますが役割が切り分けられてるので精神的に楽です。
「あああー、あの雑多なactionCreatoreとactionsを触らなきゃいけないのかー」
と思うことが無くなったのは素直に嬉しかったです。

Storeからの情報取得が簡単

次にこれです。
皆さんmapDispatchToPropsの中でStoreの情報を利用したい時どうしているでしょうか。

  • mapStateToPropsで渡してバケツリレー
  • mergeProps
  • redux-thunkのgetState

などの方法があると思います。

バケツリレーは健全な感じがするんですが
コードを見る時Propsを追って2,3ファイル移動したりすると分かりにくいですよね。
なによりmapDispatchToPropsで利用したい時など、mapStateToPropsからコンポーネント越しに値を渡すのは微妙な感じがします。

mergePropsもコンポーネントで操作があった際、storeの中身が最新状態になっているかどうか気になりますし、propsに渡す物が雑多に放り込まれる感覚がするため個人的に好きではありません。

そこでsagasのselectメソッドが活躍します。
sagasを利用した非同期通信部分限定となりますが
selectメソッドを利用すれば簡単にStoreを取ってくることが可能です。

  const { token } = yield select((state: RootState) => state.config)

上の例のようにconfigストアに格納したtoken情報を利用する時も簡単です。
RootStateを取ってこれるので複数のStoreから情報を取りたい時もお手の物です。

このメソッドは本当に助かった。。。

非同期通信処理の連打回避やローディング処理実装

ここに関しては前回書いたtakeLatest部分なのでこちらお読みください。
非常に簡単に連続したAPIコール回避やローディング処理を実装できました。
記事こちらです。

redux-sagaを使ってみて

去年hooks が普及してから redux が無くなっていくと言われていましたが
react redux typescript redux-saga を使った開発をすると
1つのアプリケーションの開発環境として魅力的に思えました。

1年後同じことを言ってるかわからないですが
非同期通信がそれなりにある案件がきたら
また、redux-sagaを利用した環境でやりたいと思っています。

お読みいただきありがとうございました。

EndouT6
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
Comments
No comments
Sign up for free and join this conversation.
If you already have a Qiita account
Why do not you register as a user and use Qiita more conveniently?
You need to log in to use this function. Qiita can be used more conveniently after logging in.
You seem to be reading articles frequently this month. Qiita can be used more conveniently after logging in.
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away
ユーザーは見つかりませんでした