У меня есть вопрос, касающийся NGXS Store и использования запомненных @Selector()
s в иерархии классов состояний.
Каков будет рекомендуемый подход к проблеме, описанной ниже?
Документация NGXS Store не содержит руководящих указаний / рекомендаций на этот счет.
С учетом этого примера настройки состояния,
export interface BaseModel { data: string[]; }
// base class not a state!
export class BaseState {
@Selector()
static dataSelect(state: BaseModel) { return state.data; }
// ...
}
export interface DerivedModel extends BaseModel {}
@State<DerivedModel>({ name: 'derived'; })
export class DerivedState extends BaseState {
// ...
}
export interface UsingModel { thing: number; }
@State<UsingModel>({ name: 'using'; })
export class UsingState implements NgxsOnInit {
constructor(private _store: Store) {}
ngxsOnInit(ctx: StateContext<UsingModel>) {
// have this state update when derived state changes
this._store.select(DerivedState.dataSelect).subscribe(data => console.log(data));
}
// ...
}
При запуске этого фрагмента кода он выведет undefined
, поскольку аргумент state
dataSelect(...)
метод не будет установлен.
Я отследил причину того, что BaseState
не является состоянием NGXS и поэтому отсутствует внутренний NGXS_META
свойство, которое в свою очередь вызывает аргумент undefined
.
Добавление BaseState
к селектору (например, @Selector([BaseState])
) для принудительного сохранения состояния
Включенный также не имеет желаемого эффекта, потому что теперь NGXS не может перейти к соответствующему срезу состояния.
Я нашел два способа сделать эту работу по желанию:
1. Дублируйте метод @Selector(...)
в каждой реализации производного состояния. Это, однако, опровергает причины, по которым иерархия классов состояний была изначально разработана
2. использовать что-то вроде @DerivedSelector(...)
, которое работает в соответствии со стандартным декоратором, но динамически создает селекторы для использования для каждого из обнаруженных производных классов состояний.
Спасибо.