Como lidar melhor com padrões de campos personalizados e logs de configuração de categoria

Dev
1

Algum contexto

O motivo pelo qual isso ocorre é porque

  1. O plugin activity pub define alguns padrões para esses campos no cliente (aqui).

  2. Todas as alterações de campo personalizado de categoria são registradas como alterações de configuração de categoria no core (aqui).

“1” (definir padrões de campo personalizado de categoria no cliente) parece ser a melhor maneira de trabalhar com o pipeline de campo personalizado de categoria no momento, pois a ação de categoria update os salvará automaticamente, e você deseja garantir que os padrões sejam definidos se os campos personalizados forem interdependentes (como são no plugin AP).

Observe que atualmente não é possível para um plugin serializar seletivamente campos personalizados para o servidor (sem monkey patching).

Dado o exposto, estou me perguntando se “2” faz sentido? Como David aponta, dada a configuração atual do pipeline, uma alteração em um campo personalizado não indica necessariamente uma alteração na configuração de configurações da categoria (ou seja, ir de nil para o padrão).

Estou curioso para ouvir as opiniões de outros sobre isso. Talvez eu esteja perdendo uma maneira melhor de lidar com os padrões de campo personalizado de categoria.

3 curtidas
2

@david Apenas trazendo isso de volta para o topo da sua lista. Qual é o seu instinto sobre isso? Se você acha que uma mudança em como o campo personalizado de categoria pode ser necessária no núcleo, posso tentar isso. Ou talvez eu veja se consigo encontrar uma nova maneira de definir padrões para campos personalizados. Ou talvez deixemos para lá por enquanto?

3

Sim, isso é complicado. Suponho que a maioria dos plugins não encontre isso porque o ‘padrão’ para a configuração de categoria deles é um valor nulo.

Você teve alguma ideia para uma alteração na API principal que pudesse ajudar a melhorar a situação?

Totalmente sem testes, mas acho que poderíamos conseguir algo agora usando um campo de entrada HTML bruto (note input minúsculo em vez do componente \u003cInput com ligação bidirecional do Ember).

<input
  value={{or category.custom_fields.my_field "valor padrão"}}
  {{on "change" this.updateMyFieldValue}}
/>

Com essa estratégia, temos controle sobre como os valores são lidos/escritos na instância do modelo. Portanto, se um valor for definido como o padrão na interface do usuário, podemos gravá-lo como ‘nulo’ nos campos personalizados:

@action
updateMyFieldValue(event){
  let newValue = event.target.value;
  if(newValue === "valor padrão"){
    newValue = null;
  }

  this.category.set("custom_fields.my_field", newValue);
}

(e então você removeria a configuração de valor padrão que descreveu em (1) do OP)

1 curtida