|
|
都说数据处理比较难，那么前端数据处理难点在哪里？
是因为现在前端框架很完善吗？所以不难吗？
关注者
361
被浏览
50,973
16 个回答
所谓的前端数据处理难，并不是指对某个确定数据的变换过程很难，而是指结合复杂程度较大的业务场景，可能会面这么一些挑战：
- 数据来源的多样化
- 原始数据与展示数据的差异性
- 联动关系的定义与实现
- 缓存的处理（易失性缓存，持久性缓存）
- 前端路由导致的应用多入口的处理
- 跨端渲染导致的处理过程的差异
- 数据处理的时序控制
数据来源多样化 ，指的是你展示的数据，可能来源于不同的地方：
- 程序中的默认定义
- HTTP请求
- WebSocket消息
- localstorage之类的本地缓存
很可能你的数据是这些东西共同导致的运算结果。
从这些地方来的数据，其形式可能是有差别的，而最终视图展示所需的数据，更是可能需要对原始数据进行加工，这就体现了 原始数据与展示数据的差异性 。
与命令行界面相比，图形界面的特点在于冗余信息的展示，把最核心的原始数据，添加了不同的辅助信息、转换之后用于展现，并且，很可能同一份业务数据同时被若干个组件以不同形态展现，当涉及此类数据变更的时候，为了整个应用的一体性，可能需要一定程度的联动更新。当整个应用中的数据被广泛复用，并且形态各异的时候， 如何优雅地定义横跨整个应用的联动更新，就会成为一种挑战 。
很多时候我们需要利用缓存来加速应用的加载和切换过程， 如果缓存的使用遍及整个应用，业务代码的复杂度就会大幅提升 ，如何控制这种复杂度，会很考验对一些东西的抽象程度。
随着应用的单页化，前端路由成为了一种比较流行的方案，当应用变大的时候，我们可能会拆分模块的加载过程，相应也需要拆分数据的加载过程。然而， 前端路由的存在会导致应用的入口增加 ，尤其是在存在多级路由的时候，每个路由是从其他路由跳转而来，还是第一次打开、通过刷新进入，都会导致每级路由数据加载过程的不一致。
如果一个页面进行了服务端渲染，很可能它的部分数据是在服务端准备好的，而另外一些则是到了前端才去查询的，如果这些数据存在关联关系， 如何设计数据获取过程，才能使得应用的逻辑更清晰，并且能以更小代价，把每块业务数据灵活地在前后端渲染之间切换 ？
除此以外， 当数据处理的过程存在时序关系的时候，如何更好地让这些时序清晰化 ？
凡此种种，都是很考验整体把控能力的。
我们所见的很多中后台系统，由于业务所限，往往是模块之间毫无关联，强行把多页应用单页化，此类应用在前端数据处理上，是比较简单的。如果所开发的应用在产品形态上有较大突破，很可能你会同时触及以上提及的所有点。
怎么在实际开发中去应对它们，欢迎关注我的专栏。
前端数据处理最大的难点（烦点）就是前端善变。
对于一个公司来说，业务基本是稳定的，即使有变动也不会太大。但是前端就比较苦逼了，变动是非常频繁的。
各种MV*前端框架前端框架的出现，通过双向数据绑定或单向数据流的思想，基本上也是关注在VIEW层，解决数据的正确精准显示问题：使视图能够精准的呈现数据，数据能够精准的表示视图。
数据包括IO（输入输出），上面的数据显示可以看作是O。对于数据的显示各种框架已经解决的很好了，而最大的难点不是来自技术的不成熟，而是产品经理。
朝三暮四：早上产品经理提了3个需求，晚上说要验收4个。
朝生暮死：早上产品经理提了一个需求，晚上程序员猝死了。
前端数据处理的难点还在于数据的来源。可能来自xhr，数据格式是json。也可能来自用户的键盘输入。也可能来自鼠标。还可能是websocket，等.....而每种数据来源的格式都不同，而且还是异步不可控的。而来自用户的输入有些是action，有些是data。
响应式编程（如rxjs）试图把所有的输入统一起来，看官网的介绍也确实非常优雅。感兴趣的可以去读读飞叔和太郎的专栏。