redux

3 月，跳不动了？>>> 调研方向 设计思想/基本用法/生态环境/性能优化 总结 设计思想 mobx 的设计思想我总结之后，主要有以下两点： 函数响应式编程； 任何源自应用状态的东西都应该自动地获得； mobx 不同于 redux 的单一数据源的统一管理，它可以有多个 store， 为了便于维护 ，每一个 store 都是一个类，这样便于维护和扩展； 同时，为了使数据可以自动更新，使用了响应式编程（异步数据流)， 它使用了观察者模式和 装饰器模式 ，将 state 包裹成observable； 当state 有改变时(自己改变或是 action 触发)， 就会相应的去更新由这个state 推导出来的 computed value 以及 reaction；(数据的更新主要由装饰器模式中的对类的修改 )； 它的工作流大致是这样子： 基本用法 mobx 与redux 一样也是单向数据流，核心概念是 state，computed value，reaction，action 等。它们的大概功能为: state: 包裹为 observable 的 的数据； computed values: 从当前 state 中计算出的值，类似与 vue 中的computed; reactions: 是当 state 改变时需要自动发生的副作用。比如打印到控制台、网络请求、递增地更新 React 组件树以修补

3 月，跳不动了？>>>   最近在琢磨react中的一些小技巧，这篇文章记录一下在redux中用装饰器来写connect。   通常我们需要一个reducer和一个action，然后使用connect来包裹你的Component。假设你已经有一个key为main的reducer和一个action.js. 我们的App.js一般都这么写： import React from 'react' import {render} from 'react-dom' import {connect} from 'react-redux' import {bindActionCreators} from 'redux' import action from 'action.js' class App extends React.Component{ render(){ return <div>hello</div> } } function mapStateToProps(state){ return state.main } function mapDispatchToProps(dispatch){ return bindActionCreators(action,dispatch) } export default connect(mapStateToProps

某厂面试归来，发现自己落伍了！>>> 这篇文章主要介绍了react-redux中connect的装饰器用法@connect详解,写的十分的全面细致，具有一定的参考价值，对此有需要的朋友可以参考学习下。如有不足之处，欢迎批评指正。 通常我们需要一个reducer和一个action，然后使用connect来包裹你的Component。假设你已经有一个key为main的reducer和一个action.js. 我们的App.js一般都这么写： import React from 'react' import {render} from 'react-dom' import {connect} from 'react-redux' import {bindActionCreators} from 'redux' import action from 'action.js' class App extends React.Component{ render(){ return <div>hello</div> } } function mapStateToProps(state){ return state.main } function mapDispatchToProps(dispatch){ return bindActionCreators(action,dispatch) }/

第一步 创建全局的store，并创建对应的reducer规则，使用combineReducers合并多个reducer import { createStore, combineReducers, compose, applyMiddleware } from 'redux'; import createPromiseMiddleware from 'redux-promise-middleware'; import filterReducer from './routes/Todo/filter/reducer'; import homeReducer from './routes/Home/reducer'; const reducer = combineReducers({ todos: todoReducer, filter: filterReducer, home: homeReducer }); const middlewares = [createPromiseMiddleware()]; // 这边可以加入其他到中间件 比如thunk logger// const middlewares = [logger, thunk];// const win = window; const storeEnhancers = compose( applyMiddleware(.

哪些东西应该放在reducer里面 不要复杂化ruducer 只有需要共享的才放进去 域数据 1：不要复杂化reducer 是指 不要所有的东西都放在redux里面 2：根据第一条，只有多个组件用到的数据才需要放入 redux里面，有的人 会说，把组件的ui状态放入redux 是方便管理，我认为 如果你需要在另外一个组件控制这个组件，那把这个组件的ui状态放入state自然是可以的，这遵循只有共享的数据才放入redux的原则，但是 一股脑的把所有的ui状态都放进去 只会增加redux的复杂性很很多不必要的代码 3:域数据，与ui状态相比，域数据被多个组件共同访问的几率要大大高于组件内部ui状态，所以 域数据应该放入redux reducer如何调用其他reducer数据？ 像id关联查询这些，或者数据库中的多表关联查询，和多表批量操作，这些在redux中如何实现？ redux希望我们以关系型数据的方式设计state，但是如果以关系型数据库的方式设计state，那就涉及到 多个reducer的并处理和顺序处理。但是reducer要求是纯函数，很显然 我们不可能在函数里面 去调用其他reducer，所以 唯一的操作路径 就是在容器组件里面 拿到其他reducer的数据，然后放入action中。至于并处理，则可以通过多个reducer响应一个action来做到。 业务逻辑在哪里？

redux是数据管理框架,使用它主要是因为react组件化之后，组件间值的传递比较麻烦，于是使用一个顶层的组件来储存和分发；这样就不用传来传去了；但是react用起来不太方便；于是有了react-redux，使用provide和connect连接起来就可以mapStateToprops来接收参数和改参数；原来action只能是对象,redux-thunk 是一个中间件，使用了它就可以派发函数了； 虽然很多新的东西，前端日新月异，比如又出了hooks,vue2才刚了解，vue3就有消息了；所以有人抱怨学不动了,其实都是为了更方便的需求； 详细： Flux 官方推出的原始辅助数据层框架，用于管理react的数据，因为react 组件传递值要一层层传，很麻烦，所以就专门给了个管理层，放在顶层，都可以穿给其它组件； 升级的了是Redux：Redux=reducer+Flux 原理： Components：借书的人 Action creatotrs：要借什么书这句话 Store:图书馆管理员 Reducers:记录本 流程： 首先需要一个store,页面从store 中取数据； 如果页面想改变store中的数据，需要派发action给store; store把action 和之前的数据一起给redux,redux结合之前的数据； 返回新的数据给store,store更新自己的数据，再告诉页面