У меня очень общий вопрос, но я не могу найти направление для хорошего решения, а не для Google, stackoverflow...
У меня есть несколько редукторов в моем приложении, отражающих мое государственное дерево. "Пользовательский" редуктор и редуктор "опроса" (создание приложения для опроса). Но теперь я хочу создать страницу профиля для пользователя. Ответы на все доступные поля не будут проходить в "пользовательский" магазин, но как насчет вариантов списка? Например, выбирая свой пол (m/f) или выбрав свое любимое прошедшее время... Как-то я чувствую, что эти параметры не должны находиться в магазине пользователя, или я ошибаюсь? Я чувствую, что для данного пользователя я хочу иметь состояние, которое говорит "gender: m", но в приложении я хочу показать "Male" вместо "m". Или я делаю большой шум из ничего, и должен ли я просто держать один большой список ключей/значений всех этих ярлыков/ценностей, доступ к ним таким образом?
Если они простые атрибуты, такие как пол, я согласен с @kujira, что вы можете сделать базовые ценности независимо от того, что вы хотите (например, m
для мужчин), а затем отобразить их другим способом в своем JSX, если это действительно то, что вы хотите сделать.
Что касается того, должны ли пользовательские атрибуты попадать внутрь редуктора Users
, ответ, вероятно, да. Просто потому, что модель может иметь много атрибутов, это не значит, что вам нужно создать другой редуктор. Как правило, вы хотите, чтобы ваше состояние редукции нормализовалось как можно больше. В нормализации говорится, что ассоциации "один-к-одному" входят в одну и ту же таблицу (или в этом случае состояние редуктора).
Единственный случай, когда у вас может быть другой редуктор, - это когда у вас по существу есть отдельная модель, а две связаны друг с другом в отношениях "один ко многим" или "многие ко многим". Если это отношение "один к одному", или вы просто хотите ограничить атрибут определенными значениями, тогда правила нормализации говорят, что они сохраняют его в одной и той же модели.
Если вы беспокоитесь о том, как принуждать к ограничению, вы можете добавить чек в свой редуктор, который взрывает ваше приложение, если для gender
передается значение, отличное от m
или f
, но такого рода практика чрезмерно защитного программирования. Если вы действительно чувствуете, что вам нужно идти по этому маршруту, можно рассмотреть вопрос об аннотации потока Facebook.
<option value="m">Male</option>
не подойдет?