著vue.js的發(fā)展，一些基于vue.js的框架如雨后春筍般出現(xiàn)在開發(fā)者面前（例如：Element-ui、Mint-ui）。但是，無論哪一種框架都不可能完全滿足項(xiàng)目需求，有時(shí)需要開發(fā)者自己編寫自定義組件。那怎樣編寫自定義組件呢？今天，老K為大家分享一下自己常用的方法。
按鈕是經(jīng)常使用的組件之一。Element-ui中的按鈕組件說明，如下圖：
今天，我們就拿這個(gè)按鈕組件為例為大家編寫一個(gè)自己的按鈕組件。
前期準(zhǔn)備：node.js開發(fā)環(huán)境，npm包管理器或者cnpm包管理器（推薦cnpm，速度快）。
首先，打開命令行窗口，用腳手架工具vue-cli搭建一個(gè)vue2.0開發(fā)環(huán)境。我們選擇搭建一個(gè)webpack-simple并放到custom-global-component目錄里。如下圖：
按步驟依次完成環(huán)境搭建。然后進(jìn)入custom-global-component文件里，輸入命令cnpm init完成依賴包的安裝，然后輸入命令npm run dev,啟動測試環(huán)境。如下圖：
如果一切順利，會出現(xiàn)vue.js經(jīng)典的歡迎頁。如下圖：
然后進(jìn)入custom-global-component/src目錄里，打開App.vue，為了便于測試，將多余代碼刪掉。如下圖：
代碼刪掉后，寫上本次的主題名稱。如下圖：
測試頁面同時(shí)會自動更新，如下圖：
在custom-global-component/src目錄里，新建components目錄，用來放組件文件。如下圖：
進(jìn)入components目錄，新建button目錄。這就是我們今天做的button組件的所在位置。如下圖：
進(jìn)入button目錄里，新建入口文件index.js、組件文件Button.vue，如下圖：
打開Button.vue，為了是我們的組件具有良好的可擴(kuò)展性，我們采用vue.js的render方法創(chuàng)建組件模板。如下圖：
組件標(biāo)簽名為“<g-button>”，轉(zhuǎn)譯的html標(biāo)簽名為“<button>”,默認(rèn)具有的樣式class名為“g-button”。
進(jìn)入入口文件index.js，引入button組件模板，生成名為“g-button”的vue組件并輸出。如下圖：
這樣一個(gè)普通的button組件就完成了。
現(xiàn)在，我們回到src目錄下，嘗試一下我們新編寫的組件。打開main.js和App.vue文件，引入并使用這個(gè)組件，如下圖：
main.js
App.vue
預(yù)覽結(jié)果：
這樣，一個(gè)可以復(fù)用的初級按鈕組件就完成了。上述代碼我已提交到github，歡迎參考！
代碼地址：
https://github.com/gaofei019/vue2.0-custom-global-component.git
當(dāng)然，這個(gè)組件遠(yuǎn)沒有達(dá)到完美，擴(kuò)展性還不夠強(qiáng)大。在下篇中，老K還會為大家繼續(xù)完善這個(gè)按鈕組件，敬請期待...
本文為原創(chuàng)內(nèi)容，若轉(zhuǎn)載請注明出處，轉(zhuǎn)發(fā)感激不盡。
最近，微軟宣布了一項(xiàng)舉世矚目的提案，表示他們將支持 JavaScript 和 TypeScript 的進(jìn)一步開發(fā)，該提案幾乎在一夜之間動搖了編程語言的基礎(chǔ)。
截止到目前為止，該提案還只是一個(gè)處于 Stage 0 階段的建議，但微軟宣布他們會按時(shí)將該提案提交給 TC39 委員會。如果這個(gè)提案被采納并付諸實(shí)施，那么必將在 JavaScript 和 TypeScript 界引發(fā)前所未有的動蕩。
JavaScript 的歷史回顧
回溯 20 年前，與現(xiàn)在的 Web 開發(fā)做比較，你就會發(fā)現(xiàn)，雖然 JavaScript 作為一種編程語言已經(jīng)有了很大的發(fā)展，但圍繞 JavaScript 的生態(tài)系統(tǒng)則取得了更大的進(jìn)步。
語言本身與生態(tài)系統(tǒng)的發(fā)展是相輔相成的，一方面在過去的二十年里 JavaScript 社區(qū)變得越來越專業(yè)，而另一方面互聯(lián)網(wǎng)本身在現(xiàn)實(shí)生活中的重要性也變得越來越突出。作為開發(fā)人員，我們無法控制用戶使用哪些瀏覽器。
這意味著用戶只有定期更新瀏覽器才能使用 JavaScript 的現(xiàn)代功能。雖然對于個(gè)人用戶來說，定期更新并不是難事，因?yàn)槿缃裨S多瀏覽器會自動更新而無需用戶的指示，但對于企業(yè)卻并非如此。
各個(gè)公司對于軟件和軟件更新有著嚴(yán)格的規(guī)定。許多公司都會使用過時(shí)的軟件或?yàn)g覽器上網(wǎng)。這是一個(gè)基本問題，甚至?xí)绊懙?HTML 和 CSS，此外，由于編程語言必須由各個(gè)瀏覽器解釋，因此也會對瀏覽器產(chǎn)生嚴(yán)重的依賴。
轉(zhuǎn)譯與捆綁
作為一名 Web 開發(fā)人員，你必須在兩種思路之間做出選擇：第一，依賴現(xiàn)代 JavaScript、CSS 或 HTML，這種方式不僅可以簡化編程，而且也可以提高易用性；第二，不使用這些現(xiàn)代功能，因?yàn)椴⒎撬腥硕际褂米钚碌臑g覽器，因此采用一些現(xiàn)代功能可能會導(dǎo)致一定數(shù)量的用戶無法正常使用。
除此之外，幾十年來我們還沒有一個(gè)像樣的 JavaScript 模塊系統(tǒng)。Node.js 從 CommonJS 借鑒了模塊系統(tǒng)，但僅限于服務(wù)器。
在最近的很長一段時(shí)間里，瀏覽器都沒有出現(xiàn)太大的提升，于是捆綁器與轉(zhuǎn)譯器應(yīng)運(yùn)而生。盡管我們使用的是 JIT（即時(shí)）編譯的編程語言，但必須經(jīng)過一個(gè)復(fù)雜的構(gòu)建過程，將源代碼轉(zhuǎn)換為實(shí)際代碼，然后才能在瀏覽器中執(zhí)行和解釋。
這是大約十年前的情況。
TypeScript 的崛起
微軟推出 TypeScript 也正好是在十年前。微軟認(rèn)為，如果在部署代碼之前，還需要一個(gè)轉(zhuǎn)譯器來轉(zhuǎn)換 JavaScript 代碼，那么在這個(gè)構(gòu)建過程中再添加一個(gè)步驟也沒什么大不了。
作為回報(bào)，你可以獲得一個(gè)良好的轉(zhuǎn)譯器，將現(xiàn)代 JavaScript 轉(zhuǎn)換成原始的 JavaScript。此外，TypeScript 是一個(gè)靜態(tài)類型系統(tǒng)，它不僅提高了 JavaScript 的可擴(kuò)展性，而且還提出了一些新概念，并為提高 JavaScript 的開發(fā)效率做出了重大貢獻(xiàn)。
因此，TypeScript 迅速崛起，并成為當(dāng)今企業(yè) JavaScript 開發(fā)的標(biāo)準(zhǔn)。
在過去的十年里，整個(gè)世界也發(fā)生了變化。雖然仍有一部分瀏覽器不會自動更新，而用戶使用的瀏覽器也不是最新版本，但這類用戶的比例已經(jīng)大幅下降了。
這意味著，你只需關(guān)注“常青瀏覽器”（指自動升級到最新版本的瀏覽器），那么非常有希望擺脫轉(zhuǎn)譯器。而且現(xiàn)在我們還可以使用 ESM（ECMAScript 2015 模塊），這是一個(gè)基于 JavaScript 的原生模塊系統(tǒng)，既可用于服務(wù)器端，還可用于客戶端。
也就是說，我們不再需要捆綁器，至少從技術(shù)角度來看是這樣。捆綁器只是構(gòu)建過程中的另一個(gè)步驟，為的是優(yōu)化 HTTP 請求，這樣就只需從服務(wù)器加載幾個(gè)大文件，而小文件的數(shù)量就大幅縮減了。
TypeScript 將成為一個(gè)障礙？
在這種情況下，構(gòu)建過程將變得越來越簡化，甚至根本不需要。微軟希望將來只有一個(gè)必要的工具會保留下來，那就是 TypeScript 編譯器，因?yàn)?Web 瀏覽器和其他 JavaScript 運(yùn)行時(shí)環(huán)境無法直接運(yùn)行 TypeScript。
這也就是說，屆時(shí)微軟的 TypeScript 會從一個(gè)非常實(shí)用的工具突然變成一個(gè)很討人厭的東西。然而微軟表示，他們不想成為障礙，相反，他們希望給予開發(fā)人員更多啟發(fā)。
微軟擔(dān)心的結(jié)果是，JavaScript 可能會像 20 年前一樣，朝著高速、直接和高效的方向發(fā)展，因?yàn)槿绻藗儾辉偈褂?TypeScript，那么也就不再需要轉(zhuǎn)譯器了。
將 TypeScript 集成到瀏覽器
最簡單的解決方法就是將 TypeScript 集成到 Web 瀏覽器和其他運(yùn)行時(shí)環(huán)境中，成為代替 JavaScript 的編程語言。從理論上講，這也并非不可能。Deno（https://deno.land/）已經(jīng)在做這方面的嘗試了。
Node.js 中有一個(gè) npm 包，名叫 ts-node，它采用了與 Deno 類似的解決方案。它會在構(gòu)建/加載應(yīng)用程序時(shí)將其編譯到內(nèi)存中，就好像可以直接運(yùn)行 TypeScript，但實(shí)際上并非如此。
此外，TypeScript 語言本身如今也變得越來越復(fù)雜，微軟并不希望將 TypeScript 編譯器的所有功能直接集成到常見的 Web 瀏覽器中，因?yàn)檫@將是一項(xiàng)非常復(fù)雜的任務(wù)，需要蘋果、Google、Mozilla 等公司通力合作，整合一個(gè)新的大標(biāo)準(zhǔn)。
無論這個(gè)發(fā)展方向正確與否，微軟都希望回避，目前這個(gè)問題的走向尚不明朗，但這項(xiàng)聲明表明這不是他們想要的結(jié)果。
中間方式：JSDoc
根據(jù)微軟最近發(fā)表的建議可以看出，他們想到了另一種不同的方式。除了（a）編寫原始的 JavaScript ；(b) 完全切換到 TypeScript，其實(shí)還存在第三種介于二者之間的一種中間方式。
TypeScript 允許你在 JavaScript 上分析代碼，甚至可以在其中存儲類型，即編寫適當(dāng)?shù)?JSDoc 注釋即可。對于某些公司來說，這種方式不僅可以通過 TypeScript 編譯器獲得類型支持，而且無需將項(xiàng)目完全遷移到 TypeScript。
這種方式最大的優(yōu)勢在于，代碼仍然是純粹的 JavaScript，不僅不需要編譯，而且只需刪除所有 JSDoc 注釋，就可以褪去 TypeScript 的外殼。我曾使用過 JSDoc，不得不說感覺更像是 TypeScript 的廉價(jià)替代品。
需要編寫的代碼更多，而且非常繁瑣，幾乎無法實(shí)現(xiàn)更復(fù)雜的類型，但總比沒有類型好。
建議：將 TypeScript 作為注釋
所以微軟的建議是，TypeScript 沿用 JSDoc 的套路，這樣就不必編譯 TypeScript 了。
類型注釋和關(guān)鍵字（例如“public”或“private”）將成為注釋，在執(zhí)行 JavaScript 代碼時(shí)會被忽略。這意味著，你可以編寫 TypeScript，而無需將 TypeScript 編譯成 JavaScript 代碼。
但是，你仍然可以使用 TypeScript 編譯器來觸發(fā)類型檢查，只不過不必編譯代碼來運(yùn)行。而“d.ts”文件將會被淘汰，因?yàn)?JavaScript 代碼中也包含這些類型。
這樣，TypeScript 編譯器就會變成一個(gè)可選的插件，就像 ESLint 之類的 linter，所有類型注釋都不會包含在執(zhí)行的代碼中。
因此，該提案被稱為“將 TypeScript 作為注釋”。
將 TypeScript 作為注釋的缺點(diǎn)
這個(gè)思路聽起來不錯(cuò)，但我看到了一些缺點(diǎn)。
我們不要忘記，TypeScript 不僅包含函數(shù)參數(shù)的原始類型，而且還有接口、聯(lián)合類型、類型關(guān)鍵字、非常復(fù)雜的類型和嵌套類型、“as”關(guān)鍵字、公共/私有/受保護(hù)關(guān)鍵字、泛型類型等等。
代碼本身就包含一些注釋，而且還包含兩種類型的注釋（單行注釋和塊注釋），如今再加上 TypeScript，那么我們就必須不使用多種類型的注釋來表達(dá)關(guān)鍵字。
所以，我不得不思考這是不是一個(gè)好方法，因?yàn)槲液芟矚g當(dāng)前的解決方案，即使它并不完美。畢竟，人們選擇 TypeScript 而不是使用 Flow 或 JSDoc 等替代方案是有原因的。TypeScript 比這些替代方案更受歡迎也是有其背后的原因的。
此外，我們編寫代碼時(shí)無法使用枚舉，因?yàn)樗鼈兪侵岛皖愋偷幕旌象w。還有命名空間、TypeScript 的 JSX 支持、參數(shù)屬性等，這些都無法使用。所以如果你想使用枚舉，就必須編譯代碼；如果不想編譯，就不能使用枚舉。
這個(gè)建議并沒有真正分割 JavaScript 與 TypeScript。我非常懷疑這是否應(yīng)該成為 TypeScript 未來的發(fā)展方向。
在我看來，這種方式會導(dǎo)致 TypeScript 開發(fā)人員陷入混亂，并形成兩個(gè)陣營。一些人堅(jiān)持使用當(dāng)前版本的 TypeScript，而另一些人將轉(zhuǎn)戰(zhàn)“將 TypeScript 作為注釋”。
最后的想法
在我看來，TypeScript 的發(fā)展有兩個(gè)方向：要么保持完整性，盡管所有代碼都需要編譯；要么給 JavaScript 創(chuàng)建一個(gè)可選的靜態(tài)類型系統(tǒng)。
這意味著，TypeScript 會成為新一代的 JavaScript，但微軟已經(jīng)否決了這個(gè)思路。因此，我的結(jié)論是，TypeScript 不應(yīng)該通過這種方式從根本上發(fā)生改變，尤其是不應(yīng)該以微軟目前提議或支持的方式。
未來幾個(gè)月或幾年內(nèi) TypeScript 究竟會如何發(fā)展，就讓我們拭目以待吧。
原文鏈接：https://betterprogramming.pub/how-microsoft-wants-to-destroy-typescript-1f1a53b18de6
《新程序員001-004》全面上市，對話世界級大師，報(bào)道中國IT行業(yè)創(chuàng)新創(chuàng)造
SX語法的特點(diǎn)是將HTML語言直接混寫嵌入JavaScript語言中，而不需要加任何引號。下面來看看對比。不使用JSX的例子：
使用JSX的例子：
JSX語法轉(zhuǎn)譯器會識別嵌入JavaScript代碼中的HTML標(biāo)簽，當(dāng)遇到“<”標(biāo)識符就會啟動JSX轉(zhuǎn)譯過程，遇到“{”標(biāo)識符就會當(dāng)作JavaScript代碼進(jìn)行處理，元素的標(biāo)簽、屬性和子元素都會被當(dāng)作參數(shù)傳給React.createElement函數(shù)。使用JSX語法的代碼： var app=<HelloComp color="blue" />;
使用原生JavaScript的等價(jià)代碼：var app=React.createElement(HelloComp, {color:"blue"});
JSX支持使用JavaScript求值表達(dá)式作為屬性值，從而達(dá)到類似模板的效果。JSX中的表達(dá)式用一對大括號{}包起來。求值表達(dá)式是要求有返回值的表達(dá)式，其原理類似于JSP中的<%=...%>。求值表達(dá)式本身與JSX沒有直接關(guān)系，只是JS的特性。求值表達(dá)式與語句有所不同，在編寫JSX時(shí)，在{}中不能使用語句（如if語句、for語句等），但可以把語句放在函數(shù)中，再在求值表達(dá)式中調(diào)用該函數(shù)。盡管在{}中不能使用if-else語句，但可以采用三元操作表達(dá)式。如：
也可以使用二元運(yùn)算符“||”來書寫，如果左邊的值為真，則直接返回左邊的值，否則返回右邊的值，與if語句的效果相同。
當(dāng)三元操作表達(dá)式不能滿足需要時(shí)，可以在JSX標(biāo)簽外使用if語句來決定應(yīng)該渲染哪個(gè)組件。如：
也可以使用變量來書寫：
或者把變量去掉，直接在{}中調(diào)用函數(shù)
render: function() {
return <div>Hello {this.getName()}</div>;
}
如果{}中包含的變量是一個(gè)數(shù)組，則會自動展開數(shù)組的所有成員，代碼如下：
