简化dva的设计流程

dva 首先是一个基于 redux 和 redux-saga 的数据流方案，然后为了简化开发体验，dva 还额外内置了 react-router 和 fetch，所以也可以理解为一个轻量级的应用框架

上面是dva官网对此框架的简介，使用了2年时间，让我体会到非常不错的用户体验。但我发现项目里有些代码写得太多，就像redux其中的一个缺点，模板代码太多了。

用过这框架的小伙伴都知道dva其中一个流程，model里执行副作用需要接受一个service返回的函数做参数，如:

// xxx.model.js
import { urlA } from 'service'
...
effects: {
  *funA({ payload }, { call }) {
    const res = yield call(urlA, payload)
    // 处理...
  }
}

// xxx.service.js
// config是配置接口信息的文件
import { getLangList, getAreaData, getCashVoucherList, getMsgList  } from 'config'
export function getLangList () {
  return request({
    url: findList,
    method: 'get',
  })
}

export function getAreaData (data) {
  return request({
    url: getAreaUrl,
    method: 'post',
    data: data,
  })
}

export function getCashVoucherList (data) {
  return request({
    url: cashVoucherList,
    method: 'post',
    data: data,
  })
}

export function getMsgList (data) {
  return request({
    url: msgList,
    method: 'post',
    data,
  })
}

...

不知大家写service的时候有没感觉总是在ctrl c + ctrl v，然后改url，总是在做重复的动作，总是在写request({url, method, data})，于是我打算将service生成request逻辑封装出来。根据开发经验我们的业务请求主要是两种method，get和post。我先做了一个约定，在书写配置时，带有?结尾的url为get请求，否则为post请求

// config.js是配置url的模块
module.exports = {
 // ...一堆配置
 preUrl: '/api', // 所有接口的共用前缀
 orderCar: {
   getOrderCount: '/limousineOrder/getOrderCount?',  // 约定是get请求
   fetchList: '/limousineOrder/findPage', // post请求
 }， // 命名空间为orderCar
 xxx: {
   xxx1: '...'
 }, // 命名空间为xxx
 // ...
}

/**
* @Descripttion: 
* @name: wjj
* @param {obj, obj || []} module: 模块空间名, opt: 配置
* @return: {obj} 函数对象
*/

// 缓存各命名空间下的service
const serviceMap = {}
// 简单自动生成service
export function createService (module, opt) {
 // 取缓存
 if(serviceMap[module]) return serviceMap[module]
 const urls = config[module]
 const { preUrl } = config
 if (!urls) return
 let funs = {}
 let method = 'post'
 const optString = Object.prototype.toString.call(opt)
 // 根据opt配置相应生成，form下的content-type为form-data,其他暂为json
 if(optString === '[object Object]') {
   let contentType = Object.keys(opt)
   contentType.forEach(ct => {
     for(const url of opt[ct]) {
       funs[url] = (data = {}) => {
         if(ct.toLowerCase() === 'form') {
           const formData = new FormData()
           Object.keys(data).forEach(d => {
             formData.append(d, data[d])
           })
           data = formData 
         }
         return request({
           url: `${preUrl}${urls[url]}`,
           method,
           data,
         })          
       }
     }
   })
 } else if(optString === '[object Array]') {
   // opt为数组时，遍历数组生成，都是content-type为json
   for(const key of opt) {
     let method = 'post'
     let value = urls[key]
     if (value.includes('?')) {
       method = 'get'
       value = value.replace('?', '')
     }
     funs[key] = data => request({
       url: `${preUrl}${value}`,
       method,
       data,
     })
   }
 } else {  
     // 默认配置全部生成一次
     for (let [key, value] of entries(urls)) {
       let method = 'post'
       if (value.includes('?')) {
         method = 'get'
         value = value.replace('?', '')
       }
       funs[key] = function (data) {
         return request({
           url: `${preUrl}${value}`,
           method,
           data,
         })
       }
     }
 }
 return funs
}

---

使用方式:

1. 命名空间下全部配置生成content-type为json请求，优点简单，缺点是跑多余的生成代码(可以添加缓存)

const urls = createService('equityDining')

2. 可根据两大contentType（form，json）分别生成指定配置，但写得多代码

const { batchListPreview, batchCreate } = createService('equityDining', {
  form: ['batchListPreview', 'batchCreate'],
  json:  ['findProjectCountPage'],
})

3. 若该空间下并指定的接口全部约定content-type是json，可简写成数组

const { sendSms, getRecord, getTempletContent } = createService('orderCar', ['sendSms', 'getRecord', 'getTempletContent'])

同事的方案

在model的副作用call的第一个参数执行一个封装好的函数，每次调用再生成相应service

// uitls.js
export function commonRequest(url, data, header) {
  let method = 'post'
  if (url.includes('?')) {
    method = 'get'
    url = url.replace('?', '')
  }
  return request({
    url: url,
    method: method,
    data,
  }, header)
}
// model
*delCombo ({ proload },{call, put}) {
    const result = yield call(commonRequest.bind(null, delcomboUrl),proload)
    // ...
},

区别

感觉有点像amd和cmd的区别

后续

手写service的生成工作（逐个手动写request）已经删减，之后我在一个新项目是这样设计的
1.将config里的url配置移到services文件下，命名为api.js，不想config承载具体url配置
2.将生成方法createService从utils里写到外围services下,即直属src下面