APP_INITIALIZER undefined results after page reload
up vote
0
down vote
favorite
I have a simple config service that I've wired with APP_INITIALIZER token in my app.shared.module.ts:
ConfigService,
provide: APP_INITIALIZER,
useFactory: (configService: ConfigService) =>
() => configService.getStuff(),
deps: [ConfigService],
multi: true
,
This executes the subscription (config.service.ts):
settings: any;
getStuff()
this.getSettings()
.subscribe(data =>
this.settings = data);
);
getSettings(): Observable<ISettings>
return (this.httpClient
.get<ISettings>(this.localbaseUrl)
.pipe(
catchError(this.errorHandlerSerevice.handleError)
)) as any;
Then I inject this service into other services (through their constructors - which I don't like) and everything works fine on the app start:
constructor()
this.settings = this.configService.settings;
Its fine when I go to the home page and refresh the app from there.
The logic is called and data returned.
However when I refresh a particular page that uses the component and calls the constructor it seems to late for the data to arrive back, hence I get undefined returned here:
this.settings = this.configService.settings;
I guess the 'wire up' is wrong...
Any suggestions how to tackle it?
angular typescript
add a comment |
up vote
0
down vote
favorite
I have a simple config service that I've wired with APP_INITIALIZER token in my app.shared.module.ts:
ConfigService,
provide: APP_INITIALIZER,
useFactory: (configService: ConfigService) =>
() => configService.getStuff(),
deps: [ConfigService],
multi: true
,
This executes the subscription (config.service.ts):
settings: any;
getStuff()
this.getSettings()
.subscribe(data =>
this.settings = data);
);
getSettings(): Observable<ISettings>
return (this.httpClient
.get<ISettings>(this.localbaseUrl)
.pipe(
catchError(this.errorHandlerSerevice.handleError)
)) as any;
Then I inject this service into other services (through their constructors - which I don't like) and everything works fine on the app start:
constructor()
this.settings = this.configService.settings;
Its fine when I go to the home page and refresh the app from there.
The logic is called and data returned.
However when I refresh a particular page that uses the component and calls the constructor it seems to late for the data to arrive back, hence I get undefined returned here:
this.settings = this.configService.settings;
I guess the 'wire up' is wrong...
Any suggestions how to tackle it?
angular typescript
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's<base href>per environment. make sure you're not implementing that for nothing.
– Stavm
Nov 9 at 13:34
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54
add a comment |
up vote
0
down vote
favorite
up vote
0
down vote
favorite
I have a simple config service that I've wired with APP_INITIALIZER token in my app.shared.module.ts:
ConfigService,
provide: APP_INITIALIZER,
useFactory: (configService: ConfigService) =>
() => configService.getStuff(),
deps: [ConfigService],
multi: true
,
This executes the subscription (config.service.ts):
settings: any;
getStuff()
this.getSettings()
.subscribe(data =>
this.settings = data);
);
getSettings(): Observable<ISettings>
return (this.httpClient
.get<ISettings>(this.localbaseUrl)
.pipe(
catchError(this.errorHandlerSerevice.handleError)
)) as any;
Then I inject this service into other services (through their constructors - which I don't like) and everything works fine on the app start:
constructor()
this.settings = this.configService.settings;
Its fine when I go to the home page and refresh the app from there.
The logic is called and data returned.
However when I refresh a particular page that uses the component and calls the constructor it seems to late for the data to arrive back, hence I get undefined returned here:
this.settings = this.configService.settings;
I guess the 'wire up' is wrong...
Any suggestions how to tackle it?
angular typescript
I have a simple config service that I've wired with APP_INITIALIZER token in my app.shared.module.ts:
ConfigService,
provide: APP_INITIALIZER,
useFactory: (configService: ConfigService) =>
() => configService.getStuff(),
deps: [ConfigService],
multi: true
,
This executes the subscription (config.service.ts):
settings: any;
getStuff()
this.getSettings()
.subscribe(data =>
this.settings = data);
);
getSettings(): Observable<ISettings>
return (this.httpClient
.get<ISettings>(this.localbaseUrl)
.pipe(
catchError(this.errorHandlerSerevice.handleError)
)) as any;
Then I inject this service into other services (through their constructors - which I don't like) and everything works fine on the app start:
constructor()
this.settings = this.configService.settings;
Its fine when I go to the home page and refresh the app from there.
The logic is called and data returned.
However when I refresh a particular page that uses the component and calls the constructor it seems to late for the data to arrive back, hence I get undefined returned here:
this.settings = this.configService.settings;
I guess the 'wire up' is wrong...
Any suggestions how to tackle it?
angular typescript
angular typescript
edited Nov 9 at 13:07
Kirk Larkin
16.8k33452
16.8k33452
asked Nov 9 at 12:42
tom33pr
133112
133112
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's<base href>per environment. make sure you're not implementing that for nothing.
– Stavm
Nov 9 at 13:34
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54
add a comment |
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's<base href>per environment. make sure you're not implementing that for nothing.
– Stavm
Nov 9 at 13:34
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's
<base href> per environment. make sure you're not implementing that for nothing.– Stavm
Nov 9 at 13:34
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's
<base href> per environment. make sure you're not implementing that for nothing.– Stavm
Nov 9 at 13:34
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54
add a comment |
1 Answer
1
active
oldest
votes
up vote
1
down vote
accepted
In order for Angular to wait for your custom APP_INITIALIZER to complete, it expects a Promise to be returned. Your getStuff method isn't returning anything, which means Angular will not wait for this.settings to get set.
You can use toPromise to convert your Observable into a Promise. Here's one example of how this could be done:
getStuff(): Promise<void>
return this.getSettings()
.toPromise()
.then(data =>
this.settings = data;
);
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
accepted
In order for Angular to wait for your custom APP_INITIALIZER to complete, it expects a Promise to be returned. Your getStuff method isn't returning anything, which means Angular will not wait for this.settings to get set.
You can use toPromise to convert your Observable into a Promise. Here's one example of how this could be done:
getStuff(): Promise<void>
return this.getSettings()
.toPromise()
.then(data =>
this.settings = data;
);
add a comment |
up vote
1
down vote
accepted
In order for Angular to wait for your custom APP_INITIALIZER to complete, it expects a Promise to be returned. Your getStuff method isn't returning anything, which means Angular will not wait for this.settings to get set.
You can use toPromise to convert your Observable into a Promise. Here's one example of how this could be done:
getStuff(): Promise<void>
return this.getSettings()
.toPromise()
.then(data =>
this.settings = data;
);
add a comment |
up vote
1
down vote
accepted
up vote
1
down vote
accepted
In order for Angular to wait for your custom APP_INITIALIZER to complete, it expects a Promise to be returned. Your getStuff method isn't returning anything, which means Angular will not wait for this.settings to get set.
You can use toPromise to convert your Observable into a Promise. Here's one example of how this could be done:
getStuff(): Promise<void>
return this.getSettings()
.toPromise()
.then(data =>
this.settings = data;
);
In order for Angular to wait for your custom APP_INITIALIZER to complete, it expects a Promise to be returned. Your getStuff method isn't returning anything, which means Angular will not wait for this.settings to get set.
You can use toPromise to convert your Observable into a Promise. Here's one example of how this could be done:
getStuff(): Promise<void>
return this.getSettings()
.toPromise()
.then(data =>
this.settings = data;
);
answered Nov 9 at 13:05
Kirk Larkin
16.8k33452
16.8k33452
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%2f53225937%2fapp-initializer-undefined-results-after-page-reload%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
I believe you're following Dave Bush: where to store angular configurations. one caveat he neglects to mention, is the fact that even with this recommendation, you are still obligated to compile per-environment for the sole purpose of changing index.html's
<base href>per environment. make sure you're not implementing that for nothing.– Stavm
Nov 9 at 13:34
@Stavm Yes, I do compile per environment. Coming back to my original issue - frankly I am annoyed with (1) this implementation and (2) the lack of options I have here and (3) the fact that the Promise makes such a difference here and (4) the fact I cannot rely on the usual page life cycle. It is rather annoying.
– tom33pr
Nov 9 at 14:54