Lazy load feature modules, ngrx action trigged before reducer is initialize
up vote
0
down vote
favorite
I'm facing following problem. My action is fired before my reducer is initialised. For this reason my reducer don't pick up the action. How can I affect it that my reducer picks up actions when fired before my reducer has been initialised?
This image shows you the redux flow.
My action is dispatched from a ConfigurationEffect. And should be captured by different XFeature-reducers these reducers are feature based reducers
Code example:
app module
@NgModule({
declarations: [AppComponent],
imports: [
BrowserModule,
CommonModule,
AppRoutingModule,
HttpClientModule,
StoreModule.forFeature('config', fromConfig.reducer),
EffectsModule.forFeature([ConfigEffects]),
EffectsModule.forRoot([AppEffects]),
StoreModule.forRoot(reducers, { metaReducers }),
StoreDevtoolsModule.instrument({
maxAge: 10,
name: 'Debug DevTools',
logOnly: true,
actionSanitizer,
stateSanitizer,
}),
],
bootstrap: [AppComponent],
})
export class AppModule {}
config effects
@Effect()
loadConfigs$ = this.actions$.pipe(
ofType(configActions.ConfigActionTypes.LoadConfigs),
switchMap((action: configActions.LoadConfigs) =>
this.configService.loadConfig().pipe(
map((result: ConfigResponse) => new configActions.SaveConfigs(result)),
catchError((err: HttpErrorResponse) => of(new configActions.FailConfigs(err.message))),
),
),
);
xFeature reducer
export function reducer(state = initialState, action: XFeatureActions | ConfigActions): XFeatureState {
switch (action.type) {
// save configs, this will be called when the device is initially loaded.
case ConfigActionTypes.SaveConfigs:
...
})
angular ngrx ngrx-store
|
show 1 more comment
up vote
0
down vote
favorite
I'm facing following problem. My action is fired before my reducer is initialised. For this reason my reducer don't pick up the action. How can I affect it that my reducer picks up actions when fired before my reducer has been initialised?
This image shows you the redux flow.
My action is dispatched from a ConfigurationEffect. And should be captured by different XFeature-reducers these reducers are feature based reducers
Code example:
app module
@NgModule({
declarations: [AppComponent],
imports: [
BrowserModule,
CommonModule,
AppRoutingModule,
HttpClientModule,
StoreModule.forFeature('config', fromConfig.reducer),
EffectsModule.forFeature([ConfigEffects]),
EffectsModule.forRoot([AppEffects]),
StoreModule.forRoot(reducers, { metaReducers }),
StoreDevtoolsModule.instrument({
maxAge: 10,
name: 'Debug DevTools',
logOnly: true,
actionSanitizer,
stateSanitizer,
}),
],
bootstrap: [AppComponent],
})
export class AppModule {}
config effects
@Effect()
loadConfigs$ = this.actions$.pipe(
ofType(configActions.ConfigActionTypes.LoadConfigs),
switchMap((action: configActions.LoadConfigs) =>
this.configService.loadConfig().pipe(
map((result: ConfigResponse) => new configActions.SaveConfigs(result)),
catchError((err: HttpErrorResponse) => of(new configActions.FailConfigs(err.message))),
),
),
);
xFeature reducer
export function reducer(state = initialState, action: XFeatureActions | ConfigActions): XFeatureState {
switch (action.type) {
// save configs, this will be called when the device is initially loaded.
case ConfigActionTypes.SaveConfigs:
...
})
angular ngrx ngrx-store
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you haveAppModule
in which you register main reducers&effects using.forRoot(...)
. Then, you have your lazy loaded angular module, e.g.MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in yourAppModule
with the difference that now you use.forFeature(...)
instead of.forRoot(...)
. In short, remove.forFeature(...)
registrations from yourAppModule
and put them into your lazy loaded module.
– dee zg
Nov 8 at 9:10
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16
|
show 1 more comment
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I'm facing following problem. My action is fired before my reducer is initialised. For this reason my reducer don't pick up the action. How can I affect it that my reducer picks up actions when fired before my reducer has been initialised?
This image shows you the redux flow.
My action is dispatched from a ConfigurationEffect. And should be captured by different XFeature-reducers these reducers are feature based reducers
Code example:
app module
@NgModule({
declarations: [AppComponent],
imports: [
BrowserModule,
CommonModule,
AppRoutingModule,
HttpClientModule,
StoreModule.forFeature('config', fromConfig.reducer),
EffectsModule.forFeature([ConfigEffects]),
EffectsModule.forRoot([AppEffects]),
StoreModule.forRoot(reducers, { metaReducers }),
StoreDevtoolsModule.instrument({
maxAge: 10,
name: 'Debug DevTools',
logOnly: true,
actionSanitizer,
stateSanitizer,
}),
],
bootstrap: [AppComponent],
})
export class AppModule {}
config effects
@Effect()
loadConfigs$ = this.actions$.pipe(
ofType(configActions.ConfigActionTypes.LoadConfigs),
switchMap((action: configActions.LoadConfigs) =>
this.configService.loadConfig().pipe(
map((result: ConfigResponse) => new configActions.SaveConfigs(result)),
catchError((err: HttpErrorResponse) => of(new configActions.FailConfigs(err.message))),
),
),
);
xFeature reducer
export function reducer(state = initialState, action: XFeatureActions | ConfigActions): XFeatureState {
switch (action.type) {
// save configs, this will be called when the device is initially loaded.
case ConfigActionTypes.SaveConfigs:
...
})
angular ngrx ngrx-store
I'm facing following problem. My action is fired before my reducer is initialised. For this reason my reducer don't pick up the action. How can I affect it that my reducer picks up actions when fired before my reducer has been initialised?
This image shows you the redux flow.
My action is dispatched from a ConfigurationEffect. And should be captured by different XFeature-reducers these reducers are feature based reducers
Code example:
app module
@NgModule({
declarations: [AppComponent],
imports: [
BrowserModule,
CommonModule,
AppRoutingModule,
HttpClientModule,
StoreModule.forFeature('config', fromConfig.reducer),
EffectsModule.forFeature([ConfigEffects]),
EffectsModule.forRoot([AppEffects]),
StoreModule.forRoot(reducers, { metaReducers }),
StoreDevtoolsModule.instrument({
maxAge: 10,
name: 'Debug DevTools',
logOnly: true,
actionSanitizer,
stateSanitizer,
}),
],
bootstrap: [AppComponent],
})
export class AppModule {}
config effects
@Effect()
loadConfigs$ = this.actions$.pipe(
ofType(configActions.ConfigActionTypes.LoadConfigs),
switchMap((action: configActions.LoadConfigs) =>
this.configService.loadConfig().pipe(
map((result: ConfigResponse) => new configActions.SaveConfigs(result)),
catchError((err: HttpErrorResponse) => of(new configActions.FailConfigs(err.message))),
),
),
);
xFeature reducer
export function reducer(state = initialState, action: XFeatureActions | ConfigActions): XFeatureState {
switch (action.type) {
// save configs, this will be called when the device is initially loaded.
case ConfigActionTypes.SaveConfigs:
...
})
angular ngrx ngrx-store
angular ngrx ngrx-store
edited Nov 8 at 8:58
asked Nov 8 at 8:49
Bo Vandersteene
196212
196212
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you haveAppModule
in which you register main reducers&effects using.forRoot(...)
. Then, you have your lazy loaded angular module, e.g.MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in yourAppModule
with the difference that now you use.forFeature(...)
instead of.forRoot(...)
. In short, remove.forFeature(...)
registrations from yourAppModule
and put them into your lazy loaded module.
– dee zg
Nov 8 at 9:10
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16
|
show 1 more comment
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you haveAppModule
in which you register main reducers&effects using.forRoot(...)
. Then, you have your lazy loaded angular module, e.g.MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in yourAppModule
with the difference that now you use.forFeature(...)
instead of.forRoot(...)
. In short, remove.forFeature(...)
registrations from yourAppModule
and put them into your lazy loaded module.
– dee zg
Nov 8 at 9:10
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you have
AppModule
in which you register main reducers&effects using .forRoot(...)
. Then, you have your lazy loaded angular module, e.g. MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in your AppModule
with the difference that now you use .forFeature(...)
instead of .forRoot(...)
. In short, remove .forFeature(...)
registrations from your AppModule
and put them into your lazy loaded module.– dee zg
Nov 8 at 9:10
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you have
AppModule
in which you register main reducers&effects using .forRoot(...)
. Then, you have your lazy loaded angular module, e.g. MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in your AppModule
with the difference that now you use .forFeature(...)
instead of .forRoot(...)
. In short, remove .forFeature(...)
registrations from your AppModule
and put them into your lazy loaded module.– dee zg
Nov 8 at 9:10
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16
|
show 1 more comment
1 Answer
1
active
oldest
votes
up vote
1
down vote
I'm uncertain if this is what you're looking for but when a reducer is registered, NgRx dispatches a update-reducers
action. You can listen to these actions inside your effect in order to disaptch the SaveConfig
action.
Pre NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', feature: 'feature1'}
{type: '@ngrx/store/update-reducers', feature: 'feature2'}
Starting from NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', features: ['feature1',
'feature2']}
add a comment |
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
1
down vote
I'm uncertain if this is what you're looking for but when a reducer is registered, NgRx dispatches a update-reducers
action. You can listen to these actions inside your effect in order to disaptch the SaveConfig
action.
Pre NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', feature: 'feature1'}
{type: '@ngrx/store/update-reducers', feature: 'feature2'}
Starting from NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', features: ['feature1',
'feature2']}
add a comment |
up vote
1
down vote
I'm uncertain if this is what you're looking for but when a reducer is registered, NgRx dispatches a update-reducers
action. You can listen to these actions inside your effect in order to disaptch the SaveConfig
action.
Pre NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', feature: 'feature1'}
{type: '@ngrx/store/update-reducers', feature: 'feature2'}
Starting from NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', features: ['feature1',
'feature2']}
add a comment |
up vote
1
down vote
up vote
1
down vote
I'm uncertain if this is what you're looking for but when a reducer is registered, NgRx dispatches a update-reducers
action. You can listen to these actions inside your effect in order to disaptch the SaveConfig
action.
Pre NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', feature: 'feature1'}
{type: '@ngrx/store/update-reducers', feature: 'feature2'}
Starting from NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', features: ['feature1',
'feature2']}
I'm uncertain if this is what you're looking for but when a reducer is registered, NgRx dispatches a update-reducers
action. You can listen to these actions inside your effect in order to disaptch the SaveConfig
action.
Pre NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', feature: 'feature1'}
{type: '@ngrx/store/update-reducers', feature: 'feature2'}
Starting from NgRx 7 this looks as:
{type: '@ngrx/store/update-reducers', features: ['feature1',
'feature2']}
answered Nov 8 at 16:26
timdeschryver
1,889117
1,889117
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53204221%2flazy-load-feature-modules-ngrx-action-trigged-before-reducer-is-initialize%23new-answer', 'question_page');
}
);
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
you should provide a bit more details. most important, where is your action being dispatched from?
– dee zg
Nov 8 at 8:51
Improved with code example
– Bo Vandersteene
Nov 8 at 9:03
hm...that doesn't look like the whole picture. So, usual setup with lazy loaded store is: you have
AppModule
in which you register main reducers&effects using.forRoot(...)
. Then, you have your lazy loaded angular module, e.g.MyLazyModule
in which you register your lazy loaded ngrx reducers/effects the same way you do in yourAppModule
with the difference that now you use.forFeature(...)
instead of.forRoot(...)
. In short, remove.forFeature(...)
registrations from yourAppModule
and put them into your lazy loaded module.– dee zg
Nov 8 at 9:10
But then my other reducers are still loaded after the action has been send. The only way to affect a solution for now is to load all reducers on startup time, which I want to avoid. There should be like a replay action or something else
– Bo Vandersteene
Nov 8 at 9:15
which other reducers? i am sorry, i might be missing something, but i have hard time understanding your overall app structure. in particular, which angular modules you have and which corresponding ngrx module you have and then what actions (from which ngrx module) are fired where and cause problems. It would be beneficial if you could clarify that a bit.
– dee zg
Nov 8 at 9:16