IP Girl
  1. IP Girl
  3. Backbone.js – où stocker les informations d’état?
Intereting Posts
Le code HTML en tant que source IFRAME plutôt qu’une URL Outils pour inspecter les fichiers .lib? Comment désactiver la vue satellite de Google Map? Comment pouvez-vous utiliser la propriété d’un object dans une chaîne entre guillemets? std :: unique_ptr pour les fonctions C qui ont besoin gratuitement Existe-t-il un moyen de restaurer Github et Bitbucket 2FA sans codes de récupération ou numéro de téléphone de sauvegarde? Plus précisément, quel est le danger de lancer le résultat de malloc? Comment vérifier si la variable BigDecimal == 0 dans java? Existe-t-il un bon éditeur JSP pour Eclipse? Comment utiliser les instructions préparées dans SQlite sous Android? Suppression en bloc dans LINQ aux entités Sélectionnez quel href se termine par une chaîne Dois-je utiliser s et s dans mes ? Terminer une activité d’une autre activité Sujet JMS vs files d’attente

Backbone.js – où stocker les informations d’état?

Je suis nouveau sur Backbone.js , et j’essaie de savoir où les variables d’état doivent vivre . Mon cas d’utilisation:

J’ai une application qui fournit une interface de lecture pour un livre (je sais, exemple classique, non?). Mes modèles sont Book et Page avec des classes de collecte pour chacun. La structure de l’application ressemble à peu près à ceci (pardonnez le visio ASCII): 

 +------------+ | Controller | +------------+ | Views Models | +--------------+ +----------------+ |-| IndexView |------| BookCollection | | +--------------+ +----------------+ | | | +--------------+ +----------------+ +-| BookView |------| Book | +--------------+ +----------------+ | | | +--------------+ | |-| TitleView |-+ | | +--------------+ | +----------------+ | +-| Page | | +--------------+ | +----------------+ +-| PageView |-+ +--------------+

En d’autres IndexView , le Controller instancie et coordonne deux vues, IndexView et BookView , soutenues par les modèles. Le BookView instancie et coordonne un ensemble de sous-vues (il y en a réellement plus qu’illustré ici).

Les informations d’état incluent:

  • le livre en cours (pointeur ou identifiant)
  • la page en cours (pointeur ou identifiant)
  • d’autres variables d’état de l’interface utilisateur, telles que la visibilité ou non des images sur la page, le fait que d’autres widgets soient ouverts ou fermés, etc.

Ma question est la suivante: où devraient se trouver ces informations d’état? Les options possibles incluent:

  • Les modèles , qui pourraient être sensibles à l’état. Cela a du sens, car ils sont destinés à stocker des données et les vues peuvent écouter les changements d’état, mais cela ne semble pas correspondre au motif prévu de Backbone.js, et n’aurait pas toujours un sens (par exemple, activer l’image dans le PageView devrait s’appliquer à toutes les pages, pas seulement à la page courante)

  • Un modèle singleton spécial destiné à contenir des informations d’état. Encore une fois, cela a du sens, facile à écouter, tous les points de vue peuvent y être liés – mais encore une fois, cela semble en dehors du standard MVC.

  • Les vues , qui sont responsables de l’état de l’interface utilisateur – mais cela nécessiterait que les vues soient au courant les unes des autres pour obtenir des informations d’état, ce qui semble incorrect

  • Le contrôleur , qui doit acheminer l’application entre les états – cela a du sens, mais cela implique un aller-retour un peu étrange, par exemple, l’ User selects "Show Images" --> View event listener is called --> View informs Controller --> Controller updates state --> Controller updates View (plutôt que le plus simple, l’ User selects "Show Images" --> View event listener is called --> View updates )

Je suppose qu’à certains égards, il s’agit d’une question générique de MVC, mais j’ai de la difficulté à comprendre. Quelle partie de l’application doit être responsable de la sauvegarde de l’état actuel?

UPDATE: Pour référence future, j’ai utilisé un modèle d’état singleton global pour ce problème. Le stream de l’interface utilisateur se présente comme suit:

  1. Les gestionnaires de l’interface utilisateur View ne font que mettre à jour app.State
  2. Mes routeurs ne font rien d’autre que mettre à jour app.State – ce sont essentiellement des vues spécialisées qui s’affichent et réagissent aux modifications des URL.
  3. Les vues écoutent les modifications sur app.State et mettent à jour en conséquence

Mon application est Open Source – vous pouvez voir le code sur Github . L’élément pertinent ici est le modèle d’état , que j’ai étendu pour traiter de l’état (de) sérialisation de l’URL.

Pourquoi ne pas créer un modèle d’état pour stocker et décrire l’état actuel? Je ne pense pas que ce soit faux. Étant donné que l’état actuel implique plus d’un modèle, je pense qu’il est raisonnable de créer un modèle d’état pour stocker et recevoir l’état actuel.

Le contrôleur pourrait alors communiquer avec le modèle d’état pour obtenir l’état actuel. Les états de l’interface utilisateur doivent être stockés dans le modèle correspondant. Le modèle d’état sait quel livre et quelle page, puis les modèles de livre et de page conservent le suivi de leurs états actuels de l’interface utilisateur.

Ne limitez pas vos applications Backbone aux constructions Backbone . Si vous trouvez que votre application a besoin d’une fonctionnalité qui ne rentre pas dans l’une des constructions de Backbone, ne la transformez pas en une seule pour conserver tout dans Backbone.

J’ai trouvé que ce modèle à colonne vertébrale était utile à cet égard. Il configure des modules pour vous et vous fournit un object d’application qui étend Backbone.Events (comme dans l’article précédemment lié). Cet object d’application peut être utilisé pour stocker des modèles, des vues et des contrôleurs / routeurs instanciés, et vous devriez être libre d’append vos propres modules non backbone à l’object application, pour prendre en charge les responsabilités qui ne correspondent pas parfaitement à l’un des objects. Construit en colonne vertébrale.