,直接跟随在输入框后面就可以了,自适应,不影响层级,也不会受外层overflow:hidden影响。但是前端开发肯定不知道有这样的实现,因为对CSS和HTML的积累弱。其次,由于HTML/CSS不太溜,JS比较溜,因此写的组件重JS,轻HTML,导致出现臭皮匠一样的组件代码,例如某组件框架的单选框模拟实现。可以看到,模板走JS API,所有的单选框状态全部走JS API,一切都是JS,然后这个这个名为iRadio的组件600多行JS代码,我勒个擦,600多行啊,恕我愚钝,这洋洋洒洒600+行的JS代码的价值在哪里?虽然这个组件也能用,功能也OK,但是……算了,平复下心情…………。最后一点,也是最重要的一点,那就是前端开发人员的抽象与封装的意识侵入太深。很多开发人员会不理解,组件难道不是抽象越好封装越好就代表质量越高吗?这是个错误的认知!如果我们是开发纯语言的JavaScript框架,那确实是需要高度抽象与封装。但是我们这里开发的是UI组件诶,UI组件,看好了,是UI组件,有UI两个字,不是纯语言的,是与视觉和体验打交道的组件。我们开看一看一些前辈的言论吧:UI逻辑很难抽象,一旦抽象就意味着死去这是玉伯的言论。并不难理解,如果有组件自信对UI层进行了完美地抽象与封装,这表明,这个组件已经对UI层的表现有了很大的限制。这是毋庸置疑的,有些事物本身就是对立的矛盾体,工程化就是要讲求一致性,但是,UI表现讲求个性化,两者本质就是矛盾,不可调和的。这就是很多前端开发人员的局限,没有意识到UI框架和逻辑框架的本质差异,仍在追求整站复用、封装良好、API丰富。一句话:UI框架妄图涵盖所有场景,想要大而全,那是死路一条。Steve Jobs有句名言:do not according to user bad habits to design, also do not according to programmers thinking design!中文意思是“不要按照用户的坏习惯去设计,也不要按照程序员的思维去设计!”因为程序员的思维是工程化,系统化,开发便捷,这样的思维适合开发内部产品,做内部产品,功能最重要,UI很次要,看得过去就可以。但是,对于to C的外部产品,程序员这种思维就很有问题了。问大家一个问题,对于to C的产品,产品的体验和品质和开发人员开发便捷哪个更重要?对吧,很显然,产品的体验和品质是更重要!此时,程序员思维就会影响产品品质,因为一个气质明显,高端大气上档次的产品,定制化的UI和设计是免不了的。当然,实际开发,开发也会尽量按照产品和设计的需求实现最终的效果,只不过这个实现的方式是在原来又大又笨的组件基础上二次封装。天呐,组件本来就很大的,还要再封装,最终组件就会变得很笨重,而且还不能覆盖所有的设计场景,最后反而是让设计师调整设计以便适应组件当前固定的功能。天哪,本末倒置,对外的产品开发,怎么能因为组件的设计糟糕而继续让产品设计再变得平庸呢!LuLu UI则不一样,立足于to C产品,贯彻面向设计的开发理念,于是最终的形态和传统的UI组件有很多不同之处,包括:去API,模块低耦合,层级扁平,适当冗余;没有版本的概念,一条核心持续往前迭代;根植于项目,任何UI变动修改组件本身,包括JS;1. 没有版本概念传统UI组件都有1.0,2.0版本之类概念,LuLu UI没有,LuLu UI就是一个核心,自顾自往前走,只有主题概念,没有版本。当某个项目需要使用的时候,直接拷贝到项目中,和整个项目融为一体,从此和LuLu UI没有任何关系,走小鸡孵化模式,一旦出壳就可以自力更生。图示如下:由于UI层是多变的,不可控的,因此,当我们UI需要根据项目实际设计进行调整的时候,请直接修改项目中LuLu UI的CSS和JS代码!2. 根植于项目UI组件的修改一定要根植于项目,而不是重置或者二次封装,这很重要,我们是UI框架,跟着项目走,设计驱动组件,而不是组件限制设计。由于我们直接修改LuLu UI中的源码,因此,什么样的设计都能够驾驭。修改原始组件?很多人觉得不可思议。大家一定要扭转意识,对外的产品,要想品质出众,定制化的处理是必不可少的,就像私人定制的礼服,一定一不开工匠的手工制作。这个和中后台项目开发不一样!用图示意就是下面这样(可以对比上面的二次封装图):同样是定制,不同在于一个二次封装,一个是原始改造,既然走原始改造策略,那我们的UI组件就可以不用大而全,不会因为要应付各种场景变得日趋臃肿,一致保持简洁,这是LuLu UI优势以及长盛之道。很多人担心修改JS驾驭不来,根据我们几十个项目的实践经验,大多数场景下,是不需要对JS进行调整的,因此,不用担心。设计理念:基于HTML开发基于HTML开发的思想符合道家的追本溯源,无为而治。我们先看一个LuLu UI下的demo:基于原生的HTML UI组件体验demo一开始进去就是一个浏览器原生UI表单,如下作图所示,title提示,日期选择,表单验证等,都是粗糙的原生的UI。此时,我们点击下提交按钮,此时会加载LuLu UI的CSS和JS,结果神奇的事情发生了,UI全部变成了LuLu UI的模样,都变漂亮了。左边是原生HTML行为,右侧是LuLu UI实现的效果。更神奇的是,我们仅仅是引入了LULU UI组件的一点CSS和JS,没有动之前一点点一丝丝的业务JS. 但是,之前的各种交互功能,却完全不受影响。如下GIF:这就是基于HTML开发的理念,基于原生HTML,专注于UI表现,让UI组件回归了其本质或者说本职作用——UI!基于HTML开发更多优点语义化,可访问性,SEO等;学习成本低,API源自标准规范;前端分离——专注HTML控件本身,而不是组件;四、再次说说LuLu UI的Pure主题LuLu UI目前四大主题:modern:IE7+,依赖jQuery,生于2015年,停止维护peak:IE8+,依赖jQuery,PC,生于2016年,开源中pure:IE9+,原生JS,支持移动,生于2019年,开源中lead:Chrome+,原生JS,支持移动,内部开发中…其中Pure主题是当前LuLu UI组件库的主力,已经开源,相比之前主题进步在于:Native JS开发,性能升级;支持Vue和React项目组件引入,应用场景进一步扩大;支持属性检测,UI层自动更新,可以更加专注业务逻辑;全矢量资源,0资源外链,加载性能大幅提升;键盘和屏幕阅读无障碍访问有所提高;基于过往的经验,优化大量内部逻辑,使API更易用;API与语言风格完全统一,更加适合新人学习;文档升级,更加规范更加详细;Pure主题的当前阶段LuLu UI Pure主题目前已经开源:github.com/yued-fe/lul…官方地址:l-ui.comPure主题虽然开源,虽然站在了Peak主题的肩膀上,虽然内部经过了多轮系统的测试,但是一定还有很多不完美的地方,所谓实践方能出真知,希望可以有更多的人一起参与LuLu UI Pure主题的建设,这也是我写这篇文章的初衷。参与的方式有很多,可以Star一下表示你的爱,可以在项目中试用并反馈遇到的问题,可以直接参与代码建设优化内部的实现逻辑等。宇宙之大,生命之少,想想看人生的价值与意义,是巨大的奇迹还是巨大的浪费?我们是不是应该:做一件遵循内心,与众不同的事情;做一件对团队,对行业有意义的事情;和LuLU UI一起,穿越喧嚣浮躁,站在未来之路上;