В современном программировании, особенно при разработке масштабируемых приложений, одна из часто возникающих задач — это преобразование внутренних идентификаторов сущностей, таких как проекты, пользователи или ингредиенты, в удобочитаемые, локализованные и информативные наименования, которые понятны пользователям. Чаще всего в базе данных данные хранятся в виде числовых или уникальных ID, что значительно облегчает их обработку и индексирование, но не подходит для отображения в пользовательском интерфейсе. Именно здесь на помощь приходит универсальная система отображения ID в имена — id-source, которая работает как во фронтенде, так и в бэкенде, обеспечивая единый источник правды и удобства работы с данными. Для любого масштабного приложения критично обеспечить, чтобы пользователи могли легко ориентироваться в информации, видеть понятные названия, а не абстрактные числа. Система id-source берет на себя преобразование ID, локализацию, форматирование и оптимизацию загрузки данных.
Например, при загрузке страницы с проектом, где вместо ID 13 пользователю нужно показать "Пластмассы", фронтенд обращается к системе id-source, которая отвечает за корректное представление имени, учитывая язык пользователя, контекст и дополнительные метаданные. Это позволяет не только делать интерфейс понятным, но и повышает удобство поиска и выбора элементов. Архитектура id-source построена вокруг концепции разделения бизнес-логики и отображения данных. Во фронтенде разработан универсальный компонент DisplayId, который принимает ID и источник ID, сообщает системе, какую сущность и какое имя нужно получить. Этот компонент можно использовать для отображения имен в таблицах, выпадающих списках или ссылках на страницы сущностей.
За счёт гибкой абстракции можно интегрировать разные типы сущностей, используя стандартный API: тип сущности (например, entity/project) предаёт информацию о том, как именно нужно искать и отображать имя. Для более низкоуровневых задач, когда требуется получить одно или несколько имен по ID без непосредственного отображения, в системе предусмотрены React hook'и useSelectIdName и useSelectIdNames. Они асинхронно запрашивают данные у бэкенда и возвращают имена, обновляясь при необходимости, что идеально подходит для динамических интерфейсов и форм. При этом специально избегается показ нагрузки в виде спиннеров, чтобы не создавать визуальных дерганий и сохранить плавность работы. Одной из уникальных черт системы является использование структурированной загрузки на бэкенде — централизованного механизма загрузки данных с определёнными "важными полями", такими как id и name, общими для многих сущностей.
Это позволяет выполнить универсальные запросы, не создавая специально под каждый тип сущности большое количество кастомного кода. Такой подход экономит время и средства, а также обеспечивает согласованность данных. Важным аспектом являются также устаревшие и удалённые значения, часто встречающиеся при управлении жизненным циклом сущностей. В id-source система предусматривает архивирование вместо удаления, что сохраняет историческую целостность данных. Пользователи видят такие устаревшие объекты в режиме просмотра, но они исключаются из выборок для новых назначений.
Это достигается за счёт концепции фундаментальных и селективных фильтров: первые позволяют получить все объекты (включая архивные), вторые — только активные — для выбора в интерфейсе. Именно благодаря этому механизму возможно соблюдение бизнес-правил без потери доступа к исторической информации. Процесс взаимодействия фронтенда и бэкенда по API представлен двумя типами запросов. Первый — это запрос конкретного списка ID с целью получить их читабельные имена. При таком вызове бэкенд игнорирует селективные фильтры и возвращает данные, даже если объекты архивированы.
Второй тип — это поиск для отображения в выпадающих списках, где учитываются фильтры, чтобы не показывать устаревшие или запрещённые к выбору элементы. Такая стратегия повышает пользовательский опыт и предотвращает ошибки при выборах. Особое внимание уделено компонентам выбора (dropdown), так как они часто работают с очень большими списками объектов, порой превышающих сотни тысяч записей. Загрузка полного списка таких данных невозможна по причинам производительности и UX. В id-source система реализована прогрессивная загрузка с поиском: список подгружается порционно, а результаты фильтруются на сервере по введённым критериям.
Это решает проблему масштабирования и делает пользовательский интерфейс отзывчивым и удобным. В некоторых случаях стандартное имя у сущности отсутствует, например, запас на складе может не иметь собственного наименования, а использовать название связанного ингредиента или рецепта. Для решения подобных задач в системе используется гибкая система кастомных меток, позволяющая задавать компоненты имени в формате выражений. Механизм разбиения на колонки и комбинирования их с помощью выражений дает возможность создавать информативные и уникальные наименования, которые легко индексируются и ищутся. Это расширяет возможности поиска и отображения, позволяя адаптировать интерфейс под специфические требования бизнеса.
Пользовательский опыт и административный контроль усилены за счёт возможности настраивать отображение и поиск непосредственно через интерфейс. Администраторы могут выбирать какие колонки будут использоваться для отображения или поиска, менять формат и порядок полей в метках. Такая гибкость поддерживается встроенными в систему конфигурациями и позволяет пользователям настраивать работу с данными без необходимости программирования. Для повышения информативности интерфейсов в id-source предусмотрена поддержка дополнительных метаданных, таких как иконки, цветовые метки и статусы, например, "заблокировано", что отражается в виде символов рядом с именами. Это помогает пользователям быстро идентифицировать состояние объектов и улучшает визуальное восприятие информации.
