【quickhybrid】API計画

前言
すべてが準備されたら、API計画を開始します.このブロックはHybridフレームワーク全体で非常に重要な内容です.結局、フロントエンドページではJS APIで機能を呼び出すだけです.基本的に、API呼び出しが便利かどうかは、体験全体に影響します.
ここでは、以下の点に細分化します.

API制約(呼び出しフォーマット、パラメータフォーマット、コールバックフォーマットを含む)

機能計画(このフレームワークがどのような機能を提供すべきかを約束する)

アクセス権チェック(重要なブロックで、チェックしてから呼び出すことができます.アクセス権チェックのコードフォーマット、いくつかのコンテンツをチェックし、どのAPIをチェックする必要はありません)

モジュール化されたAPI(モジュールによって区分され、各モジュールは個別のコンポーネントとして拡張しやすい)

その他の最適化(PC側でAPIをデバッグするページ、一部のAPIでPromiseをサポートするなど)

API制約
API呼び出しは体験全体に関係しており、すべてのAPIが以下の呼び出し方式を統一することを約束しています.

quick.   .  ({
      1: "",
      2: "",
    success: fucntion(result) {
        //     
    },
    error: fucntion(error) {
        //     
    }
});

コンストレイントの説明

すべてのインタフェースが非同期呼び出し

受信objectタイプのパラメータ

成功コールバックsuccess

成功データ取得result

コールバック関数のトリガタイミングは具体的なAPIによって決定され、あるAPIは呼び出し時にコールバック(短期)することができ、あるイベントがトリガーされてからコールバック(長期)

失敗コールバックerrorは、すべてのAPI呼び出しエラーが失敗コールバック

を実行します.
きのうけいかく
ハイブリッド開発フレームワークの最も重要な機能は__です.オリジナル機能をJS API形式でフロントエンドページ呼び出しに提供する_
本フレームワークのAPI計画は以下の通りである:(このプロジェクトでは一部の機能のみを計画し、実際の使用中に自分で拡張すればよい)

quick
    |- ui               //   ui  
    |   |- toast        
    |   |- alert       
    |   |- confirm       
    |   |- prompt          
    |   |- showWaiting         
    |   |- closeWaiting          
    |   |- actionSheet       
    |   |- pickDate     
    |   |- pickTime
    |   |- pickDateTime
    |   |- popWindow
    |- page             //   （webview）  
    |   |- open
    |   |- openLocal
    |   |- close
    |   |- reload
    |- navigator        //      
    |   |- setTitle
    |   |- setMultiTitle
    |   |- hookSysBack
    |   |- hookBackBtn
    |   |- setRightBtn
    |   |- setLeftBtn
    |   |- setRightMenu
    |- auth             //       
    |   |- getToken
    |- device           //     
    |   |- setOrientation
    |   |- getDeviceId
    |   |- getNetWorkInfo
    |   |- getVendorInfo
    |   |- closeInputKeyboard
    |   |- vibrate
    |   |- callPhone
    |   |- sendMsg
    |- runtime          //     
    |   |- launchApp
    |   |- getAppVersion
    |   |- getQuickVersion
    |   |- getGeolocation
    |   |- clearCache
    |   |- clipboard
    |   |- openUrl
    |- util             //     
    |   |- scan
    |   |- selectImage
    |   |- cameraImage
    |   |- selectFile
    |   |- openFile

上記の計画は最も一般的な機能であり、具体的には各APIの紹介であり、入力パラメータの出力パラメータなどはフレームワークのAPIドキュメントで言及される.
アクセス権チェック
フレームワーク全体が外部に公開される場合(サードパーティが仕様に従ってアクセスできるようにする場合)、権限認証は欠かせません.
認証権限がない場合?任意のページで任意のAPIを呼び出し、機密情報を取得できることが想像できます..
では、権限認証はどのようなものなのでしょうか.ニーズに応じて、等級を分けることができます.

プラットフォームレベルの(釘、微信のような対外開放の)は、バックグラウンドに協力する必要があり、完全な授権、署名、検証メカニズム

プロジェクトレベルの(Nつのプロジェクトは同じフレームワークであるが、業務はそれぞれ異なる)、簡単なアプリケーションの内部構成、直接いくつかのドメイン名のホワイトリスト情報を検証すればよい

もちろん、このフレームワークは後のプロジェクトレベルであり、大量のプロジェクトが採用されているため、直接簡単に構成すればよい(例では、このエントリはオリジナルで予約されているが、実装されていない)
ここでは具体的な実装(参照可能なソースコードの実装)はさておき、権限認証の流れについてのみ説明します:(釘、微信など)

quick.error(function(error) {
    //     
});

quick.config({
    ...
});
quick.ready(function() {
    // TODO:           ，    api
});

他のフレームワークと同様に、フロントエンドもconfig,ready,errorの3ステップであり、その後configを原生的に受信した場合、内部で検査を行う(検査内容はページアドレスがドメイン名のホワイトリストに合致するかどうかを検出するなどであってもよい…)
また、configが失敗したり、検証されていない場合、機密APIは呼び出されません.
検証なしで利用可能なAPI
すべてのAPIが検証されてから使用できるわけではありません.次のAPIのデフォルトは使用可能です(ここでは粗い分割で、実際には各APIに正確に設定できます).

ui     API
page     API
navigator     API

このような利点は、いくつかの機密データに関連しなければ、検証を必要とせずに効率を提供することができることです(検証はルールが重い場合、速度に影響します).
モジュール化されたAPI
グローバル変数quickがありますが、APIはグローバル変数の下に直接バインドされるのではなく、モジュール別に分割されます.例えば、

quick.ui
quick.device
quick.page
...

ここで説明すると,モジュール化で区切ると,フロントエンド呼び出しがより明確になるほか,生でAPI定義とコンポーネントAPI拡張を行う場合にも便利である.
コンポーネントAPIの拡張メカニズム
コンポーネントAPIの拡張メカニズムについては,ここではどのように実現するか(参照可能なソースコードを実現する)についても具体的に説明せず,概ねどのようなものかを述べる.
デフォルトでは、フレームワークは次のコンポーネント(前に計画されたすべてのモジュール)を登録します.

ui
page
navigator
auth
device
runtime
util

しかし、あるプロジェクトで突然需要が発生したと仮定して、支払い機能を追加し、APIの形式でH 5ページ呼び出しに提供するには、どのように実現すればいいのでしょうか.
なお、このフレームワーク設計の目的はN個のプロジェクトで使用できるため、すべての機能がフレームワークに統合されることは不可能であり、各プロジェクトは独自のコンポーネントを拡張することができる.
この時、この開拓メカニズムを計画する必要があります.以下のようにします.

// 1.  config ，           
quick.config({
   jsApiList: ['pay', 'speech']
});

// 2.     ，   config ，       ，              ，        API     
//       API          ，           ，             ，       
//         
...

// 3.   ，         ，        API    
quick.callApi({
    name: 'xxx',
    mudule: 'pay',
    ...
    data: {},
    success: function(result) {},
    error: function(error) {},
});

このメカニズムにより、フレームワークの拡張性を維持することができ、異なるプロジェクトでN多機能を適用しても、この方法で拡張し、一貫した使用を維持することができる.
その他の最適化
大体の機能が実現した後、次にいくつかの最適化機能を行う必要があります.具体的な効果は呼び出しを簡略化することも、デバッグを容易にすることもできます.
部分APIサポートPromise前述のAPIでは、通常のコールバックに基づいて行われており、多層コールバックがネストされている場合でも面倒なので、Promise呼び出しをサポートする方法を拡張することができます.
開拓する前に、まず基調を決めます:_すべての短期コールバックはPromise呼び出しをサポートし、長期コールバックはPromise__の使用を推奨しません.
長期コールバックは複数回のコールバック(右上隅ボタンなど)に及ぶため、Promiseは推奨されず、強引に使用しようとすると、これらのAPI呼び出しが完了するとすぐにthenに入る
具体的には参照ソースを実装し、ここでは一般呼び出しとPromise呼び出しを少し比較する

quick.ui.alert({
    title: '  ',
    message: 'sd#ddd  ',
    success: function(result) {
        console.log('  alert  ');
    },
    error: function(error) {
        console.error('  :' + JSON.stringify(error));
    }
});

quick.ui.alert({
    title: '  ',
    message: 'sd#ddd  ',
}).then(function(result) {
    console.log('  alert  ');
}).catch(function(error) {
    console.error('  :' + JSON.stringify(error));
});

上記はまだネストされていない対比の場合で、ネストがある場合、違いはもっと大きいです
PC側デバッグAPI
スパイクのデバッグページと同様に、PC側でAPIをデバッグするページ(websocketベース)も計画されており、後述する詳細な説明があります.
原理の方面のソースコードは先に参考することができますhttps://github.com/dailc/node-server-examples/tree/master/node-socketio-hybriddebug
効果をプレビューできます
その他
その他の最適化については後述する
ルートディレクトリに戻る

【quickhybrid】Hybridフレームワークを実現する方法

ソースコードgithubこのフレームワークの実装
quickhybrid/quickhybrid