No, I didn’t wrote that, but I know it got your attention ?
開始學習一項新的技術時候令人很苦惱。你經常發現自己處於教程和文章的海洋裡,還伴隨著無數的個人觀點。並且每個人都聲稱他們找到了“正確而完美的方式”。
在潛入這片海洋之前,我們必須要理解該技術的基本概念。然後我們需要建立基於技術的思維模式。如果我們開始學習 React,我們首先要以 React 的方式去思考。後面我們才可以開始將各種思維模式融為一體。
在這篇文章,我將從個人使用 React 的經歷來介紹從中學到的一些關於這種思維的經驗。我們將回顧工作時間和做個人專案的夜晚,甚至我在本地 JavaScript 活動中的演講。
我們開始吧!
React 在不斷髮展,你需要與時俱進
如果你記得 16.3.0 版本的首次公告,你會想起當時大家是多麼的激動。
下面是我們看到的一些變化和提升:
- Official Context API
- createRef API
- forwardRef API
- StrictMode
- Component Lifecycle Changes
React 的核心團隊和所有的貢獻者正在做著偉大的工作 —— 努力改進我們所喜愛的技術。在 16.4.0 版本我們看到了 Pointer Events。
毫無疑問更多的變化將會來臨,這只是時間問題:非同步渲染 (Async Rendering)、快取 (Caching) 、version 17.0.0 以及其他未知的。
所以,如果你想成為佼佼者,你必須緊跟著社群裡變化的腳步。
瞭解事物的工作原理,以及被開發出來的原因。瞭解正在解決的問題,以及開發是如何變得越來越簡單。這會讓你受益匪淺。
不要害怕把你的程式碼拆分成更小的塊
React 是基於元件的。所以你應該利用這個概念,而不是害怕把大的模組拆分更小的模組。
有時候,一個簡單的元件可能只有 4-5 行程式碼,在某些情況下,這完全沒有問題。
這樣做,可以讓新人加入時,不需要花幾天的時間去理解這些程式碼是如何執行的。
1 2 3 4 5 6 7 8 9 10 |
// isn't this easy to understand? return ( [ <ChangeButton onClick={this.changeUserApprovalStatus} text="Let’s switch it!" />, <UserInformation status={status}/> ] ); |
你不必讓元件都包含複雜的邏輯。它們可以只當視覺元件。如果這樣可以提高程式碼的可讀性和方便測試,並減少程式碼的“壞味道”,那麼對團隊的每個人來說都是個偉大的勝利。
1 2 3 4 5 6 7 8 |
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
,僅此而已。
並且,如果你不喜歡 CSS 的 class 選擇器作為 class 名到處都是,我會推薦使用 styled components。這樣可以提高可讀性。
1 2 3 4 5 6 7 8 9 10 11 |
const Number = styled.h1` font-size: 36px; line-height: 40px; margin-right: 5px; padding: 0px; `; //.. <Container> <Number>{skipRatePre}</Number> <InfoName>Skip Rate</InfoName> </Container> |
如果你擔心建立太多元件是因為太多檔案會汙染目錄,那麼重新考慮如何架構你的程式碼。我一直在使用分形結構 (fractal structrue),它非常棒。
不要侷限於基礎 —— 轉向高階
有時你可能會認為你對某些東西理解不夠,不能轉向高階應用。但是通常你不必過多擔心 —— 接受挑戰並證明自己的擔心是錯的。
通過掌握高階內容並推動你自己,你可以理解更多基礎知識以及如何將他們運用在更大的專案上。
這裡有許多模式可以嘗試:
- 複合元件(Compound Components)
- 高階元件 (High Order Components)
- Render Props
- Smart/Dumb 元件 (Smart/Dumb Components)
- 等等 (嘗試去分析)
去研究他們,你會知道為什麼使用它們、在哪裡使用它們。用起 React 你會感覺更加得心應手。
1 2 3 4 5 6 7 8 9 10 11 |
// looks like magic? // it's not that hard when you just try render() { const children = React.Children.map(this.props.children, (child, index) => { return React.cloneElement(child, { onSelect: () => this.props.onTabSelect(index) }); }); return children; } |
同時,不要害怕在工作中使用新東西 —— 當然,在一定範圍內。
有人可能會質疑,這很正常。你的任務就是用強有力的證據來捍衛你的工作和決定。
你的目標應該是解決現有的問題,讓後續開發更簡單,或者清理一些麵條式程式碼。即使你的建議被拒絕,你的收穫也會比保持沉默得到的更多。
不要過度複雜
這個聽起來像是個相反的觀點,但是有所不同。在生活中,各個地方,我們都需要保持平衡。我們不應該過度設計來炫耀,而是要務實,編寫易於理解並實現其功能的程式碼。
如果你不需要 Redux,但是你想使用它,因為很多人都在不知道它真正用途的情況下使用它。你不要這樣做。要有自己的主張,如果有人推倒你,不要害怕站起來。
有時候你可能會想,通過使用最新的技術並編寫複雜的程式碼,你可以向世界宣稱:“我不是初級,我是中級/高階開發者。看看我能做什麼!”
老實說,這便是我開發者生涯初期的心態。但是隨著時間的推移,你會明白,不為炫耀、“能實現”的程式碼更容易接受。
- 你的同事可以接手你的專案,你不是唯一負責開發、修復、測試工作的人。
- 團隊可以不需要通過長時間的會議就知道其他人做的事情。幾分鐘討論就足夠了。
- 當你同事外出度假兩週時,你可以接手他們的工作。而且你不需要工作 8 小時,因為你 1 小時就可以搞定。
人們尊重讓別人生活更輕鬆的人。因此如果你的目標是獲得別人的尊敬、提升排名、提升自己,那麼你應該為團隊而不是為你自己編寫程式碼。
你會成為大家最喜歡的團隊成員。
重構,重構,再重構 —— 這是正常的。
你可能會幾十次的改變想法,雖然專案經理改變得更頻繁。有人會評論你的工作,你也會評論他。所以結果是,你將會很多次的修改你的程式碼。
但是別擔心,這是個正常的學習過程。不犯錯、程式碼不報錯,我們就無法提升自己。
跌倒的次數越多,重新站起來就變得越容易。
但是這裡有個提醒:你要保證去測試你現在的軟體。冒煙測試、單元測試、整合測試、快照測試 —— 別不好意思去測試。
每個人都看到或者將會看到測試可以節約寶貴時間的場景。
如果你和很多人一樣,都認為做這些是浪費時間,試著以不同的角度想一想。
- 你不需要和你同事一起向他解釋是如何工作的。
- 你不需要和你同事一起向他解釋為何會出現錯誤。
- 你不需要幫你同事修 bug。
- 你不需要修 3 周後才發現的 bug。
- 你將有時間做你想做的事情。
這些都是有很多益處的。
如果你喜歡它,你會不斷成長
在過去的一年裡,我的目標是更好的使用 React。我想做一個關於它的演講。我想其他人和我一樣享受它。
我可以不停歇的整晚坐在那程式設計,觀看各種演講並享受每一分鐘。
事實是,當你想要什麼,你會發現,不知怎麼的就會有人開始幫助你。在上個月,我為 200 人做了首次關於 React 的演講。
在這過去的一年裡,我變得更加強大,React 用得更加得心應手 —— 各種模式,正規化和內部原理。我可以進行高階內容的討論並向別人講授我之前害怕接觸的話題。
今天我依舊感到興奮和享受,一如一年前的感受。
因此,我建議每個人都問問自己:“你是否喜歡你在做的事情?”
如果不喜歡,那就繼續尋找你可以談論幾個小時、每晚學習並且使你開心的那個特別的事情。
因為我們必須找到最接近我們內心的東西。成功不能強迫,而是主動獲取。
如果我可以回到一年前,那麼在進行這個大的旅程之前,這些就是我想對自己說的。
Thank you for reading!