Currently, I'm delving into the world of NGXS
alongside the Emitters
plugin within Angular
, and I find myself struggling to grasp how to organize my state files effectively.
So far, I've managed to define a basic .state file in the following manner:
export type PageStatusCases = 'LOADING' | 'IDLE' | 'ERROR' | 'INITIALIZING';
export interface AppStateModel {
pageStatus: PageStatusCases;
}
@State<AppStateModel>({
name: 'AppState',
defaults: {
pageStatus: 'INITIALIZING'
}
})
export class AppState {
@Selector()
static pageStatus(state: AppStateModel): PageStatusCases {
return state.pageStatus;
}
@Receiver({type: '[Global] Page status'})
static setPageStatus({patchState}: StateContext<AppStateModel>, {payload}: EmitterAction<PageStatusCases>): void {
patchState({pageStatus: payload});
}
}
Now, I'm venturing into a more intricate example by transforming my Service
into a State
Within my service, there are numerous BehaviorSubject
s that monitor my UI's condition.
title: BehaviorSubject<string> = new BehaviorSubject('');
backClick$: EventEmitter<void> = new EventEmitter<void>();
primaryClick$: EventEmitter<void> = new EventEmitter<void>();
toolbarVisible$: BehaviorSubject<boolean> = new BehaviorSubject(true);
primaryVisible$: BehaviorSubject<boolean> = new BehaviorSubject(false);
primaryDisabled$: BehaviorSubject<boolean> = new BehaviorSubject(false);
primaryAutoDisabled$: BehaviorSubject<boolean> = new BehaviorSubject(false);
primaryIcon$: BehaviorSubject<ToolbarPrimaryIcon> = new BehaviorSubject(ToolbarPrimaryIcon.ADD);
I've initiated the process of converting these BehaviorSubject
s into components of the state. However, I've realized that it necessitates an extensive amount of boilerplate code.
For each BehaviorSubject
, I am obligated to:
- Incorporate it in the state's model
Interface
- Specify its default state in the
State
- Define its
@Selector
within the state structure - Determine its
@Receiver
(Action
) in the state - Add its
@Select
in every component requiring it - Integrate its
@Emitter
in every pertinent component for potential updates
The current scenario entails over 100 lines of code merely to manage 7 variables correctly, which indicates that I might be overlooking something crucial. The surplus visual clutter is also becoming a concern.
It's evident that an issue exists
I'm seeking insights on what fundamental element I might be disregarding and any alternative approaches for declaring states in such circumstances.
Recently, I adopted NGXS with the emitters
plug-in under the assumption that it would streamline the process and mitigate the necessity for excessive boilerplate code. Yet, the anticipated benefits seem elusive at present.