整合營(yíng)銷服務(wù)商
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
電腦端+手機(jī)端+微信端=數(shù)據(jù)同步管理
免費(fèi)咨詢熱線：
介
我比較喜歡使用 Vue 來開發(fā)，所以有時(shí)會(huì)深入研究其功能和特性。通過這篇文章，向你們介紹十個(gè)很酷的竅門和技巧，以幫助大家成為更好的 Vue 開發(fā)者。
隨著Vue 2.6的推出，已經(jīng)引入了插槽的簡(jiǎn)寫方式，之前簡(jiǎn)寫可用于事件（例如，@click表示v-on:click事件）或冒號(hào)表示方式用于綁定（:src）。例如，如果有一個(gè)表格組件，則可以按以下方式使用此功能：
如果要在created或mounted方法中定義自定義事件偵聽器或第三方插件，并且需要在beforeDestroy方法中將其刪除以免引起任何內(nèi)存泄漏，則可以使用此功能。使用$on(‘hook:’)方法，我們可以僅使用一種生命周期方法（而不是兩種）來定義/刪除事件。
你可能已經(jīng)知道可以將props驗(yàn)證為原始類型，例如字符串，數(shù)字甚至對(duì)象。我們還可以使用自定義驗(yàn)證器，例如，如果要針對(duì)字符串列表進(jìn)行驗(yàn)證：
Vue 2.6 的最酷功能之一是可以將指令參數(shù)動(dòng)態(tài)傳遞給組件。假設(shè)有一個(gè)按鈕組件，并且在某些情況下想監(jiān)聽單擊事件，而在其他情況下想監(jiān)聽雙擊事件。這就是動(dòng)態(tài)指令派上用場(chǎng)的地方了：
有時(shí)，我們不同路由共用某些時(shí)，如果在這些路由之間切換，則默認(rèn)情況下，共享組件將不會(huì)重新渲染，因?yàn)閂ue 出于性能原因會(huì)重用該組件。但是，如果我們?nèi)匀幌Ｍ匦落秩具@些組件，則可以通過在路由器視圖組件中提供:key屬性來實(shí)現(xiàn)重新渲染。
這是一個(gè)非常酷的功能，可將所有prop從父組件傳遞到子組件。如果我們有另一個(gè)組件的包裝器組件，這將特別方便。因?yàn)椋覀儾槐匾粋€(gè)一個(gè)將prop傳遞給子組件，而是一次傳遞所有prop：
上面的可以代替下面的做法
如果子組件不在父組件的根目錄下，則可以將所有事件偵聽器從父組件傳遞到子組件，如下所示：
如果子組件位于其父組件的根目錄下，則默認(rèn)情況下它將獲得那些組件，因此不需要此小技巧。
默認(rèn)情況下，每個(gè)Vue實(shí)例都可以訪問$createElement方法來創(chuàng)建和返回虛擬節(jié)點(diǎn)。例如，可以利用它在可以通過v-html指令傳遞的方法中使用標(biāo)記。在函數(shù)組件中，可以將此方法作為渲染函數(shù)中的第一個(gè)參數(shù)訪問。
由于Vue CLI 3默認(rèn)支持使用JSX，因此現(xiàn)在（如果愿意）我們可以使用JSX編寫代碼（例如，可以方便地編寫函數(shù)組件）。如果尚未使用Vue CLI 3，則可以使用babel-plugin-transform-vue-jsx獲得JSX支持。
默認(rèn)情況下，v-model是@input事件監(jiān)聽器和:value props上的語法糖。但是，我們可以在Vue組件中指定一個(gè)模型屬性，以定義使用什么事件和值
希望這些竅門和技巧對(duì)你有所幫助，如果你也知道哪些技巧，歡迎留言。
原文：https://www.telerik.com/blogs/12-tips-and-tricks-to-improve-your-vue-projects
avaScript框架之間的終極性能之戰(zhàn)
我在網(wǎng)上瀏覽時(shí)發(fā)現(xiàn)，兩年多來我們沒有一個(gè)不錯(cuò)的JavaScript框架性能大賽。因此，在2020年總結(jié)之前，讓我們?cè)趯⑦@些庫(kù)相互抗衡中獲得一些樂趣。
如何采用20個(gè)最受歡迎的JavaScript框架，并使用JS Framework Benchmark使其并駕齊驅(qū)？
免責(zé)聲明：此比較在整個(gè)過程中很有趣，也可能具有教育意義。和往常一樣，這里的每個(gè)庫(kù)對(duì)于大多數(shù)事情來說都足夠高效。如果有什么要強(qiáng)調(diào)的是，性能可以來自多種不同的技術(shù)。雖然您可以將其用作參考，但您應(yīng)該獨(dú)立驗(yàn)證各個(gè)用例的性能。您可以在這里找到最新的官方結(jié)果。如果您想進(jìn)一步了解此基準(zhǔn)測(cè)試的內(nèi)容，請(qǐng)?jiān)诖颂幇l(fā)布指南。
還值得一提的是，我是Solid Framework的作者。因此，我不能在這里表現(xiàn)出任何偏見。但是我打算讓這些數(shù)字在很大程度上說明自己。撇開所有這些，享受比較。
我已經(jīng)采用了JS框架基準(zhǔn)測(cè)試的最新Chrome 87 監(jiān)控結(jié)果。它們?cè)贔edora 33下的Core i7 Razor Blade 15上運(yùn)行，且緩解措施已關(guān)閉。
我過濾掉了所有有問題的實(shí)現(xiàn)，然后獲得了Github星級(jí)的前20個(gè)庫(kù)。對(duì)于具有多個(gè)版本的庫(kù)，我沒有使用第三方庫(kù)就獲取了它們的最新版本和性能最高的變體。
1. Vue (177k)
2. React (161k)
3. Angular (68.9k)
4. Svelte (40.5k)
5. Preact (27.9k)
6. Ember (21.7k)
7. HyperApp(18.2k)
8. Inferno (14.6k)
9. Riot (14.4k)
10. Yew (14.2k)
11. Mithril (12.5k)
12. Alpine (12.4k)
13. Knockout (9.9k)
14. Marko (9.9k)
15. lit-html (6.9k)
16. Rax (7k)
17. Elm (6.2k)
18. Ractive (5.8k)
19. Solid (4.7k)
20. Imba (4.1k)
注意：我將把LitElement實(shí)現(xiàn)用作lit-html示例，因?yàn)闃?biāo)準(zhǔn)示例已被標(biāo)記為問題。開銷應(yīng)該最小，因?yàn)樗前b在單個(gè)Web組件中的原始lit-html。
這是當(dāng)前Web開發(fā)生態(tài)系統(tǒng)中相當(dāng)不錯(cuò)的一部分。盡管Github Stars并不是全部，但在比較中有100多個(gè)庫(kù)，因此我需要標(biāo)準(zhǔn)來選擇競(jìng)爭(zhēng)者。
每個(gè)庫(kù)將在3個(gè)類別中進(jìn)行比較：DOM性能，啟動(dòng)指標(biāo)和內(nèi)存使用情況。此外，我將框架分為4組，以將它們與原始性能同級(jí)進(jìn)行最佳比較。但是，我將在所有三個(gè)方面對(duì)庫(kù)進(jìn)行排名。
在每個(gè)組中，將存在參考Vanilla JavaScript條目。使用所有最佳技術(shù)，此實(shí)現(xiàn)都經(jīng)過了最佳化以達(dá)到最佳性能。它將作為所有比較的基準(zhǔn)。
因此，讓我們開始吧。
這是最大的組，由一些最受歡迎的庫(kù)組成。還有許多來自Facebook，Google，eBay和Alibaba等公司支持的公司。這些庫(kù)要么在性能上較少關(guān)注某個(gè)方面，要么在某一方面強(qiáng)調(diào)性能，而在其他方面則受苦。
> Group 4 Performance
這里有很多紅色和橙色，但請(qǐng)記住，這些庫(kù)平均僅比我們?cè)诖颂幨褂玫耐纯嗍止ぶ谱鞯拿钍絍anilla JavaScript示例慢大約2倍。400ms與200ms有何不同？
在原始性能方面，React是該包的領(lǐng)導(dǎo)者。考慮到架構(gòu)的差異性，盡管它從未間斷令人驚奇，但React，Marko，Angular和Ember的整體距離有多近。仍然是React，這是React Hooks的實(shí)現(xiàn)，在這里是領(lǐng)導(dǎo)者。對(duì)于所有指向額外的函數(shù)創(chuàng)建并堅(jiān)持使用類的人來說，性能參數(shù)不在您身邊。React Hooks是使用React的最高效的方法。
這里的大多數(shù)庫(kù)要么簡(jiǎn)單的列表排序?qū)е陆粨Q行性能確實(shí)很差，要么創(chuàng)建成本很高。Ember是這種情況的極端案例，因?yàn)樗母滦阅鼙仍摻M中的其他成員要好得多，但在某些最壞的情況下卻是創(chuàng)建過程。
最慢的庫(kù)（Knockout，Ractive和Alpine）都是具有類似架構(gòu)的細(xì)粒度反應(yīng)庫(kù)。Knockout和Ractive（也由Svelte的作者Rich Harris撰寫）來自2010年初VDOM庫(kù)主導(dǎo)之前。我還懷疑Alpine是否期望使用其JavaScript方法來渲染1萬行。在比較之后，我們將看不到另一個(gè)純粹的細(xì)粒度反應(yīng)庫(kù)。
接下來，我們將主要根據(jù)庫(kù)捆綁軟件的大小來比較類別的啟動(dòng)指標(biāo)。
> Group 4 Startup
此處訂單變化很大。在Alpine性能最差的地方，我們可以看到它具有最小的捆綁包大小和最快的啟動(dòng)時(shí)間。Marko（來自eBay）緊隨其后，其次是Rax（來自阿里巴巴）。所有這三個(gè)庫(kù)都是為服務(wù)器端渲染而構(gòu)建的，主要是通過更輕松的客戶端交互來實(shí)現(xiàn)的。這就是為什么他們要進(jìn)入第4組才能獲得出色的表現(xiàn)，但卻領(lǐng)先于這里的原因。
表格的后半部分是我們?cè)诨鶞?zhǔn)測(cè)試中擁有的最大的捆綁軟件，以Ember結(jié)尾，是任何其他實(shí)現(xiàn)的兩倍以上。我不知道為什么要花費(fèi)超過半兆字節(jié)才能呈現(xiàn)此表。但這確實(shí)會(huì)損害啟動(dòng)性能。
我們要看的最后一類是內(nèi)存消耗。
> Group 4 Memory
內(nèi)存往往會(huì)反映出我們已經(jīng)看到的模式，因?yàn)樗鼤?huì)對(duì)性能產(chǎn)生重大影響，而大型庫(kù)往往會(huì)使用更多模式。Alpine，Marko和React引領(lǐng)潮流。老化的細(xì)粒度反應(yīng)庫(kù)使用最多的Ember。Ember是巨大的。僅在頁(yè)面上渲染6個(gè)按鈕之后，它已經(jīng)使用了比Vanilla在整個(gè)套件中要使用的更多的內(nèi)存。
通常，該組在GitHub上代表30萬顆星，可能是NPM下載量的最大部分，但Marko和Alpine在此人群中的平均排名最高。在性能方面，React排名第三，僅次于他們。
這是我們擁有鈦白粉比例框架的組，而我們的舊React庫(kù)也已經(jīng)消失了。讓我們繼續(xù)樂觀一些。
在這些框架中，您可以知道已經(jīng)考慮了性能。他們意識(shí)到規(guī)模，并且在創(chuàng)建和更新成本之間找到了平衡。我們看到了各種各樣的方法。Yew中的一個(gè)Web Assembly框架（用Rust編寫），LitElement中的一個(gè)Web組件。
事不宜遲，讓我們看看他們的做法。
> Group 3 Performance
分?jǐn)?shù)已經(jīng)提高了一點(diǎn)，我們看到的差距甚至更大。Preact是該組中性能最高的，僅增加了LitElement。Vue 3和Riot捆綁在一起，這兩個(gè)庫(kù)都位于中間，它們的歷史都包括反應(yīng)性和VDOM。Mithril是最早將性能放在首位的VDOM庫(kù)之一，Yew是唯一的WASM庫(kù)尾部。
在性能方面，所有這些庫(kù)都是相似的。在這堆中沒有純的反應(yīng)庫(kù)。它們都使用自頂向下的呈現(xiàn)方式，無論是VDOM還是簡(jiǎn)單的Tag Template Literal diff。與上一組相比，它們的對(duì)帳清單更智能（請(qǐng)參閱交換行性能）。但是，大多數(shù)仍然具有某些最慢的選擇行性能。
Yew是例外，但在其他方面則較慢。讓我們看看其余的測(cè)試是否有幫助。
> Group 3 Startup
情況有所改觀，但在啟動(dòng)指標(biāo)方面，Preact仍然處于領(lǐng)先地位。Yew是這一堆中唯一真正的大型庫(kù)。WASM庫(kù)的確偏大。
再次，我們看到一種結(jié)果配對(duì)。Vue是Yew最大的第二名。Preact和Riot非常緊湊。Mithril和LitElement在中間
Preact是React的4kb替代品，絕對(duì)是我們迄今為止所看到的最小的庫(kù)。但是最小的庫(kù)仍在繼續(xù)。盡管如此，這個(gè)范圍內(nèi)的任何庫(kù)都不應(yīng)該太關(guān)注它們的包大小。
> Group 3 Memory
Yew這次贏了。在所有經(jīng)過測(cè)試的框架中，它具有最小的內(nèi)存占用量。WASM庫(kù)在這里往往做得很好。其他都非常接近。Mithril和普瑞特Preact是最差的，但不是很多。
這里沒有太多可拉的東西。您可能會(huì)認(rèn)為L(zhǎng)itElement示例可能比其他非紅豆杉庫(kù)更輕巧，因?yàn)樗鼪]有像其余的那樣使用虛擬DOM。但是，正如我們將在以后看到的，VDOM并不意味著更多的內(nèi)存。
Riot和Preact的平均排名最高，其次是LitElement，排名第三。Riot雖然沒有脫穎而出，但在這個(gè)小組中沒有弱點(diǎn)，因此取得了勝利。但是，對(duì)于這些框架中的任何一個(gè)都很難失望。借助WASM和Web組件，它們代表了許多人認(rèn)為Web的未來。
但是我們還沒有完成。下一組代表對(duì)網(wǎng)絡(luò)未來的不同想法。輸入編譯器…
這一組是激烈的競(jìng)爭(zhēng)。我們擁有大多數(shù)被稱為編譯語言的庫(kù)。每個(gè)都有自己的風(fēng)味。我們擁有不變的結(jié)構(gòu)化Elm，受Ruby啟發(fā)的Imba和"消失的" Svelte。
注意：引起我注意的是，并不是每個(gè)人都熟悉Svelte以前的"消失的框架"綽號(hào)。它描述了從輸出中基本進(jìn)行自我編譯的能力。我不是在建議Svelte去任何地方。對(duì)帶來困惑感到抱歉。
奇怪的是HyperApp，它與其他應(yīng)用程序完全相反。沒有編譯器。沒有模板。只需h函數(shù)和一個(gè)最小的Virtual DOM。
猜猜這將如何發(fā)展？
> Group 2 Performance
好吧，最小的虛擬DOM勝出。與最近的言論相反，事實(shí)證明虛擬DOM不僅是性能不佳的秘訣，而且編譯并沒有使其他庫(kù)受益。
在已編譯的庫(kù)中，我們實(shí)際上看到了3種不同的方法來渲染所有具有大約相同的平均性能。Imba使用DOM協(xié)調(diào)（更接近我們之前看到的LitElement），Elm使用虛擬DOM，最后一個(gè)Svelte使用組件反應(yīng)系統(tǒng)。
您應(yīng)該注意，虛擬DOM庫(kù)的選擇行最差，因?yàn)檫@是其額外工作所顯示的。但是這些庫(kù)還具有更快的初始渲染。如果您仔細(xì)觀察到目前為止的結(jié)果，您應(yīng)該注意到Virtual DOM庫(kù)與Reactive庫(kù)之間的共享特性。但除此之外，性能還很嚴(yán)格。
因此，讓我們繼續(xù)。我們的編譯器如何調(diào)整啟動(dòng)時(shí)間/捆綁大小？
> Group 2 Startup
好吧，正如您所看到的那樣，這個(gè)小的虛擬DOM庫(kù)不僅性能更高，而且比其他的更小。實(shí)際上，HyperApp是我們所有庫(kù)中最小的實(shí)現(xiàn)。編譯器無法贏得成功。
它和Svelte都比我們的Vanilla JavaScript參考構(gòu)建小。那怎么可能？以一種更可重用的方式編寫更少的代碼來編寫抽象。Vanilla JS實(shí)現(xiàn)針對(duì)性能而非大小進(jìn)行了優(yōu)化。
Elm在這個(gè)群體中仍處于規(guī)模競(jìng)爭(zhēng)中。但是，Imba開始進(jìn)入某些第4組庫(kù)的范圍。
好了，留下記憶。編譯器大放異彩的最后機(jī)會(huì)。
> Group 2 Memory
內(nèi)存接近，幾乎是平局，但是Svelte最終為編譯器贏得了勝利。對(duì)虛擬DOM的一些甜蜜的報(bào)復(fù)顯示它比它更小，更快。
老實(shí)說，所有這些庫(kù)都具有出色的內(nèi)存配置文件。現(xiàn)在應(yīng)該很清楚，更少的內(nèi)存和更好的性能之間的關(guān)系。
不相信炒作嗎？
不。更多的事情比表面上看起來復(fù)雜。精心設(shè)計(jì)的系統(tǒng)，無論是運(yùn)行時(shí)還是編譯時(shí)，或者無論采用何種技術(shù)方法，都可以制成高性能的系統(tǒng)。
HyperApp是該組的明顯贏家，其后是Svelte，其次是Elm和Imba。通過這種對(duì)性能的專注，您知道這些庫(kù)在大多數(shù)情況下都可以提供，并且始終顯示在基準(zhǔn)測(cè)試的頂部。
那還剩下什么？
如果我告訴您，聲明性JavaScript庫(kù)對(duì)它們的性能如此有信心，就不用擔(dān)心原始WASM，Web Worker或您使用的任何技術(shù)，該怎么辦。歡迎來到…
在某一時(shí)刻，它可能被稱為"超快"，我相信它曾經(jīng)是這些庫(kù)的口號(hào)之一。如果您要跟蹤的話，只剩下2個(gè)庫(kù)了。實(shí)際上，這類庫(kù)中有少數(shù)幾家不斷推陳出新。但是在流行的中只有2種。它們平均比原始的手工優(yōu)化Vanilla JS慢20％。
這是要看的東西。在這里，我們有2個(gè)庫(kù)，如果查看它們的代碼，它們可能被視為同級(jí)庫(kù)，但使用的方法完全不同。Inferno是世界上性能最高的虛擬DOM庫(kù)之一。在最出色的5個(gè)執(zhí)行者中，有3個(gè)是虛擬DOM庫(kù)。選擇行測(cè)試的速度下降可以視為證據(jù)。
另一方面，Solid使用細(xì)粒度的反應(yīng)性，例如第4組中最慢的舊庫(kù)。重新出現(xiàn)此技術(shù)的位置很奇怪，但正如我們所見，Solid解決了它們的弱點(diǎn)。創(chuàng)建時(shí)間與更新時(shí)間一樣快。與Vanilla JavaScript的5％差距令人難以置信。
奇怪的是，Inferno和Solid的共同點(diǎn)是JSX模板和React受啟發(fā)的API。對(duì)于所有其他具有經(jīng)過優(yōu)化的自定義DSL的庫(kù)，也許您不會(huì)期望在性能的頂峰找到任何東西。但是，正如HyperApp所示，某些事情對(duì)性能的影響比人們想象的要小。
> Group 1 Startup
Solid將HyperApp和Svelte作為第三個(gè)庫(kù)加入，其庫(kù)比Vanilla JS實(shí)現(xiàn)小。但是Inferno也不是懈怠。
似乎性能庫(kù)較小時(shí)，有時(shí)添加更多代碼可以提高性能。更好的列表協(xié)調(diào)算法，更明確的防護(hù)措施，更精細(xì)的更新。
Inferno可能比前幾組中的某些庫(kù)更大，但它仍然是一個(gè)10kb以下的庫(kù)，并且?guī)缀踉谒行阅苌暇蝗珙A(yù)期。
> Group 1 Memory
在那里。除了Yew及其對(duì)WASM的使用以外，它們是整個(gè)競(jìng)爭(zhēng)中最低的內(nèi)存消耗框架。考慮到他們的表現(xiàn)，這并不奇怪。
這種內(nèi)存消耗數(shù)字反映了對(duì)對(duì)象的非常仔細(xì)的考慮，并創(chuàng)建了閉包。其中很多確實(shí)來自兩個(gè)庫(kù)都進(jìn)行的定制JSX轉(zhuǎn)換。
內(nèi)存性能的提高對(duì)Solid尤為重要，因?yàn)镾olid與大多數(shù)細(xì)粒度的反應(yīng)式庫(kù)一樣，都將CPU開銷換成了內(nèi)存消耗。在這種比較中，能夠征服內(nèi)存開銷是Solid如何采用與大多數(shù)最慢的庫(kù)類似的技術(shù)并使之成為最快的方法的很大一部分。
天空是極限。
…或者說Vanilla JavaScript是。但是我們這里的聲明式庫(kù)性能如此之差，您永遠(yuǎn)都不會(huì)知道它們之間的區(qū)別。當(dāng)使用DOM時(shí)，我們需要認(rèn)真考慮，許多不同的技術(shù)可以有效地渲染DOM。
我們?cè)谶@里看到它。Solid在十年前就被認(rèn)為是古老而緩慢的技術(shù)，奪得了性能冠軍，而Inferno再一次證明了虛擬DOM不能高效完成的工作。
在構(gòu)建JavaScript前端時(shí)，我們有很多選擇。這只是快速瀏覽框架帶來的性能開銷。當(dāng)涉及到應(yīng)用程序中的實(shí)際性能時(shí)，用戶代碼具有更大的影響。
但是，我真正想在這里打動(dòng)的是，測(cè)試您的解決方案并了解性能是很重要的。現(xiàn)實(shí)總是與營(yíng)銷不同。虛擬DOM不能保證很慢。不能保證編譯器會(huì)產(chǎn)生最小的捆綁包。自定義模板DSL不能保證是最佳的。
最后，我將為您提供完整的表，將所有庫(kù)一起顯示。僅僅因?yàn)閹?kù)快要結(jié)束了，并不一定意味著它很慢，但是與這些競(jìng)爭(zhēng)激烈的競(jìng)爭(zhēng)對(duì)手相比，它的得分更差。
單個(gè)圖表中的所有框架。
所有結(jié)果都添加到一個(gè)列表中（第1名獲得20分，最后1名獲得分）。在平局的情況下，性能優(yōu)先。
1. Solid (57)
2. HyperApp (54)
3. Inferno (51)
4. Svelte (51)
5. Elm (46)
6. Riot (40)
7. Preact (39)
8. Imba (36)
9. lit-html (36)
10. Yew (32)
11. Vue (29)
12. Mithril (29)
13. Marko (28)
14. Alpine (28)
15. React (19)
16. Rax (16)
17. Angular (12)
18. Knockout (11)
19. Ractive (8)
20. Ember (6)
特別提及AJ Meyghani在2018年的比較，這啟發(fā)了這篇文章。
(本文由聞數(shù)起舞翻譯自Ryan Carniato的文章《JavaScript Frameworks, Performance Comparison 2020》，轉(zhuǎn)載請(qǐng)注明出處，原文鏈接：https://medium.com/javascript-in-plain-english/javascript-frameworks-performance-comparison-2020-cd881ac21fce)
中級(jí)
一小時(shí)
有一定編程經(jīng)驗(yàn)。
Typescript
組件，正如它名字一樣，由各個(gè)部分組合而成。它包含哪些部分呢？來看下面這張圖：
圖中列出了四個(gè)文件：
大家發(fā)現(xiàn)它們之間的共同點(diǎn)了嗎？
下面通過問答的形式一步一步詳細(xì)講解組件。
Q：為什么這個(gè)四個(gè)文件是以app開頭？是不是組件都是以app開頭？
組件的基本組成部分文件命名規(guī)范是：
組件名稱.component.文件類型
例如：app.component.css
組件名稱：app
文件類型：css樣式
中間英文單詞component翻譯過來是組件的意思，把它放在中間起到一個(gè)區(qū)分作用，讓人一眼就知道這是組件的一部分。
整體見名知意就是負(fù)責(zé)組件樣式的文件。
綜上所述：組件不是都以app開頭。
Q：“app.component.spec.ts”后綴和其他三個(gè)不太一樣，它的文件類型是什么呢？
“app.component.spec.ts”的文件類型是ts（Typescript）。它是負(fù)責(zé)組件的單元測(cè)試功能。
它的命名規(guī)范和上面組件組成部分命名規(guī)范是不一樣的。
下面是組件單元測(cè)試的命名規(guī)范：
組件名稱.component.spec.文件類型
Q：這四個(gè)文件它們的作用分別是什么？
app.component.css：負(fù)責(zé)組件樣式。
app.component.html：負(fù)責(zé)組件模版。
app.component.spec.ts：負(fù)責(zé)組件單元測(cè)試。
app.component.ts：負(fù)責(zé)組件邏輯。
Q：組件的基本組成部分只有這四個(gè)嗎？
對(duì)的，其中只有單元測(cè)試不是必須的。也就是“app.component.spec.ts”文件可以不要。
好了，有關(guān)組件的組成部分就介紹到這。
下面進(jìn)入今天的主題內(nèi)容，負(fù)責(zé)組件邏輯的“app.component.ts”。
“app.component.ts”位置及內(nèi)容：
具體內(nèi)容：
我們要分三部分來看組件中的內(nèi)容：
第一部分，導(dǎo)出的組件類：
第二部分，@Component裝飾器：
第三部分，組件類中的屬性：
從圖中我們可以看到，這是一個(gè)普通的類。其實(shí)，組件類就是一個(gè)普通的類。
書寫一個(gè)組件類時(shí)，它的類名首字母必須是大寫，同時(shí)得遵循駱駝命名法。
它的名稱是怎么來取的呢？
注意看它的文件名“app.component.ts”，最后的文件類型去除后，將其“app”和
“component”前后部分，按照首字母大寫和駱駝命名法規(guī)則書寫，書寫的結(jié)果就是“AppComponent”。
這一部分也稱之為“組件的元數(shù)據(jù)”。
我們先來看官方的描述：
@Component 裝飾器會(huì)指出緊隨其后的那個(gè)類是個(gè)組件類，并為其指定元數(shù)據(jù)。 在下面的范例代碼中，你可以看到 AppComponent 只是一個(gè)普通類，完全沒有 Angular 特有的標(biāo)記或語法。 直到給它加上了 @Component 裝飾器，它才變成了組件。
組件的元數(shù)據(jù)告訴 Angular 到哪里獲取它需要的主要構(gòu)造塊，以創(chuàng)建和展示這個(gè)組件及其視圖。 具體來說，它把一個(gè)模板（無論是直接內(nèi)聯(lián)在代碼中還是引用的外部文件）和該組件關(guān)聯(lián)起來。 該組件及其模板，共同描述了一個(gè)視圖。
除了包含或指向模板之外，@Component 的元數(shù)據(jù)還會(huì)配置要如何在 HTML 中引用該組件，以及該組件需要哪些服務(wù)等等。
這個(gè)例子展示了一些最常用的 @Component 配置選項(xiàng)：
提示：文件地址中的“.”表示當(dāng)前路徑。
將他們的值結(jié)合解釋就是：
selector的值為“app-root”，在需要顯示App組件的HTML中寫上<app-root></app-root>即可。
templateUrl的值為“./app.component.html”，而“app.component.html”我們知道，它和“app.component.ts”都在app目錄下，作用就是組件的模版，里面寫的都是HTML代碼。
“app.component.html”內(nèi)容：
這個(gè)就是組件呈現(xiàn)的模版內(nèi)容，為什么說是模版內(nèi)容呢？
因?yàn)槔锩孢€涉及到占位符（即不是實(shí)際數(shù)據(jù)，暫時(shí)用其他名稱代替）。比如下面即將要說到的title。
styleUrls的值為“['./app.component.css']”，注意，它比“./app.component.html”多了一個(gè)中括號(hào)，在編程語言中，我們都用 []（中括號(hào)）來表示數(shù)組，它可以有多個(gè)類型一樣的值。這里的 []（中括號(hào)）表示的也是這個(gè)意思，表示可以有多個(gè)像“./app.component.css”一樣的組件樣式，其中“./app.component.css”里面寫的都是CSS代碼。同樣，“app.component.css”和“app.component.html”還有“app.component.ts”都在app同一目錄下。
“app.component.css”內(nèi)容沒有寫東西，暫時(shí)是空的。
如圖所示，AppComponent組件類中有一個(gè)title屬性，值為“hello”。
在第二部分的“app.component.html”內(nèi)容中，我們看到這樣一段代碼：
其中被<h1>標(biāo)簽中的內(nèi)容“Welcome to {{ title }}!”，出現(xiàn)了title字樣，還被 {{ }} （兩個(gè)花括號(hào)）包裹著，它們之間有關(guān)聯(lián)嗎？先打一個(gè)問號(hào)，接著，來證明他們之間是有關(guān)聯(lián)的。
運(yùn)行Angular應(yīng)用，主頁(yè)面顯示如下：
大家看到了什么？“Welcome to hello!”
這說明了，“app.component.ts”組件類里的屬性綁定到了“app.component.html”模版中，然后經(jīng)過Angular CLI編譯，瀏覽器進(jìn)行渲染成最終的頁(yè)面。
那么有人就要問了，“app.component.html”模版中為什么要用 {{ }} （兩個(gè)花括號(hào)）把title包裹起來呢？
{{ }} 叫插值表達(dá)式。可以將組件類里的屬性綁定到組件模版中。后面章節(jié)中會(huì)詳細(xì)講解。
在“app.component.ts”定義一個(gè)subTitle屬性，值為“Angular”，然后將其綁定到“app.component.html”組件模版中，位置在“Welcome to hello!”的下面，被<h1>包裹，內(nèi)容最終為“I like Angular”。
示例：
“app.component.ts”組件類：
“app.component.html”組件模版：
最終頁(yè)面：
看看你的是否跟我一樣呢？
我們大家一起回顧之前主頁(yè)面“index.html”那一章，在那一章我們知道“index.html”是用戶第一個(gè)訪問到的頁(yè)面，內(nèi)容如下：
其中我們看到了在<body>標(biāo)簽里面有一個(gè)<app-root>標(biāo)簽：
我們說過，這個(gè)<app-root>標(biāo)簽是AppComponent組件。
這還不算是重點(diǎn)，重點(diǎn)是大家有沒有發(fā)現(xiàn)<body>標(biāo)簽里面就一個(gè)<app-root>標(biāo)簽，其他什么都沒有。但是啟動(dòng)Angular應(yīng)用之后竟然是這樣的頁(yè)面：
每個(gè) Angular 應(yīng)用都至少有一個(gè)組件，也就是根組件，它會(huì)把組件樹和頁(yè)面中的 DOM 連接起來。 每個(gè)組件都會(huì)定義一個(gè)類，其中包含應(yīng)用的數(shù)據(jù)和邏輯，并與一個(gè) HTML 模板相關(guān)聯(lián)，該模板定義了一個(gè)供目標(biāo)環(huán)境下顯示的視圖。
上述是官方對(duì)根組件對(duì)描述。
由此看來，AppComponent就是應(yīng)用的根組件，以后再有新的組件出來，它們的父組件大多數(shù)會(huì)是AppComponent，它們的selector也會(huì)寫在“app.component.html”組件模版中。
至此，Angular組件已有一個(gè)初步了解，更深入的了解在后續(xù)開發(fā)中再講解。
如果大家有問題或想了解更多前沿技術(shù)，請(qǐng)?jiān)谙路搅粞曰蛟u(píng)論，我會(huì)為大家解答。
Angular第二十章：app開發(fā)目錄
Angular第二十二章：組件的HTML模版
加入同步學(xué)習(xí)小組，共同交流與進(jìn)步。
如果你也熱愛前沿技術(shù)，歡迎關(guān)注我們。
原創(chuàng)不易，未經(jīng)允許不得轉(zhuǎn)載！
*請(qǐng)認(rèn)真填寫需求信息，我們會(huì)在24小時(shí)內(nèi)與您取得聯(lián)系。
