前端工程

置信看到「Future.js」这个名字，会想起之前某厂间断开源的好几个前端相干我的项目之一的「Modern.js」——没错！就像「Fxxk Design」一样，这个名字也是受「启发」而起的，也是把一些正在建设中与布局要做的我的项目进行了「概念包装」。 从目前的理解来看，Modern.js 是要建设「大而全」的体系和打造「事实标准」。这种指标我是反对的，但拥护由商业组织牵头，尤其是国内的，应该由非盈利集体/组织发动并牵头主导与社区共建——不会呈现 KPI 开源等状况。 「大而全」的体系和打造「事实标准」是相辅相成的，一个「大而全」的体系和一系列「事实标准」能够让以后凌乱的 Web 前端变得更加有序，让技术深耕技术，令业务专一业务——这也是「反混沌」要做的事件。 业界现状在 React/Vue、Babel/Webpack 等呈现并风行之前的 jQuery 时代，前端开发是「面向页面」的，并且简直没有构建工具的参加，这时的范式能够说是「手动」或「人工」——DOM 的操作和数据的更新都要写很多代码去解决。 当 React/Vue、Babel/Webpack 等流行起来后，前端开发转为「基于组件」的，不仅代码的内聚性大幅晋升，DOM 操作也不必费神了——React/Vue 这一类库/框架将视图构造的变动与状态进行了绑定，状态变动时视图构造就会跟着变动。 与此同时，掀起了「工程化」潮流，构建工具链越发成熟，谱写了「流程自动化」的序章——能够认为当代的范式是「半自动」。 随同着 Node.js 的问世与倒退，前端一直地扩大着本人的能力边界——从 GUI 到 CLI，从运行时到编译时，从前端到后端，甚至是跳到 Rust、Dart 等非 JS 系的语言去了…… 然而，这些层出不穷的技术对于业务开发人员来说无疑是不友善的—— 最间接的影响就是扩散注意力。业务开发人员的次要关注点应该是业务相干的事件，如畛域常识、业务需要的落地等，而不是三天两头的「新技术」轰炸。搞得人人都很焦虑，巴不得多买点课程抓紧时间学，连吃饭拉屎都在学！ 而后就是进步了业务开发的复杂度。回忆一下当初新立个我的项目都须要做啥，与当初比照下，哪个让页面跑起来更容易更简略些？哪个呈现问题了排查起来更好找些？说实话，我听到 Babel/Webpack 就青筋抽动。 下面所列的是以后很显著很有影响的两个问题，为前端开发带来了凌乱——这是（我认为的）下一代范式要着重解决的，同时也是「反混沌」的使命——促成前端工业化过程，打造拆卸导向的工业流水线。 最近这几年也有其他人/团队在向相似方向摸索，例如飞冰。但它们的一些要害个性不是我想要的——锁定在某个视图库/框架上，并且是背靠商业组织。 Future.js要治理这凌乱局势，有两个关键点——将零碎（狭义的）各个档次、各个环节之间的通信规范化、标准化，这就须要一个「大而全」的体系和一系列「事实标准」；足够的形象和封装，让下层业务开发人员无需太去关注具体用的是什么技术以及怎么去用，并帮他们更好更快地实现业务需要。 兴许有人会说：「都规范化、标准化了，你让那些做业务开发的还怎么跳槽？！」我只想说：「真想进步本人的话，疾速把业务需要实现之后用那省下来的工夫去参加规范和基础设施的建设不好吗？」 作为「反混沌」体系的子体系之一，「Future.js」就是「大而全」的体系和「事实标准」在工具层面的体现。 名字中「Future」的含意不是它代表本人是「将来的做法」、「将来的方向」，而是「Future-oriented」，即「面向未来」。因而，它不是一个「大而全」的「框架」，而是「大而全」的、可自由组合、渐进式的「生态矩阵」。 「Future.js」的指标不仅是让前端开发变得有序，更是要做好前端的「本职工作」——连贯（产品、UX/UI）设计与后端。在这一点上，「Future.js」的方向是「配置驱动」。 总的来说，「Future.js」外表上是一套 JS-based 的解决方案，在有些场景会借助于其余语言的能力。与「Fxxk Design」一样，该体系下的我的项目将采纳分层、低耦合的架构作为根本准则。 建设中的最先要解决的就是配置化开发中后盾前端利用，目前与「Fxxk Design」体系相结合的局部架构为—— 图中所示架构的思维在「聊聊中后盾前端利用」系列文章中曾经阐明，这里不再赘述。能够看出，整体分为底层的 Organik 和下层的 Handie 这两大部分。 Organik 是一个配置驱动，或者说元数据驱动的逻辑引擎，次要作用就是收集各类元数据，如数据类型形容、模型形容、UI 组件形容、渲染类型形容、视图形容、模块形容等，依据须要将它们进行关联生成各种上下文。 Handie 则是一个包装在 Organik 和 Petals 里面的「壳儿」，间接面向业务开发人员。其外部又分为三层——技术栈无关的 handie；连贯技术栈的 handie-vue 与 handie-react 等；将上下文与 UI 组件连贯的 @handie/bulbasaur（Vue）和 @handie/squirtle（React）之类。 ...

从事前端开发的你，不知有没有被问过：「前端有架构吗？」 问你的人的身份，可能是你的 boss 或下属，可能是后端共事，也可能是前端同行；问你的人的目标，可能是刁难，可能是讥嘲，也可能是求教。 前端开发家喻户晓，做前端开发所依赖的核心技术就是 HTML、CSS 和 JS，就像好基友一样如影随行，咱们将它们仨亲切地并称为「三剑客」。 通过这二十多年，尤其是在 V8 引擎及 Node.js 呈现之后，以「三剑客」为根底的衍生技术如雨后春笋般大量呈现，前端及其关联社区与前端工程师这个职业失去了空前的蓬勃发展，甚至让很多人感觉一个前端工程师不仅仅能够做 web 前端开发，还能够写后端，代替客户端工程师——前端技术一统天下！ 工作内容除了做网页，前端技术还能利用于命令行工具、客户端利用、服务端利用、聊天机器人、爬虫、IoT 等场景。只有脑洞足够大，就不怕场景不够多。 然而，绝大部分的前端工程师在工作中都会接触到这些吗？ 试想一下，本人的工作历程是不是这样的—— 在一家 150 人规模以下的守业公司，可能业务还在摸索期，须要一直地疾速试错以找到能够铆足劲儿去发力的点。这时前端团队也没几个人，可能就三五个吧，并且 leader 不是什么大牛，也没有一套方法论作为团队建设的领导，兴许你是这个团队里实力最强的。 这个期间所须要的就是可能疾速迭代产出成绩，而后去验证是否无效。基本不会给你工夫去思考、布局前端团队的倒退方向与基础设施建设。如果特意破费工夫去做这些，没准儿公司会认为你「不务正业」，到时 KPI 打个不及格。 经验一段时间的焦头烂额，在此期间工程目录、代码提交很可能都很随便，并且没有 code review。有闲暇下来回头一看，代码一坨一坨跟那个什么似的，实现与「优雅」这个词绝缘。 随着业务的疾速倒退，我的项目、利用越来越多，团队人数也越来越多，然而标准约定、基础设施仍然简直没有。在业务线做开发的前端，也不太会想着整个团队的工具对立，本人怎么爽就怎么来。最终导致一个团队用了多种视图层库、多个组件库，给收敛技术栈带来很大妨碍。 终于，公司的业务开始走上正轨，前端团队也曾经有二三十人了，胸怀大志、急别人所不急的你感觉再这样横蛮成长上来是必定不行的，靠堆人力去满足疾速倒退且多变的业务需要是十分低效且低级的形式，必须要有技术上的基础设施去撑持！即便公司层面不容许工作工夫去做这种久远看来对公司是百利而无一害的事件，也要去做，就业余时间去做！ 在所有基础设施中，最高级、最能间接体现出开发提效成绩的，就是高度形象的 UI 框架。通过了不知多少个的「上班后」和「周末」，可算搞出了个可能满足肯定业务场景的，在本人负责的几个利用中初见成效。 正当你为本人所做的事件如冀望中那样失去了收益而感到快慰时，忽然有人冒出来质疑你所做的事件，并且有可能就是前端团队中的。还好有其他人对你做的事示意认可，感觉有价值，让你有能源在这件事上继续下去。兴许他是个后端开发，违心去用，或违心帮你在部门中推广。 你一直地给 UI 框架减少新的性能，并千方百计去革新旧零碎。在公司拓展业务所须要的新利用和以前老利用的保护中，你所做的货色确确实实节俭了不少人力和资源。在有新的一批后端开发入职时，还会邀请你在新人培训上给他们解说如何应用你所开发的 UI 框架辅助实现工作。这严严实实地打了当初质疑你的人的脸。 后盾零碎页面的常见模式就是供数据 CRUD 的列表页、表单页和详情页，当把撑持这些场景的交互和数据处理的外围逻辑都曾经形象了之后，你发现再怎么欠缺 UI 框架也不会有像之前那样比拟显著的效率晋升，顶多是优化了交互和开发体验，使性能更稳固而已。 你陷入了思考：「该做些什么能力持续为开发提效呢？」 之前做的 UI 框架，是对交互逻辑和数据逻辑进行了高度封装，并提供了大量的 CSS class 和工具办法。尽管使在做页面时能够少写很多 CSS 和 JS 代码，但对于 HTML 代码来说并没有缩小。 貌似找到了该冲破的点，但要怎么去做呢？ 左思右想，你忽然灵光乍现，想起了本人已经用过的基于「世界上最好的语言」开发的博客零碎——WordPress。既然后盾零碎页面如此模式化，何不效仿 WordPress 将不易变的局部作为「主题」，易变的局部作为「文章」？ 这样做会带来另外一个益处，就是将页面代码数据化了，有什么纯前端的问题批改就只是数据修改，而不必走简短繁冗的运维公布流程。日后如果公司有了本人的设计语言，再退出可视化搭建的个性，业务后盾零碎的开发和保护前端就不太用参加了！ 现实状况下，产品经理用已有物料拖拖拽拽生成「原型」，该「原型」就是最终界面；业务性能确定后，后端开发定模型、写接口，而后配置界面的数据展现。这样一来，业务零碎迭代的整个过程中，根本能够疏忽前端这个角色了。 那么前端干什么呢？在这样的合作模式下，前端的次要工作就是欠缺物料库，并且让产品经理和后端开发应用起来更不便。这种提效形式所带来的收益，与开发 UI 框架相比，基本不是一个档次的，想想都感觉兴奋！ 然而，现实的饱满遮不住事实的骨感。听到你的想法的人，要么质疑地问你一些问题，要么嘴上示意反对心理暗地讥笑——不想些怎么让业务倒退起来的事件，终日想什么乌七八糟、花里胡哨的货色！ ...

在软件开发中，研发效率永远是开发人员一直谋求的主题之一。于公司而言，在竞争强烈的互联网行业中，产出得快和慢兴许就决定着公司的生死存亡；于集体而言，效率高了就能够少加班，多出工夫去晋升本人、倒退喜好、陪伴家人，工作、生存两不误。 晋升效率的路径，无外乎就是「办法」和「工具」。以一个开发者的思维来想，就是将工作内容进行总结、演绎，从一组类似的工作内容中提炼共同点，形象出解决这一类问题的办法，从而造出便于在今后的工作中更为疾速解决这类问题的工具。这个「工具」能够是个函数、组件、中间件、插件，也能够是 IDE、其余开发工具的扩大，甚至是语言。 面向组件在古代前端开发中，如果去问一个业务前端开发：「如何晋升团队开发效率？」对方所答复的内容中，极有可能会呈现「组件库」。没错，在前端工程化趋近欠缺的明天，在近几年 React、Vue 等组件化库/框架的影响下，面向组件开发的思维形式早已深入人心。 组件库提效无限当初，组件库曾经是一个前端团队的必备设施了，久远来看，团队肯定且必须要有本人的组件库。开源的第三方组件库再好，对于一家企业的前端团队来说也只是短期用来充饥的，因为它们无奈齐全满足一家公司的业务场景，并且出于多终端反对的思考，必然要进行二次开发或者自研。 组件库有了，团队和公司中推广的成果也不错，绝大多数的人都在用。应用组件开发页面绝对 jQuery 时代要每块功能区都得从 <span>、<div> 等 HTML 标签码起来说的确晋升了效率，然而无限；要搞出页面须要重复去引入组件，而后组合拼装进去，就像工厂流水线上的工人拼装整机，依然要去做很多反复动作。 只有感觉以后的开发方式反复的动作多了，就代表还能持续提效，得想个法子缩小反复无意义动作。 面向组件的开发方式，是古代前端页面开发提效的初级阶段，也是一个团队所要必经的阶段。 更高层面的提效在之前写的文章中有段话—— 组件能够很简略，也能够很简单。依照复杂程度从小到大排的话，能够分为几类： 根底组件；复合组件；页面；利用。对，不必揉眼睛，你没有看错！ 站在更高的角度去看，「页面」和「利用」也是一种「组件」，只不过它们更为简单。在这里我想要说的不是它们，而是「根底组件」和「复合组件」。 欧雷《我来聊聊面向组件的前端开发》 文中提到了「页面」和「利用」也能够看作是种「组件」。尽管与过后的想法有些差别，但本文的内容就是要在那篇文章的根底上简略聊聊在「页面」层面的提效。 一般来说，「页面」是用户所能看到的最大、最残缺的界面，如果能在这个层面有个很好的形象计划，在做业务开发时与单纯高空向组件开发相比，应该会有更大的提效成果。 GUI 倒退了几十年，人机交互的图形元素及布局形式曾经绝对固定，只有不是呈现像 Google Glass 之类的革命性交互设施，就不会产生重大扭转。在业务开发中界面模式更是千篇一律，尤其是 web 页面，尤其是中后盾零碎的 web 页面，肯定能够通过什么形式来将这种「千篇一律」进行形象。 试着来回忆下，本人所做过的中后盾零碎的绝大部分页面是不是我所形容的这样—— 页面整体是高低或左右布局。如果是高低布局的话，下面是页头，上面的左侧可能有带页面导航的侧边栏，或者没有侧边栏间接将页面导航全副集中在页头中，残余区域是页面主体局部，承载着这个页面的次要数据和性能；如果是左右布局，左侧毋庸置疑就是有页面导航的侧边栏，页头跑到了右侧下面，其余是页面主体。 中后盾零碎的次要性能就是 CRUD，即业务数据的增删改查，绝对应的页面展示及交互模式就是列表页、表单页和详情页。列表页汇总了所有业务数据的简要信息，并提供了数据的增、删、改和更多信息查看的入口；表单页肩负着数据新增和批改的性能；详情页可能看到一条业务数据记录最残缺的信息。 每新增一个业务模块，就要又写一遍列表页、表单页和详情页……重复做这种事件有啥意思呢？既然这三种页面会重复呈现，那罗唆封装几个页面级别的组件好了，有新需要的时候就建几个页面入口文件，外面别离引入相应的页面组件，传入一些 props，完活儿！ 这种形式看起来不错，然而存在几个问题： 没有形容出页面内容的构造，已封装好的页面组件对于使用者来说算是个黑盒子，页面内容是什么构造不去看源码不得而知；如果新需要中尽管须要列表页、表单页和详情页，但与已封装好的可能笼罩大部分场景的相干组件所反对的页面有些差别，扩展性是个问题；每来新需要就要新建页面入口文件而后在外面引入页面组件，还是会有很多无意义反复动作和反复代码，工夫长了还是感觉烦。我须要一种既能看一眼就理解内容构造和关系，又具备较好扩展性，还能缩小反复代码和无意义动作的形式——是的，兜了一个大圈子终于要进入正题了——面向模板开发。 面向模板面向模板的前端开发有三大因素：模板；节点；部件。 富裕表达力的模板我所说的「模板」的次要作用是内容构造的形容以及页面的配置，观感上与 XHTML 相近。它次要具备以下几个特色： 字符全副小写，多单词用连接符「-」连贯，无子孙的标签间接闭合；蕴含极少的具备形象语义的标签的标签集；以特定标签的特定属性的模式反对无限的轻逻辑。为什么不抉择用 JSON 或 JSX 来形容和配置页面？因为模板更合乎直觉，更易读，并且中立。用模板的话，一眼就能简直不必思考地看出都有啥，以及层级关系；如果是 JSON 或 JSX，还得在脑中进行转换，减少心智累赘，并且拼写起来绝对简单。Vue 上手如此「简略」的起因之一，就是它「合乎直觉」的设计。 要应用模板去形容页面的话，就得自定义一套具备形象语义的标签集。 页面的整体布局能够用如下模板构造去形容： <layout> <header> <title>欧雷流</title> <navs /> </header> <layout> <sidebar> <navs /> </sidebar> <content>...</content> </layout> <footer>...</footer></layout>看起来是不是跟 HTML 标签很像？但它们并不是 HTML 标签，也不会进行渲染，只是用来形容页面的一段文本。 ...

看到题目，个别会有两种反馈： 「哇～好高大上啊！」 「嗯，这个话题真大……」 ——的确如此。 深情前戏我不生吞活剥那个什么百科来说啥是「面向组件」和为啥这么做，而是从工作现状以及本人思考的角度来论述，并试着拟出一个解决方案。 前端眼里的「组件」对于前端开发人员来说，「组件」通常就是指页面上的 UI 组件，次要包含外观和交互。一个合格的组件应该是可复用、可定制、松耦合的，它可能代表一个事物，能够实现一个动作。 组件能够很简略，也能够很简单。依照复杂程度从小到大排的话，能够分为几类： 根底组件；复合组件；页面；利用。对，不必揉眼睛，你没有看错！ 站在更高的角度去看，「页面」和「利用」也是一种「组件」，只不过它们更为简单。在这里我想要说的不是它们，而是「根底组件」和「复合组件」。 其中，根底组件具备简略的外观和根底的性能，而复合组件则是依据具体场景所进行的根底组件的组合和封装。 为啥要「面向组件」在从事一段时间的前端开发之后，就会发现： 「一个零碎里的页面性能怎么都差不多？」 「每个网站根本都一个模子里刻进去的！」 ——说得没错！ 你在 CTRL + C 并 CTRL + V，改掉雷同中的不同之后，保留文件并刷新页面，点这点那看看成果——「我靠！这俩页面的交互一毛一样，怎么在那个页面好好的，到这里就不好使了？！」 1……2……3……个小时过来了，这该死的小强到底是从哪里溜进来的一点儿脉络也没有……心里窝火地始终在「MMP」，一不小心说漏了嘴——「妈卖批的！！！」 兄弟，淡定！ 呈现这种问题，是因为没有面向组件开发。那些你所感觉的「类似」的局部，就能够提取进去造成组件，以备再次出现相似场景时应用。你以往所依赖的「CTRL + C / V 大法」，讲道理，是下下策中的下下策。 等组件积攒得多了，页面就不再是本人苦思冥想一行一行代码挤出来的，而是顺手从现成的库中拿来一个一个组件拼出来的。如此一来，不仅页面性能更加稳固，前端开发也能脱离干燥而变得更加乏味，辞别那一整天大部分工夫在摁臭虫的鬼日子—— 后端：「什么时候能够联调？」 前端：「页面早就弄好了，接口呢？」 后端：「……」 「面向组件」是啥啊换个词，「组件化」，兴许更为相熟。但，所以，到底是指什么呢？ 对于抽象概念的含意，每个人都会有本人的了解，正所谓「一千个读者心中有一千个哈姆雷特」。有人会说： 就是把相干的 HTML、CSS、JS 和图片等文件放到同一个文件夹里吧？——没啥故障。 在进行面向组件开发时，的确会将同一个组件的相干文件放在一个文件夹中，然而，这并不是外围。重要的是，可能将一个简单的货色恰到好处地拆分成更小且独立的，高内聚低耦合，让他人不用理解其外部运作原理拿来就用——这是思维，也是能力。 进入正题「面向组件」开发，或者说「组件化」，由来已久，并不陈腐。这个话题在前端圈儿也炒了很多年了，这个框架那个库的层出不穷，为什么我当初还要再拿进去嚼一遍呢？ 理由很简略： 在他人那不成问题的，在我这可能很是问题；对他人很管用的工具，对我可能并不太实用。他人爽的姿态我不爽要进行面向组件开发，前提是得有可行的技术计划，依我看，须要必备几点： 组件的款式和交互不会意外地被外界烦扰——对外隔离；一个组件相干的资源要在我用到时再给我——按需加载；让前端技术不那么强的后端开发也能够用——门槛低。红极一时的充分发挥 jQuery 专长的两个宝儿，jQuery UI 和 Bootstrap 提供了很多 UI 组件，对后端开发人员也很敌对，看起来符合要求。但从它们组件的实现形式以及资源加载模式来看—— jQuery UIBootstrap当初的前端圈儿，一提到「组件」，大多数人的兴奋点都在 React、Vue、Angular 等 MV* 框架上。它们是很不错，不仅满足了「对外隔离」和「按需加载」，还大大地晋升了前端开发的效率，能大红大紫成这样自有其情理。 我司的业务是 to B 的，因而前端开发场景很「明确」，根本能够简略粗犷地了解为：「前台」就是挪动端，「后盾」就是桌面端。 前台开发用的是基于 React 和 Ant Design Mobile 二次开发的框架。It works well，可能 hold 住以后的需要。然而，后盾开发就不一样了。 ...

本文首发于欧雷流。因为我会时不时对文章进行补充、修改和润色，为了保障所看到的是最新版本，请浏览原文。本文是一个文章系列的第一篇，次要阐明几个基本概念以及所要探讨的指标主体，目标是对立认知上的「上下文」以尽量避免因信息不对称而造成了解阻碍。 这一系列文章是对于前端 UI 组件的，我想通过这个系列静下心来好好聊聊与之相干的内容。 每个名词都是概念，就像一个「数据包」，依据其被「压缩」的信息量，要真正地了解一个词语可能须要大量的常识储备。 基本概念咱们要聊的是「前端 UI 组件」，这个词能够进一步拆分成「前端」、「UI」和「组件」这三个词。所以，要想弄明确「前端 UI 组件」是什么，得先把组成它的三个词搞懂。 UI？GUI？平时在议论一个软件的视觉方面的问题时，总会用到「UI」这个英文缩写，有时也会说「GUI」。尽管它们是不同的含意，但在大多数状况下，咱们是将这两个词划等号了。在这里，我试图帮大家将这两个词辨别开，就算用法仍然不变，至多可能意识到它们的区别。 人与机器间，更确切地说是与人造零碎间，是如何进行互动的以及如何更好地交互，是人们始终在摸索的——也就是「人机交互」这个词所代表的。「人造零碎」能够是各种各样的物理机器，也能够是计算机系统和软件。 「交互」的实质就是人/物体间的信息替换，即信息从一个人/物体输入，输出到另一个人/物体中。因而，两个人/物体、输入形式、输出形式是交互的几个基本要素。 在人机交互的场景中，进行互动的对象是人和人造零碎。人通过敲击、触摸、谈话等形式输入信息，通过视觉、听觉、触觉等形式输出信息；人造零碎则通过文本、图形、声音等形式输入信息，通过将人以各种形式产生的信息转化为电流的形式输出信息。 在人机交互中起到信息替换作用的那块空间，叫做「人机交互界面」，也叫「用户界面」。「UI」就是「用户界面」所对应的英文单词「User Interface」的缩写。 不同的交互方式和档次产生了不同的「用户界面」，如：基于文本的「命令行界面（Command-line Interface）」、基于图形的「图形用户界面（Graphical User Interface）」、基于语音的「自然语言用户界面（Natural-language User Interface）」等等。 其中，「图形用户界面」是目前比拟宽泛应用的，它的英文缩写就是「GUI」。 前端开发所谓的「前端开发」就是利用 web 前端技术进行 GUI 相干的开发工作，专门从事这类工作的人被称为「前端开发者」。 在以前，「前端开发者」是指「页面重构工程师」和「前端开发工程师」；随着业务和技术的倒退，「页面重构工程师」慢慢退出历史舞台，「前端开发者」根本与「前端开发工程师」划等号，并且称说变得更精简——「前端工程师」。 在职业产生扭转的同时，作为一个「前端开发者」，作为一名「前端工程师」，企业和业界的冀望变高了，所承当的职责变重了——这是一次职业降级，也是一次行业荡涤——适应的人变更强了，不适的人被淘汰了。 时至今日，「前端开发」的含意也不是当初单纯地写写页面做做网站，还涵盖了前端工程相干的 CLI 工具、挪动端和桌面端的客户端利用、服务端中比拟凑近前端的局部等等等等——这俨然是一个「客户端工程师」所做的工作——没错！「前端开发」实质上就是「客户端开发」的一个分支，只不过这点越来越被强化了，并且「客户端开发」越来越趋势对立，能够称之为「泛客户端开发」。 无论工作内容和职业职责怎么变，只有是做这行，所要解决的外围问题是不变的——人与人造零碎之间如何更好地进行互动。 组件？控件？在软件工程中，「组件（component）」个别是指软件的可复用块，好比制造业所应用的「构件」。这是一个比拟宽泛的概念，它能够是软件包，能够是 web 服务，也能够是模块等。 但在前端眼里，「组件」通常是指页面上的视图单元，即「UI 组件」。能够说，「UI 组件」是「组件」的子集。你可能还总会听到「控件（control）」这个词。放轻松，别抓头，它只是「UI 组件」的一个别名而已。 一般的组件通用性很差，也就是说，它根本只能用于某个特定的零碎且不能被替换。有一种组件，它是基于标准化的接口标准开发进去的，能用在任何对接了该接口的零碎，也能被任何合乎该接口标准的组件替换——它就是「可替换组件」，就像制造业所应用的「标准件」。 可替换的 UI 组件是前端 GUI 开发从手工作坊到主动拆卸的关键所在。 相干概念下面通过三个比拟根本的概念论述了「前端 UI 组件」是什么，上面再来说说会对其产生重大影响的几个概念—— 设计体系所谓的「设计体系」，即「Design System」，是与 UI 组件非亲非故的一个概念。能够认为，设计体系是 UI 组件的外观及交互的理论依据，而 UI 组件是设计体系的具体实现。 设计体系的存在是为了辅助像网站、利用等数字产品的设计与开发，它作为惟一的参考而让不同团队的人（如产品经理、设计师和开发人员等）能够一起参加到数字产品的建设当中。 基于设计体系设计并开发进去的产品无论是在观感上还是体验上都可能放弃肯定的一致性，建立产品形象并流传品牌价值。 设计体系所涵盖的内容，包含但不限于设计语言、格调指南、模式库、UI 组件、品牌语言及与之相干的应用阐明文档——设计体系自身不是一个交付物，但它是由一些交付物组成的，并会随着产品、工具和技术等的更新而一直进化。 从下面所列出的设计体系的涵盖内容中能够看出，形成它的元素有无形的，像模式、UI 组件、指南及给设计师和开发人员所应用的工具等；还有一些是有形的，像品牌价值观、合作形式、思维形式和独特信念等。 ...

本文首发于欧雷流。由于我会时不时对文章进行补充、修正和润色，为了保证所看到的是最新版本，请阅读原文。在软件开发中，研发效率永远是开发人员不断追求的主题之一。于公司而言，在竞争激烈的互联网行业中，产出得快和慢也许就决定着公司的生死存亡；于个人而言，效率高了就可以少加班，多出时间去提升自己、发展爱好、陪伴家人，工作、生活两不误。 提升效率的途径，无外乎就是「方法」和「工具」。以一个开发者的思维来想，就是将工作内容进行总结、归纳，从一组相似的工作内容中提炼共同点，抽象出解决这一类问题的方法，从而造出便于在今后的工作中更为快速解决这类问题的工具。这个「工具」可以是个函数、组件、中间件、插件，也可以是 IDE、其他开发工具的扩展，甚至是语言。 面向组件在现代前端开发中，如果去问一个业务前端开发：「如何提升团队开发效率？」对方所回答的内容中，极有可能会出现「组件库」。没错，在前端工程化趋近完善的今天，在近几年 React、Vue 等组件化库/框架的影响下，面向组件开发的思维方式早已深入人心。 组件库提效有限现在，组件库已经是一个前端团队的必备设施了，长远来看，团队一定且必须要有自己的组件库。开源的第三方组件库再好，对于一家企业的前端团队来说也只是短期用来充饥的，因为它们无法完全满足一家公司的业务场景，并且出于多终端支持的考虑，必定要进行二次开发或者自研。 组件库有了，团队和公司中推广的效果也不错，绝大多数的人都在用。使用组件开发页面相对 jQuery 时代要每块功能区都得从 <span>、<div> 等 HTML 标签码起来说确实提升了效率，然而有限；要搞出页面需要反复去引入组件，然后组合拼装出来，就像工厂流水线上的工人拼装零件，仍然要去做很多重复动作。 只要觉得当前的开发方式重复的动作多了，就代表还能继续提效，得想个法子减少重复无意义动作。 面向组件的开发方式，是现代前端页面开发提效的初级阶段，也是一个团队所要必经的阶段。 更高层面的提效在之前写的文章中有段话—— 组件可以很简单，也可以很复杂。按照复杂程度从小到大排的话，可以分为几类： 基础组件；复合组件；页面；应用。对，不用揉眼睛，你没有看错！ 站在更高的角度去看，「页面」和「应用」也是一种「组件」，只不过它们更为复杂。在这里我想要说的不是它们，而是「基础组件」和「复合组件」。 ——欧雷《我来聊聊面向组件的前端开发》 文中提到了「页面」和「应用」也可以看作是种「组件」。虽然与当时的想法有些差异，但本文的内容就是要在那篇文章的基础上简单聊聊在「页面」层面的提效。 一般来说，「页面」是用户所能看到的最大、最完整的界面，如果能在这个层面有个很好的抽象方案，在做业务开发时与单纯地面向组件开发相比，应该会有更大的提效效果。 GUI 发展了几十年，人机交互的图形元素及布局方式已经相对固定，只要不是出现像 Google Glass 之类的革命性交互设备，就不会发生重大改变。在业务开发中界面形式更是千篇一律，尤其是 web 页面，尤其是中后台系统的 web 页面，一定可以通过什么方式来将这种「千篇一律」进行抽象。 试着来回想下，自己所做过的中后台系统的绝大部分页面是不是我所描述的这样—— 页面整体是上下或左右布局。如果是上下布局的话，上面是页头，下面的左侧可能有带页面导航的侧边栏，或者没有侧边栏直接将页面导航全部集中在页头中，剩余区域是页面主体部分，承载着这个页面的主要数据和功能；如果是左右布局，左侧毋庸置疑就是有页面导航的侧边栏，页头跑到了右侧上面，其余是页面主体。 中后台系统的主要功能就是 CRUD，即业务数据的增删改查，相对应的页面展现及交互形式就是列表页、表单页和详情页。列表页汇总了所有业务数据的简要信息，并提供了数据的增、删、改和更多信息查看的入口；表单页肩负着数据新增和修改的功能；详情页能够看到一条业务数据记录最完整的信息。 每新增一个业务模块，就要又写一遍列表页、表单页和详情页……反复做这种事情有啥意思呢？既然这三种页面会反复出现，那干脆封装几个页面级别的组件好了，有新需求的时候就建几个页面入口文件，里面分别引入相应的页面组件，传入一些 props，完活儿！ 这种方式看起来不错，然而存在几个问题： 没有描述出页面内容的结构，已封装好的页面组件对于使用者来说算是个黑盒子，页面内容是什么结构不去看源码不得而知；如果新需求中虽然需要列表页、表单页和详情页，但与已封装好的能够覆盖大部分场景的相关组件所支持的页面有些差异，扩展性是个问题；每来新需求就要新建页面入口文件然后在里面引入页面组件，还是会有很多无意义重复动作和重复代码，时间长了还是觉得烦。我需要一种既能看一眼就理解内容结构和关系，又具备较好扩展性，还能减少重复代码和无意义动作的方式——是的，兜了一个大圈子终于要进入正题了——面向模板开发。 面向模板面向模板的前端开发有三大要素：模板；节点；控件。 富有表达力的模板我所说的「模板」的主要作用是内容结构的描述以及页面的配置，观感上与 XHTML 相近。它主要具备以下几个特征： 字符全部小写，多单词用连接符「-」连接，无子孙的标签直接闭合；包含极少的具备抽象语义的标签的标签集；以特定标签的特定属性的形式支持有限的轻逻辑。为什么不选择用 JSON 或 JSX 来描述和配置页面？因为模板更符合直觉，更易读，并且中立。用模板的话，一眼就能几乎不用思考得看出都有啥，以及层级关系；如果是 JSON 或 JSX，还得在脑中进行转换，增加心智负担，并且拼写起来相对复杂。Vue 上手如此「简单」的原因之一，就是它「符合直觉」的设计。 要使用模板去描述页面的话，就得自定义一套具有抽象语义的标签集。 页面的整体布局可以用如下模板结构去描述： <layout> <header> <title>欧雷流</title> <navs /> </header> <layout> <sidebar> <navs /> </sidebar> <content>...</content> </layout> <footer>...</footer></layout>看起来是不是跟 HTML 标签很像？但它们并不是 HTML 标签，也不会进行渲染，只是用来描述页面的一段文本。 ...

本文首发于欧雷流。由于我会时不时对文章进行补充、修正和润色，为了保证所看到的是最新版本，请阅读原文。看到标题，一般会有两种反应： 「哇～好高大上啊！」「嗯，这个话题真大……」 ——的确如此。 深情前戏我不生搬硬套那个什么百科来说啥是「面向组件」和为啥这么做，而是从工作现状以及自己思考的角度来阐述，并试着拟出一个解决方案。 前端眼里的「组件」对于前端开发人员来说，「组件」通常就是指页面上的 UI 组件，主要包括外观和交互。一个合格的组件应该是可复用、可定制、松耦合的，它能够代表一个事物，可以完成一个动作。 组件可以很简单，也可以很复杂。按照复杂程度从小到大排的话，可以分为几类： 基础组件；复合组件；页面；应用。对，不用揉眼睛，你没有看错！ 站在更高的角度去看，「页面」和「应用」也是一种「组件」，只不过它们更为复杂。在这里我想要说的不是它们，而是「基础组件」和「复合组件」。 其中，基础组件具有简单的外观和基础的功能，而复合组件则是根据具体场景所进行的基础组件的组合和封装。 为啥要「面向组件」在从事一段时间的前端开发之后，就会发现： 「一个系统里的页面功能怎么都差不多？」「每个网站基本都一个模子里刻出来的！」 ——说得没错！ 你在 CTRL + C 并 CTRL + V，改掉相同中的不同之后，保存文件并刷新页面，点这点那看看效果——「我靠！这俩页面的交互一毛一样，怎么在那个页面好好的，到这里就不好使了？！」 1……2……3……个小时过去了，这该死的小强到底是从哪里溜进来的一点儿头绪也没有……心里窝火地一直在「MMP」，一不小心说漏了嘴——「妈卖批的！！！」 兄弟，淡定！ 出现这种问题，是因为没有面向组件开发。那些你所觉得的「相似」的部分，就可以提取出来形成组件，以备再次出现类似场景时使用。你以往所依赖的「CTRL + C / V 大法」，讲道理，是下下策中的下下策。 等组件积累得多了，页面就不再是自己苦思冥想一行一行代码挤出来的，而是随手从现成的库中拿来一个一个组件拼出来的。如此一来，不仅页面功能更加稳定，前端开发也能脱离枯燥而变得更加有趣，告别那一整天大部分时间在摁臭虫的鬼日子—— 后端：「什么时候可以联调？」前端：「页面早就弄好了，接口呢？」 后端：「……」 「面向组件」是啥啊换个词，「组件化」，也许更为熟悉。但，所以，到底是指什么呢？ 对于抽象概念的含义，每个人都会有自己的理解，正所谓「一千个读者心中有一千个哈姆雷特」。有人会说： 就是把相关的 HTML、CSS、JS 和图片等文件放到同一个文件夹里吧？——没啥毛病。 在进行面向组件开发时，确实会将同一个组件的相关文件放在一个文件夹中，然而，这并不是核心。重要的是，能够将一个复杂的东西恰如其分地拆分成更小且独立的，高内聚低耦合，让别人不必了解其内部运作原理拿来就用——这是思想，也是能力。 进入正题「面向组件」开发，或者说「组件化」，由来已久，并不新鲜。这个话题在前端圈儿也炒了很多年了，这个框架那个库的层出不穷，为什么我现在还要再拿出来嚼一遍呢？ 理由很简单： 在别人那不成问题的，在我这可能很是问题；对别人很管用的工具，对我可能并不太适用。别人爽的姿势我不爽要进行面向组件开发，前提是得有可行的技术方案，依我看，需要必备几点： 组件的样式和交互不会意外地被外界干扰——对外隔离；一个组件相关的资源要在我用到时再给我——按需加载；让前端技术不那么强的后端开发也可以用——门槛低。红极一时的充分发挥 jQuery 特长的两个宝儿，jQuery UI 和 Bootstrap 提供了很多 UI 组件，对后端开发人员也很友好，看起来符合要求。但从它们组件的实现方式以及资源加载形式来看—— jQuery UIBootstrap现在的前端圈儿，一提到「组件」，大多数人的兴奋点都在 React、Vue、Angular 等 MV* 框架上。它们是很不错，不仅满足了「对外隔离」和「按需加载」，还大大地提升了前端开发的效率，能大红大紫成这样自有其道理。 我司的业务是 to B 的，因此前端开发场景很「明确」，基本可以简单粗暴地理解为：「前台」就是移动端，「后台」就是桌面端。 前台开发用的是基于 React 和 Ant Design Mobile 二次开发的框架。It works well，能够 hold 住当前的需求。然而，后台开发就不一样了。 ...