Один из подходов к этому - рассматривать каждое хранилище как таблицу базы данных, а каждое новое состояние, которое вы записываете как новую запись / строку в таблице. Нормализуя ваши модели, вы можете иметь магазин плеера и дневной магазин. Если вам нужна вся история дней и состояний игроков за определенный день, вы можете постоянно вставлять новые состояния, а не обновлять текущие состояния. Игрокам может понадобиться атрибут для указания времени данного состояния (например, внешний ключ, указывающий на ассоциированное состояние дня).
Могут быть записаны селекторы для выбора текущего состояния или поиска данного состояния в течение заданного времени. в истории игры, если это требование бизнеса. В документации ngxs по селекторам упоминается объединение несвязанных состояний с мета-селекторами . Вы можете рассмотреть возможность использования этих селекторов, чтобы объединить соответствующего игрока и состояние дня для заданной потребности поиска.
Редактировать 1: Нормализация данных и сохранение снимков решает двойные проблемы, о которых вы упоминали иметь полную историю игр и поддерживать больше состояний управления.
По конкретному c вопросу о поддержании разных состояний без циклической зависимости следует избегать импорта двух файлов друг в друга. Два способа справиться с этой задачей:
Подумайте, где вам нужно объединить состояния - выберите один в качестве основы для основного бизнес-объекта - и импортируйте файлы только одним способом в это состояние.
Если ни одно из состояний не является основанием для основного бизнес-объекта, введите третье состояние, которое выполняет эту роль, и импортируйте в него другие состояния.
Затем используйте мета-селектор, предоставленный NGXS, и присоединитесь к соответствующим состояниям там.
например.
export class DaysState{
@Selector([DaysState, PlayersState])
static getGameState(days, players) {
return [...days, ...players];
}
}