Vee:迅速に移植できるエンジニアリング構造

8717 ワード

概要
最近webをする時、多くのvue関連技術を使ったため、最も初期はweexで、使用中のすべてのwebアクセスがめちゃくちゃで、全く構造が言えなくて、ajaxはずっとインタフェースファイルの中で混合して、コードは猫に壊された毛糸のボールのようです.
これは深刻な問題を招いた:いったんバグが発生したら、彼の発生した位置を理解するのは難しいが、実はこれも完全に私の問題ではない.結局、開発チーム全体がこのように書いて、気絶したが、幸いなことに、毛糸球は最終的に安定期に入った.
しかし、それらのコードに直面して、私は書き直さない限り、一度も興味を持ったことがありません.
したがってjsコードが良好な構造を持つことができれば,後期のメンテナンスにおいてもマルチエンドの移植においても優れている.
Springエンジニアリングの構造を参照して、私は後でこれらのコードの中のすべてのAJAXのアドレスを単独で1つのjsに抽出して、そしてcontrollerにアクセスすることによって、それぞれサービスを編纂して、すべてのAjaxはすべてサービスの中で実行して、それから帰ってきたデータはVueのインタフェースの中で、インタフェースの中で更に処理して、彼を展示の必要なデータに変えます.
AjaxはHttpモジュールのサポートを必要とするが、プラットフォームによってHttp方式が異なる、微信のwx.request、ブラウザのfetchまたはaxios、JQuery、さらにはXMLHTTPRequest、さらにはいくつかの奇妙なアクセス方法があるので、Httpモジュールは抽象化されるべきで、各プラットフォームのjsはhttpを書き直し、これらの要求をPromiseにパッケージし、それらのサービスに提供するためにエクスポートする必要があります.
そこで整理すると、次のようになります.
Httpモジュール
exportはclassであり、静的get、post、put、deleteメソッドを提供し、Type Scriptを使用する場合、httpはインタフェースとして保持され、各プラットフォーム上でこのインタフェースの異なる実装を提供し、4つのメソッドはそれぞれURLまたはURLとデータを入力し、サービス側から返されるPromiseオブジェクトを出力することができる.
ServiceAPIモジュール
exportはclassであると同時に、1つのConstのAPIフィールドをExportし、異なるAPIアドレスが属するcontrollerに従ってグループ化します.たとえば、UserControllerのLogin:
export const API = {
	USER: {
		LOGIN: 'API  '
	}
}

APIのアドレスにはつなぎ合わせる必要があるところがたくさんあります.これらの場所は、使用するときは正則でマッチングして置き換えることで、プラス記号を直接使用することを避けたほうがいいです.これは乱れているように見えますが、正則は遅くなりますが、速度は受け入れられないわけではありません.
springのel式を真似て、文字列とjsonオブジェクトを直接つなぐことができるようなものを作りました.
export class ElExpr {
  static regex = /\$\{[^\^$}]+\}/g
  constructor (str) {
    this.el = str
    this.vars = str.match(ElExpr.regex)
    if (this.vars !== null) {
      this.vars = this.vars.map(elem => elem.substring(2, elem.length - 1))
    } else {
      this.vars = []
    }
  }

  spread (data) {
    let result = '' + this.el
    for (let name in data) {
      if (this.vars.indexOf(name) !== -1) {
        result = result.replace('\$\{' + name + '\}', data[name])
      }
    }
    return result
  }

  prepar (data) {
    this.preparData = data
  }

  toString () {
    if (this.preparData) {
      let result = this.spread(this.preparData)
      return result
    }
    return this.el
  }
}

では、API定数とは、${変数名}というものを含むEl式であり、必要に応じてServiceAPIクラスが提供する静的メソッドでアドレス取得を行い、必要な式文字列やパラメータを与えるだけで、すぐにリンクされた文字列をURLとして得ることができる.
また,この方法では,ES 6の展開演算子を用いてユーザが提供するパラメータに埋め込むデフォルトの変数値をいくつか提供することができ,使用時にデフォルトのパラメータの一部を省くことができる.
サービスモジュール
バックエンドサーバと直接対話し、データを取得して使いやすいjsオブジェクトにカプセル化し、具体的なインタフェースにかかわらず、バックエンド機能モジュールと一つ一つ対応し、HttpモジュールとServiceAPIに依存する必要がある.
Serviceモジュールは1つだけではなく、classとしてエクスポートされ、データアクセスのための静的メソッドが提供されます.
Utilモジュール
null,undefined,空文字列などの空の判断方法,Objectの深いコピー,Objectとarrayの相互比較などの汎用ツール方法を提供する.
小結
このようにして、いったんマルチプラットフォームの移植が必要になったら、私がしなければならないことは何ですか?簡単なインタフェースしか残っていませんよね?Httpはプラットフォームによって書き換える必要があるほか、以上のサービス、Util、APIなどはすべて動かずに直接移動することができます--もちろん、これは最も理想的な状況です.
実は私はずっと1つの新しい特性を気にして、装飾器と言って、これはJavaの注釈とあまりにも似ていて、もしできるならば、装飾器とElを使って直接API定数に取って代わって、AOPエージェントのこれらのサービスを通じて、直接データアクセスを実現することができて、カプセル化した後に必然的にもっと簡単であることができて、しかし、そんなに簡単ではないようです.