Brix

前言

如果你熟悉Brix的发展历程,那么你一定关注过Brix1.0和2.0的官方网站,那里有段话是这样描述的:

Brix 是基于 KISSY(PC端)和 Zepto、SeaJS 等(移动端)底层类库的应用层组件框架。 目标是打造面向前台展示型业务、后台管理型业务、移动高端版业务的通用且易用的一淘UX前端组件平台。

Brix 来自 一淘 UX,即 Bricks 的谐音。 我们致力于一淘前端平台化建设,为新商业文明制砖,让开发者能够凭借 Brix 建造自己的梦想之城。

2013-5-28 Hackathon 北京 确立了Brix 3.x的发展方向,以及要解决的问题。

总体设计

目标

Brix完成了三个大的目标:

  • 组件开发规范的确立
  • 组件初始化和销毁的管理
  • 组件、模块基于数据驱动的局部刷新

位置

Brix让行为和结构分离,无论是webapp类型的项目,还是传统的jsp php页面,组件的渲染形式和管理方式都是统一的。

pagelet

Brix 对组件和区块做了统一的初始化和销毁,使用者不再需要关心组件的实例化问题,我们来看看基于传统开发和基于Brix开发会有什么不同呢?

传统实现

KISSY.use('brick1path,brick2path,……,brickNpath',function(S,Brick1,Brick2,……,BrickN){
    var config1 = {}//config1是Brick1组件需要的配置
    var brick1 = new Brick1(config1)
    var config2 = {}//config2是Brick2组件需要的配置
    var brick2 = new Brick2(config2)
    ……
    var configN = {}//configN是BrickN组件需要的配置
    var brickN = new BrickN(configN)

    //组件间的交互

    brixck1.on('eventtype',function(){
        brick2.dosomething()
    })
    ……

    brixck2.on('eventtype',function(){
        brickN.dosomething()
    })

})

大家一定很习惯这样的用法,而且感觉结构也很清晰。

那么,如果引入Brix,又会怎样?

Brix实现

KISSY.use('brix/app',function(S,App){
    // 所有组件的配置
    var config = {
        el:'#id'//提供一个容器节点
    }
    App.boot(config).once('ready',function(brix){
        //brix就是实例化出来的根组件,并有父子关系。
        var brick1 = brix.one('brick1') //获取组件实例
    })
})

如果组件是独立的,那么我们可以在不修改js逻辑的情况下,直接对dom结构修改来达到组件是否使用。

##Brix概述

##版本推荐

不要被下面怎么多的版本吓到了,Brix的发展依赖KISSY的版本升级.

在最早做Brix1.0的时候,KISSY还在1.2时代,那时候并没有RichBase,Brix自身实现了一整套组件生命周期管理。

KISSY 1.3之后引入了RichBase,包含了Brix的生命周期管理,Brix直接用了RichBase。

KISSY 1.4将RichBase和Base模块做了合并,并对map等做了重大调整,Brix为了保持使用者不受影响,发布了3.4.0版本,并对原有2版本做了升级,发布2.1.0版本,兼容KISSY 1.4.x版本

而Brix本身在升级过程中也引入了许多的特性,比如Brix 3 引入了promise(方便开发者对组件渲染流程的控制)、父子组件关系(bxParent,bxChildren)、自定义事件委托(类似dom事件的冒泡)。

anywhere,无论你现在在用KISSY的任何版本,都能找到对应的Brix.

  • KISSY 1.4.x -> brix3.4.0

未压缩版 压缩版

  • KISSY 1.4.x -> brix2.1.0

未压缩版 压缩版

  • KISSY 1.3.x -> brix3.3.0

未压缩版 压缩版

  • KISSY 1.3.0 -> brix2.0

未压缩版 压缩版

  • KISSY 1.2.x -> brix1.0

未压缩版 压缩版