阶段技术总结 (dva)

本篇博客适合个人笔记,描述用法,深入了解 dva 请自行查看文档

创建一个新的页面

src/pages 文件夹下创建一个新的页面,目录结构如下:

> Shipping
	> components
	> models
	index.jsx

配置路由

config/config.js中按照,pro 示例配置路由


状态管理的整个过程

这里指的是使用状态管理的整个思路,不是指代码的书写顺序,代码的书写过程应该是下面的倒序

第一步: @connect(() => ({})),添加在组件申明之前

这里我的习惯是把state放在组件的中, 而没有放在model

如果把state放在model中,@connect(() => ({}))中,就要接收model中的state

第二步:每个事件都要向后端发送请求,每个事件都会触发dispatch

拿到dispatch这个方法

const { dispatch } = this.props

dispatch的使用

dispatch({
	type: '[model文件名]/[effects中的方法]',
	payload: [传递参数],
	callback: res => { 
	  // 拿到 effects 方法中 callback 传回来的数据,做相应处理,这里我主要是把数据更新到 组件的 state 中
	  this.setState({
	  ...
	  })
	}
})
第三步:model文件

model文件中的主体内容

export default {
  namespace: '[对应文件名]',
  state: {},

  effects: {},

  reducers: {
    // 如果下面 effects 方法中用到 yield put()
    // [对应方法](state, { payload }) {  // 第一个参数为,初始 state;第二个参数为,effects 中传递过来的 payload
    //   ...
    //   return {
    //   [经过修改后的 state]
    //   }
    // }
  },
};

effects方法

// 实例代码
*fetch({ payload, callback }, { call }) {
  const res = yield call(query, 'shipping', payload);
  // 如果 dispatch 有传过来一个 callback 的函数的话,调用这个 callback,把 res 作为参数传递,调用组件中的 callback  
  if (callback) callback(res);
  // 这里为什么是如果?因为可以用另一种方法代替 callback 的使用,就是 
  // yield put({ type: [reducers 中的方法], payload})
},

effects中的yield call()

import { [接口名] } from '@/services/api';

const res = yield call([接口名], '[接口参数]', payload);  // 第三个参数为详细参数,对应 services 文件中的 params
第四步:services/api.js文件
import request from '@/utils/request';   // 调用接口请求
import { stringify } from 'qs';   // 字符串转换

export async function [接口名](resource, params) {   // 第一个参数,对用上面的 [接口参数]
  
  return request(`/api/${resource}?${stringify(params)}`);
}

dva 异步获取接口数据的几种方式

主要介绍两种可法

传统的用法(callback)
*fetch({ payload, callback }, { call }) {
  const res = yield call(query, '[resource]', payload)
  if (res && callback) callback(res)
}

dispatch({
  type: '[namespace]/fetch',
  payload: {
    page: 1,
  },
  callback: res => {
    console.log(res)
  }
})
优雅的写法(return)
*fetch({ payload }, { call }) {
  const res = yield call(query, '[resource]', payload)
  return res
}

dispatch({
  type: '[namespace]/fetch',
  payload: {
    page: 1,
  },
}).then(res => {
  console.log(res)
})
  • 2
    点赞
  • 2
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
前言如释重负,好用的技术就应该越来越简单React Hooks 是 React 16.8 从提案转为正式加入的新特性。这个新特性是个非常棒的设计。 可以说对于React 技术栈的发展具分割线一样的意义。讲师在课程中提到:之前使用 React 作为主要的前端技术,开发一款网页游戏。在整个游戏的各个模块中,Redux ,mobx,以及蚂蚁金服的 ant-design,dva, umi 这些框架或者第三方库都有涉及使用。但是自从了解了Facebook官方提案的 Hooks 特性后,才真正觉得获得了前所未有的解脱。如果你有React开发经验,学习了解 Hooks 后,一定有一种如释重负的轻松感。React 带来了方便也带来了迷茫相信关心 React Hooks 这项新特性的童鞋,很多已经有了一定的 React 开发经验。那么你一定有所体验,React 给我们带来方便的同时,也的确和长久以来的前端开发模式有极大的不同。React 并不需要用继承,而是推荐用嵌套。React 有独特的 jsx 语法。大多数情况 jsx 都使得我们的代码更加简洁了。然而有些时候也给我们带来了一些困扰。 比如数据的传递,逻辑的复用。 react 是一种 mvvm 的设计模式,作为开发者一定要清楚,那些数据是业务数据,那些数据是UI数据。否则你的代码很有可能会陷入混乱局面。大型项目中模块化与功能解耦困难在公司项目中 App 稍大的时候,我们发现状态提升和只通过 props 进行数据传递。很多时候都很难实现我们的需求。这时无论我们是否清楚的了解,但是状态管理也就是 redux mobx 等,轻易地进入到了公司的项目中。我们经过初期的尝试发现状态管理,确实比用纯粹的 React 带来了数据传递上的方便,以及代码组织上的清晰。但前提是你看懂且理解了 redux 大神晦涩的官网文档。 本来 React 被设计用来组件化前端开发。但当我们初期使用状态管理,我们常常会过度的使用状态数据,业务逻辑和ui逻辑没有清楚的分离,最终你的应用代码结果可能是:除了少数几个组件是独立的解耦的,大多数组件都因为状态数据的共享而耦合在了一起,且他们也完全依赖状态管理框架。无法再轻松的转移复用。使用高阶组件,属性渲染,渲染回调等高级特性,确实可以帮我们解决模块或功能的解耦问题。但是这些方法,确实有点超出普通“猿类”的技能。且降低了代码的可读性,对于团队协作,这是很致命的问题。React Hooks 真正开启前端模块化的金钥匙对于以上问题,React Hooks 都有很好的解决方案,官方的设计动机就是解决这些曾经的繁琐,化繁为简。React Hooks 让我们在纯函数中就可以使用 React 的众多特性。而不必使用类。代码扁平,易读。解耦状态相关逻辑,UI逻辑和业务逻辑更好的分离。这些逻辑往往是纯函数,而以前很容易混合在类组件中。通过自定义 Hooks 我们可以把应用中“状态相关”逻辑解耦出来,独立编写到我们自己的hooks 中。从而更加易于复用和独立测试。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值