アプレットログイン
ユニオニドとオープニド
アプレットログインを理解するには、アプレット/パブリックログインが最も重要なユーザー識別子の2つを含むことを理解するように書いてください：
キーアプリ
wx.login 公式に提供されているログイン機能
wx.checkSession 、ユーザの現在のsession_keyが有効かどうかを確認します。
wx.authorize ユーザに対して事前に認可要求を開始します。
wx.getUserInfo 基本ユーザ情報の取得
ログインプロセス設計
以下は、私が遭遇したいくつかのログインプロセスについての説明です。
既存のログインシステムの活用
既存システムのログインシステムを直接再利用し、アプレット側でユーザー名、パスワード/ CAPTCHA入力ページを設計するだけで、簡単にログインを実現することができます。
OpenIdを使ったユーザーシステムの作成
前述したように、OpenIdはユーザーIDのための小さなプログラムであり、これを使用すると、簡単に小さなプログラムベースのユーザーシステムのセットを実現することができます。具体的な手順は次のとおりです：
アプレットクライアントがwx.login経由でコードを取得
アプレットクライアントキャッシュ ログイン状態をカスタマイズし、その後のインターフェイスへの呼び出しでユーザーのIDとしてそれを持ち運びます。
Unionidを使ったユーザーシステムの作成
wx.getSettingを使用してユーザーの権限を取得します。
- ユーザが既に認証されている場合は、API wx.getUserInfoを直接呼び出して、ユーザに関する最新の情報を取得します；
- ユーザーが認証されていない場合は、ログインを促すボタンがインターフェイスに表示され、ユーザーがそれをクリックして認証すると、ユーザーの最新情報が取得されます。
ユーザーデータを取得した後、それを表示したり、独自のバックエンドに送信したりすることができます。
備考
wx.login(GetCode)===> wx.getUserInfo(ユーザー認証)===> ユニオニッドを取得する
アプレットにはクッキーの概念がないため、ログイン状態はローカルにキャッシュされなければなりません。したがって、ログイン状態に有効期限を設定することを強くお勧めします。
もし、風コントロールのセキュリティ検証、マルチプラットフォームログインなどの機能をサポートする必要がある場合、プラットフォーム、チャンネル、deviceParamなどのいくつかのパブリックパラメータを追加する必要があるかもしれないことを言及する価値があります。サーバー側とのプログラムを決定するとき、フロントエンドの学生は、合理的なシステムを設計するために、タイムリーにこれらの合理的な提案を提示する必要があります。
openid、unionid インターフェースで明示的に送信しないでください。
アプレットイメージエクスポート
頻繁にアプレットを開発し、使用する学生は、トラフィックを引き付けるための一般的な方法であるこの機能に慣れていない必要があり、通常、同時に小さなプログラムのQRコードのイメージに添付されます。
基礎
エクスポートされるスタイルは、まず canvas 要素を使って canvas 上に描画されます。
エレガントに実現するには
上記の原則によると、実装は非常に簡単ですが、唯一のドラフト抽出の設計は、描画することができますが、一般的な機能として、毎回ので、コードの山を書くことは非常に困難ではありません。その小さなプログラムは、どのように一般的な方法をエクスポートイメージを支援するために設計するのですか？アイデアは次のとおりです：
必要なスタイルを描画するステップを省略することはできません。しかし、このような長方形、丸みを帯びた長方形、円、帆立貝、三角形、テキスト、イメージなどの一般的なグラフィック描画が含まれている描画ライブラリをカプセル化することができます描画コードを減らすために、唯一のスタイル情報を絞り込む必要がある、あなたが簡単に描画することができ、最終的にアルバムにイメージをエクスポートします。私はよりエレガントで明確な描画するには、次の方法は、実際には、また、描画の種類を指定するタイプパラメータを追加するために使用することができます、着信1は、描画を実現するためのスタイルの配列です。
前のステップの実装と組み合わせることで、カードの同じタイプは、複数のエクスポート要求のシナリオを持っている場合は、また、カスタムコンポーネントのアプローチを使用することができます、共通のコンポーネントとして、カードの同じタイプをカプセル化する必要性でイメージをエクスポートする関数は、コンポーネントの導入することができます。
class CanvasKit {
constructor() {
}
drawImg(option = {}) {
...
return this
}
drawRect(option = {}) {
return this
}
drawText(option = {}) {
...
return this
}
static exportImg(option = {}) {
...
}
}
let drawer = new CanvasKit('canvasId').drawImg(styleObj1).drawText(styleObj2)
drawer.exportImg()
備考
- アップレットはネットワークイメージをキャンバスに描画することができないため、描画する前にまずdownLoadFileでイメージをローカルの一時ファイルにダウンロードする必要があります。
- 多くの場合、エクスポートしたイメージにQRコードを描画する必要がある、QRコードをエクスポートありますが、パラメータをエンコードする必要があります運ぶ必要があり、特定の長さの制限がある、あなたは問題を解決するために短いリンクのサーバー側の生成を使用することができます
アプレット - 統計
埋もれたSDKの設計
アプレットのコード構造は、各ページは、ページのビジネスロジックを達成するために、アプレットの基本的なロジックの助けを借りて、データのこの層のパッケージ化、ライフサイクル関数を含むビジネスロジックオブジェクトを受け入れ、ページメソッドを持っているということです。これを通じて、あなたは、ページのパッケージ化、そのライフサイクルとクリックイベントを改ざん、埋もれたコードに混合し、ビジネスロジックに干渉しない限り、いくつかの簡単な設定を行うことが埋もれ、単純なコードを次のように達成するためのアイデアを考えることができます：
アイデアを理解するためだけのコード
page = function(params) {
let keys = params.keys()
keys.forEach(v => {
if (v === 'onLoad') {
params[v] = function(options) {
stat() //埋もれたコードの公開
params[v].call(this, options)
}
}
else if (v.includes('click')) {
params[v] = funciton(event) {
let data = event.dataset.config
stat(data) // クリックして埋める
param[v].call(this)
}
}
})
}
このアイデアは、埋没ポイントに適用できるだけでなく、グローバルな例外処理、リクエストの統一処理、その他のシナリオにも使用できます。
分析インターフェース
いくつかの特別なビジネスでは、インターフェイスの埋没ポイントを取ることができ、インターフェイスの埋没ポイントとはどういう意味ですか？多くの場合、いくつかのapiは、マルチポジションの呼び出しではなく、特定のページでのみ呼び出され、思考のこのラインを介して分析することができ、インターフェイスが要求され、行為がトリガされ、それは完全にサーバー側のログを介して埋もれたデータを導出することができますが、このアプローチは、より限定的であり、プロセスの結果の分析に属し、エラーがあるかもしれませんが、それについて考える方法として使用することができます。
アプレット - エンジニアリング
エンジニアリング
現在のフロントエンドの開発プロセスは、エンジニアリングは、それが何であるかを行う必要がある小さなプログラムのエンジニアリングの必要不可欠な部分であり、まず解決する必要がある現在の小さなプログラム開発を見てください：
- はcssプリコンパイラをサポートしていませんが、主流のcssソリューションとして、less、sass、stylusは、cssの効率を向上させることができます。
- npmパッケージの導入はサポートされていません。
- ES7以降のjsの機能をサポートしていないため、非同期awaitなどの機能が使えません。
- 外部フォントファイルの導入には対応せず、base64にのみ対応
- eslintのようなコードチェックツールはありません。
プログラムの選択
現在、一般的に使用されるエンジニアリングソリューションは、webpack、rollup、小包などは、一般的にシングルページのアプリケーションのパッケージ化と処理で使用されますが、小さなプログラムは、本質的に "マルチページアプリケーション "であり、いくつかの特定の構成があります。解決すべき問題によると、ファイルのコンパイル、変更、これらのプロセスをコピーする以上のものではありませんが、これらのニーズについては、ストリームベースのgulpの対処に非常に適していると思うと、マルチページアプリケーションのWebpackの設定と比較して、より簡単です。したがって、gulpはアプレットのための推奨されるエンジニアリングソリューションです。
具体的な開発アイデア
これはgulpのタスクを通して行われます：
- lessファイルをリアルタイムで適切なディレクトリにコンパイルします。
- async、awaitをサポートするランタイムファイルの導入
- フォントファイルをbase64にコンパイルし、使いやすいように対応するcssファイルを生成します。
- npmパッケージが参照されている場所の依存関係を分析し、npmパッケージをファイルに分割し、適切なディレクトリにコピーします。
- コード仕様のチェック
上記を実装するのはそれほど難しくありませんが、それでは純粋なgulpビルドスクリプトと合意されたディレクトリだけで、新しいアプレットがあるたびにこのスクリプトをコピーして対応しなければならないのでしょうか？明らかにそうではありません。では、どうすればアプレットエンジニアリングを本当に実現できるのでしょうか？単純な足場が必要かもしれませんし、足場は機能をサポートする必要があります：
- 新規プロジェクト、ページ作成、コンポーネント作成のサポート
- 組み込みビルドスクリプトのサポート
- アプレットの公開をサポートするだけでなく、Jenkinsのような継続的インテグレーションを行うツールにアクセスする方法を見つけることもできます。
