数据驱动模式借助react的实践探索
之前谈到过很多次数据驱动的理解,这次通过实际项目检验了一下自己的想法。 相关文件《前端数据驱动的价值》 《前端数据驱动的陷阱》 项目详设详设的重要性对于复杂一点的项目,做一个详细设计非常重要。有人会疑惑,前端还需要详设吗? 在某种程度上,开发者详设在整个开发周期中占得比重越大,能力就越强。 react详设的步骤
基本上上面梳理清楚了,后面就可以直接写代码了。 道和术网上看到很多讲解redux+react的实践思路,设计模型。感觉都是实践方式上面的讲解。 比较经典的一张图: 今天我这边想换一种思路去解释他。 数据驱动+react实践的一个前提相信react的性能! 快照概念model能力超级强大,请记住,每个model都必须能够对应一种页面状态(能够像恢复快照一样)。model和页面状态存在一种一一对应的关系。 如下图: 每一个M都和下面的页面对应,用 当用户有交互行为时,通过 慢动作: 用户对M1的页面一做了一个操作( 注意我强调了刷新两个字。 核心就是页面的行为使得数据改变,数据渲染出数据改变后相应的页面。 这个就是我所理解的数据驱动。 为了达到上面目的,其实我们有意忽略了性能问题。就是用户每次操作都会重新渲染数据,生成对应的新页面。 那么性能问题如何解决,这时 说实话,如果没有这种最小 从上面看,代码其实可以分为两大部分:
数据驱动副产物单元测试某种程度上,前端是非常难去写单侧的,因为涉及到dom,哪怕是时间允许,单侧的使用度也不是很高。 用户行为回放回答上面那个图片,通过model可以记录一个页面的快照,那么如果对于单个用户,单个终端,按照时间轴记录一连串的model,我们就可以回放用户的操作行为。 数据驱动的思考这种模式某种程度上,是为了提高开发效率,减少页面的复杂度(参考《前端数据驱动的价值》),减少开发的复杂度。 想想5-6年前,还是多页面时代,每个模块都是一个页面,数据都由后端去套模板。然后用户每个操作基本上都会触发一些刷新。数据驱动和有点类似,只是借用react在单页面上实现了。前端也承担了更多的数据处理工作。 博客地址http://tangguangyao.github.io/ 微信公众号
(编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |