Un cliente se acercó a mí con la solicitud de crear un directorio de usuarios basado en tarjetas.
Dado que está alojado en discourse.org, inicialmente dije que esto no sería posible (independientemente de cualquier problema de rendimiento), ya que los atributos necesarios para rellenar una tarjeta de usuario no están disponibles en el objeto de usuario serializado con los elementos del directorio.
Sin embargo, tras discutirlo más a fondo, determiné que un enfoque podría ser realizar una PR en el núcleo que añada atributos de usuario al serializador de elementos del directorio mediante una configuración del sitio. La idea es que esta funcionalidad será útil para varios estilos de directorio de usuarios que requieren diversas combinaciones de atributos de usuario (ejemplo a continuación).
Experimentando con esto, he llegado a un enfoque relativamente simple, que puedes ver en este diff:
Crear un DirectoryItemUserSerializer dedicado (el actual “UserSerializer” dentro del DirectoryItemSerializer siempre me ha parecido un poco extraño).
Si el administrador del sitio ha seleccionado algún atributo de usuario para añadir:
Crear un usuario serializado para aprovechar las protecciones de ese serializador, por ejemplo, atributos de personal / privados / no confiables.
Serializar cualquier atributo añadido que pase el filtro de UserSerializer.
Los objetivos aquí son:
No afectar en absoluto al comportamiento existente.
Serializar solo los atributos solicitados.
Si ustedes están de acuerdo con este enfoque/solicitud, lo terminaré:
Añadiendo una validación en la configuración del sitio (es decir, para asegurar que la cadena introducida sea un atributo de usuario).
Añadiendo pruebas.
Sin embargo, pensé que era mejor consultarlo primero con ustedes.
Ejemplo
Como ejemplo del tipo de funcionalidad que esto permitiría, la captura de pantalla a continuación de mi entorno local usando solo este cambio en el núcleo + un componente de tema que sobrescribe el directorio existente y utiliza un componente de tarjeta de usuario modificado:
Creo que @blake y @awesomerobot están trabajando con otro cliente con requisitos similares. Estoy bastante abierto a una configuración del sitio como la que tenemos en always_include_topic_excerpts.
La salvedad es que me gustaría que esto se pruebe y que la configuración del sitio esté oculta.
Sé que a @david también le ha interesado el problema. Estoy un poco dividido, pero quizás una solución a más largo plazo y más limpia sería:
Agregar configuraciones de sitio ocultas para “permitir que plugins y temas opten por información serializada adicional”, desactivadas por defecto.
Luego, establecer un protocolo en temas/plugins para “solicitar” la información adicional.
La ventaja aquí es que algunos temas tendrán la información serializada adicional y otros no.
Me gustaría esperar un poco a David antes de darte luz verde.
¿Qué te parece si el serializador del directorio de usuarios acepta un nuevo parámetro como users.json?include_profile=true?
Así podríamos añadir una API de plugins en JS que permita a los temas incluir este parámetro:
api.userListIncludeProfile(true)
“Profile” incluiría todo lo que contiene el serializador normal de usuarios (teniendo cuidado de no introducir consultas n+1). No creo que especificar campos individuales marque mucha diferencia en el rendimiento, así que, en mi opinión, deberíamos mantenerlo simple.
El mismo enfoque podría funcionar para las listas de temas, por ejemplo ?include_excerpts=true.
También me gusta porque significa que la “configuración del serializador por tema” no se verá afectada por la caché anónima.
Casi, pero esto no funciona correctamente porque cuando vas a la página de inicio del sitio o a la ruta /u, no tienes la opción de agregar un parámetro a la ruta; necesitamos cambiar los valores predeterminados
En ese caso, creo que una configuración de sitio oculta es un buen punto de partida. Sería agradable hacerlo por tema, pero primero necesitamos construir cierta infraestructura allí. Todavía creo que una configuración booleana de “la lista de usuarios incluye el perfil” será más fácil de entender.
Genial. Avísennos si consideran que esto es un pr-welcome y en qué formato, y estaremos encantados de crearlo. Por nuestra parte, @fzngagan se encargará de esto a partir de ahora.
Una cosa que hay que aclarar aquí es el protocolo para solicitar datos adicionales. ¿Podemos confiar en la configuración del sitio en el frontend para solicitar los datos o, como sugeriste, añadir otra API en plugin-api?
Mantengámoslo simple, ignora mi publicación sobre parámetros y APIs de JavaScript.
Si la configuración del sitio está habilitada en el servidor, devuelve la información adicional. Si está deshabilitada, no lo hagas.
Por ahora, los administradores tendrán que habilitar la configuración manualmente. En el futuro, podríamos considerar permitir que los temas activen o desactiven esta configuración automáticamente.
