簡單介紹一下小程序的插件

插件？納尼？npm包么？

未接觸過小程序的插件時，以為它與 npm 包類似，我們可以封裝各種各樣便捷的功能，提供給他人使用。

經過這幾天接觸，竟有了追攀更覺相逢晚的趕腳，發現小程序的插件真真是個好東西。同時，也發現它與傳統意義上的插件還是有很大差別的。小程序的插件， 在一定程度上我們可以理解為是一個微服務。

微信小程序的插件功能更偏向于一個具體的行業服務，例如快遞行業，如果我們有相關接口，我們可以開發一個快遞查詢插件，這樣的話，一些電商服務的小程序或者其它對快遞查詢有需求的小程序就都可以接入我們的插件了。

官網中對小程序插件這樣介紹

插件，是可被添加到小程序內直接使用的功能組件。開發者可以像開發小程序一樣開發一個插件，供其他小程序使用。同時，小程序開發者可直接在小程序內使用插件，無需重復開發，為用戶提供更豐富的服務。

小程序開發者可便捷地把插件添加到自己的小程序內，豐富小程序的服務。當用戶在使用小程序時，將可以在小程序內使用插件提供的服務。

插件是對一組 js 接口、自定義組件或頁面的封裝，用于嵌入到小程序中使用。插件不能獨立運行，必須嵌入在其他小程序中才能被用戶使用；而第三方小程序在使用插件時，也無法看到插件的代碼。因此，插件適合用來封裝自己的功能或服務，提供給第三方小程序進行展示和使用。

插件開發者可以像開發小程序一樣編寫一個插件并上傳代碼，在插件發布之后，其他小程序方可調用。小程序平臺會托管插件代碼，其他小程序調用時，上傳的插件代碼會隨小程序一起下載運行。

相對于普通 js 文件或自定義組件，插件擁有更強的獨立性，擁有獨立的 API 接口、域名列表等，但同時會受到一些限制，如一些 API 無法調用或功能受限。對于一些特殊的接口，如 wx.login 和 wx.requestPayment ，雖然插件不能直接調用，但可以使用 插件功能頁 來間接實現。

有沒有好強大好邪惡的感覺～

插件的使用

添加插件

• 插件的開發和使用自小程序基礎庫版本 1.9.6 開始支持。

• 每個小程序，最多可以添加5個插件

• 在使用插件前，首先要在小程序管理后臺的“設置-第三方服務-插件管理”中添加插件。開發者可登錄小程序管理后臺，通過 appid 查找插件并添加。如果插件無需申請，添加后可直接使用；否則需要等待插件所有者同意申請后，方可在小程序中使用相應的插件。

引入插件代碼包

使用插件前，使用者要在 app.json 中聲明需要使用的插件

如上例所示， plugins 定義段中可以包含多個插件聲明，每個插件聲明以一個使用者自定義的插件引用名作為標識，并指明插件的 appid 和需要使用的版本號。其中，引用名（如上例中的 myPlugin）由使用者自定義，無需和插件開發者保持一致或與開發者協調。在后續的插件使用中，該引用名將被用于表示該插件。

使用插件中的自定義組件

使用插件提供的自定義組件，和使用普通自定義組件的方式相仿。在 json 文件定義需要引入的自定義組件時，使用 plugin:// 協議指明插件的引用名和自定義組件名，例如：

{
    "usingComponents": {
        "hello-component": "plugin://myPlugin/hello-component"
    }}

出于對插件的保護，插件提供的自定義組件在使用上有一定的限制：

• 默認情況下，頁面中的 this.selectComponent 接口無法獲得插件的自定義組件實例對象；

• wx.createSelectorQuery 等接口的 >>> 選擇器無法選入插件內部。

• 使用插件的頁面

  <navigator url="plugin://myPlugin/hello-page">
      Go to pages/hello-page!</navigator>

  • 插件的頁面從小程序基礎庫版本 2.1.0 開始支持。

  • 需要跳轉到插件頁面時，url 使用 plugin:// 前綴，形如 plugin://PLUGIN_NAME/PAGE , 如：

• 插件js接口調用

  var myPluginInterface = requirePlugin('myPlugin');
  
  myPluginInterface.hello(); 
  var myWorld = myPluginInterface.world;

  • 以上就是如何使用插件了，是不是很簡單呢。不要以為開發一個插件會有多難，那僅僅比使用起來，難了那么一點點。

    

  • 使用插件的 js 接口時，可以使用 requirePlugin 方法。例如，插件提供一個名為 hello 的方法和一個名為 world 的變量，則可以像下面這樣調用：

插件的開發

開放范圍：

• 企業、媒體、政府及其他組織主體。

創建插件項目

• 略。(官網相關介紹還是很棒的，此處就不多做贅述勉填篇幅了，多聊點有用的東西吧)

按照官網的步驟新建插件項目，你會得到這樣一個目錄結構：

三個文件夾分別是doc、miniprogram、plugin和一個project.config.json文件。

• doc ：這份開發文檔將展示在插件詳情頁，供其他開發者在瀏覽插件和使用插件時進行閱讀和參考。官網有提到。

• miniprogram ： 插件是用在小程序上的，那開發的時候該如何測試呢。不用擔心，人家小程序團隊肯定會想到并給予相應的解決方法的。這不，miniprogram就是做這個用的。你可以把它看成是一個簡單的小程序，專門供本地測試插件使用。

• plugin ：如你所想，這就是主角了。我們的插件。

• project.config.json : 項目配置文件。需要關注 compileType 字段，compileType == ‘plugin’ 時才能正常的使用插件項目。

用官方話講就是這樣的：

其中miniprogram 文件夾是一個普通小程序項目，用來編寫小程序插件的使用 Demo，上傳插件代碼時這個 Demo 會一起上傳，并作為小程序插件的發布的審核依據。

下面將重點介紹一下plugin文件。

• 配置文件plugin.json

  { "publicComponents": { "hello-component": "components/hello-component" }, "pages": { "hello-page": "pages/hello-page" }, "main": "index.js"}

  • 這個配置文件將向第三方小程序開放一個自定義組件 hello-component，一個頁面 hello-page 和 index.js 下導出的所有 js 接口。

  • 假設有這樣的一個場景，插件內的某個頁面A，只能通過插件的頁面B訪問，其他方式無法訪問，那么是否在plugin.json內配置頁面B就可以，無需配置A頁面呢。答案是否定的，雖然在開發者工具中可以使用相對路徑來跳轉，但在真機上是無法實現的。所以我想說的是，插件中的頁面，想要正常展示，必須在plugin.json文件中注明。

  • 向第三方小程序開放的所有自定義組件、頁面和 js 接口都必須在插件配置文件 plugin.json 列出，格式如下：

• 插件調用API的限制

  • 上文提到plugin目錄下的index.js文件是導出所有js接口的文件。但插件插件可以調用的 API 與小程序不同，主要有兩個區別：

    1.插件的請求域名列表與小程序相互獨立

    2.一些 API 不允許插件調用（這些函數不存在于 wx 對象下插件的自定義組件

• 插件可以定義若干個自定義組件，這些自定義組件都可以在插件內相互引用。但提供給第三方小程序使用的自定義組件必須在配置文件中列出。

• 插件的頁面組件

  • 插件從小程序基礎庫版本 2.1.0 開始支持頁面。插件可以定義若干個插件頁面，可以從本插件的自定義組件、其他頁面中跳轉，或從第三方小程序中跳轉。其中，提供給第三方小程序跳轉的頁面必須在配置文件中列出。

  • 自基礎庫版本 2.2.2 開始，在插件自身的頁面中，插件還可以調用 wx.navigateTo 來進行頁面跳轉， url 格式與使用 navigator 組件時相仿。

• 插件的接口

  • 插件可以在接口文件（在配置文件中指定，這里是index.js文件）中 export 一些 js 接口，供使用插件的第三方小程序調用。

• 預覽、上傳和發布

  • 插件可以像小程序一樣預覽和上傳，但插件沒有體驗版。

  • 插件會同時有多個線上版本，由使用插件的小程序決定具體使用的版本號。

  • 手機預覽和提審插件時，會使用一個特殊的小程序來套用項目中 miniprogram 文件夾下的小程序，從而預覽插件。

  • （建議的方式）如果當前開發者有測試號，則會使用這個測試號；在測試號的設置頁中可以看到測試號的 appid 、 appsecret 并設置域名列表。

  • 否則，將使用“插件開發助手”，它具有一個特定的 appid 。

• other

  • 插件在使用 wx.request 等 API 發送網絡請求時，將會額外攜帶一個簽名 HostSign ，用于驗證請求來源于小程序插件。這個簽名位于請求頭中，形如：

    X-WECHAT-HOSTSIGN : {
      "noncestr": "NONCESTR",
      "timestamp": "TIMESTAMP",
      "signature": "SIGNATURE"
    }

插件的未來

筆者認為首先插件應該有獨立的功能，例如之前提到的快遞查詢，其次，插件有很大一部分會被用戶信息制約，所以，筆者認為插件的功能也應該跟用戶是弱相關的。一個小程序現在是支持5個插件的，在使用第三方的插件的時候需要申請，只有對方通過后才能使用。綜上，插件其實更適合獨立的小功能的場景，與主小程序也是獨立運營和管理的狀態。（祖哥，為啥要用筆者啊，我覺得這個“筆者”，額～，略顯風騷啊）

插件總體上有兩大優勢：

1.通用性：在開發者處理和開發小程序特有的功能時，其他通用功能，可以直接拿別人的優秀插件，接入自己的小程序，從而完善小程序的功能。而且，小程序的插件是通用的，任何想用的企業都能申請使用。對于開發者而言，更是方便至極。

2.節約開發成本：對于開發者而言，插件功能的出現，能縮短小程序開發周期，節約研發成本，給小程序開發人員帶來更多 的靈活性。小程序插件功能可以說是為了降低開發者難度，減少開發周期。

那么說起對插件的未來，必定是瑕瑜互見的。極端點說，插件發展到某一天，想要完成一個小程序，只需要找一些合適的插件，拼裝一下就是一個小程序了。也是因為這樣，肯定會有許多低端開發者開發出大量質量粗糙的小程序版本出來。當然這是極端的說法，一個優秀的小程序，必定含有自己定制的內容，總的來說，插件的出現是一個多方共贏的事情。插件對于開發者來說，可以通過自己的技能+創意，實現一部分的變現；對于服務商來說，不用重復造輪子，可以用更少的費用、更少的時間做出更好的東西；對于微信來說，可以完善整個生態鏈，讓更多的開發者、創業者、服務者齊聚到小程序平臺，并為他們提供更好的服務和幫助。

其他

• 插件大小限制和小程序本身一樣。但插件使用方計算代碼包大小時會合并計入引用的插件大小。因此還是應該盡量小。 ——來自網絡：小程序開發者回復

• 小程序的 AppID 可以創建小程序插件項目，插件是獨立于小程序之外的，但是 AppID 是公用的，所以不要使用原有的小程序項目進行插件開發；

• 插件對標一個微服務，開發插件必須有 appid，所以，一個小程序對應只能開發一個插件；

• 開通插件時的插件名稱和頭像確定后是不允許修改的；會感覺插件貌似就是一個更小的小程序~~

• 目前沒有插件可供搜索的地方，期待微信的插件商城的出現；

• 插件發布需要通過微信審核，而且貌似審核更加嚴格，而且插件支持多個線上版本的同時存在；

• 插件的使用需要申請，插件開發者同意后，使用方可以接入使用插件。這里多提一句，有一些插件的作者并未設置使用權限，自然使用者申請后就直接可以用了，否則在插件列表里會看到類似審核中的字樣。

• 開發插件時，在開發者工具中看似正常運行的代碼，跑在真機上也許就會給你一個驚喜。

• 以上就是本文的全部內容了。目前尚未在實踐中使用小程序插件，僅僅是后續工作有相關需要，算是技術儲備，估計如果真的在開發中使用，依舊會有不少坑要踩。古語有云，沒有過不去的坎，只有過不完的坎。。。