2015-07-10 97 views
12

最近我已經完成了一些React教程,特別是那些採用Flux架構的教程。所有這些教程都以各種形式利用了react/lib/keymirrorReact的keyMirror有什麼好處?

我明白它確實是,但我不確信我完全理解它提供的好處。不過,這可能暗示我對的理解,它的作用並不完全正確!

我的理解是:

  1. 它產生的enumerable
  2. 枚舉類型通常用於功能語言,但在object-orientated code中也很有用。
  3. minification雖然有好處,但我不確定在這種情況下我完全理解這些。
  4. Bill Fisher指出使用字符串代替常量不會不合理,而且當您擁有大量常量時真的會帶來好處。

我想的問題是,在小中等規模的應用程序,並在keyMirror內一次定義常量,然後需要,並在兩個不同的位置引用它們(動作和存儲)提供的任何有形的好處相比字符串,引用只有在行動和商店?

如果像比爾說的那樣有助於在一個地方看到一個常量列表,那麼僅僅保留一個帶有字符串常量的txt文件就足夠了。

回答

11

您必須等待React團隊的成員確認這一點,但我猜測其中一個原因是因爲業務邏輯中的常量字符串文字不受其樣式指南的鼓勵。在許多開發人員使用相同代碼的情況下,如果邏輯是通過設置和檢查硬編碼的字符串構建的,那麼從哪裏去找到任何術語的起源並不那麼明顯。

第二個原因是相關的,但是某些IDE會讓你自動查找,完成或重構屬性名稱,但不是文字字符串。將字符串定義在一個地方使這些工作流程變得更容易。

最後,更好的優化是可能的,因爲UglifyJS可以處理所有可枚舉的引用,它可以將該符號重命名爲更短,而不會影響dev代碼的易讀性或任何引用的魯棒性。

所以我想說,除了小型短期應用程序之外,將文字字符串移動到組織良好的常量對象中是個好主意。 KeyMirror只是其中一種幫助器,可以確保屬性值與密鑰匹配。我相信這是爲了讓您可以重新使用任何財產的價值作爲有效的關鍵。

+0

謝謝。那裏有一些好的想法。我沒有考慮過的事情。 – nickbdyer

+0

糾正我,如果我錯了,但我相當確信uglify只重命名像本地作用域變量名稱...不是對象屬性。如果uglify開始重命名對象屬性,那麼任何曾經使用'myObj ['property']'的地方都會立即被破壞......即,一半網絡。 –

+0

@JimboJonny是的,這可能是真的。我發誓我聽說過一個工具(Closure Compiler?)解析和自省代碼來檢查它是否可以縮短屬性,但我不確定。在那一點上,你會認爲編譯器也可以找到並替換多餘的字符串文字。 – gus