第一部分：前端資料層的探索與實踐（一）在使用redux的過程中，由於業務複雜度的提公升，store裡面儲存的資料越來越多，通常會有多層次的巢狀和重複資料。同時在與後端互動的過程中，我們經常會討論是否要按照ui的層次結構來返回資料，結果被後端駁回，因為如果後端從資料庫中取到資料後，還要特意為前端加一層轉換，一來是考慮到伺服器壓力，二來是考慮到多裝置的時候無法復用介面。第二部分：前端資料層的探索與實踐（二）
在這樣的契機之下，我開始思考，面對複雜的應用，前端也需要處理業務邏輯，那麼資料應該如何組織和管理？
這次我先講正規化化資料。
所謂「正規化化」，就是資料庫設計時使用的一系列原理與技術。在講正規化之前，我們先說一下大家都不陌生的關係型資料庫，這就是應用正規化化的典型。
關係型資料庫：建立在關係模型上的資料庫。
關係模型：若干個儲存資料的二維表，每一行稱為一條記錄，每一列稱為乙個字段。表與表之間用關係來描述，有一對一/一對多/多對多三種關係。
藉此兩個概念很容易想到我們接觸得非常多的資料庫。那關係型資料庫在儲存和管理資料的時候遵循哪些原則呢，見下：
第一正規化（1nf）：表列（或稱屬性或稱字段）具有原子性，不可再分。
第二正規化（2nf）：滿足1nf的前提下，錶行（或稱例項）必須具有唯一可以被區分的主鍵key
第三正規化（3nf）：滿足1nf&&2nf的前提下，每個表中不包含已在其他表中定義的非關鍵字段，也就是不能有冗餘資料。
明白了正規化化的概念與設計原則，我們以redux應用為例，看一下我們應該怎樣設計正規化化資料，先看乙個簡單的例子，我們組織資料通常是這樣：
我們分析以上這個例子，可以看出實體有article/author/comment/commenter，對應設計為資料庫表的時候可以建三張表user/comment/article，所以正規化化資料應該像這樣：
總結：這樣帶來的好處顯而易見：
當伺服器端把資料傳到前端的時候，我們不太可能手動的去把這些資料正規化化，好在我們已經有了很多成熟的庫，幫我們做轉化。在redux應用中，推薦比較多的就是 normalizr 了，這個庫主要是幫我們將資料做正規化化處理，輸出的資料可以放在state中，顯然，這樣的正規化化資料在store中進行手動處理，會非常不方便，也有這樣的庫來幫助我們解決正規化化資料在store中的問題，比如denormalizr。但是還有乙個更好的工具，redux-orm，它可以說是normalizr和denormalizr的結合（如果是vue，也有類似的工具vuex-orm）。
一直認為學習要在熟悉掌握基礎的前提下多加實踐，所以我這一部分只是講了一些正規化化的基礎概念，同時引出生態鏈中與此相關的受歡迎的庫。第二部分我將詳細講一下我的redux-orm實踐。歡迎小夥伴們一同**?
敏捷實踐之敏捷與OKR的一些探索
敏捷落地在我們團隊落地已經接近五年了，作為乙個相對成熟的團隊，不少問題也浮現了出來，比如不少團隊成員對於未來缺乏長期規劃和工作上也相對的缺乏熱情和激情。團隊大多都忙於應對專案上的工作，對於個人自身的成長關注度不足，存在溫水煮青蛙的危險。最近一直在尋找合適的手段來幫助大家突破困局，再一次啟用團隊，發現...
資料驅動模式借助react的實踐探索
之前談到過很多次資料驅動的理解，這次通過實際專案檢驗了一下自己的想法。前端資料驅動的價值 前端資料驅動的陷阱 對於複雜一點的專案，做乙個詳細設計非常重要。有人會疑惑，前端還需要詳設嗎？根據我的經驗，詳設非常重要，非常體現能力。對於乙個新人，詳設能夠給開發做一些提前準備。對於乙個老手，詳設可以提前預見...
RSA的前端與node層應用
由於前幾天有朋友問我rsa的使用方式，便花了一些時間去看了一下文件自己做了一下前端和node端 由來 由於表單提交的資料用f12或其他抓包工具可以看的一清二楚，所以前端在處理表單提交的時候會要求使用rsa md5等類似的加密工具加資料加密後再上傳 用到的類庫 node rsa 非對稱性加密 加密 解...