我们为什么要写组件呢?这里不细分组件、插件、控件,追究其原因无非让代码,能够复用,追求更快的开发效率。其实还有个重要的原因,项目大了之后,难以维护。这个时候就会把项目中重复的部分抽取出来,形成一个组件。但是组件也会有些’缺点’,这个最后讲。
组件需求
要实现如图的一个条件选择器
有的时候,项目时间紧张,就会直接切图,通过jquery的dom选择器实现这个’简单的功能’。
需求分析
为了更好的维护,以及更好的复用此组件,就要做些抽象。
- 数据层:用来决定按钮个数以及按钮是否选择
- 表现层:按钮使用现有的ui组件
- 逻辑层:按钮事件等逻辑处理
数据层
data: null, choseT: 0, choseF: 0, getDataStatistics: function() { var list = this.data; var choseT = 0; var choseF = 0; var len = list.length; for (var i = 0; i < list.length; i++) { if(list[i].checked == 'checked') { choseT++; }else { choseF++; } } return { choseT: choseT, choseF: choseF, len: len }; }, dataChangeAll: function(checked) { var list = this.data; var len = list.length; checked = checked || ''; if(checked == 'checked') { this.choseT = len; this.choseF = 0; }else { this.choseT = 0; this.choseF = len; } for (var i = 0; i < len; i++) { list[i].checked = checked; } }, dataChangeSingle: function(index, checked) { var list = this.data; var choseT = this.choseT; var choseF = this.choseF; if(checked == 'checked') { choseT++; choseF--; }else { choseT--; choseF++; } this.choseT = choseT; this.choseF = choseF; list[index].checked = checked; }
数据层主要对原始数据做些CURD的一些操作,具体的操作看具体的业务需求,但是要具有这个意识。
表现层
说白了表现层也就是template层或者view层,就是用户所看到的,一般会用一个比较成熟的ui库,比如bootstrap
getHtml: function(list, statistic) { var html = ['<div class="sales-dialog">', '<div>', '<div class="tag-box-chose J_view_checkNav">', this.getChoseNav(statistic), '</div>', '<div class="mt_10 J_view_checkItems">', this.getChoseItem(list), '</div>', '</div>', '</div>'].join(''); return html; }, getChoseNav: function(statistic) { var checkAll = ''; var checkNone = ''; var len = statistic.len; if(statistic.choseT == len) { checkAll = 'checked'; } if(statistic.choseF == len) { checkNone = 'checked'; } return [ '<label class="tag '+checkAll+'">', '<input type="radio" name="radio-grade input-fat" class="J_view_checkAll" '+checkAll+' />', '<span class="tag-tit">全选</span>', '</label>', '<label class="tag '+checkNone+'">', '<input type="radio" name="radio-grade" class="J_view_checkNone" '+checkNone+'/>', '<span class="tag-tit">全不选</span>', '</label>' ].join(''); }, getChoseItem: function(list) { var inputs = ''; var doInputFunc = function(i, detail) { return [ '<div style="display:inline-block;150px;">', '<label data-toggle="checkbox" class="checkbox-pretty inline '+detail.checked+'">', '<input type="checkbox" value="'+i+'" class="J_view_checkItem " '+detail.checked+'><span>'+detail.name+'</span>', '</label>', '</div>', ].join(''); }; for (var i = 0; i < list.length; i++) { inputs += doInputFunc(i, list[i]); } return inputs; }, domAction: function($el, type, data) { var html = ''; type = type || 'all'; if(type == 'item') { html = this.getChoseItem(data); $el.find('.J_view_checkItems').html(html); }else if(type == 'all') { html = this.getChoseNav(data); $el.find('.J_view_checkNav').html(html); } }
众所周知,template就是根据数据渲染成html,在spa项目尤其重要。
逻辑层
这层主要做 调用template方法将数据渲染到页面上;将页面上的一些事件结果,映射到数据层。其实现在流行的MVVM模式,就是在逻辑层这里做了更多的事情,只是开发者们不用去关心细节处理,更专注业务的开发。
eventBind: function($el) { var _this = this; var $target = ''; // 全选 $el.on('change', '.J_view_checkAll', function() { if(!$(this).parent().hasClass('checked')) { _this.module.dataChangeAll('checked'); _this.view.domAction($el, 'all', _this.module.getDataStatistics()); _this.view.domAction($el, 'item', _this.module.data); } }); // 全不选 $el.on('change', '.J_view_checkNone', function() { if(!$(this).parent().hasClass('checked')) { _this.module.dataChangeAll(''); _this.view.domAction($el, 'all', _this.module.getDataStatistics()); _this.view.domAction($el, 'item', _this.module.data); } }); // 单个 $el.on('click', '.J_view_checkItem', function() { $target = $(this); var index = $target.val(); var checked = ''; if($target.prop('checked')) { checked = 'checked'; } _this.module.dataChangeSingle(index, checked); _this.view.domAction($el, 'all', _this.module.getDataStatistics()); }); }, eventUnbind: function($el) { $el.off('change'); $el.off('click'); },
总结
这样子写能更好的抽象出公共部分,在其它模块就只要传入数据就可以了,不用重复拷贝代码了。
一开始说到组件会有‘缺点’?尤其是业务组件?
分析
项目版本迭代是一个很正常的事情,第一版的时候,比如这个数据选择项这个组件,在每个模块都有这样的需求。但是在下一个版本的时候,产品经理在其中一个模块更改了业务需求,这就导致这个模块的数据选择项,跟其它模块的数据选择项不一样了,但是又有80%甚至90%的相似度,这个时候就非常困扰,到底是重新写个,还是再对原来的组件,增加个兼容配置项?
重新写会有很多重复的代码。新增配置项,又必须保证之前所有的模块都要正确,得必须都验证过去。有人就会觉得直接去验证好了啊,但是项目大了之后,一个一个去验证不是解决问题的办法。
最终解决
在写组件的时候,业务逻辑部分,现预留配置项,以便后面业务发生改变,通过配置项来重置。尤其是觉得产品经理会更改频繁的部分。
实在是觉得更改逻辑较大,那就重新写个吧,因为一个一个去验证之前的模块的成本还是很大的。
原文地址 http://tostring.site/2016/07/16/%E6%80%8E%E4%B9%88%E5%86%99%E5%A5%BD%E7%BB%84%E4%BB%B6/