在你崩潰之前，這8種做法會(huì)讓React應(yīng)用程序先崩潰
React庫(kù)的優(yōu)勢(shì)非常明顯：創(chuàng)建復(fù)雜的交互用戶界面非常簡(jiǎn)單。最大的特點(diǎn)是可以在不破壞其他組件的情況下，將組件直接組合在一起。即使是Facebook、Instagram、Pinterest這樣的社交媒體巨頭也大量使用React，同時(shí)通過谷歌Maps這樣的大型API創(chuàng)造無縫的用戶體驗(yàn)。
如果你正在用React構(gòu)建一個(gè)應(yīng)用程序，或是考慮將其用于即將開展的項(xiàng)目，那么本教程就是為你準(zhǔn)備的。希望通過公開一些需要再三考慮的代碼執(zhí)行，來幫助你構(gòu)建出色的React應(yīng)用程序。
下面是React里會(huì)使應(yīng)用程序崩潰的八種做法：
1. 在null上設(shè)置默認(rèn)參數(shù)
這是一個(gè)令人毛骨悚然的陷阱，可以讓開發(fā)人員全線崩潰。畢竟，應(yīng)用程序崩潰不是小事——任何類型的崩潰如果處理不當(dāng)，隨時(shí)都可能導(dǎo)致資金損失。
比如：
在應(yīng)用程序組件中，如果日期最終是falsey，它將初始化為null。直覺告訴我們，在默認(rèn)情況下，當(dāng)項(xiàng)是一個(gè)falsey值時(shí)，應(yīng)該將其初始化為空數(shù)組。但是當(dāng)日期為falsey時(shí)，應(yīng)用程序會(huì)崩潰，因?yàn)闂l目為空。
如果沒有傳遞值或者未定義的值，那么默認(rèn)函數(shù)參數(shù)允許使用默認(rèn)值初始化已命名參數(shù)!
因此，下次將默認(rèn)值設(shè)置為null時(shí)，一定要三思而后行。當(dāng)空數(shù)組是值的預(yù)期類型時(shí)，可以將值初始化為空數(shù)組。
2. 用方括號(hào)抓取屬性
有時(shí)抓取屬性的方式可能會(huì)影響到應(yīng)用程序的行為。也就是說會(huì)造成應(yīng)用程序崩潰。下面是一個(gè)用方括號(hào)執(zhí)行對(duì)象查找的例子：
這些實(shí)際上都是100%有效的用例，除了比對(duì)象鍵查找慢之外，實(shí)際上沒有任何問題。無論如何，隨著查找的深入，應(yīng)用程序里也會(huì)出現(xiàn)問題：
如果你對(duì)此代碼段實(shí)施某些增強(qiáng)并犯了一個(gè)小錯(cuò)誤(例如將j中的J大寫)，結(jié)果將立即返回undefined，并且會(huì)發(fā)生崩潰：
令人毛骨悚然的部分是，應(yīng)用程序會(huì)直到一部分代碼嘗試使用未定義值進(jìn)行屬性查找時(shí)才會(huì)崩潰。
所以在同一時(shí)間，joesProfile(經(jīng)過偽裝的未定義)將在應(yīng)用程序運(yùn)行，沒有人會(huì)知道這個(gè)未定義值正在蔓延，直到一段代碼執(zhí)行屬性查找，如joesProfile.age，因?yàn)閖oesProfile未定義!
為避免崩潰，一些開發(fā)人員會(huì)在查找不成功時(shí)初始化一些默認(rèn)有效返回值：
至少現(xiàn)在，應(yīng)用程序沒有崩潰。這說明，當(dāng)你使用方括號(hào)表示法應(yīng)用查找時(shí)，往往是無效的。
然而，如果沒有實(shí)際的例子，很難解釋這種做法的嚴(yán)重性。所以，接下來我們舉一個(gè)真實(shí)的例子。以將要展示的這個(gè)代碼示例為例，它可以追溯到8個(gè)月前的存儲(chǔ)庫(kù)。為了保護(hù)這個(gè)代碼來源的一些隱私，我們重名了幾乎所有的變量，但是代碼設(shè)計(jì)、語(yǔ)法和架構(gòu)完全一樣：
fixVideoTypeNaming是一個(gè)函數(shù)，它將根據(jù)作為參數(shù)傳入的值提取視頻類型。如果參數(shù)是一個(gè)視頻對(duì)象，它將從.videoType屬性中提取視頻類型。如果是字符串，則調(diào)用者傳入videoType，這樣就可以跳過第一步。有人發(fā)現(xiàn)視頻類型.mp4property在應(yīng)用程序的幾塊地方都被拼錯(cuò)了。用fixVideoTypeNaming來快速修補(bǔ)這個(gè)錯(cuò)誤。
現(xiàn)在，這個(gè)應(yīng)用程序是用Redux構(gòu)建的——因此語(yǔ)法。
要使用這些選擇器，你可以導(dǎo)入到connect高階組件中，以附加一個(gè)組件來偵聽狀態(tài)的那部分。
UI組件
該組件接收HOC傳遞給它的所有屬性，并顯示適應(yīng)屬性里的數(shù)據(jù)的信息。理想狀態(tài)下可行，現(xiàn)實(shí)中只是暫時(shí)可行。 如果回到容器中，看看選擇器是怎么選擇它們的值的，其實(shí)可能已經(jīng)埋下了一個(gè)定時(shí)炸彈，正在等著爆炸：
在開發(fā)任何類型的應(yīng)用程序時(shí)，為了確保較高的可信度和減少開發(fā)流程中的漏洞，一般在開發(fā)過程中進(jìn)行測(cè)試，以保證應(yīng)用程序按預(yù)期運(yùn)行。 然而，在這些代碼片段的案例中，如果沒有經(jīng)過測(cè)試，而且沒有及早處理，應(yīng)用程序就會(huì)崩潰。例如，state、app、media、video、videoType是鏈的四個(gè)層次。
如果一個(gè)開發(fā)人員在修復(fù)應(yīng)用程序的另一部分時(shí)不小心出錯(cuò)了，而state、app、media、video變成未定義狀態(tài)，那么應(yīng)用程序?qū)⒈罎?，因?yàn)樗鼰o法讀取未定義的videoType的屬性。
此外，如果videoType出現(xiàn)了另外一個(gè)錯(cuò)誤，而fixVideoTypeNaming沒有更新以適應(yīng)mp3的問題，那么該應(yīng)用程序?qū)⒚媾R另一個(gè)意外崩潰的風(fēng)險(xiǎn)。而這除非發(fā)生在真實(shí)的用戶身上，否則沒人能夠檢測(cè)到它。那時(shí)就為時(shí)已晚了。 絕不可以僥幸認(rèn)為應(yīng)用程序永遠(yuǎn)不會(huì)碰到這樣的漏洞。請(qǐng)小心點(diǎn)!
3. 渲染時(shí)粗心地檢查空對(duì)象
在過去有條件地渲染組件的黃金時(shí)期，有人曾做過一件事，那就是檢查數(shù)據(jù)是否使用Object.keys填充到對(duì)象中。如果有數(shù)據(jù)，那么如果條件通過，組件將繼續(xù)渲染。
假設(shè)調(diào)用了某個(gè)API，并在響應(yīng)的某個(gè)地方接收了作為對(duì)象的項(xiàng)。話雖如此，乍一看似乎完全沒有問題。項(xiàng)目的預(yù)期類型是對(duì)象，所以用Object.keys完全沒問題。畢竟，如果出現(xiàn)錯(cuò)誤并轉(zhuǎn)化為falsey值，的確可以通過把項(xiàng)初始化為空對(duì)象來進(jìn)行防御。
但服務(wù)器不總是返回相同的結(jié)構(gòu)。如果將來項(xiàng)變成數(shù)組會(huì)怎樣?Object.keys(items)不會(huì)崩潰，但會(huì)返回一個(gè)奇怪的輸出，比如[“0”、“1”、“2”]。被該數(shù)據(jù)渲染的組件該如何反應(yīng)呢?
但這還不是最糟的部分。代碼片段中最糟的是，如果屬性里收到的項(xiàng)是空值，那么項(xiàng)甚至不會(huì)初始化為默認(rèn)值。
那么在開始使用應(yīng)用程序前，就崩潰了：
再說一遍，請(qǐng)小心點(diǎn)!
4. 在渲染前粗心地檢查數(shù)組是否存在
這可能和第3條的情況非常相似，但是數(shù)組和對(duì)象經(jīng)?？梢曰Q使用，所以應(yīng)該單列出來。
如果你有這樣做的習(xí)慣：
那么至少確保有單元測(cè)試，始終密切關(guān)注這段代碼，或者在傳遞給渲染函數(shù)前及早正確地處理arr,否則如果arr變成對(duì)象文字，應(yīng)用程序就會(huì)崩潰。當(dāng)然， &&操作符會(huì)認(rèn)為它是真實(shí)的，并嘗試.map對(duì)象文字，這最終導(dǎo)致整個(gè)應(yīng)用程序的崩潰。
所以請(qǐng)牢記于心。節(jié)省你的精力以及挫敗感，把它留給更值得你特別關(guān)注的大問題吧!
5. 沒有使用Linter
如果在開發(fā)應(yīng)用程序時(shí)，沒有使用任何類型的linter，或者根本不知道它們是什么，你必須知道為什么它們?cè)陂_發(fā)中很有用。
用來輔助開發(fā)流程的linter是ESLint(https://eslint.org/?source=post_page---------------------------)，這是一個(gè)著名的JavaScript的linting工具，它允許開發(fā)人員在不執(zhí)行代碼的情況下發(fā)現(xiàn)問題。
這個(gè)工具非常有用，它就像半個(gè)導(dǎo)師一樣，及時(shí)糾正錯(cuò)誤——就好像有人在指導(dǎo)你一樣。它甚至描述了為什么你的代碼可能是錯(cuò)誤的，并建議你應(yīng)該做什么。
這里有一個(gè)例子：
關(guān)于ESLint最酷的是，如果不喜歡某些規(guī)則或是不同意其中的一些規(guī)則，可以禁用這些規(guī)則，這樣它們就不會(huì)在開發(fā)時(shí)顯示為 linting警告/錯(cuò)誤了。
6. 在渲染列表時(shí)進(jìn)行解構(gòu)
過去有些人出現(xiàn)過這種情況，而且很難檢測(cè)到漏洞?；旧?，如果有一個(gè)項(xiàng)目列表，并且準(zhǔn)備渲染每個(gè)項(xiàng)目的一堆組件，如果列表中有一個(gè)項(xiàng)目不是期待值，那么應(yīng)用程序會(huì)出現(xiàn)漏洞。如果應(yīng)用程序不知道如何處理值類型，就有可能會(huì)崩潰。
這里有一個(gè)例子：
代碼可以成功地運(yùn)行。來看看API調(diào)用，而不是返回這個(gè)——
——如果在API客戶端出現(xiàn)了意外情況并且返回這個(gè)數(shù)組時(shí)，如何解決這個(gè)問題呢?
那么應(yīng)用程序就會(huì)崩潰，因?yàn)樗恢廊绾翁幚恚?/p>
- Uncaught TypeError: Cannot read property 'name' of undefined
- at eval (DataList.js? [sm]:65)
- at Array.map (<anonymous>)
- at DataList (DataList.js? [sm]:64)
- at renderWithHooks (react-dom.development.js:12938)
- at updateFunctionComponent (react-dom.development.js:14627)
所以為了防止應(yīng)用崩潰，可以在每次迭代中都設(shè)置一個(gè)默認(rèn)對(duì)象：
現(xiàn)在，用戶不會(huì)再對(duì)你的技術(shù)和專業(yè)知識(shí)評(píng)頭論足了，因?yàn)樗麄儾粫?huì)再看到頁(yè)面崩潰的情況了：
然而，即使應(yīng)用不再崩潰，建議進(jìn)一步處理缺失值，比如為具有類似問題的整個(gè)項(xiàng)目返回null，因?yàn)槠渲袥]有任何數(shù)據(jù)。
7. 沒有充分研究你要實(shí)施的東西
不少人曾犯過這個(gè)致命的錯(cuò)誤：對(duì)自己實(shí)施的搜索輸入過度自信，過早相信自己的觀點(diǎn)。
這是什么意思呢?搜索輸入這一部分本應(yīng)是個(gè)簡(jiǎn)單的任務(wù)——而且的確如此。整個(gè)搜索功能出現(xiàn)問題的真正原因是在查詢中包含字符。
如果將關(guān)鍵字作為查詢發(fā)送到搜索API，僅僅認(rèn)為用戶鍵入的每個(gè)鍵是有效的是不夠的，即使是因?yàn)樗鼈兌荚阪I盤上。
只要100%確保這樣的正則表達(dá)式完全按預(yù)期運(yùn)行，并避免遺漏任何可能使應(yīng)用崩潰的無效字符：
該示例是搜索API最新的、既定的正則表達(dá)式。 以前它是這樣的：
可以看到斜杠/不見了，而這導(dǎo)致了應(yīng)用崩潰!如果該字符最終通過網(wǎng)絡(luò)發(fā)送到API，猜猜API會(huì)如何處理URL?
另外，不要完全相信在網(wǎng)上找到的例子。其中有許多都不是經(jīng)過充分測(cè)試的解決方案。而且就正則表達(dá)式而言，大多數(shù)用例沒有真正的標(biāo)準(zhǔn)。
8. 不限制文件輸入的大小
限制用戶選擇的文件大小是很好的做法，因?yàn)榇蠖鄶?shù)情況下，如果不會(huì)出現(xiàn)任何品質(zhì)損失，可以對(duì)大文件進(jìn)行壓縮。
但關(guān)于為什么把文件大小限制在某個(gè)限度內(nèi)，還有一個(gè)更重要的原因。在公司里，用戶上傳圖片時(shí)偶爾會(huì)被“凍結(jié)”。并不是每個(gè)人都有Alienware 17 R5電腦，所以必須考慮用戶的特殊情況。
你不會(huì)希望用戶在本應(yīng)上傳文件的時(shí)候卻上傳電子游戲吧?
以下是將文件限制為5 MB(5,000,000字節(jié))限制的示例：
