Diary

@ssig33

04 Sep 2017 Mon 18:26

redux-api-middleware についてのものすごく表面的な理解

この週末自作 Web アプリに redux と redux-api-middleware を入れるということをやっていた、特に redux-api-middleware はよく理解してなかったので。これまで俺がどうしていたかというと、通信にかんすることは他のコンポーネントにぜったいに影響を与えさせないみたいなことを維持させて axios でアレするのと redux を使うのを併用するみたいな地獄みたいなことしてた、 redux-api-middleware 使うとコードの見た目キモくて嫌いなんだ、、、でもそうも言っておられん社会情勢なので、、、

背景

redux-api-middleware という名前について

redux ではフローの中で副作用を扱うことを禁止している。この為 API アクセスとかは出来ないので、それをなんかこう上手いところやってくれる middleware という仕組みを用意している。

公式ではロギングを例になんかまあいろいろ説明を書いてくれている。ちなみに読んでない。なんでロギングを例にするんだ、あきらかにみんな興味あるのは HTTP アクセスでしょ、こういう微妙に利用者に嫌がらせっぽいことしてくるのが気に食わない、、、

API アクセスという副作用を伴う作業をうまいところやってくれるライブラリが redux-api-middleware

どう使うのか

action creator 側に以下のように書く

import { CALL_API } from 'redux-api-middleware'

export default {
  load: ()=> {
    return {
      [CALL_API]: {
        endpoint: '/api',
        method: 'GET',
        types: ['REQUEST', 'SUCCESS', 'FAILURE'],
        credentials: 'same-origin',
      }
    }
  }
}

このようにしたあと、ふつうに load を dispatch する。 CALL_API とかそういうのはもうそういうもんと思っておく!!!

credentials: 'same-origin' をつけないと Cookie を使ってくれない。

types というのは reducer が受け取る action type 。リクエスト開始されると一番目の名前でアクションが、完了すると二番目の名前でアクションが、失敗すうと三番目の名前でアクションが発生する。

なのでリクエスト成功して state 更新したいときは reducer には

const reducer = (state = initialState, action)=>{
  switch(action.type){
    case 'REQUEST': 
      return {
        loading: true
      }
    case 'SUCCESS':
      return {
        data: action.payload
      }
    case 'FAILURE':
      return { fail: true }
    default:
      return state;
  }
}

これでコンポーネント側では this.props.loading が true ならローディングインジケーターを出して this.props.fail が true ならエラーメッセージを出して、あと this.props.data になにか入っとけばそれでなにか表示する みたいにすればいい。

感想

内部とか、 redux の middleware の根本的な仕組みとか一切理解しなくてもわりと表層的な理解でガシガシ書けるのでいい気はする。する、、、、