刀耕火种

 

这种书写方式依赖延续了jQuery时代的思维方式:

  • js里查找dom
  • js里绑定事件

在以前的文章里写过,如果不使用组件化编程,js里查找dom以及在js里绑定事件可能会带来如下问题:

  • 浪费带宽
  • 用户反馈无响应
  • 脚本错误
  • 页面短暂错乱

上面的书写方式粗暴、原始、落后,即:刀耕火种。

石器锄耕

会发现,查找dom的代码已销声匿迹。直接标记nc-id,就自动挂载在this下。
值得注意的是,传入了第二参数关闭了DOM diff。关掉diff的结果就是,每次组件HTML会全部重新替换渲染,绑定的事件全部丢失,所以需要将绑定事件的代码写入onRefresh里,这样每次重新渲染都会再绑定一次。
比刀耕火种先进一点:石器锄耕。

直捣黄龙

会发现,查找dom和绑定的代码同时销声匿迹!!

  • 需要使用input,直接标记nc-id为textBox,就可以this.textBox访问
  • 需要绑定事件,直接在HTML内声明事件和回调onsubmit="add(event)"

也可以通过add(event,this)拿到event和触发该事件的dom元素。

代码通俗简洁干净直接,目的直观明确。故:直捣黄龙。

子承父业

TodoApp不过是TodoList的炎黄子孙,故TodoApp可以通过this._super访问父辈。也可访问父辈任何方法。有人会说:“组合”优于“继承”的。一定要明白:OOP既能组合也能继承,是不冲突的。且看下面例子。

万夫一力

前一个例子的继承,这个例子是组合。不能说你的框架是Class base就不能使用组合,这是天大的误解。而我依稀记得极限编程关于面向对象设计的推论是:优先使用对象组合,而不是类继承。作为框架的设计者,虽然会有一些约束,但是如果连组合和继承都不能共存,那就是设计的最大败笔。
使用Nuclear既能继承也能组合,关键看程序逻辑该怎么抽象和实现复杂度。

藕断丝连

这个例子和上个例子的区别是:共用option。option的变更会自动更新依赖option的组件。

四海为家

且看上面的new TopApp没传第二个参数指定容器。后面使用setNuclearContainer指定容器。这个场景还是比较常见,创建游离态组件,后续根据需要指定容器。AlloyLever就是这么干的: https://github.com/AlloyTeam/AlloyLever/blob/master/src/js/main.js

如虎添翼

style方法内的样式自会对自身生效,不会污染其他组件。可以操作对象实例option,option的变更会自动更新组件,属性设置>方法调用。
双向绑定的好处以前写过一篇文章专门介绍,从上面的例子也能可出:

  • 组件内部的代码更简洁
  • 组件外部的代码更简洁

壁垒森严

不用担心template标签的兼容性问题,Nuclear帮你处理好了。支持所有现代浏览器(包括IE9+)。
Nuclear也在js里进行了动态插入了template { display: none !important; }。但是js还没执行到且浏览器不兼容template的话,用户会看到一闪而过的模板原始代码。
所以为了避免IE9一闪而过的模板原始代码直接显示,建议在head中加入。

如果你像手Q hybrid应用那样只需要兼容webkit的话,天生支持template,就不用加入上面的兼容样式。

鬼斧神工

使用ES6 Template literals解决多行文本问题。

人剑合一

使用ES6 Template literals解决多行文本问题,style和html当然可以合在一起。

Nuclear从出生,API简单稳定,几乎没怎么变动,内部是实现在不断的完善,API驱动非常重要,不能因为实现某些API困难而做任何妥协,比如让使用框架的着多传个参数、多调用一次方法,这都是设计的缺陷。

Nuclear就是不妥协的结果。因为简单的设计,所以可以有很多强大的玩法,待续...

广而告之

Nuclear Github: https://github.com/AlloyTeam/Nuclear

加入Nuclear,一起让组件化开发体验更加惬意、舒适..

{{uname}}

{{meta.replies}} 条回复
写下第一个评论!

-----------到底了-----------