设计心理学

design

大概一年前看过,最近看了ant design推荐的书籍目录,又快速看了一遍。

大概归纳为以下一些关键概念:

符合用户心理模型
引导用户操作
不要打断用户心流
限制操作
及时反馈

可视性
正确的概念模型
正确的匹配
反馈

利用外部环境因素提示
使控制与被控制设备形成自然的关联,例如位置。

看到“形成自然关联”这个点的时候,想到vim,绝对是个反面教材,vim的操作何止逆自然,简直逆天。但vim在“不打断操作者心流”这点上做到了极致。

发表在 books | 留下评论

读书React+d3.js

reactandd3

很短的一本书,讲的是react和d3如何搭配。

大概思路就是d3管计算,react管画图,即生成html与svg的dom,外部css管样式或者react的内联样式,需要配合svg知识。

d3的enter和exit基本就用不上了,这本书大体上就是这个思路。

发表在 books | 留下评论

react与redux优化部分总结

最近被问了很多redux优化的问题,以下是一些总结,有些是网上搜的,也有自己琢磨的。
先说网上搜的,redux的reducer当switch的条件太多时,可配合redux-ignore,需要为相关联的业务reducer指定相同的type前缀来实现。
react-redux中的connect函数的第三个参数option,设置pure为true,然后通过自己实现相关的props与state比较实现优化,具体比较函数参照react-redux网站api。
使用immutablejs,确保每次只要数据变化则返回新对象,没变化肯定返回原对象。
使用reselect或类似的memorize工具,缓存reducer状态可避免重新计算。
redux的store中存放的数据太大时肯定占很多内存,在退出相关业务时记得dispatch一个针对当前reducer的CLEAR作用的action,让对应的结构分支中恢复初始空数据状态,起到回收内存作用。
如果reducer太多,每次dispatch需要经过太多判断和运算,我想到了拆分redux的store,为整个应用引入多个store,这样每个store的dispatch只管自己,肯定会高效一些。各个store需要共享数据的话,话想引用store实例getState获取数据即可。
这样的话在整个项目的最外层就不能用一个Provider包裹了,每个业务通过自己的Provider关联独立的store,不过我隐约记得redux的教程上说最好就一个store。但是就像后端一旦规模大了,只能进行各种横向拆分,前端也是这个道理,当业务太庞大时架构复杂性需要为性能让路。
react优化,stateless组件,PureComponent,shouldComponentUpdate自己添加比较逻辑
无论是否使用redux,当组件内状态过多时,将部分组建独立出来,使分离组件彼此独立渲染。这点在vue中也是一个道理。
还有其他优化以后再添加。
发表在 ecmascript | 留下评论