<font id="zqva1"></font>
<rt id="zqva1"></rt>
  • <tt id="zqva1"></tt>
    <cite id="zqva1"></cite>

    <cite id="zqva1"><noscript id="zqva1"></noscript></cite>
      <rp id="zqva1"><meter id="zqva1"></meter></rp>

        <cite id="zqva1"></cite>
          <b id="zqva1"></b>
          <rp id="zqva1"></rp>
          <cite id="zqva1"></cite>

          <rt id="zqva1"></rt>

        1. <rp id="zqva1"></rp>

          你不知道的前端SDK開發技巧

          時間:?2017-12-07閱讀:?1485標簽:?前端
          作者:陳達孚 ,來源:https://segmentfault.com/a/1190000012307844
          香港中文大學研究生,《移動Web前端高效開發實戰》作者之一,《前端開發者指南2017》譯者之一,在中國前端開發者大會,中生代技術大會等技術會議發表過主題演講, 專注于新技術的調研和使用. 

          最近在做公司內部的一個的一個SDK的重構,這里總結一些經驗分享給大家。


          類型檢查和智能提示

          作為一個SDK,我們的目標是讓使用者能夠減少查看文檔的時間,所以我們需要提供一些類型的檢查和智能提示,一般我們的做法是提供JsDoc,大部分編輯器可以提供快捷生成JsDoc的方式,我們比較常用的vscode可以使用Document This

          另一種做法是使用Flow或者TypeScript,選擇TypeScript的主要原因是自動生成的JsDoc比較原始,我們仍然需要在上面進行編輯,所以JsDoc維護和代碼開發是脫離的,往往會出現代碼更新了,JsDoc忘記更新的情況。

          除此之外開發過程中我們無法享受到類型檢查等對SDK開發比較重要的特性,TypeScript可以讓我們減少犯錯,減少調試的時間,另一方面這次開發的SDK在提供出去的時候就會進行一次相對簡單的壓縮,保證引入后的體積,所以會希望壓縮掉JsDoc,而TypeScript可以通過在tsconfig.json中將declaration設置為true單獨的d.ts文件。

          一個帶提示的SDK:

          最后,對于開發同學來說,就算不使用TypeScript,也強烈建議使用vscode提供//@ts-check 注解,它會通過一些類型推導來檢查你的代碼的正確性,可以減少很多開發過程中的bug。

          還有一個小技巧,如果你使用的庫沒有提供智能提示,你可以通過NPM/yarn的-D安裝@types/{pkgname},這樣你開發過程中就能夠享受到vscode提供的智能提示,而-D安裝到devDependencies中,也不會增加你在構建時的代碼體積。


          接口

          既然提到了TypeScript,就提一下TypeScript的語法,基礎類型沒有必要贅述,而一些曾經的高級語法現在ES6也都能支持,這里提幾點常用但是JavaScript開發者不太習慣使用的語法。

          很多人在開始使用TypeScript的時候,會很迷戀使用any或者默認的any,推薦在開發中打開tsconfig中的strict和noImplicitAny來保證盡量少的any使用,要知道,濫用any就等于你的類型檢查并沒有實質效果。

          對一些暫時不能確定內容的對象的類型,可以使用{[key: string]: any},而不要直接使用any,后期可以慢慢擴展這個接口直到完全消除any,同時TypeScript的類型支持繼承,在開發過程中,可以拆解接口,利用組合繼承的方式減少重復定義。

          但是接口也會帶來一個小痛點,目前vscode的智能提醒不能很好的對應到接口,當你輸入到對應變量的時候,雖然會高亮,但是高亮的也只是一個定義了名字的接口。沒有辦法直接看到接口里定義了什么。但是當你輸入了接口里面定義的key的部分時,vscode會給你完整key的提示。雖然這對開發過程中有一點不夠友好,但是vscode開發團隊表示這是他們故意設計的,所以在API參數上可以選擇將一些必要(重要)參數用基礎類型直接使用,而將一些配置放入一個定義為接口的對象中。


          枚舉

          你有在代碼中使用過:

          const Platform = {
              ios: 0,
                android: 1
          }

          那你在TypeScript中就應該使用枚舉:

          enum Platform {
            ios,
            android
          }

          這樣在函數中你就可以為某個參數設置類型為number,然后傳入Platform.ios這樣,枚舉可以增加代碼的維護性,它可以利用智能提示保證你輸入的正確,不再會出現魔數(magic number)。相對于對象,它保證了輸入的類型(你定義的對象可能某一天不再只有number類型的value),不再需要額外的類型判斷。


          裝飾器

          對于裝飾器其實很多開發者既熟悉又陌生,在redux,mobx比較流行的現在,在代碼中出現裝飾器的調用已經很普遍,但是大多數開發者并沒有將自己代碼邏輯抽成裝飾器的習慣。

          比如在這個SDK的開發中,我們需要提供一些facade來兼容不同的平臺(iOS, Android或者Web),而這個facade會通過插件的形式讓開發者自己注冊,SDK會維護一個注入后的對象,常規的使用方法是到了使用函數后判斷環境再判斷對象中有沒有想有的插件,有就使用插件。

          實際來看,插件就是一個攔截器,我們只要阻止真正的函數運行就可以,大概的邏輯是這樣的:

          export function facade(env: number) {
            return function(
              target: object,
              name: string,
              descriptor: TypedPropertyDescriptor<any>
            ) {
              let originalMethod = descriptor.value;
              let method;
          
              return {
                ...descriptor,
                value(...args: any[]): any {
                  let [arg] = args;
                  let { param, success, failure, polyfill } = arg;   // 這部分可以自定義
                  if ((method = polyfill[env])) {
                    method.use(param, success, failure);
                    return;
                  }
                  originalMethod.apply(this, args);
                }
              };
            };
          }

          在SDK的開發過程中另一個常會遇到的就是很多參數的校驗和再封裝,我們也可以使用裝飾器去完成:

          export function snakeParam(
            target: object,
            name: string,
            descriptor: TypedPropertyDescriptor<any>
          ) {
            let callback = descriptor.value!;
          
            return {
              ...descriptor,
              value(...args: any[]): any {
                let [arg, ...other] = args;
                arg = convertObjectName(arg, ConvertNameMode.toSnake);
                callback.apply(this, [arg, ...other]);
              }
            };
          }÷


          泛形

          泛形可以根據用戶的輸入決定輸出,最簡單的例子是

          function identity<T>(arg: T): T {
              return arg;
          }

          當然它沒有什么特別的意義,但是它表明了返回是根據arg的類型,在一般開發過程中,你逃不開范型的是Promise或者前面的TypedPropertyDescriptor這種內建的需要類型輸入的地方,不要草率的使用any,如果你的后端返回是一個標準結構體類似:

          export interface IRes {
            status: number;
            message: string;
            data?: object;
          }

          那么你可以這樣使用Promise:

          function example(): Promise<IRes> {
              return new Promise ...
          }

          當然泛形有很多高級應用,例如泛形約束,泛型創建工廠函數,已經超出了本文的范圍,可以去官方文檔了解。


          構建

          如果你的構建工具是Webpack,在SDK的開發中,盡量使用node方式調用(即webpack.run執行),因為SDK的構建往往會應對很多不同的參數變化,node方式相比純配置方式可以更加靈活的調整輸入輸出的參數,也可以考慮使用rollup,rollup的構建代碼更加面向編程方式。

          需要注意的是,在Webpack3和rollup中構建中可以使用ES6模塊化的方式構建,這樣業務代碼引入你的SDK后,可以通過解構引入的方式減少最終業務代碼的體積,如果你只是提供了commonjs的包,那么構建工具的tree sharking是無法生效的,如果使用babel的話注意關閉module的編譯。

          另外一種減少單個包體積的方式,可以使用lerna在一個git倉庫里構建多個NPM包,比起拆倉庫可以更方便的使用公共部分的代碼,但是也需要注意對公共部分代碼的修改不要影響到別的包。

          其實對于大多數的SDK的來說,Webpack3和rollup使用感受是差不多的,比較常用的插件都有幾乎同名的對應。不過rollup有兩個優勢,一個是rollup的構建更細化,rollup.rollup接受inputOptions生成bundle,還可以generate生成sourcemap,write生成output,在這個過程中我們可以做一些細致的工作。

          第二點是rollup.rollup會返回一個promise,也就意味著我們可以使用async的方式來寫構建代碼,而webpack.run還是使用的回調函數,雖然開發者可以封裝成promise,但是個人覺得還是rollup的寫法還是更爽一點。


          單元測試

          上周我同事做了一個在線的分享,我發現很多同學都對單測很感興趣也很疑惑,在前端開發中,對涉及UI的業務代碼開發單測試比較困難的,但是對于SDK,單元測試肯定是準出的一個充要條件。當然其實我也很不喜歡寫單測,因為單測往往比較枯燥,但是不寫單測肯定會被老司機們“教育”的~_~。

          一般的單測使用mocha作為測試框架,expect作為斷言庫,使用

          同樣你可以用TypeScript寫單測,當然在執行過程中,不需要再編譯了,我們可以直接給mocha注冊ts-node來直接執行,具體方式可以參考Write tests for TypeScript projects with mocha and chai?—?in TypeScript!。但是有一點需要提醒你,寫單測的時候盡量依賴文檔而不是智能提示,因為你的代碼出錯,可能會導致你的智能提示也是錯誤的,你根據錯誤的智能提示寫的單測肯定也是。。。

          對于網絡請求的模擬可以使用

          最后我們用一個npm script加上nyc在mocha前面,就可以獲得我們的單測報告了。

          這里我還提了幾個TypeScript使用中的小tips給大家參考。

          tips: 如何在非發包情況下給內部庫添加聲明

          這個SDK在開發過程會依賴一個內部NPM包,為了讓這個NPM支持TypeScript調用,我們有幾種做法:

          tips: 如何處理resolve和reject不同類型的promise回調

          默認的reject返回的參數類型是any,不一定能滿足我們的需要,這里給一個解決方案,并非最佳,作為拋磚引玉:

          interface IPromise<T, U> {
            then<TResult1 = T, TResult2 = never>(
              onfulfilled?:
                | ((value: T) => TResult1 | PromiseLike<TResult1>)
                | undefined
                | null,
              onrejected?:
                | ((reason: U) => TResult2 | PromiseLike<TResult2>)
                | undefined
                | null
            ): IPromise<TResult1 , TResult2>;
            catch<TResult = never>(
              onrejected?:
                | ((reason: U) => TResult | PromiseLike<TResult>)
                | undefined
                | null
            ): Promise<TResult>;
          站長推薦

          2.騰訊云: 提供云服務器、云數據庫、云存儲、視頻與CDN、域名等服務。騰訊云各類產品的最新活動,優惠券領取點擊進入

          3.廣告聯盟: 整理了目前主流的廣告聯盟平臺,如果你有流量,可以作為參考選擇適合你的平臺點擊進入

          鏈接: http://www.modern-decoration.com.cn/article/detial/229

          前后端分離的優缺點

          前后端分離已經成為互聯網項目開發的業界標準使用方式,通過 nginx + Tomcat 的方式(也可以中間加一個 nodejs) 有效的進行解耦,并且前后端分離會為以后的大型分布式架構,彈性計算架構,微服務架構

          前端開發面試,如何寫好一個簡歷,脫穎而出

          通常在各個招聘網站,我們填寫完一些信息后,網站就可以幫助我們生成一個很不錯的簡歷。但是作為一名開發者,尤其是前端開發者,可能對這種簡歷并不滿意。這時候,相信有很多同胞們就希望能自己動手做一個很漂亮的web版的簡歷:

          前端一定要會node嗎?

          Node 是一個讓 JavaScript 運行在服務端的開發平臺,它讓 JavaScript 成為與PHP、Python、Perl、Ruby 等服務端語言平起平坐的腳本語言。

          張鑫旭:我對前端從業人員分布與技術風向的一點看法

          Web 前端這個職業從出現到現在 20 年的歷史應該有了,隨著這么多年前端發展和積累,累積百萬前端從業開發者絕對有的,當下至少有 50 萬前端開發從業者。從我篩選簡歷到最終錄取大概百分之一的錄取率,綜合我們廠算是小廠來看

          中臺微服務了,那前端呢?

          文章中詳細描述了基于 DDD 設計思想的中臺微服務設計方法以及分布式架構實施過程中的關注點等內容。中臺建設完成后,通過微服務實現了后端應用的解耦,提高了中臺應用的彈性伸縮能力

          學習web前端開發,學歷到底重不重要?

          首先,我們先了解一下一般情況下學歷的作用是什么,對于我們大多數人來講,在進行面試的時候,學歷最重要的一個作用就是“敲門磚”,現在任何公司招聘,都會寫上大專學歷以上或者是本科學歷以上,但是對于真正有能力的人

          千萬級用戶網站門戶前端設計

          對于千萬級的注冊用戶的門戶項目是前端這塊是怎么去實現的,自己在平常的工作中總結了一些經驗,也是在不斷的挫折中,不斷演練的,希望總結出來給大家參考下,和大家一起探討,一起進步。

          前端為什么學node?

          隨著互聯網的高速發展以及市場需求推動,Node已經成為前端知識棧必備技能之一,很多企業在招聘中也會著重考察求職者對Node的掌握程度。那么就有人好奇了從事Web前端為什么要學習Node.js?下面本篇文章就來給大家詳細的分析一下

          自學WEB前端的詳細路線

          學習web前端編程技術肯定是以就業拿到高薪工作為主要目的的,可是高薪不會那么輕易拿到,這是一個最簡單的道理。沒有付出就沒有回報,在整個學習web前端編程技術的過程中,你需要付出時間、精力、金錢。廢話不多說直接上干貨

          大前端時代下的熱修復平臺建設

          隨著移動需求的增加、移動項目的拓展,如果移動端應用出現 Bug 不能及時得到修復,影響的不僅僅是用戶體驗,還會造成業務上的損失,因此,建立一套完整的熱修復平臺迫在眉睫。

          內容以共享、參考、研究為目的,不存在任何商業目的。其版權屬原作者所有,如有侵權或違規,請與小編聯系!情況屬實本人將予以刪除!

          文章投稿關于web前端網站點搜索站長推薦網站地圖站長QQ:522607023

          小程序專欄: 土味情話心理測試腦筋急轉彎幽默笑話段子句子語錄成語大全運營推廣

          国产精品高清视频免费 - 视频 - 在线观看 - 影视资讯 - 唯爱网