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