Backbone: Dar model.set una opción de análisis

Creado en 21 jun. 2013  ·  13Comentarios  ·  Fuente: jashkenas/backbone

La contraparte de colección de set le permite proporcionar una opción de "análisis" para ejecutar la función del analizador antes de procesar el objeto de colección. Esto es útil cuando tiene datos de arranque de los que desea construir una colección, ya que no pasarán por la función de recuperación.

¿Hay alguna razón por la que el objeto modelo no ofrece la misma opción para la recopilación en paralelo? Me parece incoherente que se omita.

Editar: Tras una inspección más detallada, el restablecimiento aún respeta la opción de análisis.

duplicate

Comentario más útil

De hecho, estoy usando model.set (model.parse (data)) en este momento, ya que falta la opción de análisis. Sería muy bueno tenerlo por coherencia con collection.reset, etc.

Todos 13 comentarios

Me referiría a viabilidad de esto, pero creo que es ciertamente razonable tener paridad API entre modelos y análisis de colecciones. ¡Gracias por abrir un número @etler!

La implementación debería ser bastante sencilla. Creo que la pregunta principal es si hay alguna razón para no hacerlo. Además, ¿qué pasaría cuando se proporciona una clave val en lugar de un objeto de atributo?

Esto suena bien, pero el caso que me causará un problema en la parte superior de mi cabeza es parse con defaults ( observe el orden de los eventos aquí ). Me encantaría ver a un PR con sus pensamientos de implementación.

Genial, me encantaría intentarlo.

De hecho, también iba a abrir un boleto para esto, pero luego encontré el # 2013 ... aunque supongo que fue antes de que hubiera un Collection#set .

Estoy de acuerdo con @wookiehangover en que sería bueno tener la paridad de API, y me he encontrado con casos en los que tiene sentido usar parse para manejar datos anidados (acabo de usar model.set(model.parse(data)) como se menciona en el otro boleto).

@tgriesser ¡No sé cómo me perdí ese número! Estoy de acuerdo con esa discusión para ese caso de uso, pero creo que un caso de uso más convincente es el de analizar datos de arranque (así como el análisis anidado, que también estoy haciendo). También he estado usando la misma solución alternativa, pero como dijiste, ahora que hay un Collection#set , ahora también hay un argumento de paridad.

¿Cuál es el caso de uso real para necesitar esto?

Si desea llamar a set en un modelo existente a donde el objeto tiene datos anidados, estaría extrayendo del modelo en parse . He querido esta funcionalidad en varias ocasiones.

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')

Ahora puedes hacer esto:

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

y debería funcionar ... (sí, model.set(model.parse( funciona, pero es más sencillo tener la misma api para analizar datos anidados en colecciones y modelos) ... aunque con el problema de # 2623 solo funciona hasta ahora abajo.

¿Alguien ha pensado en cómo funcionaría este cambio con los valores predeterminados? ¿Y sin doble análisis?

Para que funcione con los valores predeterminados, creé un options.defaults , asignado en la función de inicialización para pasar a set , para que pudieran aplicarse después del paso de análisis. No sé si esa es una decisión de diseño que nos gustaría, pero no pude pensar en una solución alternativa.

Pasemos esta conversación al PR abierto ...

¿Hay alguna actualización sobre esto?

De hecho, estoy usando model.set (model.parse (data)) en este momento, ya que falta la opción de análisis. Sería muy bueno tenerlo por coherencia con collection.reset, etc.

¿Fue útil esta página
0 / 5 - 0 calificaciones