如昨天预告的一样,今天来介绍元件化开发的技术背景,它是什麽、为什麽重要,最後再讲一下元件的开发流程。
首先,「元件化开发」是由於前後端分离跟前端框架的兴起而达成的。
这边的前端框架主要是指 单页式应用( Single Page Application ) 的框架,帮前端把 HTML, CSS 和 JS 整合在一起,同步处理许多其他的问题方便开发,想知道更多的话可以看我之前在 Medium 写的文章:前端框架第 0 课:学习框架前该知道的事(偷业配)。
以往前後端分离之前,每个页面都是由後端即时吐 HTML 给浏览器的,但随着网页技术的发展、高互动性网站的大量需求,前端框架随之出现,在框架这边实作了单一 HTML 就可以渲染所有画面的机制,後端往後只要吐一份有引用框架程序码的 HTML 给浏览器就好,让前後端正式分离。
而前端透过框架来处理画面,後端只需要开出 API 来让前端去接资料就好。
前後端分离後,让前端可以很单纯地按造自己想要的方式去实作画面。
前端框架其实就只是在帮我们去整合前端独自开发时,都会所需要的一系列工具而诞生的。
而「元件」则是前端框架中的一项重要概念。
在这里提一下「元件」的定义:「可复用、各自独立的 UI,如 Button」。
在元件化开发时,我们所追求的是一个能开箱即用 ( out-of-the-box ) 的 UI 元件,因此 UI 元件本身除了画面之外,功能也需要健全(使用者事件处理、动画 和 一些基本情境)。
把网站中会需要的元素都切成一个个的 UI 元件後,接下来不论是继续开发还是团队合作上,都是在组装这些 UI 元件 并接上後端资料跟处理商业逻辑。
UI 元件组装的状况是指一个 UI 元件可以与其他 UI 元件组在一起,形成一个有更复杂或更适合专案情境的大 UI 元件。
例如:多选选项 (Checkbox) 可以跟输入框 (Input) 整合成一个 被点选後会跑出输入框的复合元件 ( CheckboxInput )。
(这部分一样会在 Day 06 的 Atomic Design 介绍更详细!)
一个 UI 元件会包含它的样式和功能等等所有东西,使用的人可以再按照这个元件开出来的属性对其进行客制化,而完全不用去理会内部实作逻辑,提升了开发速度的同时也减少了对整份程序码的认知负担。
更具体一点说,元件化开发就是在「拆分功能,封装元件,独立维护」。
「大事化小,小事化无。」(X
「把大页面拆成小区块,小区块再拆成一个个的元件。」(O
它为什麽很重要其实就跟上面提到元件化开发的本质一样:
SOP 基本上是这样:先定义规格 (Spec),再实作介面(interface),最後实作元件 (Component),以下会照顺序来介绍这三个阶段在做什麽。
规格基本上就是指你的元件要开发到什麽样的程度、会有哪些可能的使用情境,想要因应怎样的需求。
如果规格没在事先定义好的话,会让实作的工程师不知道这个元件应该要有哪些功能,元件有部分是大家公认会有的功能,但也有很多是根据使用情境才会产生的功能,像是 Tabs 的右边要不要有其他的功能键等等。
总之就是:定义好规格,才不会使後续在使用时才衍生太多额外需求,进而需要反覆回来修改。
虽然不可能一次到位,但确实可以减轻许多来来回回的流程。
更重要的是可以预防以下两个问题:
这点简单来说就是我们能对元件客制化到什麽程度,这也会直接影响到使用时的麻烦程度。
像是复合式的元件,我们是需要连能使用的元件都先定义好,还是就开一个介面给使用者使用,前者就是使用起来很方便,只要指定一些元素传进去就好,而後者则是需要每次都重写很多次子元素。
因应元件的弹性不一致,弹性越高的,元件的实作复杂度就越低,有些实作的成本会是在使用时体现,但若弹性很低,也就意味着我们事先对元件做了更多的处理,那麽使用时就能很方便少写很多程序码,也因此弹性就跟复杂度成反本,弹性越高的元件可以越不复杂,越低的处理越多事就会变越复杂,进而可能会影响到效能或使用上的不直觉。
这边先引用一下维基百科对介面的定义:「程序编写或设计的方法论中作为程序元件功能的抽象化」。
这句话看起来很拗口,但其实就是你希望元件提供你的功能、也可以说是元件的 API,以 Button 来说,你会希望它可以点击 (onClick)、非同步操作时可以提供载入的状态 (Loading)、有按钮名称 (Label) 等等。
而介面对使用者来说就是一个黑盒子,使用者只要知道这个元件的介面是什麽,就能知道这个元件能做到哪些事情了。
先定义好介面,後续实作就只是再一一实现使用介面所预期的结果,如:disabled 要改变 CSS 跟 无效化元件。
同时,也会有许多 Component 都有类似的功能,这时候其实就能把共通的功能抽出来做成一个介面,後续的 Component 就都可以在这个介面的基础下再进行更多的封装,最常见的就是表单元件,至少会有当前的值 (value) 跟改变值的行为 (onChange),再来是识别用的 id、name,或是输入错误的提示 (error message) 等等。
介面的部分会在 Day 12 开始的 UML 篇章跟大家介绍得更仔细。
规格跟介面都介绍完後,我们可以看到只有最後的元件实作环节会跟你使用的框架 (React、Vue、Angular) 语法有关,所以虽然本系列实作的环节会用 React 来写,但基本上影响的程度不会到很大,至少需求跟架构都能在进入到实作前厘清。
主要就是把定义好的介面一一实作出来,在 HTML 定义元件呈现的架构、CSS 去写样式,并需要处理各种情境的变化(像是 disabled 颜色要变淡)、而 JS 和 框架的语法来撰写互动逻辑和资料流的管理。
其实就是比较纯粹地在写 Code 啦,但如果前面的规格和需求步骤没有确实,在实作时就会要一直来来回回确认很多东西,其实对於整个开发体验(Developer Exprience)来说是很糟糕的。
如果你听完还很模糊的话没关系,在这先有个概念,等到 Day 21 实战演练系列开始时搭配程序码再回来看就会更有感罗!
上述讲完规格、需求和实作在做什麽之後,更细一点来讲流程会是这样:
如果想知道更多软件开发流程的细节,可以参考
软件业到底在干嘛?软件业开发流程、各职能大揭密! 或 Software Development Process: How to Pick The Process That’s Right For You ,但实际上还是很看公司本身的体质,来决定采取怎样的开发流程哩!
今天一样是打底的过程,让我们理解当今前端是如何能做到元件化开发的一些背景,像是前後端分离、应映前端框架而生的元件概念,以及对於元件化开发这一概念的解释。
整个元件化开发的概念基本上其实就是很常用到的东西要整合起来,遵循 DRY ( Don't Repeat Yourself ) 的原则,而对於前端来说,很常用到的就是各种 UI 元件了。
後半开发流程的部分则是给个概念,之後介绍完介面跟一些实作後再回来看效果会更好。
明天会介绍的是 UI 元件的分类系统,并会透过现行几个比较完整的 UI 元件库来介绍,敬请期待罗!
<<: 第19天 - 来试着做一个简易购物系统(3)建购物车的资料表、一点点SESSION
在做模型训练时,要先将训练资料做一些事前的处理,为以下这几类:资料平衡、异常点处理、缺失值处理、特徵...
修饰词~可以限制类别的存取层级 我的举例是:像是一些私密的东西你不想让别人随便乱看一样 就要设隐私权...
Colab连结 相信每个人在学习ML时,都会遇到超参数 Batch size 应该要设置多少才好的问...
Genero FGL为一个出自於资料库的语言,但怎麽和资料库搭上边的,我们还是需要来做一下理解。 ...
访问控制(RAM)是什麽? 访问控制(Resource Access Management,RAM)...