Backbone: Donnez à model.set une option d'analyse

Je m'en remettrais à faisabilité de cela, mais je pense qu'il est certainement raisonnable d'avoir une parité API entre les modèles et l'analyse des collections. Merci d'avoir ouvert un problème @etler !

La mise en œuvre devrait être assez simple. Je pense que la question principale est de savoir s'il y a une raison de ne pas le faire ? De plus, que se passerait-il lorsqu'une clé val était fournie au lieu d'un objet attribut ?

Cela semble bien, mais le cas qui causera un problème au sommet de ma tête est parse avec defaults ( notez l'ordre des événements ici ). J'aimerais voir un PR avec vos réflexions sur la mise en œuvre.

Super, j'aimerais bien m'y essayer.

J'allais en fait ouvrir un ticket pour cela aussi - mais je suis ensuite tombé sur # 2013... bien que je suppose que c'était avant qu'il y ait un Collection#set .

Je suis d'accord avec @wookiehangover que la parité API serait bien d'avoir, et j'ai rencontré des cas où il est logique d'utiliser l'analyse pour gérer les données imbriquées (je viens d'utiliser model.set(model.parse(data)) comme mentionné dans le autre billet).

@tgriesser Je ne sais pas comment j'ai raté ce problème ! Je suis d'accord avec cette discussion pour ce cas d'utilisation, mais je pense qu'un cas d'utilisation plus convaincant est l'analyse des données bootstrap (ainsi que l'analyse imbriquée, ce que je fais également). J'ai également utilisé la même solution de contournement, mais comme vous l'avez dit, maintenant qu'il y a un Collection#set , il y a maintenant aussi un argument de parité.

Quel est le cas d'utilisation réel pour avoir besoin de cela?

Si vous souhaitez appeler set sur un modèle existant dans lequel l'objet contient des données imbriquées que vous extrairez du modèle dans parse . J'ai voulu cette fonctionnalité à plusieurs reprises.

class Book extends Models.Document
   constructor: ->
      <strong i="8">@info</strong> = new InfoModel()
      <strong i="9">@chapters</strong> = new ChaptersCollection()
      super

   parse: (attrs, options) ->
      @info.set(attrs.info, options)
      @chapters.set(attrs.chapters, options)
      _.omit(attrs, 'info', 'chapters')

Maintenant, vous pouvez faire ceci :

book.set({
  title: 'title',
  info: {
    some: data
    someNested: {
        otherData: ...
    }
  },
  chapters: [{...}, {...}]
}, {parse: true});

et cela devrait fonctionner... (oui, model.set(model.parse( fonctionne, mais il est plus simple d'avoir la même API pour analyser les données imbriquées dans les collections et les modèles)... bien qu'avec le problème #2623 cela ne fonctionne que jusqu'à présent vers le bas.

Quelqu'un a-t-il une idée de la façon dont ce changement fonctionnerait avec les valeurs par défaut ? Et sans double analyse ?

Pour le faire fonctionner avec les valeurs par défaut, j'ai créé un options.defaults , attribué dans la fonction d'initialisation pour passer à set , afin qu'ils puissent être appliqués après l'étape d'analyse. Je ne sais pas si c'est une décision de conception que nous voudrions, mais je n'ai pas pu penser à une solution alternative.

Déplaçons cette conversation sur les relations publiques ouvertes...

Y a-t-il une mise à jour à ce sujet ?

J'utilise actuellement model.set(model.parse(data)) car l'option d'analyse est manquante. Ce serait vraiment bien d'avoir pour cohérence avec collection.reset etc.