这周把之前分给我的模块, 用RN写完了, 但是没有工程结构, 也没有明确架构.
最后的两天去了解了一下Redux, 然后去新开了一个工程去做重构.
下面的是这星期在写RN的时候总结的一些东西.
可能就是之前自己一直写iOS Native, 对其他的了解的不多, 看到很多JS的文法都觉得很不可思议, 所以可能写的东西还挺小白的(诶, 我本身就是小白...).
望各位大佬不吝赐教.
为什么可以import一个文件夹
在仿照一个工程写的时候, 看到他在引入的时候是这么写的
import Actions from '../actions';
而对应的action是这样的文件结构:
文件夹结构
也就是说, 从语句上看, 在引入的时候, 是将整个的文件夹都引入了.
而他指出的Action, 则是自己定义的一个名字, 代表整个的文件夹.
这里牵扯到了index.js这个文件.
也是在写这个工程的时候, 我发现, 每一个文件夹下面都有一个index.js文件.
而且里面什么也没有做, 只是将这个文件夹里面所有的除他之外所有的文件, 引入, 并且一起export.
比如这个action文件夹下的index.js的代码如下:
import * as navigationActions from './navigation';
import * as todosActions from './todos';
export default {...navigationActions, ...todosActions};
那么这样的话, 在外部引入整个文件夹的时候.
编译器就会去查找在这个文件夹下是否存在index.js文件, 如果存在的话, 就默认是引入的是他.
关于export和import
在写的时候也困惑 为什么在export的时候要加上default修饰.
也好奇
import * as todosActions from './todos';
与
import todosActions from './todos';
之间的差别是什么.
看到一个SOF的回答
代码如下:
export.js
let b = {b: 2};
export default {a: 1}; // <- this is the ONLY default export
export {b};
export let c = {c: 3};
import.js
import SomeName from 'export'; // 'SomeName' is now the {a: 1} instance.
import {b} from 'export'; // 'b' is now the {b: 2} instance.
import * as ns from 'export'; /* 'ns' now has properties 'default', 'b' & 'c',
representing {a: 1}, {b: 2} & {c: 3} respectively */
代码的注释已经解释的很清楚了.
意思是:
在有多种不同的export形式, 可以用default来修饰, 如第一种情况
export default {a: 1};
也可以不用default修饰, 如后两种情况
export {b};
export let c = {c: 3};
那么他们的不同体现在了其他文件去引用的时候:
import SomeName from 'export';
用default修饰的引出, 可以允许在引入方不做指定究竟引出的是什么名字, 而自定义名字.
而没有用default修饰的, 在引用的时候, 就要和在引出的时候变量名进行对应:
import {b} from 'export';
而第三种引用方式, 是将引入文件的不伦任何形式的引出都引入进来.
就是说, 上面的三个引出, 在这种引入方式下面, 都是可以用的.
NOTE: 第三种引入方式只适用于ES6之后.
...this.props
在写Redux的时候, 在Container文件里面总是会看见这样的东西.
render() {
return (
<View style={styles.container}>
<Header {...this.props} num={this.props.todos.length}/>
<Main {...this.props}/>
</View>
);
}
当时觉得...this.props是一个怪操作.
其实看一下的话, 大概能猜出来, 是将属性进行传递, 从父组件传递到了子组件.
然后去查了下, 是ES6的特性, 叫拓展运算符.
作用是把数组或类数组对象展开成一系列用逗号隔开的值.
关于redux里面的业务代码要在哪里写的问题
在GitHub上面看到了一段写的很好.
翻译来给大家.
原文链接.
译文:
我认为业务写在哪里这个问题很重要, 虽然他带来的影响不是立即就可以显现的. 我认为业务逻辑代码应该写在action-creators里面.
Reducers应该保持简洁. 如在个别例子里面不符合这个模式-我们需要知道工程一致性是好的并且我们最好在这个模式上面保持一致. 下面是用这个模式的一些原因:
- Action-creators通过使用redux-thunk这样的中间件可以拥有异步性. 而你的应用又会向你的store发起异步更新, 那么一些业务逻辑就需要在action这里结束.
- Action-creators (更多时候其实就是他们返回的thunk)可以使用共享的selector,
因为他们可以去访问完成状态. Reducer不可以, 只可以访问自己那部分的节点. - 通过使用edux-thunk, 一个简单的action-creator可以发送出很多actions, 这使得复杂的状态更新变得简单并且促进了代码的重用.
想象你的状态有与项目列表相关的元数据。每次将项目修改、添加到或从列表中移除时，元数据都需要更新. 保持列表及其元数据同步的“业务逻辑”可以放在一下面一些地方：
- reducers中. 每一个reducer可以负责更新元数据以及列表
- 视图中(组件与容器). 每个视图，调用一个动作(添加、编辑、删除) 的时候它还负责调用updatemetadata. 这种方法不好,并且有明显的原因.
- action-creators中. 每个 action-creators(添加、编辑、删除)会返回一个thunk来发送action, 一次来更新列表并且另外发送一个action来更新元数据.
上面这三个选择, 第三种是更好的.第一种和第三种都可以写出干净的代码, 但是只有第三种支持对元数据和列表的更新操作是异步的.
网友评论