IS
и харкод на фронте - приемлемо, типа?
Size: a a a
2021 June 08
IS
вы такого не утверждали, я уточняю
Д
По сути нет, но, от ситуации. Слишком примитивные я бы продублировал, лишний запрос к api, лишнее подмешивание к сущностям со стороны сервера, лишние байты одних и тех же данных
Д
Пример status
0 - temp
1 - enabled
2 - disabled
4 - deleted
Такое я точно продублирую, это enum
0 - temp
1 - enabled
2 - disabled
4 - deleted
Такое я точно продублирую, это enum
IS
звучит как мысль о жёстком хайлоаде, вряд ли этот тот кейс
кроме того, об оптимизациях на пару байт я бы явно не стал превентивно задумываться
кроме того, об оптимизациях на пару байт я бы явно не стал превентивно задумываться
Д
Пример статуса:
{
id: String,
text: String,
color: String
}Д
Это я подмешаю
IS
надо почитать что-то про хайлоад, хотя сомневаюсь, что такие данные знания в вакууме имеют какой-либо смысл
Д
Там байт, там ms, глядишь а у тебя уже секунда
Д
join еще добавит
Д
создание json с подмешиванием тоже
Д
И в каком нибудь сложном проекте получаешь, особенно под нагрузкой где каждая ms дорога
Д
15 лет назад так и делал
Д
Заводил базу status, пихал 5 строчек
Д
А ради чего не понятно
Д
Цвета так же хранил у статусов
IS
ну окей, а насчёт дублей - тот же SSOT выкинуть просто?
IS
не к тому сообщению ответил, не суть
Д
Но если это были бы теги как в github, где пользователи создают свои, то тут понятно, таблица.
Д
Это не должно быть идеальной парадигмой. Их в разработке нет