从 React 的组件更新谈 Immutable 的应用

在上一篇文章《Immutable 在 JavaScript 中的应用》 中主要介绍了 Immutable 之于 JavaScript。而基于 Immutable 的特性,将其应用在 React 项目的开发中非常合适,解决了 React 中的一些痛点,能进一步提升 React 组件的性能以及更好的管理组件的状态。 在介绍 Immutable 如何在 React 中应用之前,先来谈谈 React 组件是如何更新的。 React 是基于状态驱动的开发,可以将一个组件看成是一个有限状

谈谈 external 模式的打包

模块化在前端日新月异的工程化工具的推动下已经摆脱了前端模块加载器(SeaJS、RequireJS)的束缚,现在通常的方案是使用 browserify 或 webpack 来将模块化的文件打包,然后直接在浏览器端使用。 但是通常的打包策略是将整个项目打包成一个文件 bundle.js,默认情况下 bundle.js 中囊括了所有的依赖,包括第三方的从 node_modules 中加载的文件,这会造成 bundle.js 非常臃肿,而且在生产环境中不能很好的利用静态资源的缓存策略

Immutable 在 JavaScript 中的应用

Mutable 对象 在 JavaScript 中,对象是引用类型的数据,其优点在于频繁的修改对象时都是在原对象的基础上修改,并不需要重新创建,这样可以有效的利用内存,不会造成内存空间的浪费,对象的这种特性可以称之为 Mutable,中文的字面意思是「可变」。 对于 Mutable 的对象,其灵活多变的优点有时可能会成为其缺点,越是灵活多变的数据越是不好控制,对于一个复杂结构的对象来说,一不小心就在某个不经意间修改了数据,假如该对象又在多个作用域中用到,此时很难预见到数据是否

2015 年度个人总结

2015 年又划上了句号,于我来说,又老了一岁,已经到了那个不再张口闭口“我还年轻”的年龄段,年龄对于我来说已经有所忌讳了,相信很多同龄人都会有同样复杂而又微妙的心情。时间对于每个人都很公平,一年 365 天,一天 24 小时,不会因为人的身份地位而有所偏颇,在时间面前,人非常渺小。 工作 上半年怀着无奈和遗憾,从聚美离职了,这么快离开聚美是我始料未及的。在聚美,个人能力得到了较大的磨练,因为所面临的问题是我职业生涯中从前未有过的。第一次带团队,团队从最初的一盘散沙,没有方向

Ballade: 重新诠释 Flux 架构

由于 React 的单向数据流的设计,衍生出了单向数据流的架构模式 Flux。 在 MVC 的分层架构中,Flux 属于 M 层,也就是 Model,而在 Flux 中,Store 是关键部分,Action 和 Dispatcher 都是围绕着 Store 来设计的,所以 Flux 架构模式的目标就是基于单向数据流如何更好的管理数据,在 Views 或 Controller-views 与数据之间进行解耦。 我在之前的 React 应用的架构模式 Flux 有详细的介绍过 F