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