公司内部培训总结——数据对于前端操作dom的重要性

2019独角兽企业重金招聘Python工程师标准>>>

在TW培训的两周和自学了一周后，我对前端的认识发生了较大的改变。 之前受自身技术与眼界的限制，我对js与前端框架的认识基本停留在使用其对DOM对象进行直接操作的层面上，无论是操作样式或是内容都是通过简单粗暴的方式进行，在这一过程中对数据的处理一直是被忽略与回避的一个问题。而数据处理在现阶段的前端开发中其实是一个相当重要的环节，这其实也是我在这次培训中了解到的最重要的一点。 以前我对前端代码与事件流程的理解是代码生成页面、样式表渲染页面、加载js绑定相关事件、用户进行操作、操作触发事件调用函数、函数对相应DOM对象的属性进行直接操作；而现在我对其的理解是代码生成页面、样式表渲染页面、加载js代码、获取服务端数据、根据数据初始化页面、用户进行操作、操作触发事件修改数据（state、status等）、检测到数据改变、调用相应函数根据新的数据重新渲染。 举个简单的例子吧，po主之前一直习惯使用的框架是Jquery。现在po主要写一段代码实现点击一个按钮，每次点击向指定的ul标签中添加一个li标签。如果是在以前po主会以以下方式实现，为button的click事件绑定一个函数，函数通过ul的class或者其它属性找到这个ul然后append一个li进去；而现在po主的做法首先依然是为button的click事件绑定一个函数，但这个函数是向一个json中插入一个值数据结构大概是这个样子jsonUl = ['li','li'...]，然后在这个函数的最后调用另外一个函数，被调用的函数的作用是根据这个jsonUl刷新ul中的内容。当然这两个方法都能实现这个例子的需求，但后者的步骤明显更加复杂因为其涉及到了数据的修改。如果按照po主以前的习惯肯定是会选择前者，可能看到这里大家也早就看出来po主是个菜逼了，该散就散了吧~ 那么我就来分析一下两种做法的区别吧,最明显的区别就在于是否对数据进行了操作这一点，但其实这操作在这个例子中我认为其实是没必要，因为例子的功能需求很简单也没有提及要对数据进行操作所以其实第一种操作就已经实现了效果，如果需求上加入了要对相应数据进行操作的要求（这里的这个要求其实是不明确的），那么以前的我应该会在第一个做法中修改DOM的函数中添加一个操作数据的方法（这里其实是有违单一功能原则的），这样从效果上看就跟第二种方法一样既操作了数据，也实现了视觉效果的添加。可能到这里因为写得比较乱，看的人可能会晕吧。 上面提到在方法一中添加一个数据操作后就和方法二实现了同样的结果，但是在这种情况下其实才能涉及到po主想谈的核心点，通过数据来操作对象。通过分析其实可以很明显的看出方法一对数据的修改与对dom的操作其实是一个并列的关系，只存在代码上的先后顺序而没有逻辑上的先后之分；而方法二则是存在逻辑上的先后顺序的，是数据在改变后dom才进行了相应的改变。在我的理解中这样操作最大的优势其实是在测试与维护上。我们假设在函数执行的过程中对数据的操作出现了问题，具体到例子中我们可以看作是在添加字段的时候连续添加了两次，那么如果是以第一种方法来运行最后呈现出来的结果会是正常的，而第二种方法呈现出来的结果这会与我们预期的产生偏差。那么发现这个错误的时间节点就会有区别了，而我们都知道问题存在的时间越久那么修复它的成本也就越高，所以从这点上来看第二种方法就比第一种方式有了一定优势。 在举着个例子的时候po主突然又想到了一点，就是渲染的速度问题，是单加入一个li快呢还是，全部刷新一遍快呢。但是随即就感觉这个问题几乎没有意义，因为这个时间实在是差得太小了。 所以在po主的培训过程中老师也是不断的强调，所有的操作其都是应该根据相应的数据来进行的，而在这个过程中po主其实对dom对象的认识也有了一定的提高（不知道算不算提高吧）。po主因为之前的项目对数据的操作是比较少的，之前就是觉得后台数据什么的太麻烦了所以才选了做前端，更多的是对dom对象在进行直接操作，所以在培训开始的时候po主一只认为自己很久没有对数据进行过操作了，但是在构思这篇博客的时候突然发现其实这特么的不是一样的么向ul标签里面插入一个li标签和向一个叫ul的json字段里面加一个交li的字段其实是没有本质区别的，存在的区别是在具体的操作上和所用的语句的不同而已。具体而言就是： <ul><li></li></ul>到<ul><li></li><li></li></ul>与[ul:{'li'}]到[ul：{'li','li'}] 所以其实所有的通过这种形式组成的页面都是能够完整的被转换为json的数据格式的，所以每个标签内的信息都能够存入到相应的json数据中。ps：突然有点丧心病狂的想找个网站把它层次全部用json写出来。 刚刚的例子我是在使用Jquery的前提下构思的，所以可能还是会有人觉得这样操作是不是比较麻烦，但是设想一下如果是以angular作为开发框架，因为数据修改后框架会自动为你把要刷新的位置刷新了其实也并不麻烦。而且在当前大数据的环境下，这种操作模式几乎是不可避免的。po主在三周前也一直以为自己是个狂热的对dom对象进行直接操作的前端菜逼，但是现在回想起来其实之前的项目几乎不可避免的大量用到了数据改变dom的情况。比如之前po主做的一个类似maka的网站，每一次dom对象的添加与删除都必须向用于记录元素信息的json中添加一条数据或删除一条数据否则是无法做保存的功能的，直所以po主一开始没有明确的感觉到这点其实就跟之前例子里提到的一样这两个步骤是放在两个文件里然后在一个事件中调用的，现在想来也是为何当时开发的时候在保存的那块经常出问题而页面显示又没有问题的根源，因为对数据和对对象的操作虽然是同时进行但又各自独立起来的！！！所以po主又想到了那个项目还没有开发的撤销功能，因为没有用到redux的关系，一次编辑可能会有上百次的操作，以之前的代码实现几乎是一个会令人崩溃的过程吧。 写到这里大概也就差不多了，虽然各位看官可能看着头晕，但是我自己是对通过数据操作dom而不是直接操作dom有了更加清晰的了解了，下一篇博客应该不出意外会写自己学习react的一些总结，因为在写这篇博客的过程中我突然意识到其实所有的前端框架组合来组合去其实要到达的目的都是一样的，只是具体代码的不同，侧重解决的问题不同而已。另外，po主自己之前的毕业设计是做的一款以Fate为主题的卡牌游戏，现在很想继续把它做下去，有想要了解的朋友也可以来找我要源码，但是po主真的是很菜的，所以如果做的不好浪费了你们宝贵的时间也请在浪费一点时间来给我指正啊~~~~

转载于:https://my.oschina.net/twleo2016/blog/709231