A contraparte de coleção de set permite que você forneça uma opção de "análise" para executar a função do analisador antes de processar o objeto de coleção. Isso é útil quando você tem dados de bootstrap a partir dos quais deseja construir uma coleção, pois eles não passarão pela função de busca.
Existe uma razão para o objeto de modelo não fornecer a mesma opção para coleção paralela? Parece-me inconsistente que seja omitido.
Editar: Após uma inspeção mais aprofundada, a redefinição ainda respeita a opção de análise.
Eu recomendaria @caseywebdev sobre a capacidade de fazer isso, mas acho que é certamente razoável ter paridade de API entre modelos e análise de coleções. Obrigado por abrir um problema @etler!
A implementação deve ser bastante simples. Acho que a principal questão é se há alguma razão para não o fazer. Além disso, o que aconteceria quando uma chave val fosse fornecida em vez de um objeto de atributo?
Isso parece bom, mas o caso que causará um problema no topo da minha cabeça é parse
com defaults
( observe a ordem dos eventos aqui ). Eu adoraria ver um PR com suas idéias de implementação.
Ótimo, adoraria tentar.
Na verdade, eu ia abrir um tíquete para isso também - mas então me deparei com o # 2013 ... embora eu presuma que foi antes que houvesse Collection#set
.
Concordo com @wookiehangover que seria bom ter paridade de API, e encontrei casos em que faz sentido usar a análise para lidar com dados aninhados (acabo de usar model.set(model.parse(data))
conforme mencionado no outro ingresso).
@tgriesser Não sei como não percebi esse problema! Eu concordo com essa discussão para esse caso de uso, mas acho que um caso de uso mais atraente é para analisar dados inicializados (bem como análise aninhada, o que também estou fazendo). Também tenho usado a mesma solução alternativa, mas, como você disse, agora que existe um Collection#set
, também existe um argumento de paridade.
Qual é o caso de uso real para precisar disso?
Se você deseja chamar set
em um modelo existente onde o objeto tem dados aninhados que você estaria puxando do modelo em parse
. Eu quis essa funcionalidade em várias ocasiões.
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')
Agora você pode fazer isso:
book.set({
title: 'title',
info: {
some: data
someNested: {
otherData: ...
}
},
chapters: [{...}, {...}]
}, {parse: true});
e deve funcionar ... (sim, model.set(model.parse(
funciona, mas é mais simples ter a mesma API para analisar dados aninhados em coleções e modelos) ... embora com o problema de # 2623 isso só funcione até agora baixa.
Alguém pensou em como essa mudança funcionaria com os padrões? E sem dupla análise?
Para fazê-lo funcionar com os padrões, criei um options.defaults
, atribuído na função de inicialização para passar para set
, para que eles pudessem ser aplicados após a etapa de análise. Não sei se essa é uma decisão de design que gostaríamos, mas não consegui pensar em uma solução alternativa.
Vamos passar esta conversa para o PR aberto ...
Existe alguma atualização sobre isso?
Na verdade, estou usando model.set (model.parse (data)) agora, pois a opção de análise está faltando. Seria muito bom ter consistência com collection.reset etc.
Comentários muito úteis
Na verdade, estou usando model.set (model.parse (data)) agora, pois a opção de análise está faltando. Seria muito bom ter consistência com collection.reset etc.