国产av日韩一区二区三区精品,成人性爱视频在线观看,国产,欧美,日韩,一区,www.成色av久久成人,2222eeee成人天堂

Un utilisateur cliquant sur un bouton est essentiellement le même qu'un utilisateur accédant via une URL. Il s'agit d'une "entrée", donc le problème et le mécanisme de traitement sont les mêmes?: surveiller "l'entrée" dans le code de la couche de vue et traiter certaines vues. les couches (telles que les composants de bouton) basculent, correction d'URL) les changements d'état interne, génèrent/extraient un niveau d'abstraction pur et supérieur (non lié à l'affichage des composants ou aux détails de l'URL), des données/messages, les diffusent à l'aide d'une sorte de mécanisme d'événement, puis il n'a rien à voir avec vous, alors s'il existe une couche contr?leur, écoutez ces événements dans cette partie du code et appelez les méthodes des objets de modèle correspondants (qui peuvent encapsuler les dépendances et les appels entre les objets de modèle eux-mêmes, mais la complexité un-à-plusieurs ici ne sera pas exposée à l'extérieur), et également surveiller les changements d'état de certains objets de modèle et appeler les méthodes des objets de vue correspondants (ou restituer le DOM virtuel). Tout est lié.

Par exemple, j'utilise généralement NervJS (modèle) + DermJS (vue) + URLKit (route). Les objets NervJS et DermJS ont leurs propres méthodes d'événement. De plus, un bus unifié peut également être transmis lorsque l'objet vue/modèle est. objet d'événement initialisé.

Lorsque vous écrivez un composant d'interface utilisateur, vous ne voulez bien s?r pas qu'il dépende d'un modèle spécifique. Lorsque vous écrivez un composant de modèle, vous ne voulez pas qu'il dépende d'une interface utilisateur spécifique, donc des liaisons telles que one-to. -beaucoup se trouvent à un autre endroit (en particulier le code de logique métier) est complété. L'objet de vue et l'objet de modèle n'ont pas besoin et ne doivent pas savoir combien et lesquels en ont, il est donc impossible de ??plusieurs actions correspondent respectivement au magasin. ".

Quant aux problèmes de ? fichier unique ? et de ? chaos en constante augmentation ?, c'est la même chose que la configuration des fichiers de routage. Vous pouvez vous référer à une expérience pertinente.

En évolution, si vous avez besoin d’une action pour correspondre à plusieurs magasins, c’est en fait facile à résoudre.
Lors de l'enregistrement du rappel dans le Store, vous pouvez répondre à cette action, et vous pouvez également modifier l'ordre correspondant via waitFor. waitFor來改變相應的順序。

如果擔心代碼變亂的話，可以再單獨寫一個constants文件，定義好觸發(fā)的事件名稱就可以了。

舉個例子：

點擊一個按鈕，觸發(fā)send事件，會更新兩個Store分別是StoreA和StoreB。可以寫一個constants.js，先定義事件名稱：

constants:

module.exports = {
    "ActionTypes": {
        "SEND": "SEND"
    }
};

然后在兩個Store里面分別注冊回調(diào)：

StoreA:

var AppDispatcher = require('path/to/disp'),
    constants = require('path/to/constants');

StoreA.dispatchToken = AppDispatcher.register(function(payload) {
    var action = payload.action;
    if (action.type === constants.ActionTypes.SEND) {
        // callback A
    };
});

StoreB:

var AppDispatcher = require('path/to/disp'),
    constants = require('path/to/constants');

StoreB.dispatchToken = AppDispatcher.register(function(payload) {
    var action = payload.action;
    if (action.type === constants.ActionTypes.SEND) {
        // callback B
    };
});

在觸發(fā)點擊事件的時候，在Action中觸發(fā)Disp的這個事件，就會順序執(zhí)行在StoreA和StoreB

Lorsque cela se produit, je me demande généralement si je peux ajouter une couche entre eux.

Si vous ne l'avez pas vu, ou si vous l'avez vu mais avez oublié, voici un article qui mérite d'être lu?:

Modèles pour l'architecture d'applications JavaScript à grande échelle

En termes simples, vous avez besoin de quelque chose de "conventionnel" pour que la vue et le modèle n'aient pas besoin de dépendre l'un de l'autre (qu'il s'agisse d'une dépendance 1:1 ou d'une dépendance 1:N).

Vous pouvez également utiliser des modèles d'événements et d'observateurs simples. Si la logique métier est complexe, utilisez un médiateur pour compléter la communication et la synchronisation entre les modules.

PS : La situation idéale est que chacun de vos modules ne conna?t que lui-même (quels événements sont déclenchés, quels événements sont écoutés), et ne se soucie de rien d'autre, encore moins de l'instance de l'autre partie, ou de l'instance du médiateur.