[譯] 在使用 React 一年之後，我學到了這些重要的經驗和教訓
原文: The most important lessons I’ve learned after a year of working with React
翻譯: joky （有稍做修改）
學習一項新技術總是會遇到很多挫折! 萬事開頭難，然後中間難，然後結尾難…（手動滑稽）。你可能會讓自己遨遊於各種教程或書籍的海洋中，去傾聽別人提出的不同觀點。每個人的觀點似乎都是正確且完美的，這讓我們很難判斷我們選擇的教程是否對我們有利。
在我們置身於海洋之前，我們需要了解這項新技術的基本概念。例如我們要開始學習React，我們就要站在 React 的角度進行思考，與 React 合二為一。
下面我會跟大家分享我這一年來從 React 中學到的經驗和教訓
持續關注 React 最新動向
如果你還記得 React 16.3.0 的釋出公告，你就會知道，它帶來了一些令人興奮的功能。
以下是我收集到的部分 React 16.3.0 的功能：
-
官方 Context API
-
createRef API
-
forwardRef API
-
嚴格模式
-
元件生命週期更改
React 核心團隊和社群貢獻者們一直在努力改進著這項我們喜歡的技術。在 React 16.4.0 我們迎來了指標事件（Pointer Events），同時更多的功能也會隨著時間的推移陸續在後續版本中推出：快取、非同步渲染以及其它未知功能（譯者注: React 16.8.0 推出 Hooks）
所以，如果你想成為高手，你必須持續關注 React 社群中所發生的事
瞭解這些技術的執行原理以及它們為什麼被開發出來。
瞭解你正在解決的問題，以及如何使開發變得更容易。
這會對你有很大的提升和幫助
大膽的將你的程式碼分割成小元件
React 是基於元件的。所以你應該利用這個概念，大膽的將程式碼分成小元件
一個簡單的元件可以只由 4-5 行程式碼組成，在某些情況下，這完全沒問題。
而且，別人可以很輕鬆的閱讀並理解你的程式碼。
// 簡單易懂，不是嗎？
return (
[
<ChangeButton
onClick={this.changeUserApprovalStatus}
text="Let’s switch it!"
/>,
<UserInformation status={status}/>
]
);
你製作的元件不必包含複雜的邏輯，例如你可以寫一個僅用來展示文字的元件。如果這有利於提高程式碼的可讀性和可測試性，並且可以減少程式碼中的壞味道，那麼對團隊中的每個人來說都是一項偉大的勝利。
import ErrorMessage from './ErrorMessage';
const NotFound = () => (
<ErrorMessage
title="Oops! Page not found."
message="The page you are looking for does not exist!"
className="test_404-page"
);
在上面這個示例中，所有的屬性都是靜態的。我們只是用這個元件來顯示網站的 Not Found 資訊，僅此而已。
同樣，如果你不想到處寫 className，我建議使用樣式化元件，這有助於提高可讀性。
const Number = styled.h1`
font-size: 36px;
line-height: 40px;
margin-right: 5px;
padding: 0px;
`;
//..
<Container>
<Number>{skipRatePre}</Number>
<InfoName>Skip Rate</InfoName>
</Container>
如果你擔心建立過多的元件會汙染資料夾，那請重新考慮如何構建你的程式碼。我一直在使用分形結構，它很棒。
嘗試使用更高階的技術
有時你可能會認為，你所掌握的知識還不夠支撐你去學習更高階的技術。這種擔心往往是多餘的 - 你應該嘗試去挑戰新技術。
通過掌握更高階的技術，可以讓你瞭解更多基礎知識，以及如何讓它們發揮更大的作用。
下面列出一些你可以探索的高階技術：
-
複合元件
-
高階元件
-
Render Props
-
Smart/Dumb 元件
-
其它高階技術...
深入瞭解它們，你就會知道為什麼使用以及何時使用它們，這會讓你對 React 得心應手。
// 看上去很複雜？
// 其實一點也不難
render() {
const children = React.Children.map(this.props.children,
(child, index) => {
return React.cloneElement(child, {
onSelect: () => this.props.onTabSelect(index)
});
});
return children;
}
同樣，不要只是在個人專案或Demo中進行實驗。要大膽的在工作中嘗試這些新技術（當然，在允許的範圍內）。
當你這麼做時，你的領導或同事可能會產生質疑，這很正常。你需要做的就是用強有力的論據來捍衛你的工作和決定。你可以使用新技術用來解決現有的問題，讓開發變得更簡單，或者只是用來重構一些難以維護的程式碼。即便你的建議遭到拒絕，你也會學到更多。
不要讓你的專案過於複雜
我們不應該過度炫技，編寫花哨的程式碼。而應該腳踏實地。編寫易於理解的程式碼。
如果你不瞭解 Redux，並且不知道它的用處。但是僅僅因為周圍的人都在用它，你就想用它的話，建議你不要這麼做。要有自己的主見，當別人質疑你時，你要挺身而出。
有時，你可能想利用最新的技術編寫一些花哨的程式碼來向全世界炫耀你的技術。說實話，這是我作為一個初學者時的心態。但是隨著時間的推移，你會明白，編寫平實的程式碼更有用：
-
同事可以幫忙處理你的工作，你不用一個人負責 開發/修復Bug/測試 等全部工作
-
團隊裡的人可以很輕鬆的瞭解你的工作內容
-
當你休假時，同事可以接管你的工作，並能很輕鬆的完成
所以，如果您想獲得團隊成員的尊重，請提升你的水平。並在寫程式碼時為團隊而不是為你自己著想。這會讓你成為一個受歡迎的團隊成員。
重構，重構，再重構
由於專案經理會頻繁的變更需求，所以你需要更頻繁的更改和重構你的程式碼。別擔心，這是一個正常的學習過程，沒有什麼問題是不能解決的。
同時，你要確保對你的軟體進行了測試。不管是 冒煙測試、單元測試、整合測試、快照測試 - 大膽的使用它們
雖然測試可以節省大量的時間，但是或許你像很多人一樣，認為測試是在浪費時間，但是請考慮這些好處：
-
您不必向您的同事解釋程式碼的工作原理
-
您不必向您的同事解釋程式碼為什麼崩潰
-
您不必為您的同事修復Bug
-
您不必修復一個數周之後才發現的Bug
-
你有時間做自己想做的事
總結
在過去的一年裡，我的目標是提高我的 React 技術。
在這一年期間，我變得更強大並且對 React 的使用更得心應手 - 各種模式、正規化、內部工作原理。我可以參與更高級別的討論並向其他人傳授我之前不敢接觸的知識。直到今天，回想起過去一年的成長經歷，我仍然感到激動和興奮。
所以我建議大家問一下自己：“你喜歡你現在做的事嗎？”
如果不喜歡，請尋找一項你可以談論幾個小時，學習一整晚，並感到快樂的事。
因為我們必須找到我們內心深處真正感興趣的事，並堅持下去，直到成功。