私のアプリでは、メソッドをクライアントとサーバーの間の共有場所に配置しました。この方法では、流星のドキュメントで提案されているように、メソッド メカニズムが楽観的な UI を処理します。
しかし、David Weldon のブログで 2 層の実装について読んだばかりで、非常に理にかなっています。
問題は、2 層実装で楽観的な UI を実現するにはどうすればよいかということです。
メソッドをサーバーに移動し、楽観的な UI のテンプレート イベントで clientDB を更新し、クライアント側から DB へのすべての更新を拒否します。
メソッドをクライアント側で利用できるが、別のメソッドからしか呼び出せない方法はありますか?
提案されたアプローチは高く評価されます。
重要なことは、クライアント側の挿入/更新を拒否することだと思います。それが完了したら、クライアントから第 2 層のコードを実行できますが、拒否されるため、実際には何もしません。
そのビューをサポートするhttps://www.discovermeteor.com/blog/meteor-pattern-two-tiered-methods/からのいくつかの段落を次に示します。
クライアントサーバー
postSubmit 関数は主にサーバー上で実行されることを期待していると述べましたが、2 つの状況でクライアント上で実行されます。
まず、メソッドのクライアント側シミュレーションの一部として、postSubmit メソッドから呼び出されたとき。その場合、Meteor はシミュレーションを実行し、クライアント側のデータベースに投稿を挿入し、最後にサーバー側の postSubmit メソッド呼び出しをトリガーします。
もう 1 つのユース ケースは、ブラウザ コンソールから直接 postSubmit 関数を呼び出す場合です。その場合、Posts.insert() 呼び出しはクライアント側の挿入を許可していないため失敗し、何も起こりません。
許可/拒否は Meteor メソッド内から実行されるコードには影響しないことに注意してください。これが、許可/拒否ポリシーを宣言しなくてもシミュレーションが失敗しない理由です。
つまり、答え #1: メソッドを共通の場所に保管し、安全でないパッケージを削除します (meteor remove insecure)
#2 への回答: それらは拒否されるため、メソッドの外で呼び出されても問題ありません。