Comments 11
Мало! Надо ещё больше кода! Надо написать отдельный фреймворк для генерации классов выпадающих списков!
Энтропия всё растет и наша вселенная коллапсирует все быстрее.
В целом подход выглядит лучше, чем отдельные Enum, но не знаю, зачем вам понадобилось строго типизировать label. Если оставить его string (что в целом разумно - там может быть что угодно с учетом локализации и спецсимволов), то не придется обратно конвертировать в enum тип. Будет достаточно typeof enumConfig.Person.type[number]['value'] как string union, и в коде непосредственно писать строки вроде status: 'WORKING'. Типизация будет строгой, зато меньше нормализации и преобразований, когнитивной нагрузки в целом оберток.
Еще если вы уж выкладываете код на TypeScript, можно было бы побольше поработать над читаемостью. Сейчас читается сложно из-за разнородного нейминга - где-то сущность выносится вперед EnumConfig, где-то в середине UniqEnum, где-то есть явное определение что это тип с помощью суффикса PersonType. Дженерики в качестве динамических переменных тоже с разным неймингом: где-то однобуквенные T и K, где-то без префикса Seen, где-то с префиксом TValue.
TS-код это тоже код, и стабильные паттерны нейминга улучшают читаемость, как в js коде, где давно уже сложились best practice. В TS-коде они тоже есть - вот пример моего стиля, можно прогнать через LLM и спросить "почему именно так", ну либо сформировать свои паттерны. Такой вот лайт-код-ревью, надеюсь будет полезным)
Похожий путь прошли, только пришли к немного другому решению, const object с as const вместо enum, но тот же принцип. Главный выигрыш который вы правильно нащупали, это когда к значению нужно добавить метаданные (цвет, иконку, условие видимости), с enum это всегда костыль, а с конфигом просто ещё одно поле. Плюс Claude Code такой паттерн знает хорошо и генерирует аккуратно, в отличие от enum-хелперов которые каждый раз делает по-своему.
А я вообще всё свёл к enum, причём числовым с автонумерацией и Count в конце. Числовой EnumName в строку можно перевести через EnumName[], этот строковой ключ можно использовать в локализации, даже автоматически проверять, чтобы все ключи enum присутствовали в ней. И всё это с минимальной обвязкой TS-типов - пара однострочников.
Как-то (пере) усложненно…
У меня на бэке есть енам, который попадает в swagger spec, из него генерится енам на фронт + модель для выпадающего списка (кастомным плагином для @hey-api/openapi-ts) и фсиоо… Основная беда для меня не тут… Есть еще хранимые процедуры в бд, которые тоже бы хотелось программировать с удобствами - да, порой, там нужны те же енумы. Вот с этим сейчас и борюсь. Есть идеи, как сделать по красоте?
Рефакторинг выпадающих списков: от enum к конфигу-константе