Um cliente me abordou com o pedido de criar um diretório de usuários baseado em cartões.
Como ele está hospedado no discourse.org, inicialmente disse que isso não seria possível (além de quaisquer problemas de desempenho), pois os atributos necessários para preencher um cartão de usuário não estão disponíveis no objeto de usuário serializado junto aos itens do diretório.
No entanto, após discutir o assunto mais a fundo, concluí que uma abordagem seria fazer um PR no núcleo (core) que adicione atributos de usuário ao serializador de itens do diretório por meio de uma configuração do site. A ideia é que essa funcionalidade seja útil para vários estilos de diretório de usuários que exigem combinações variadas de atributos de usuário (exemplo abaixo).
Ao experimentar isso, desenvolvi uma abordagem relativamente simples, que você pode ver neste diff:
Criar um DirectoryItemUserSerializer dedicado (o atual “UserSerializer” dentro do DirectoryItemSerializer sempre me pareceu um pouco estranho).
Se o administrador do site tiver selecionado algum atributo de usuário para adicionar:
Criar um usuário serializado para aproveitar as proteções desse serializador, por exemplo, atributos de equipe / privados / não confiáveis.
Serializar quaisquer atributos adicionados que passem pelo filtro do UserSerializer.
Os objetivos aqui são:
Não afetar o comportamento existente de forma alguma.
Serializar apenas os atributos solicitados.
Se vocês estiverem de acordo com essa abordagem/solicitação, vou finalizar isso:
Adicionando uma validação na configuração do site (ou seja, para garantir que a string inserida seja um atributo de usuário).
Adicionando testes.
No entanto, achei melhor apresentar isso a vocês primeiro.
Exemplo
Como exemplo do tipo de funcionalidade que isso permitiria, a captura de tela abaixo do meu ambiente local, usando apenas essa alteração no núcleo + um componente de tema que substitui o diretório existente e utiliza um componente de cartão de usuário modificado:
Acho que @blake e @awesomerobot estão trabalhando com outro cliente com requisitos semelhantes. Estou meio aberto a uma configuração do site como temos always_include_topic_excerpts.
A ressalva é que gostaria que isso fosse testado e que a configuração do site ficasse oculta.
Sei que @david também tem se interessado pelo problema. Estou um pouco dividido aqui, mas talvez uma solução de longo prazo mais limpa seja:
Adicionar configurações de site ocultas para “permitir que plugins e temas optem por informações serializadas extras”, desativadas por padrão.
Em seguida, criar um protocolo em temas/plugins para “solicitar” as informações extras.
A vantagem aqui é que alguns temas terão as informações serializadas extras e outros não.
Gostaria de aguardar um pouco por David antes de dar o seu aval.
Que tal fazer o serializador do diretório de usuários aceitar um novo parâmetro como users.json?include_profile=true?
Assim, poderíamos adicionar uma API de plugin em JS que permita aos temas incluir esse parâmetro:
api.userListIncludeProfile(true)
O “perfil” incluiria tudo o que está no serializador de usuário regular (cuidando para não introduzir consultas n+1). Acredito que especificar campos individuais não fará muita diferença no desempenho, então, na minha opinião, devemos manter as coisas simples.
A mesma abordagem poderia funcionar para listas de tópicos também: ?include_excerpts=true.
Também gosto disso porque significa que a “configuração do serializador por tema” não será quebrada pelo cache anônimo!
Quase lá, mas isso não funciona corretamente, pois quando você acessa a página inicial do site ou o caminho u, não temos a liberdade de adicionar um parâmetro ao caminho; precisamos alterar os padrões
Nesse caso, acho que uma configuração oculta do site é um bom ponto de partida. Seria legal tornar isso por tema, mas precisamos construir uma infraestrutura para isso primeiro. Ainda acho que uma configuração booleana “lista de usuários inclui perfil” será mais fácil de lidar.
Legal. Avise-nos se vocês consideram isso um pr-welcome e em que formato, e ficaremos felizes em criar um. Do nosso lado, @fzngagan vai cuidar disso a partir daqui.
Uma coisa a esclarecer aqui é o protocolo para solicitar dados adicionais. Podemos confiar na configuração do site no frontend para solicitar os dados ou, como você sugeriu, adicionar outra API no plugin-api?
Vamos manter as coisas simples, ignore meu post sobre parâmetros e APIs JavaScript.
Se a configuração do site estiver habilitada no servidor, retorne as informações extras. Se estiver desabilitada, não retorne.
Por enquanto, os administradores precisarão habilitar a configuração manualmente. Podemos considerar permitir que temas alterem essa configuração automaticamente no futuro.
