Ко мне обратился клиент с просьбой создать каталог пользователей в виде карточек.
Поскольку он размещён на discourse.org, я изначально заявил, что это невозможно (не считая любых проблем с производительностью), так как атрибуты, необходимые для заполнения карточки пользователя, отсутствуют в объекте пользователя, сериализуемом вместе с элементами каталога.
Однако после дальнейшего обсуждения я пришёл к выводу, что один из подходов может заключаться в создании PR в основную ветку, который добавит атрибуты пользователя в сериализатор элементов каталога через настройку сайта. Идея состоит в том, что этот функционал будет полезен для различных стилей каталогов пользователей, требующих разных комбинаций атрибутов пользователя (пример ниже).
В ходе экспериментов я разработал относительно простой подход, который вы можете увидеть в этом diff:
Создать отдельный DirectoryItemUserSerializer (текущий «UserSerializer» внутри DirectoryItemSerializer всегда казался мне немного странным).
Если администратор сайта выбрал какие-либо атрибуты пользователя для добавления:
Создать сериализованного пользователя, чтобы воспользоваться защитными механизмами этого сериализатора, например, для атрибутов персонала, приватных или ненадёжных.
Сериализовать все добавленные атрибуты, которые проходят фильтрацию UserSerializer.
Цели здесь следующие:
Не изменять существующее поведение ни в каком виде.
Сериализовать только запрошенные атрибуты.
Если вы поддерживаете этот подход/запрос, я завершу работу следующим образом:
Добавлю валидацию для настройки сайта (то есть, чтобы убедиться, что введённая строка является атрибутом пользователя).
Добавлю тесты.
Однако я решил сначала обсудить это с вами.
Пример
В качестве примера того, какой функционал это позволит реализовать, ниже приведён скриншот с моего локального окружения, где используется только это изменение в ядре + компонент темы, который переопределяет существующий каталог и использует модифицированный компонент карточки пользователя:
Я думаю, что @blake и @awesomerobot работают с другим клиентом с похожими требованиями. Я в целом открыт к идее настройки сайта, подобной always_include_topic_excerpts.
Оговорка: я хотел бы, чтобы это было протестировано, и чтобы настройка сайта была скрытой.
Я знаю, что @david также проявлял интерес к этой проблеме. Я немного колеблюсь, но, возможно, более чистым долгосрочным решением будет:
Добавить скрытые настройки сайта для «разрешения плагинам и темам запрашивать дополнительную сериализованную информацию» (по умолчанию выключено).
Затем реализовать протокол в темах/плагинах для «запроса» этой дополнительной информации.
Преимущество здесь в том, что некоторые темы будут иметь дополнительную сериализованную информацию, а некоторые — нет.
Я хотел бы немного подождать с Дэвидом, прежде чем дать вам зеленый свет.
Как насчет того, чтобы заставить сериализатор каталога пользователей принимать новый параметр, например users.json?include_profile=true?
Тогда мы сможем добавить API для JS-плагинов, которое позволит темам добавлять этот параметр:
api.userListIncludeProfile(true)
«Профиль» будет включать все данные из обычного сериализатора пользователей (будучи осторожным, чтобы не вызвать запросы N+1). Я не думаю, что указание отдельных полей существенно повлияет на производительность, поэтому, на мой взгляд, стоит оставить всё простым.
Такой же подход можно применить и к спискам тем: ?include_excerpts=true.
Мне также нравится это решение, потому что оно означает, что «конфигурация сериализатора для каждой темы» не будет нарушена анонимным кэшем!
Почти, но это работает некорректно, потому что при переходе на главную страницу сайта или по пути u у вас нет возможности добавить параметр в путь — нам нужно изменить значения по умолчанию
В таком случае, я думаю, что скрытая настройка сайта — хорошее начало. Было бы здорово сделать её зависимой от темы, но сначала нужно построить соответствующую инфраструктуру. Я всё ещё считаю, что булевая настройка «список пользователей включает профиль» будет проще для понимания.
Один момент, который нужно прояснить, — это protocol для запроса дополнительных данных. Можем ли мы полагаться на настройку сайта на фронтенде для запроса данных или, как вы предложили, добавить еще один API в plugin-api?
Давайте упростим задачу: проигнорируйте мой пост о параметрах и JavaScript API.
Если настройка сайта включена на сервере, возвращайте дополнительную информацию. Если она отключена — не возвращайте.
На данный момент администраторам придётся включать эту настройку вручную. В будущем мы, возможно, рассмотрим возможность автоматического переключения этой настройки темами.
