摘要:你是一個對感興趣的開發者嗎不用擔心,這真的不會讓你成為一個背叛者或其他什么,真的。事實上,這個想法并不是或獨創的它只是一種很棒的軟件開發實踐方式。把代碼分離到不同的文件里并不會自動導致關注點分離。
原文鏈接 : Getting to Grips with React (as an Angular developer)
原文作者 : DAVE CEDDIA
譯者 : 李林璞(web前端領域)
譯者注:翻譯如有疏漏,歡迎指出!感謝!轉載請保留此頭部。
你是一個對 React 感興趣的 Angular 開發者嗎?不用擔心,這真的不會讓你成為一個背叛者或其他什么,真的。
或許你早就已經開始玩 React 了:閱讀了 Facebook 的官方教程,創建了一些組件...
也或許你正處于我幾個月前處于的境地:對React完全沒有經驗,除了聽說過它有多快,它有個虛擬 DOM 的概念,單向綁定,和一些像 Flux , Redux 和 Reflux 之類亂七八糟的東西。
在接下來一系列的文章里我將嘗試幫助你將你辛苦習來的 “Angular” 主義知識應用到 React 當中。
在 Angular 里,你可能已經習慣去編寫各種指令 directive。如果你是按照流行的規范去編碼的話,相信你程序的各個部分都是由一個或多個指令構建而成,并到處都使用了隔離的作用域 scope(如果這聽起來很熟悉但并不像你所做的話,或許你可以閱讀一下將scope轉化為controllerAs)。
React 有著相同的概念:編寫組件 component。將你的程序按功能拆分成組件塊,并盡可能讓每個組件塊保持獨立和可復用性。事實上,這個想法并不是 React 或 Angular 獨創的 - 它只是一種很棒的軟件開發實踐方式。盡可能寫一些簡短并具備可復用性的代碼(函數,組件,指令,隨便你怎么稱呼它們)。
一個關鍵的差別在于 React 里 所有東西都是組件 ,從根節點到下面所有。Angular 讓你使用 ng-controller 去混合和匹配所有指令,并在之后特定地路由出各自的指令和模板... React 讓這個事情變簡單了一點。所有東西都是組件,頁面,按鈕甚至是路由,我們隨后會講到這些。
好了,所以說 React 的“組件”是類似于“指令”的。那么它的代碼看起來是怎樣的呢?
下面是一個展示歌曲名字的 Angular 指令:
angular.module("demo", []).directive("songName", function() {
return {
scope: {
song: "="
},
restrict: "E",
template: "{{ ctrl.song.name }}",
controller: function() {},
controllerAs: "ctrl",
bindToController: true
};
});
接下來是用 React 寫的相同功能的組件:
var SongName = React.createClass({
propTypes: {
song: React.PropTypes.object.isRequired
},
render: function() {
return {this.props.song.name};
}
});
你馬上就可以發現一些相似之處:它們都期望得到一個 song 對象,并都似乎有各種各樣的模板。
一些不同之處在于:React 相對 Angular 有著更少的代碼。我敢說...更簡潔了不是嗎?React 里,期望的參數(song)有著某種類型驗證,并且 HTML 沒有引號!
事實上那個看上去沒加引號的 HTML 并不是真正的 HTML。(等下就會講到)
React.createClass 和 angular.directive 類似 - 它創建了一個組件類。這個組件 必須 有一個 render 方法,propTypes 是一個可選對象,但最好把它寫上。
還是要對得起 Angular ,它的1.5版本其實介紹了一個 component 方法來縮短指令的長度,所以上面的指令可以簡寫成下面這樣:
angular.module("demo", []).component("songName", {
bindings: {
song: "="
},
template: "{{ $ctrl.song.name }}"
});
更簡單的寫法。它甚至默認沒有控制器!我推薦閱讀一下Todd Motto的關于組件方法的文章并在你的代碼里嘗試一下。
但它還是沒有 propTypes ...
propTypespropTypes是一個驗證組件所需參數的方法。你可以把個別參數標記為“必需的”或“可選的”(默認它們都是可選的),把它想象成類型檢測吧。
下面是真正很酷的部分:如果你指定了propTypes并說明一個參數是必需的(像上面那樣),然后你忘記把它傳進來,你就會在控制臺得到一個提示信息。
比起 Angular 這真的太棒了!當你忘記給指令傳參時你就再也不怕莫名其妙地報錯了。
props什么是 "prop" ?它實際上是 “property” 的簡寫(感謝 React 的開發者,讓我們再也不用打出 this.properties 或者 this.propertyTypes 了)。
你可以把 props 看作是傳給組件的屬性。就像在指令里,你會在 HTML 元素里傳遞屬性一樣 - props 會在 JSX 元素里被當作屬性傳遞。
使用組件下面是 Angular 里指令的使用方法:
// Notice how you have to mentally translate "songName" to "song-name"?
然后下面是 React 里組件的使用方法:
// Notice how you DON"T need to mentally translate SongName to anything?
所有沒有子元素的標簽在 JSX 里都可以自終止。
但讓我們先花幾分鐘來講講 JSX吧...
JS里的HTML?!在我對 React 了解不多的時候,我知道它是把 HTML 和 JS 混合起來的,然后我就想這樣做真的很 丑陋 啊。我意思是,這對于最佳實踐的思考來說已經很多年不會這么寫了不是嗎?從那段使用 jQuery 的黑暗日子開始,我們就已經知道在 JS 里寫 HTML 元素是一件很取巧而且開發體驗相當糟糕的事情,所以為什么 React 會再次犯同樣的錯誤呢?
所以,這里有兩件事情需要搞清楚:
那并不是字符串。
你注意到它是怎么做到不給 “HTML” 加引號的嗎?那是因為它并不是 HTML。不加引號也并不是一種語法糖,React 是不會將那個東西轉換成 HTML 的。
那并不是HTML。
那是 JSX 。我知道它長得很像 HTML ,馬上你可能會想:“JSX嘛 ...只是對 HTML 做了一些細微的改變然后換了個名字而已”,好吧,你也可以那么說。我倒覺得它是給我們提供了一種用函數調用去創建 DOM 元素的語法糖。
創建 DOM 元素的函數調用?是的,看看下面的代碼:
// This JSX...
{this.props.song.name}
// Compiles to this function call:
React.createElement("span", {className: "song-name"}, this.props.song.name);
// React.createElement("tagName", props, children);
看起來還挺有道理的,不是嗎? HTML 創建嵌套的 DOM 節點,那我們就用嵌套的函數調用替代了嵌套的 DOM 節點...
// This is valid JSX:Hello World// ...which compiles to this call: React.createElement("div", null, React.createElement("span", {className: "greeting"}, React.createElement("strong", null, "Hello"), React.createElement("strong", null, "World") ));
實現上來說,這些 React.createElement 方法并沒有創建真正的 DOM 節點,它們創建了虛擬的 DOM 節點。
但...關注點的分離!所以說我們并不是把 HTML 字符串寫到 Javascript 里的!
但代碼邏輯始終還是和表現層混合起來的!那可不能算對!這么多年的軟件開發實踐告訴我們這樣做是很不好的。放心,現在只是還沒做完呢,你并沒有把視圖和邏輯混合起來。
我認為這是一種類似“貨物崇拜”的東西,我們經常在沒真正搞清楚為什么的情況下去贊同和執行。有很多很好的理由去說明為什么需要把邏輯和視圖層給分離開,但當你回頭再看會發現同樣也有很多很好的理由去合并它們。
或許你已經寫過一些帶有控制器和分離的模板文件的 Angular 指令了是吧?
告訴我你有多么經常在看不到或者無法修改控制器的情況下去到模板文件里去修改一些東西?又有多么經常在沒有接觸到模板的情況下去修改控制器?
這些看上去算是你對關注點的分離嗎?
我們喜歡把 JS 和 HTML 分離到不同的文件里去讓它們“關注點分離”,可復用性我們來了!
但其實它們很少會那樣工作。一個指令的控制器和模板通常會緊緊關聯在一起,所以很自然地,它們就像是硬幣的兩面。把代碼分離到不同的文件里并不會自動導致關注點分離。
如果你還沒注意到的話,其實我是想嘗試通過上面的說法告訴你模板和邏輯控制其實是可以共存在一個文件里的,而且這樣做或許看起來更有道理一些。
試試看我敢打賭你還是充滿疑惑。正常,我曾經也是的。
個人來說,我發現從長期以來信服的理論當中跳出來到一個看似完全相反的位置確實是一件相當困難的事情。我試過親自去嘗試那么做并證明給自己看這個新方法并不是那么糟糕。
希望你也可以去做同樣的事情,只需要一點點時間。去嘗試一下 React 的官方教程(不需要什么亂七八糟的工具 - 下載并運行他們的服務就可以開始寫代碼了),或者也可以試一下我的三分鐘輸出 Hello World 教程(不需要編譯哦!)。
或許就可以像我做的那樣,你會發現寫 React 組件確實很有意思。又或者你會發現 React 并不是你想要的東西,但至少你嘗試并驗證過了。
如果你決定使用它了,那就回來這兒吧,我等你!
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/87804.html
摘要:正在暑假中的課多周刊第期我們的微信公眾號,更多精彩內容皆在微信公眾號,歡迎關注。若有幫助,請把課多周刊推薦給你的朋友,你的支持是我們最大的動力。原理微信熱更新方案漲知識了,熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號:fed-talk,更多精彩內容皆在微信公眾號,歡迎關注。 若有幫助,請把 課多周刊 推薦給你的朋友,你的支持是我們最大的動力。 遠上寒山石徑...
摘要:正在暑假中的課多周刊第期我們的微信公眾號,更多精彩內容皆在微信公眾號,歡迎關注。若有幫助,請把課多周刊推薦給你的朋友,你的支持是我們最大的動力。原理微信熱更新方案漲知識了,熱更新是以后的標配。 正在暑假中的《課多周刊》(第1期) 我們的微信公眾號:fed-talk,更多精彩內容皆在微信公眾號,歡迎關注。 若有幫助,請把 課多周刊 推薦給你的朋友,你的支持是我們最大的動力。 遠上寒山石徑...
摘要:在其他方面,我們只需要考慮針對特定任務時所使用框架的成本。當我們必須使用或不應該使用框架時我強烈主張要了解編寫某個工具的目的。 非常有價值的建議:哪些框架是合理的,哪些并不合理。 作者:Tod Hansmann 來源:https://opensource.com/articl...翻譯:瘋狂的技術宅說明:本專欄文章首發于公眾號:jingchengyideng 。 showImg(htt...
閱讀 1861·2021-11-15 11:39
閱讀 1226·2021-10-18 13:29
閱讀 1188·2021-08-31 09:42
閱讀 2741·2019-08-30 11:11
閱讀 2117·2019-08-26 12:12
閱讀 2116·2019-08-26 10:17
閱讀 3391·2019-08-23 18:38
閱讀 3228·2019-08-23 18:38