Обновить

Рефакторинг выпадающих списков: от enum к конфигу-константе

Уровень сложностиСредний
Время на прочтение7 мин
Охват и читатели3.6K
Всего голосов 1: ↑1 и ↓0+3
Комментарии2

Комментарии 2

Мало! Надо ещё больше кода! Надо написать отдельный фреймворк для генерации классов выпадающих списков!

Энтропия всё растет и наша вселенная коллапсирует все быстрее.

В целом подход выглядит лучше, чем отдельные 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 и спросить "почему именно так", ну либо сформировать свои паттерны. Такой вот лайт-код-ревью, надеюсь будет полезным)

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации