精华内容
下载资源
问答
  • Web Components 原生开发使html组件化模块化
    千次阅读 热门讨论
    2021-01-25 09:52:26

    目录结构:
    在这里插入图片描述

    入口文件:index.html

    <!DOCTYPE html>
    <html>
    	<head>
    		<meta charset="utf-8" />
    		<meta name="viewport" content="width=device-width, initial-scale=1">
    		<title>使用组件</title>
    		<!-- <link rel="import" href="components/hello-world.html" id="hello-world"> -->
    	</head>
    	<body>
    		<hello-world></hello-world>
    
    
    		<script type="module" src="./components/hello-world.js"></script>
    	</body>
    </html>
    

    模块文件:

    // import './header.js' //引入组件
    
    class HelloWorld extends HTMLElement {
    	constructor() {
    		super();
    		const shadowRoot = this.attachShadow({ mode: 'open' });
    		shadowRoot.innerHTML = this.template();
    	}
    	template() {
    		return `
    			<style>
    					h1{
    					color: #f00;
    					}
    			</style>
    
    			<h1>组件元素</h1>
    			<!-- <edo-header></edo-header> -->
    		`;
    	}
    	// 生命周期:首次被插入文档DOM时
    	connectedCallback() {
    		console.log('template element is connected');
    	}
    	// 生命周期:从文档DOM中删除时
    	disconnectedCallback() {
    		console.log(1111);
    	}
    	// 生命周期:被移动到新的文档时
    	adoptedCallback() {
    		console.log(22222);
    	}
    
    	// 生命周期:监听属性变化
    	attributeChangedCallback() {
    		console.log(3333333);
    	}
    }
    customElements.define('hello-world', HelloWorld);
    

    打开:
    在这里插入图片描述

    效果:
    在这里插入图片描述

    更多相关内容
  • Web应用的组件化开发(一)

    千次阅读 2017-05-27 20:28:39
    1. 为什么要做组件化? 无论前端也好,后端也好,都是整个软件体系的一部分。软件产品也是产品,它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的,在产品目标确定的情况下,成本有两个途径来优化:...

    基本思路

    1. 为什么要做组件化?

    无论前端也好,后端也好,都是整个软件体系的一部分。软件产品也是产品,它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的,在产品目标确定的情况下,成本有两个途径来优化:减少部署成本,提高开发效率。

    减少部署成本的方面,业界研究得非常多,比如近几年很流行的“去IOE”,就是很典型的,从一些费用较高的高性能产品迁移到开源的易替换的产品集群,又比如使用Linux + Mono来部署.net应用,避开Windows Server的费用。

    提高开发效率这方面,业界研究得更多,主要途径有两点:加快开发速度,减少变更代价。怎样才能加快开发速度呢?如果我们的开发不是重新造轮子,而是 每一次做新产品都可以利用已有的东西,那就会好很多。怎样才能减少变更代价呢?如果我们能够理清模块之间的关系,合理分层,每次变更只需要修改其中某个部 分,甚至不需要修改代码,仅仅是改变配置就可以,那就更好了。 我们先不看软件行业,来看一下制造行业,比如汽车制造业,他们是怎么造汽车的呢?造汽车之前,先设计,把整个汽车分解为不同部件,比如轮子,引擎,车门, 座椅等等,分别生产,最后再组装,所以它的制造过程可以较快。如果一辆汽车轮胎被扎破了,需要送去维修,维修的人也没有在每个地方都修一下,而是只把轮胎 拆下来修修就好了,这个轮胎要是实在坏得厉害,就干脆换上个新的,整个过程不需要很多时间。

    席德梅尔出过一款很不错的游戏,叫做《文明》(Civilization),在第三代里面,有一项科技研究成功之后,会让工人工作效率加倍,这项科技的名字就叫做:可替换部件(Replacement Parts)。所以,软件行业也应当引入可替换的部件,一般称为组件。

    2. 早期的前端怎么做组件化的?

    在服务端,我们有很多组件化的途径,像J2EE的Beans就是一种。组件建造完成之后,需要引入一些机制来让它们可配置,比如说,工作流引擎,规 则引擎,这些引擎用配置的方式组织最基础的组件,把它们串联为业务流程。不管使用什么技术、什么语言,服务端的组件化思路基本没有本质差别,大家是有共识 的,具体会有服务、流程、规则、模型等几个层次。

    早期展示层基本以静态为主,服务端把界面生成好,浏览器去拿来展示,所以这个时期,有代码控制的东西几乎全在服务端,有分层的,也有不分的。如果做了分层,大致结构就是下图这样:

    120140115115021

    这个图里,JSP(或者其他什么P,为了举例方便,本文中相关的服务端技术都用Java系的来表示)响应浏览器端的请求,把HTML生成出来,跟相 关的JavaScript和CSS一起拿出去展示。注意这里的关键,浏览器端对界面的形态和相关业务逻辑基本都没有控制权,属于别人给什么就展示什么,想 要什么要先提申请的尴尬局面。

    这个时期的Web开发,前端的逻辑是基本可忽略的,所以前端组件化方式大同小异,无论是ASP还是JSP还是其他什么P,都可以自定义标签,把HTML代码和行间逻辑打包成一个标签,然后使用者直接放置在想要的地方,就可以了。

    在这一时代,所谓的组件化,基本都是taglib这样的思路,把某一块界面包括它的业务逻辑一起打成一个端到端的组件,整个非常独立,直接一大块从界面到逻辑都有,而且逻辑基本上都是在服务端控制,大致结构如下图所示。

    220140115115033

    3. SPA时代,出现了新问题

    自从Web2.0逐渐流行,Web前端已经不再是纯展示了,它逐渐把以前在C/S里面做的一些东西做到B/S里面来,比如说Google和微软的在线Office,这种复杂度的Web应用如果还用传统那种方式做组件化,很显然是行不通的。

    我们看看之前这种组件化的方式,本质是什么?是展现层跟业务逻辑层的隔离,后端在处理业务逻辑,前端纯展现。如果现在还这么划分,就变成了前端有界 面和逻辑,后端也有逻辑,这就比较乱了。我们知道,纯逻辑的分层组件化还是比较容易的,任何逻辑如果跟展现混起来,就比较麻烦了,所以我们要把分层的点往 前推,推到也能把单独的展现层剥离出来。

    如下图所示,因为实际上HTML、CSS、JavaScript这些都逐渐静态化,所以不再需要把它们放在应用服务器上了,我们可以把它们放在专门 的高性能静态服务器上,再进一步发展,就可以是CDN(Content Delivery Network,内容分发网络)。前端跟后端的通信,基本都是通过AJAX来,也会有一些其他的比如WebSocket之类,总之尽量少刷新了。

    320140115115047

    在这张图里面可以看到,真正的前端已经形成了,它跟应用服务器之间形成了天然的隔离,所以也能够很独立地进行一些发展演进。

    现在很多Web程序在往SPA(单页面程序,Single Page Application)的方向发展,这类系统通常比较类似传统的C/S程序,交互过程比较复杂,因此它的开发过程也会遇到一些困难。

    那为什么大家要做SPA呢?它有很多明显的好处,最核心的优势就是高效。这个高效体现在两个方面:一是对于用户来说,这种方式做出来的东西体验较 好,类似传统桌面程序,对于那些需要频繁操作的行业用户,有很大优势。二是运行的效率较高,之前集成一些菜单功能,可能要用iframe的方式引入,但每 个iframe要独立引入一些公共文件,服务器文件传输的压力较大,还要初始化自己的一套内存环境,比较浪费,互相之间也不太方便通信,一般要通过 postMessage之类的方式去交互。

    有了SPA之后,比如一块界面,就可以是一个HTML片段,用AJAX去加载过来处理之后放到界面上。如果有逻辑的JavaScript代码,也可以用require之类的异步加载机制去运行时加载,整体的思路是比较好的。

    很多人说,就以这样的需求,用jQuery再加一个异步js加载框架,不是很足够了吗?这两个东西用得好的话,也是能够解决一些问题的,但它们处理 的并不是最关键的事情。在Web体系中,展现层是很天然的,因为就是HTML和CSS,如果只从文件隔离的角度,也可以做出一种划分的方式,逻辑放在单独 的js文件里,html内部尽量不写js,这就是之前比较主流的前端代码划分方式。

    刚才我们提到,SPA开发的过程中会遇到一些困难,这些困难是因为复杂度大为提升,导致了一些问题,有人把这些困难归结为纯界面的复杂度,比如说, 控件更复杂了之类,没有这么简单。问题在于什么呢?我打个比方:我们在电脑上开两个资源管理器窗口,浏览到同一个目录,在一个目录里把某个文件删了,你猜 猜另外一个里面会不会刷新?

    毫无疑问,也会刷新,但是你看看你用的Web页面,如果把整个复杂系统整合成单页的,能保证对一个数据的更新就实时反馈到所有用它的地方吗?怎么做,是不是很头疼?代码组织的复杂度大为提高,所以需要做一些架构方面的提升。

    4. 架构的变更

    提到架构,我们通常会往设计模式上想。在著名的《设计模式》一书中,刚开始就讲了一种典型的处理客户端开发的场景,那就是MVC。

    传统的MVC理念我们并不陌生,因为有Struts,所以在Web领域也有比较经典的MVC架构,这里面的V,就负责了整个前端的渲染,而且是服务端的渲染,也就是输出HTML。如下图所示:

    420140115115100

    在SPA时代,这已经不合适了,所以浏览器端形成了自己的MVC等层次,这里的V已经变成客户端渲染了,通常会使用一些客户端的HTML模版去实现,而模型和控制器,也相应地在浏览器端形成了。

    520140115115113

    我们有很多这个层面的框架,比如Backbone,Knockout,Avalon,Angular等,采用了不同的设计思想,有的是MVC,有的是MVP,有的是MVVM,各有其特点。

    以Angular为例,它推荐使用双向绑定去实现视图和模型的关联,这么一来,如果不同视图绑定在同一模型上,就解决了刚才所说的问题。而模型本身也通过某种机制,跟其他的逻辑模块进行协作。

    这种方式就是依赖注入。依赖注入的核心理念就是通过配置来实例化所依赖的组件。使用这种模式来设计软件架构,会牺牲一些性能,在跟踪调试的便利性等方面也会有所损失,但换来的是无与伦比的松耦合和可替代性。

    比如说,这些组件就可以单独测试,然后在用的时候随手引入,毫无压力。对于从事某一领域的企业来说,光这一条就足以吸引他在上面大量投入,把所有不常变动领域模型的业务代码都用此类办法维护起来,这是一种财富。

    5. MV*框架的基本原理

    如果我们来设计Angular这么一个前端框架,应当如何入手呢?很显然,逻辑的控制必须使用JavaScript,一个框架,最本质的事情在于它的逻辑处理方式。

    我们的界面为什么可以多姿多彩?因为有HTML和CSS,注意到这两种东西都是配置式的写法,参照后端的依赖注入,如果把这两者视为跟Spring框架中一些XML等同的配置文件,思路就豁然开朗了。

    与后端不同的是,充当前端逻辑工具的JavaScript不能做入口,必须挂在HTML里才能运行,所以出现了一个怪异的状况:逻辑要先挂在配置文 件(HTML)上,先由另外的容器(浏览器或者Hybird的壳)把配置文件加载起来,然后才能从某个入口开始执行逻辑。好消息是,过了这一步,逻辑层就 开始大放异彩了。

    从这个时候开始,框架就启动了,它要做哪些事情呢?

    • 初始化自身(bootstrap)
    • 异步加载可能尚未引入的JavaScript代码(require)
    • 解析定义在HTML上的规则(template parser)
    • 实例化模型(scope)
    • 创建模型和DOM的关联关系(binding, injection)

    这些是主线流程,还有一些支线,比如:

    • 解析url的search字符串,恢复状态(route)
    • 加载HTML部件模板(template url)
    • 部件模板和模型的关联(binding)

    6. 如何做组件化

    6.1. HTML的组件化

    SPA的一个典型特征就是部分加载,界面的部件化也是其中比较重要的一环。界面片段在动态请求得到之后,借助模版引擎之类的技术,经过某种转换,放置到主界面相应的地方。所以,从这个角度来看,HTML的组件化非常容易理解,那就是界面的片段化和模板化。

    6.2. JavaScript的组件化

    JavaScript这个部分有好几个发展阶段。

    • 早期的共享文件,把公共功能的代码提出出来,多个页面共用
    • 动态引用,消灭全局变量
    • 在某些框架上进一步划分,比如Angular里面又分为provider,service,factory,controller

    JavaScript组件化的目标是什么呢,是清晰的职责,松耦合,便于单元测试和重复利用。这里的松耦合不仅体现在js代码之间,也体现在js跟 DOM之间的关系,所以像Angular这样的框架会有directive的概念,把DOM操作限制到这类代码中,其他任何js代码不操作DOM。

    620140115115446

    如上图所示,总的原则是先分层次,层内再作切分。这么做的话,不再存在之前那种端到端组件了,使用起来没有原先那么方便,但在另外很多方面比较好。

    6.3. CSS的组件化

    这方面,业界也有很多探索,比如LESS,SASS,Stylus等。为什么CSS也要做组件化呢?传统的CSS是一种扁平的文本结构,变更成本较 高,比如说想要把结构从松散改紧凑,需要改动很多。如果把实际使用的CSS只当作输出结果,而另外有一种适合变更的方式当作中间过程,这就好多了。比如 说,我们把一些东西定义成变量,每个细节元素使用这些变量,当需要整体变更的时候,只需修改这些变量然后重新生成一下就可以了。

    以上,我们讨论了大致的Web前端开发的组件化思路,后续将阐述组件化之后的协作过程和管控机制。

    展开全文
  • Web前端工程化与组件化开发实践
  • 组件Web可视化开发平台在调度自动化系统中的应用.pdf
  • Web可视化开发平台着重阐述了可视化的开发Web应用, 不仅融入了单点登录、图形自动生成、表单设计器、布局设计器、设备拓扑生成和业务功能快速开发功能组件, 还分析了各地区电网业务需求, 进一步强化了各个组件的功能...
  • 1. 什么是前端工程 自有前端工程师这个称谓以来,前端的发展可谓是日新月异。...套模板(RD)”的开发模式,这种模式下的前端开发虽说不是刀耕火种的原始状态,但是效率非常低下。 前端的工程问题与...

    1. 什么是前端工程化

    自有前端工程师这个称谓以来,前端的发展可谓是日新月异。相比较已经非常成熟的其他领域,前端虽是后起之秀,但其野蛮生长是其他领域不能比的。虽然前端技术飞快发展,但是前端整体的工程生态并没有同步跟进。目前绝大多数的前端团队仍然使用非常原始的“切图(FE)->套模板(RD)”的开发模式,这种模式下的前端开发虽说不是刀耕火种的原始状态,但是效率非常低下。

    前端的工程化问题与传统的软件工程虽然有所不同,但是面临的问题是一样的。我们首先回顾一下传统的软件开发流程模型:

    上图中的运行和维护并不是串行关系,也并非绝对的并行关系。维护贯穿从编码到运行的整个流程。

    如果说计算机科学要解决的是系统的某个具体问题,或者更通俗点说是面向编码的,那么工程化要解决的是如何提高整个系统生产效率。所以,与其说软件工程是一门科学,不如说它更偏向于管理学和方法论

    软件工程是个很宽泛的话题,每个人都有自己的理解。以上是笔者个人的理解,仅供参考。

    具体到前端工程化,面临的问题是如何提高编码->测试->维护阶段的生产效率。

    可能会有人认为应该包括需求分析和设计阶段,上图展示的软件开发模型中,这两个阶段具体到前端开发领域,更恰当的称谓应该是功能需求分析和UI设计,分别由产品经理和UI工程师完成。至于API需求分析和API设计,应该包括在编码阶段。

    2. 前端工程化面临的问题

    要解决前端工程化的问题,可以从两个角度入手:开发和部署。

    从开发角度,要解决的问题包括:

    1. 提高开发生产效率;
    2. 降低维护难度。

    这两个问题的解决方案有两点:

    1. 制定开发规范,提高团队协作能力;
    2. 分治。软件工程中有个很重要的概念叫做模块化开发其中心思想就是分治。

    从部署角度,要解决的问题主要是资源管理,包括:

    1. 代码审查;
    2. 压缩打包;
    3. 增量更新;
    4. 单元测试;

    要解决上述问题,需要引入构建/编译阶段。

    2.1 开发规范

    开发规范的目的是统一团队成员的编码规范,便于团队协作和代码维护。开发规范没有统一的标准,每个团队可以建立自己的一套规范体系。

    值得一提的是JavaScript的开发规范,尤其是在ES2015越来越普及的局面下,保持良好的编码风格是非常必要的。笔者推荐Airbnb的eslint规范。

    2.2 模块/组件化开发

    2.2.1 模块还是组件?

    很多人会混淆模块化开发和组件化开发。但是严格来讲,组件(component)和模块(module)应该是两个不同的概念。两者的区别主要在颗粒度方面。《Documenting Software Architectures》一书中对于component和module的解释如下:

    A module tends to refer first and foremost to a design-time entity. ... information hiding as the criterion for allocating responsibility to a module.
    A component tends to refer to a runtime entity. ... The emphasis is clearly on the finished product and not on the design considerations that went into it.

    In short, a module suggests encapsulation properties, with less emphasis on the delivery medium and what goest on at runtime. Not so with components. A delivered binary maintains its "separateness" throughout execution. A component suggests independently deployed units of software with no visibility into the development process.

    简单讲,module侧重的是对属性的封装,重心是在设计和开发阶段,不关注runtime的逻辑。module是一个白盒;而component是一个可以独立部署的软件单元,面向的是runtime,侧重于产品的功能性。component是一个黑盒,内部的逻辑是不可见的。

    用通俗的话讲,模块可以理解为零件,比如轮胎上的螺丝钉;而组件则是轮胎,是具备某项完整功能的一个整体。具体到前端领域,一个button是一个模块,一个包括多个button的nav是一个组件。

    模块和组件的争论由来已久,甚至某些编程语言对两者的实现都模糊不清。前端领域也是如此,使用过bower的同行知道bower安装的第三方依赖目录是bower_component;而npm安装的目录是node_modules。也没必要为了这个争得头破血流,一个团队只要统一思想,保证开发效率就可以了。至于是命名为module还是component都无所谓。

    笔者个人倾向组件黑盒、模块白盒这种思想。

    模块化/组件化详情链接

    模块化

    就是将一个大文件拆分成相互依赖的小文件,再进行统一的拼装和加载。在工程化之前,一直是使用js、jquery、ajax,这没有模块概念,对于开发大型且复杂的系统会有一定的限制。

     

    组件化

    首先,组件化≠模块化。好多人对这两个概念有些混淆。

    模块化只是在文件层面上,对代码或资源的拆分;而组件化是在设计层面上,对UI(用户界面)的拆分。

    从UI拆分下来的每个包含模板(HTML)+样式(CSS)+逻辑(JS)功能完备的结构单元,我们称之为组件。

    组件:页面是个大型组件,可以拆成若干个中型组件,然后中型组件还可以再拆,拆成若干个小型组件,小型组件也可以再拆,直到拆成DOM元素为止。DOM元素可以看成是浏览器自身的组件,作为组件的基本单元。

    传统前端框架/类库的思想是先组织DOM,然后把某些可复用的逻辑封装成组件来操作DOM,是DOM优先;而组件化框架/类库的思想是先来构思组件,然后用DOM这种基本单元结合相应逻辑来实现组件,是组件优先。这是两者本质的区别。

    2.2.2 模块/组件化开发的必要性

    随着web应用规模越来越大,模块/组件化开发的需求就显得越来越迫切。模块/组件化开发的核心思想是分治,主要针对的是开发和维护阶段。

    关于组件化开发的讨论和实践,业界有很多同行做了非常详细的介绍,本文的重点并非关注组件化开发的详细方案,便不再赘述了。笔者收集了一些资料可供参考:

    1. Web应用的组件化开发;
    2. 前端组件化开发实践;
    3. 大规模的前端组件化与模块化。

    3. 构建&编译

    严谨地讲,构建(build)和编译(compile)是完全不一样的两个概念。两者的颗粒度不同,compile面对的是单文件的编译,build是建立在compile的基础上,对全部文件进行编译。在很多Java IDE中还有另外一个概念:make。make也是建立在compile的基础上,但是只会编译有改动的文件,以提高生产效率。本文不探讨build、compile、make的深层运行机制,下文所述的前段工程化中构建&编译阶段简称为构建阶段。

    3.1 构建在前端工程中的角色

    在讨论具体如何组织构建任务之前,我们首先探讨一下在整个前端工程系统中,构建阶段扮演的是什么角色。

    首先,我们看看目前这个时间点(2016年),一个典型的web前后端协作模式是什么样的。请看下图:

    上图是一个比较成熟的前后端协作体系。当然,目前由于Node.js的流行开始普及大前端的概念,稍后会讲述。

    自Node.js问世以来,前端圈子一直传播着一个词:颠覆。前端工程师要借助Node.js颠覆以往的web开发模式,简单说就是用Node.js取代php、ruby、python等语言搭建web server,在这个颠覆运动中,JavaScript是前端工程师的信心源泉。我们不讨论Node.js与php们的对比,只在可行性这个角度来讲,大前端这个方向吸引越来越多的前端工程师。

    其实大前端也可以理解为全栈工程师,全栈的概念与编程语言没有相关性,核心的竞争力是对整个web产品从前到后的理解和掌握。

    那么在大前端模式下,构建又是扮演什么角色呢?请看下图:

    大前端体系下,前端开发人员掌握着Node.js搭建的web server层。与上文提到的常规前端开发体系下相比,省略了mock server的角色,但是构建在大前端体系下的作用并没有发生改变。也就是说,不论是大前端还是“小”前端,构建阶段在两种模式下的作用完全一致,构建的作用就是对静态资源以及模板进行处理,换句话说:构建的核心是资源管理

    3.2 资源管理要做什么?

    前端的资源可以分为静态资源和模板。模板对静态资源是引用关系,两者相辅相成,构建过程中需要对两种资源使用不同的构建策略。

    目前仍然有大多数公司将模板交由后端开发人员控制,前端人员写好demo交给后端程序员“套模板”。这种协作模式效率是非常低的,模板层交由前端开发人员负责能够很大程度上提高工作效率。

    3.2.1 静态资源构建策略

    静态资源包括js、css、图片等文件,目前随着一些新规范和css预编译器的普及,通常开发阶段的静态资源是:

    1. es6/7规范的文件;
    2. less/sass等文件(具体看团队技术选型);
    3. [可选]独立的小图标,在构建阶段使用工具处理成spirit图片。

    构建阶段在处理这些静态文件时,基本的功能应包括:

    1. es6/7转译,比如babel;
    2. 将less/sass编译成css;
    3. spirit图片生成;

    以上提到的几个功能可以说是为了弥补浏览器自身功能的缺陷,也可以理解为面向语言本身的,我们可以将这些功能统称为预编译。

    除了语言本身,静态资源的构建处理还需要考虑web应用的性能因素。比如开发阶段使用组件化开发模式,每个组件有独立的js/css/图片等文件,如果不做处理每个文件独立上线的话,无疑会增加http请求的数量,从而影响web应用的性能表现。针对诸如此类的问题,构建阶段需要包括以下功能:

    1. 依赖打包。分析文件依赖关系,将同步依赖的的文件打包在一起,减少http请求数量;
    2. 资源嵌入。比如小于10KB的图片编译为base64格式嵌入文档,减少一次http请求;
    3. 文件压缩。减小文件体积;
    4. hash指纹。通过给文件名加入hash指纹,以应对浏览器缓存引起的静态资源更新问题;
    5. 代码审查。避免上线文件的低级错误;

    以上几个功能除了压缩是完全自动化的,其他两个功能都需要人工的配置。比如为了提升首屏渲染性能,开发人员在开发阶段需要尽量减少同步依赖文件的数量。

    以上提到的所有功能可以理解为工具层面的构建功能。

    以上提到的构建功能只是构建工具的基本功能。如果停留在这个阶段,那么也算是个及格的构建工具了,但也仅仅停留在工具层面。对比目前较流行的一些构建产品,比如fis,它具备以上所得的编译功能,同时提供了一些机制以提高开发阶段的生产效率。包括:

    1. 文件监听。配合动态构建、浏览器自动刷新等功能,提高开发效率;
    2. mock server。并非所有前端团队都是大前端(事实上很少团队是大前端),即使在大前端体系下,mock server的存在也是很有必要的;

     我们也可以将上面提到的功能理解为平台层面的构建功能。

    3.2.2 模板的构建策略

    模板与静态资源是容器-模块关系。模板直接引用静态资源,经过构建后,静态资源的改动有以下几点:

    1. url改变。开发环境与线上环境的url肯定是不同的,不同类型的资源甚至根据项目的CDN策略放在不同的服务器上;
    2. 文件名改变。静态资源经过构建之后,文件名被加上hash指纹,内容的改动导致hash指纹的改变。

    其实url包括文件名的改动,之所以将两者分开论述是为了让读者区分CDN与构建对资源的不同影响。

    对于模板的构建宗旨是在静态资源url和文件名改变后,同步更新模板中资源的引用地址

    现在有种论调是脱离模板的依赖,html由客户端模板引擎渲染,简单说就是文档内容由JavaScript生成,服务端模板只提供一个空壳子和基础的静态资源引用。这种模式越来越普遍,一些较成熟的框架也驱动了这个模式的发展,比如React、Vue等。但目前大多数web产品为了提高首屏的性能表现,仍然无法脱离对服务端渲染的依赖。所以对模板的构建处理仍然很有必要性。

    具体的构建策略根据每个团队的情况有所差异,比如有些团队中模板由后端工程师负责,这种模式下fis的资源映射表机制是非常好的解决方案。本文不讨论具体的构建策略,后续文章会详细讲述。

    模板的构建是工具层面的功能。

    3.2.3 小结

    构建可以分为工具层面和平台层面的功能:

    • 工具层面
    1. 预编译,包括es6/7语法转译、css预编译器处理、spirit图片生成;
    2. 依赖打包;
    3. 资源嵌入;
    4. 文件压缩;
    5. hash指纹;
    6. 代码审查;
    7. 模板构建。
    • 平台层面
    1. 文件监听,动态编译;
    2. mock server。

    4. 总结

    一个完整的前端工程体系应该包括:

    1. 统一的开发规范;
    2. 组件化开发;
    3. 构建流程。

    开发规范和组件化开发面向的开发阶段,宗旨是提高团队协作能力,提高开发效率并降低维护成本。

    构建工具和平台解决了web产品一系列的工程问题,旨在提高web产品的性能表现,提高开发效率。

    随着Node.js的流行,对于前端的定义越来越宽泛,在整个web开发体系中。前端工程师的角色越来越重要。本文论述的前端工程体系没有涉及Node.js这一层面,当一个团队步入大前端时代,前端的定义已经不仅仅是“前端”了,我想Web工程师这个称号更合适一些。

    之前跟一位前端架构师讨论构建中对于模块化的处理时,他提到一个很有意思的观点:所谓的压缩打包等为了性能做出的构建,其实是受限于客户端本身。试想,如果未来的浏览器支持大规模并发请求、网络延迟小到微不足道,我们还需要压缩打包吗?

    诚然,任何架构也好,策略也好,都是对当前的一种解决方案,并不是一条条铁律。脱离了时代,任何技术讨论都没有意义。

    参考文献:链接

     

    展开全文
  • 前端组件化开发实践总结

    千次阅读 多人点赞 2021-10-13 12:46:52
    自从 2010 年第一份工作接触了前后端半分离的开发方式之后,在后面的这些年里,对前端的组件化开发有了更全面一点的认识,组件化在我们的前端开发中,对提高开发效率、代码的可维护性和可复用性有很大帮助,甚至对跟...

    自从 2010 年第一份工作接触了前后端半分离的开发方式之后,在后面的这些年里,对前端的组件化开发有了更全面一点的认识,组件化在我们的前端开发中,对提高开发效率、代码的可维护性和可复用性有很大帮助,甚至对跟设计师沟通的效率和企业的品牌形象都有着深刻的影响。这篇文章就把我在开发中总结的一些组件化开发经验分享一下。示例中的所有代码都是伪代码,你可以按照实际情况应用到 React 或 Vue 的项目中。

    前端组件化发展历史

    在讨论组件化开发之前,我们先看看前端组件化开发的发展历史。网页开发刚起步时,并没有『前端』这个概念,更不用提组件化了。当时,网页只是作为可以在浏览器中浏览的富文本文件,开发网页就是使用一些标签让浏览器解析并显示。受制于 HTML 只是描述式的语言,网页中的代码没有办法复用,即使是类似的页面,都需要复制粘贴大量的重复代码:

    <!-- index.html -->
    <nav>
      <!-- 导航 -->
    </nav>
    <main>
      <!-- 内容 -->
    </main>
    <footer>
      <!-- 页脚 -->
    </footer>
    
    <!-- blogPost.html -->
    <nav>
      <!-- 相同的导航 -->
    </nav>
    <main>
      <!-- 不同的内容 -->
    </main>
    <footer>
      <!-- 相同的页脚 -->
    </footer>
    

    后来随着模板引擎的出现,可以把网页的代码分割成片段(Fragments)或模板(Templates),例如导航,内容,页脚等等,之后在需要的地方,使用引入(Include)语法,把这些片段引入进来,从而避免重复代码,这样形成了组件化的雏形,常见的动态脚本语言都有自己的模板引擎,例如 PHP、ASP 和 JSP:

    <!-- nav.jsp -->
    <nav>
      <!-- 导航 -->
    </nav>
    
    <!-- index.jsp -->
    <jsp:include page="nav.jsp" />
    

    只是这些片段在数据管理方面仍然会比较麻烦,还是需要使用客户端 JavaScript 脚本,手动控制数据和 HTML 视图的同步。而对于样式,也还是存在全局污染的问题。
    再后来,有些高级的开发语言,例如 Java, 推出了基于服务器的组件化开发技术,例如 JSF (JSP 的后继),基于 MVC 设计模式,通过 Java Class (POJO) 定义数据模型(Model),为 JSF 页面模板提供数据。JSF 的数据模型中有事件和生命周期相关的方法,而模板和数据模型通信的方式是 Ajax,通过使用 JSF facelets 组件的方式,可以直接发送 Ajax 请求,调用模型中的方法:

    <!-- index.xhtml -->
    <html
      xmlns="http://www.w3.org/1999/xhtml"
      xmlns:h="http://xmlns.jcp.org/jsf/html"
      xmlns:f="http://xmlns.jcp.org/jsf/core"
    >
      <h:commandButton id="submit" value="Submit">
        <f:ajax event="click" />
      </h:commandButton>
      <h:outputText id="result" value="#{userNumberBean.response}" />
    </html>
    
    // UserNumberBean.java
    @Named
    @RequestScoped
    public class UserNumberBean implements Serializable {
    	/* 其它代码省略 */
    
        public String getResponse() {
            if ((userNumber != null)
                    && (userNumber.compareTo(dukesNumberBean.getRandomInt()) == 0)) {
                return "Yay! You got it!";
            }
            if (userNumber == null) {
                return null;
            } else {
                return "Sorry, " + userNumber + " is incorrect.";
            }
        }
    }
    
    

    代码来源:Jarkarta EE 官方示例
    不过这种方式严格限定了编程语言,例如要用 JSF 技术就必须要使用 Java,并且样式污染的问题和客户端数据管理的问题仍然没有解决。
    随着 Node.js 的普及,JavaScript 可以脱离浏览器运行了,并且带来了 npm 包管理器,基于 npm 庞大的工具链,可以 Node.js 的代码打包成浏览器中能够运行的代码。而这期间,产生了像 React、Vue 和 Angular 这样的、适合大型前端项目开发的库和框架。

    在这里插入图片描述

    React 和 Vue 目前的流行程度比较高一些,它们都是纯客户端的、组件化的 JS 库,不依赖任何后端编程语言,让程序员都能够快速上手。不过,随着项目规模的扩大,如何利用好这些库进行组件化开发,成了前端工程师必须要掌握的课题。

    什么是组件

    那么到底什么是组件呢?你想一下日常生活中,电脑上的硬件,例如显卡、内存、CPU,或者汽车的零部件:轮胎、发动机、方向盘等,这些都属于组件,它们组合起来能形成一个完整可用的产品,对于遵循了设计规范的组件,只要型号匹配,无论品牌、样式,都可以互相兼容。
    我们前端工程师其实就当于是一个工厂,我们需要按照一定的规范,产生出合格的网页组件,利用它们组装成完整的页面。组件一般包含 HTML 模板、CSS 样式和 JavaScript 数据逻辑,自成一体,可以直接在其它组件中使用,组件本身的模板、样式和数据不会影响到其它组件。组件还包含一系列可配置的属性,动态的产生内容。

    常见的基础组件有按钮、导航、提示框、表单输入控件、对话框、表格、列表等,我们在它们的基础上又能组合出更复杂的组件,那么对于前端中的组件的定义就非常广泛了,小到一个按钮,大到一个页面都可以形成一个组件,例如两个相似的页面,可以复用一个页面组件,只需要通过修改组件的属性,来形成一个新的页面。

    在这里插入图片描述

    为什么要组件化开发

    你可能也知道,React 和 Vue 其实也可以完全按照传统的网页开发方式进行开发,最多是把网页大体分成几个部分,放到单独的几个文件里就好了,对于简单的网站来说没什么问题,但是如果开发的是大型的应用,例如网页版的 QQ 音乐、微信、邮箱等,它们有大量的、细小的组件,并且重复出现,这时如果针对每个页面编写 HTML 和样式,那么就会造成太多冗余代码了。

    <!-- playlist.html -->
    <div class="card">
      <div class="card__title"></div>
      <div class="card_content"></div>
    </div>
    
    <!-- homepage.html -->
    <div class="card">
      <div class="card__title"></div>
      <div class="card_content"></div>
    </div>
    
    <!-- user.html -->
    <div class="card">
      <div class="card__title"></div>
      <div class="card_content"></div>
    </div>
    

    如果使用组件化的方式,我们可以把重复出现的页面内容定义成组件,这样就不用复制粘贴同样的代码了,减少代码的体积:

    <!-- 伪组件 -->
    <!-- Card.comp -->
    <div class="card">
      <div class="card__title"></div>
      <div class="card_content"></div>
    </div>
    
    <!-- playlist.html -->
    <Card />
    
    <!-- homepage.html -->
    <Card />
    
    <!-- user.html -->
    <Card />
    

    当某个页面内容是复合组件时,那么可以直接把基础组件直接拿过来应用:

    <Card>
      <Title></Title>
      <Button></Button>
    </Card>
    

    利用这种方式,甚至可以达到 1 分钟产生一个新页面的恐怖速度,这对于你来说,节省时间去摸鱼,岂不美哉?

    <Page title="页面1" data="{...}" /> <Page title="页面2" data="{...}" />
    

    对于大型的公司来说,公司的网站、APP、桌面应用、Web 端应用等的设计风格都是一样的,同样的组件会在不同平台中使用,这个时候团队之间可以共享一套组件库,复用到各端平台上,减少重复开发的成本。React 和 Vue 都支持创建跨平台的应用,这时组件化开发就显得更重要了:

    在这里插入图片描述

    使用组件化开发之后,代码也容易维护了,如果页面某个部分出了问题,那么我们可以针对出现问题的组件进行修复,多次用到这个组件的地方也都会一起修复了。
    最后,设计师在设计产品界面的时候,会把重复出现的 UI 也做成『组件』,这个组件的概念几乎和前端中的组件一模一样,这时可以跟设计师交流想法,看看他/她是怎么规划组件的,这样也减少了在开发时,设计规划组件的时间。

    接下来分享一下我在组件化开发中总结的经验:

    一、组件的规划

    在正式进行前端应用开发之前,需要有充分的时间来分析,看看页面上的哪些内容需要做成组件。这一步只需要大致规划一下:

    • 如果公司设计师提供了详细的设计规范,那么直接按照规范中的组件来开发就可以了。

    在这里插入图片描述

    • 如果只有设计稿,那么就看看哪些内容有 2 次或更多次在其它页面中用到了,这些大概率需要设计为组件。
    • 如果连设计稿都没有,那么可以用市面上现成的组件库,例如 ant design。
    • 如果没有设计稿,还要自己从零开发,那么可以根据通用的套路,把基础组件,例如按钮、菜单等,规划出来,并把可能会多次用到的页面内容,也规划出来,例如导航,底部信息、联系方式区域,这样可以只改动需要变化的部分,不影响其它部分。

    这一步不用太过详细,浪费太多时间,后续开发的时候如果遇到不确定是否要写成组件的部分,可以直接把这部分代码写到大的组件里,如果其它组件又用到了,再把它抽离成组件。

    二、组件代码管理

    组件的代码应该遵循就近原则,也就是说:

    • 和组件有关的 HTML、CSS 、JS 代码和图片等静态资源应该放在同一个目录下,方便引用。
    • 组件里的代码应该只包括跟本组件相关的 HTML 模板、CSS 样式和 JS 数据逻辑。
    • 所有的组件应放到一个统一的『组件文件夹中』。

    如果组件之间有可以复用的 HTML 和 CSS,那么这个复用的部分可以直接定义成一个新的组件。

    如果组件之间有可以复用的 JS 数据逻辑,那么可以把公用的数据逻辑抽离出来,放到公共的业务逻辑目录下,使用到该逻辑的组件,统一从这个目录中导入。

    如果项目中使用到了全局状态管理,那么状态管理的数据应放在独立的目录里,这个目录还会存放分割好的状态片段 reducer,之后统一在 store 中合并。

    对于项目中的** API 处理**,可以把它们单独放到一个文件夹里,对于同一个数据类型的操作,可以放到同一个 js 文件里,例如对 user 用户数据的增删改查,这样能尽最大可能进行复用,之后在组件里可以直接引入相关 api 进行调用。如果直接写在组件里,那么使用相同 API 的组件就会造成代码重复。
    例如下面是一个组件化开发的目录结构示例(框架无关):

    project
    |-- components                # 所有组件
          |-- Card                # Card 组件
              |-- index.js        # Card 组件 js 代码
              |-- Card.html       # Card 组件 html 模板
              |-- Card.css        # Card 组件 css 样式
              |-- icon.svg        # Card 组件用到的 icon
    |-- logics                    # 公共业务逻辑
          |-- getUserInfo.js      # 例如获取用户信息
    |-- data                      # 全局状态
          |-- store.js            # 全局状态管理 store
          |-- user.reducer.js     # user reducer
          |-- blogPost.reducer.js # blogPost reducer
    |-- apis                      # 远程请求 API 业务逻辑
          |-- user.js             # user API
          |-- blogPost.js         # blogPost API
    

    三、组件样式管理

    在编写组件样式的时候,应只设置组件 CSS 盒子内部的样式,影响外部布局的样式要尽可能的避免,而应该由使用该组件的父组件去设置。例如,如果有一个组件设置了外边距,但是这个组件经常会用于 grid 或 flex 布局中,那么这个额外的边距会对布局造成影响,只能通过重置外边距的方式取消边距,这就不如组件不设置外边距,由父组件的布局决定它的位置,或者外边距。

    在这里插入图片描述

    类似的还有定位相关的样式,绝对定位、固定定位等对文档流有影响,应交由父组件决定,除非这个组件只有绝对定位这一种情况,例如对话框。
    组件中的 CSS 要局部化,以避免影响全局样式。传统的 CSS 样式是全局的,如果有两个不同的组件,使用了相同的 class 名字,那么后定义的样式会覆盖之前定义的。一般前端库中都有定义局部样式的功能,例如通过 CSS Modules。

    <!-- Vue -->
    <style scoped></style>
    
    <!-- React,通过文件名 -->
    Button.module.css
    

    修改子组件的样式时,优先使用选择器特异性(CSS Specificity)策略选定特定元素,而行内样式(inline-style)在设置简单样式的时候使用,尽一切可能避免 !important,因为如果再有上一层组件(爷爷组件)需要修改这个组件的样式时,就会很困难了。

    四、组件属性管理

    组件属性的命名要与它实际展示的内容相符。例如一个博客文章组件,title 属性表示标题,content 代表内容,showFullArticle 表示是否显示全文。

    <!-- 不推荐,full 表示什么? -->
    <BlogPost title="" content="" full="" />
    <!-- 推荐 -->
    <BlogPost title="" content="" showFullArticle="" />
    

    组件的属性应有必要的类型检查,避免在使用属性时出现异常,例如在需要数组的地方传递了布尔类型,那么如果代码有遍历数组的逻辑,就会出错。

    props: {
    	title: String,
      content: String,
      showFullArticle: Boolean
    }
    

    代表事件的属性,应该和现有的 HTML 事件名称规范保持一致,以 on 开头,后面用英文表示会触发的事件,例如 onEdit 表示会触发编辑事件。

    <BlogPost onEdit="" />
    

    组件的属性不能直接和状态进行捆绑,而是应该只作为状态的初始值。如果把属性值作为状态值,那么就破坏了单一数据流向机制,此时该组件可以通过自身修改状态,也能通过父组件的属性变化修改状态,很容易造成数据的不一致。推荐的做法是,设置一个初始值属性,可以通过父组件传递进来,当作状态的初始值,然后丢弃,后续只通过该组件修改状态值。

    const { initialTitle } = props;
    const title = state(initialTitle);
    
    // 修改
    updateTitle() {
     title = "...";
    }
    

    五、组件状态管理

    组件的状态分为全局状态和局部状态两种。
    局部状态是定义在组件本身的状态,应由组件本身内部管理,当子组件需要该组件的状态值时,通过属性传递给子组件,此时状态变化时,子组件也会自动刷新。

    // 父组件
    const someState = state("");
    
    <ChildComponent prop1="someState"></ChildComponent>;
    

    当子组件需要给父组件传递状态的值时,要通过事件的方式传递给父组件,尽最大可能避免使用 ref

    // 父组件
    function getStateVal(val) {
      console.log(val);
    }
    <ChildComponent onChange="getStateVal" />
    
    // 子组件
    <input onChange="e => getStateVal(e.target.value)" />
    

    状态的变化还应只通过事件或生命周期来进行,不能在其它同步执行的代码中进行,这样不会引起组件的刷新。

    const someState = state();
    
    // 错误
    const state = "newState";
    
    // 正确
    handleButtonClick() {
      someState = "newState";
    }
    

    全局状态是多个组件共享的,如果有多个组件共享某个状态,那么应该把状态定义在这些组件统一的、最接近的父组件中,或者使用全局状态管理库。

    在这里插入图片描述

    全局状态的修改,应该由类似于 actions 的行为触发,然后使用 reducer 修改状态,这样能追溯状态的变化路径,方便调试和打印日志。

    // 组件
    function updateState() {
      emitAction("changeState");
    }
    
    // reducer
    function someState(state, action) {
    	switch(action) {
        "changeState": someState => {
          	log(someState);
        		return newState
        }
      }
    }
    

    全局状态推荐按领域(Domain)来拆分 reducer,而不是按页面。例如按 user 用户、文章 posts、评论 comments 来拆分,而不是以 HomePage 主页、BlogPostListPage 博客列表页,BlogPostPage 博客详情页这样来拆分。这样做的好处是,能够最大限度的复用 reducer 中的逻辑。

    // userReducer
    
    {
    	"updateUser": ...
      "deleteUser": ...
      /* ... */
    }
    

    六、组件的组合

    前端开发就是组合不同的组件。
    在组合组件的时候,尽量使用『插槽』的形式(例如 React 的 children/render props,Vue 的 slot),这样可以减少组件的嵌套,避免多层传递属性或事件监听。
    使用 slot:

    // Layout 组件
    <div>
      <!-- nav slot -->
      <!-- content slot -->
      <!-- footer slot -->
    </div>
    
    // 首页 function handleNavChange() {}
    
    <Layout>
      <nav onChange="handleNavChange"></nav>
      <main></main>
      <footer></footer>
    </Layout>
    

    不使用 slot:

    // Layout props: { onNavChange: function }
    <Layout>
      <!-- 还需再传递一层 -->
      <nav onChange="onNavChange"></nav>
      <main></main>
      <footer></footer>
    </Layout>
    
    // 首页 function handleNavChange() {}
    <Layout onNavChange="handleNavChange" />
    

    如果有循环展示列表的地方,需要对循环中最外层的组件设置 key,这样在列表发生变化时,能帮助前端库判断是否可以通过排序的方式,重复利用现有的组件,来更新视图,而不是销毁重建。

    let todos = [{id: 1, content: "todo1"}, {id:2, content: "todo2"}, {id:3,
    content: "todo3"}];
    
    <List>
      for todo in todos:
      <item content="todo.content" key="todo.id" />
    </List>
    
    // todos 顺序变化,列表也只是根据 id 调整顺序,不会销毁重建 todos = [{id: 3,
    content: "todo3"}, {id:2, content: "todo2"}, {id:1, content: "todo1"}];
    

    如果有按条件展示组件的地方,且切换频率高,或有动画需求,要使用设置 css display 的方式,例如 vue 中的 v-show,如果切换频率低,可以使用加载、销毁的方式,例如 vue 中的 v-if,React 中使用 && 逻辑判断。

    七、组件的复用

    在复用组件的时候,可以通过改变组件的属性来修改一些简单的组件内容。

    <Card title="" content="<ContentComp />" />
    

    如果组件结构类似,但是有些内部的组件不一样,可以考虑通过『插槽』来复用。

    <!-- Comp -->
    <div>
      <h1></h1>
      <!-- slot -->
    </div>
    
    <!-- 其它组件 -->
    <Comp>
      <p>替换 slot</p>
    </Comp>
    

    如果有业务逻辑需要复用,尤其是涉及到状态变化的,那么可以把它抽离为公共的业务逻辑,利用 Hooks(React)或 Composables (Vue)来复用。

    // 公共逻辑 (/logic/useSomeLogic.js)
    function useSomeLogic() {
      const someState = state();
      const updateState = (v) => (someState = v);
      return {
        someState,
        updateState,
      };
    }
    
    // 组件1复用
    import userSomeLoginc from "/logic/useSomeLogic.js";
    const { someState, updateState } = useSomeLogic();
    
    // 组件2复用
    import userSomeLoginc from "/logic/useSomeLogic.js";
    const { someState, updateState } = useSomeLogic();
    

    如果有视图样式需要复用,那么可以直接把这部分再抽离成一个新的组件。

    小结

    这篇文章从组件的代码、样式、属性、状态、组合和复用的这几个场景上,总结了一些我在前端开发中的一些经验和个人看法,可能并不适用所有项目,如果你有更好的最佳实践和经验,欢迎分享!如果觉得本文有帮助,请分享给其它人,感谢!

    原文地址:https://zxuqian.cn/7-ways-to-organize-frontend-components,欢迎访问查看更多前端开发教程!
    Bilibili:峰华前端工程师
    公众号:峰华前端工程师

    展开全文
  • Javascript组件化开发设计思想

    千次阅读 2018-09-20 15:52:39
    一、引言 项目中经常用web弹层组件-layer,其常见的代码如下: ...那么,什么是组件开发、为什么要采用这种开发形式、怎么进行组件化开发呢?下面就来一探究竟吧。   二、什么是组件化开发 当多组功能相...
  • java web 组件化开发?

    2008-07-15 14:03:11
    页面组件化,逻辑组件化,业务组件化,数据组件化,按一定的规律组合各种组件以期达到客户需求。 是个很美好的愿景。 对比一下.net和flex以及对应的...java web组件化开发又在哪里? 看好dojo,看好jsf。 ...
  • Web应用的组件化开发

    万次阅读 2014-06-14 21:54:33
    1. 为什么要做组件化? 无论前端也好,后端也好,都是整个软件体系的一部分。软件产品也是产品,它的研发过程也必然是有其目的。绝大多数软件产品是追逐利润的,在产品目标确定的情况下,成本有两个途径来优化:...
  • 无论如何形式,组件开发已然成为我们工作中的必备技能,为了更好的复用性和可维护性,组件化开发是必然选择,也正是因为组件化开发越来越重要,几年前web标准推出了Web Component这一概念,意在解决html原生标记语言...
  • Vue全家桶之组件化开发

    千次阅读 多人点赞 2020-01-06 07:56:26
    学习组件化开发,首先掌握组件化的开发思想,组件的注册方式,组件间的数据交互方式,组件插槽的用法,vue调式工具的用法,组件的方式来实现业务逻辑功能。 组件化开发思想,组件注册,组件调式,组件间的数据交互,...
  • 前端组件化开发

    万次阅读 多人点赞 2016-11-28 16:40:54
    它的核心意义是分离职责,属于代码级模块的产出。它本身是提供服务的功能逻辑,是一组具有一定内聚性代码的组合,职责明确。 组件(Component)和模块(Module)又是一对容易混淆的名词,也常常被用来相互替换。个人...
  • 前端组件化开发和模块化开发的区别  首先,组件化和模块化的意义都在于实现了分治,目前我们开发的项目复杂度不断的上升,早已不是我们一个人能完成的工作,团队合作的话又会产生配合困难等各方面问题,组件化和...
  • 什么叫组件化开发

    万次阅读 多人点赞 2018-02-24 21:38:46
    转载:什么叫组件化开发? - aloo的回答 - 知乎 https://www.zhihu.com/question/29735633/answer/90873592  从第一代码农写下第一行代码开始到上个世纪的80年代的软件危机,码农一直在考虑一个问题,怎么让写代码...
  • Web的材料组件Web的材料组件(MDC-Web)帮助开发人员执行材料设计。 这些组件由Google的工程师和用户体验设计师的核心团队开发,可实现可靠的开发Web的材料组件Web的材料组件(MDC-Web)可帮助开发人员执行...
  • Vue 组件化开发

    千次阅读 2020-07-15 23:27:05
    为什么需要组件化开发,许多答案都是复用,而我却认为分而治之或许是更好的答案
  • Flutter组件化开发方案

    千次阅读 2018-12-15 09:47:13
    这样可以有效的将Flutter和Native进行物理隔离,但随着Flutter承载的业务越来越多,与Native交互的接口变的越来越多,带来了很多管理问题,因此我们迫切需要采用新的开发模式,本文将介绍Flutter的组件化开发方案。...
  • 采用OSGi/Equinox实现采用上一节第二中方式,将OSGi容器集成于普通的JEE Server中。在OSGi容器中,实现对Web组件中资源的解析和对外界Http请求的调度,使得Web组件开发和普通JEE卡发没有区别不大
  • 前端模块化、组件化开发

    千次阅读 2017-11-20 16:35:58
    使用过ReactJS进行Web UI的组件化开发,和使用过AngularJS的双向数据绑定和模块化后,感觉到了组件化、模块化、双向数据绑定对Web前端开发的重要性。 1、组件化可以极大提高前端代码的可维护性,前端的组件化简单的...
  • Android 开发:由模块化到组件化(一)

    万次阅读 多人点赞 2016-12-15 01:43:15
    组件化?到底是什么鬼?有啥区别. 有这种感觉才是对的,模块化和组件化本质思想是一样的,都是"大化小",两者的目的都是为了重用和解耦,只是叫法不一样.如果非要说区别,那么可以认为模块化粒度更小,更侧重于重用,而组件化...
  • 第四章:web前端高级React 文章目录系列文章目录一、React组件的定义及分类二、函数式组件三、类组件四、组件的渲染五、组合组件六、提取组件七、Props 的只读性 一、React组件的定义及分类 组件允许我们可以将UI...
  • 前端组件化

    千次阅读 2020-12-21 10:40:47
    组件化 [外链图片转存失败,源站可能有... 什么是组件化? 前端组件化开发,就是将页面的某一部分独立出来,将这一部分的数据层(M)、视图层(V)和控制层(C)用黑盒的形式全部封装到一个组件内,暴露出一些开箱即用
  • 前言作为一名前端工程师,我们每天都在和组件打交道,我们也许基于react/vue使用过很多第三方组件库,比如ant design,elementUI,iView等,或者基于它们进行过组件...
  • 上一章我们搭建了vue-cli,npm等环境,并且基于组件化开发的模式借助vue+webpack+openlayers6实现了地图的加载。今天这一章,我们将继续组件化的开发地图相关功能,我会通过具体的地图功能实例来进行阐述,大家加油...
  • js组件化开发发展

    千次阅读 2016-03-30 15:49:50
    这次的组件化完完全全不一样了,custom element的出来的组件,可以是以前任意的东西,然后注册成任意一个名字的组件,可以就,也可叫,反正你想叫啥,就叫啥,然后小伙伴(host)把你的组件(element)直接import进去了...
  • 爱奇艺知识WEB前端组件化实践

    千次阅读 2021-01-29 11:42:26
    组件化作为一种开发模式,其在代码复用,提高开发效率上的效果被广泛认可。组件化思想适用于移动端、Web前端、PC端、TV端等多种类型的客户端和前端开发。本文主要讲述爱奇艺知识 WEB 前端...
  • 文章目录组件化前言集中配置版本控制app与 lib模式切换整合lib进主app里解决多个Application问题解决module之间的资源冲突组件之间的跳转与通信方式Activity路由跳转组件之间的数据通信总结 组件化前言 项目总会...
  • web前端组件开发 之 弹窗组件实现

    千次阅读 2017-03-22 02:57:24
    widget 抽象类首先抽象出弹窗组件的一些共有属性和方法。widget抽象类中 定义一个最外层容器,即整个弹窗,在widget构造函数中,添加一个属性:this.boundingBox = null; // 弹窗组件最外层容器 在widget抽象类中,...
  • Kotlin开发的 Jetpack+Mvvm+组件化 玩安卓客户端

    千次阅读 热门讨论 2021-03-10 11:51:22
    github: 玩安卓mvvm组件化客户端 项目截图 项目介绍 基于Mvvm模式集成谷歌官方推荐的JetPack组件库LiveData+ViewModel+DataBinding,以ARouter为组件路由实现的玩Android开放API安卓客户端 数据源于玩Android ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 372,074
精华内容 148,829
关键字:

web组件化开发