westore
1.0.0
setDataとより直感的なプログラミングエクスペリエンスに、DeepClone + Datadiffを内部的に使用します。 updateだけで、 setDataを使用する必要がなくなります。
Westoreアーキテクチャは、MVP（Model-View-Presenter）アーキテクチャに非常に似ています。
ストアレイヤーは、メディエーターパターンの仲介者として理解でき、ビューとモデルの間の多対多数の関係の数を0に減らし、ビューオブジェクトビューとモデルオブジェクトモデルの間の相互作用のトランジット制御を担当します。
ミニプログラムによって運ばれるプロジェクトがますます複雑になるにつれて、合理的なアーキテクチャはミニプログラムのスケーラビリティとメンテナンスを改善できます。ページ/コンポーネントにロジックを書くことは罪です。ビジネスロジックが複雑になると、ページ/コンポーネントはますます肥大化し、維持が困難になります。要件が変更されるたびに、Westoreは、あらゆる複雑さのミニプログラムに適した合理的なミニプログラムアーキテクチャを定義し、プロジェクトベースをより堅牢で、メンテナンスしやすく、拡張可能にします。
npm i westore --saveNPM関連の問題リファレンス：ミニプログラム公式ドキュメント：NPMサポート
| プロジェクト | 説明する |
|---|---|
| ウェストレア | Westoreのコアコード |
| Westore-Example | Westoreの公式の例 |
| Westore-Example-TS | Westoreの公式例（TS+SCSS） |
そのクラス図は次のとおりです。
// 平台无关的 Model
import Counter from '../models/counter'
// 平台无关的 Model
import User from '../models/user'
import { Store } from 'westore'
// 页面 store，一个页面一个
class HomeStore extends Store {
constructor ( ) {
super ( )
this . data = {
count : 0 ,
motto : 'Hello World' ,
userInfo : null
}
// 消费 Model
this . counter = new Counter ( )
// 消费 Model
this . user = new User ( {
onUserInfoLoaded : ( ) => {
this . syncUserModel ( )
}
} )
this . syncCountModel ( )
}
// 同步 Model 的数据到 ViewModel 并更新视图
syncCountModel ( ) {
this . data . count = this . counter . count
this . update ( )
}
// 同步 Model 的数据到 ViewModel 并更新视图
syncUserModel ( ) {
this . data . motto = this . user . motto
this . data . userInfo = this . user . userInfo
this . update ( )
}
increment ( ) {
this . counter . increment ( )
this . syncCountModel ( )
}
decrement ( ) {
this . counter . decrement ( )
this . syncCountModel ( )
}
getUserProfile ( ) {
this . user . getUserProfile ( )
}
}
module . exports = new HomeStoreユニバーサルモデルはフレームワークフリーであり、このような単純なプログラムのためにこのロジックを分離する価値さえありませんが、需要が拡大するにつれて、そうすることの大きな利点が見つかります。したがって、もう少し複雑な例があります。
ゲームスクリーンショット：
デザイン図：
写真のライトブルーの部分は、コードのラインを変更せずに、ミニプログラムヘビ、ミニゲームヘビ、ウェブヘビプロジェクトで再利用できます。
アプリケーションスクリーンショット：
デザイン図：
写真のライトブルーの部分は、コードのラインを変更せずに、Applet TodoAppおよびWeb TodoAppプロジェクトで再利用できます。
公式の例では、次のようにSnakeとTodoAppをミニプログラムディレクトリに導入します。
├─ models // 业务模型实体
│ └─ snake-game
│ ├─ game.js
│ └─ snake.js
│
│ ├─ log.js
│ ├─ todo.js
│ └─ user.js
│
├─ pages // 页面
│ ├─ game
│ ├─ index
│ ├─ logs
│ └─ other.js
│
├─ stores // 页面的数据逻辑，page 和 models 的桥接器
│ ├─ game-store.js
│ ├─ log-store.js
│ ├─ other-store.js
│ └─ user-store.js
│
├─ utils
詳細なコードについては、ここをクリックしてください
QRコードをスキャンして経験します。
回答setdataにどこに行きましたか？以前は、ユーザーが直接使用しないように、WestoreがこのAPIをカプセル化する理由について最初に考えなければなりません。アプレットでは、 setDataからビューを変更します。
this . setData ( {
'array[0].text' : 'changed text'
} )しかし、直感的なプログラミングエクスペリエンスは次のとおりです。
this . data . array [ 0 ] . text = 'changed text'データが応答しない場合は、手動で更新します。
this . data . array [ 0 ] . text = 'changed text'
this . update ( )上記のプログラミングエクスペリエンスは、直感的で開発者に優しいです。したがって、WestoreはSetdataを隠し、開発者に直接さらされるのではなく、Diffdataを内部的に使用して最短の更新パスを作成し、更新メソッドのみが開発者に公開されます。
Westore Diffdataの能力を見てみましょう。
diff ( {
a : 1 , b : 2 , c : "str" , d : { e : [ 2 , { a : 4 } , 5 ] } , f : true , h : [ 1 ] , g : { a : [ 1 , 2 ] , j : 111 }
} , {
a : [ ] , b : "aa" , c : 3 , d : { e : [ 3 , { a : 3 } ] } , f : false , h : [ 1 , 2 ] , g : { a : [ 1 , 1 , 1 ] , i : "delete" } , k : 'del'
} )diffの結果は次のとおりです。
{ "a" : 1 , "b" : 2 , "c" : "str" , "d.e[0]" : 2 , "d.e[1].a" : 4 , "d.e[2]" : 5 , "f" : true , "h" : [ 1 ] , "g.a" : [ 1 , 2 ] , "g.j" : 111 , "g.i" : null , "k" : null } 
違いの原則：
export function diffData ( current , previous ) {
const result = { }
if ( ! previous ) return current
syncKeys ( current , previous )
_diff ( current , previous , '' , result )
return result
}State.Dataの前のラウンドのキーは、主に同期されており、OBJで削除された配列またはキーで削除された要素を検出します。
プログラミングエクスペリエンスを改善しながら、SetDataがSetDataの最短パスアップデートであるたびに、大量の新しいデータを渡すという問題も回避します。
したがって、Westoreを使用しない場合、そのようなコードをよく見ることができます。
Westoreを使用した後：
this . data . a . b [ 1 ] . c = 'f'
this . update ( ) 現在の観点から見ると、ほとんどのミニプログラムプロジェクトは、Miniプログラムのページコンストラクターにビジネスロジックを蓄積しており、基本的に読みやすさはありません。 Westore Architectureの目標は、ビジネス/ゲームのロジックを切り離します。ページは純粋なページです。ユーザーの入力を表示および受信する、クリック、スライド、長い押し、その他のジェスチャーコマンドのみ、およびストアに指示を転送する責任があります。その後、ストアは実際のプログラムロジックモデルを呼び出します。この階層的境界は明確で、強力なメンテナンス、拡張性、テスト能力があります。単一のファイルモジュールのサイズも非常に適切に制御できます。
mit
