Should the Angular Module be a Empty JavaScript Module?
I'm now learning Angular 7. I'm currently clear about the bootstrapping design in Angular and the metadata object usage marking angular components and modules. However, I've still not seen an example or a case where angular module is not an empty class.
So, I'm currently wonder that:
- Angular Module is only designed statically to configure and organize related things together?
- Involving Dynamic Logic code in an Angular Module, maybe written in constructor of the module class, is not a best practice?
javascript angular angular7
add a comment |
I'm now learning Angular 7. I'm currently clear about the bootstrapping design in Angular and the metadata object usage marking angular components and modules. However, I've still not seen an example or a case where angular module is not an empty class.
So, I'm currently wonder that:
- Angular Module is only designed statically to configure and organize related things together?
- Involving Dynamic Logic code in an Angular Module, maybe written in constructor of the module class, is not a best practice?
javascript angular angular7
add a comment |
I'm now learning Angular 7. I'm currently clear about the bootstrapping design in Angular and the metadata object usage marking angular components and modules. However, I've still not seen an example or a case where angular module is not an empty class.
So, I'm currently wonder that:
- Angular Module is only designed statically to configure and organize related things together?
- Involving Dynamic Logic code in an Angular Module, maybe written in constructor of the module class, is not a best practice?
javascript angular angular7
I'm now learning Angular 7. I'm currently clear about the bootstrapping design in Angular and the metadata object usage marking angular components and modules. However, I've still not seen an example or a case where angular module is not an empty class.
So, I'm currently wonder that:
- Angular Module is only designed statically to configure and organize related things together?
- Involving Dynamic Logic code in an Angular Module, maybe written in constructor of the module class, is not a best practice?
javascript angular angular7
javascript angular angular7
edited Nov 15 '18 at 6:40
Goncalo Peres
1,4791619
1,4791619
asked Nov 3 '18 at 16:13
千木郷千木郷
330211
330211
add a comment |
add a comment |
1 Answer
1
active
oldest
votes
I would think the main difference is that Angular components, modules and services use decorators from the angular package.
E.g. @Component()
does this:
* Component decorator allows you to mark a class as an Angular component and provide additional
* metadata that determines how the component should be processed, instantiated and used at
* runtime.
This is straight from the source code which you can look up.
The things you pass into this is also quite angular-specific. Other than that, no there should not be a big difference.
If you interface with a component which needs initialization, you should not use the JS constructor. It will execute slightly earlier than ngOnInit
and could cause problems since this is how angular works.
If you write custom modules then you can of course just do things conventionally.
A way to initialize modules is the forRoot
convention:
Here you basically create a singleton with a given configuration:
(taken from the link)
src/app/core/user.service.ts (constructor)
constructor(@Optional() config: UserServiceConfig) {
if (config) { this._userName = config.userName; }
}
src/app/core/core.module.ts (forRoot)
static forRoot(config: UserServiceConfig): ModuleWithProviders {
return {
ngModule: CoreModule,
providers: [
{provide: UserServiceConfig, useValue: config }
]
};
}
src/app/app.module.ts (imports)
import { CoreModule } from './core/core.module';
/* . . . */
@NgModule({
imports: [
BrowserModule,
ContactModule,
CoreModule.forRoot({userName: 'Miss Marple'}),
AppRoutingModule
],
/* . . . */
})
export class AppModule { }
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53133142%2fshould-the-angular-module-be-a-empty-javascript-module%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
I would think the main difference is that Angular components, modules and services use decorators from the angular package.
E.g. @Component()
does this:
* Component decorator allows you to mark a class as an Angular component and provide additional
* metadata that determines how the component should be processed, instantiated and used at
* runtime.
This is straight from the source code which you can look up.
The things you pass into this is also quite angular-specific. Other than that, no there should not be a big difference.
If you interface with a component which needs initialization, you should not use the JS constructor. It will execute slightly earlier than ngOnInit
and could cause problems since this is how angular works.
If you write custom modules then you can of course just do things conventionally.
A way to initialize modules is the forRoot
convention:
Here you basically create a singleton with a given configuration:
(taken from the link)
src/app/core/user.service.ts (constructor)
constructor(@Optional() config: UserServiceConfig) {
if (config) { this._userName = config.userName; }
}
src/app/core/core.module.ts (forRoot)
static forRoot(config: UserServiceConfig): ModuleWithProviders {
return {
ngModule: CoreModule,
providers: [
{provide: UserServiceConfig, useValue: config }
]
};
}
src/app/app.module.ts (imports)
import { CoreModule } from './core/core.module';
/* . . . */
@NgModule({
imports: [
BrowserModule,
ContactModule,
CoreModule.forRoot({userName: 'Miss Marple'}),
AppRoutingModule
],
/* . . . */
})
export class AppModule { }
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
add a comment |
I would think the main difference is that Angular components, modules and services use decorators from the angular package.
E.g. @Component()
does this:
* Component decorator allows you to mark a class as an Angular component and provide additional
* metadata that determines how the component should be processed, instantiated and used at
* runtime.
This is straight from the source code which you can look up.
The things you pass into this is also quite angular-specific. Other than that, no there should not be a big difference.
If you interface with a component which needs initialization, you should not use the JS constructor. It will execute slightly earlier than ngOnInit
and could cause problems since this is how angular works.
If you write custom modules then you can of course just do things conventionally.
A way to initialize modules is the forRoot
convention:
Here you basically create a singleton with a given configuration:
(taken from the link)
src/app/core/user.service.ts (constructor)
constructor(@Optional() config: UserServiceConfig) {
if (config) { this._userName = config.userName; }
}
src/app/core/core.module.ts (forRoot)
static forRoot(config: UserServiceConfig): ModuleWithProviders {
return {
ngModule: CoreModule,
providers: [
{provide: UserServiceConfig, useValue: config }
]
};
}
src/app/app.module.ts (imports)
import { CoreModule } from './core/core.module';
/* . . . */
@NgModule({
imports: [
BrowserModule,
ContactModule,
CoreModule.forRoot({userName: 'Miss Marple'}),
AppRoutingModule
],
/* . . . */
})
export class AppModule { }
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
add a comment |
I would think the main difference is that Angular components, modules and services use decorators from the angular package.
E.g. @Component()
does this:
* Component decorator allows you to mark a class as an Angular component and provide additional
* metadata that determines how the component should be processed, instantiated and used at
* runtime.
This is straight from the source code which you can look up.
The things you pass into this is also quite angular-specific. Other than that, no there should not be a big difference.
If you interface with a component which needs initialization, you should not use the JS constructor. It will execute slightly earlier than ngOnInit
and could cause problems since this is how angular works.
If you write custom modules then you can of course just do things conventionally.
A way to initialize modules is the forRoot
convention:
Here you basically create a singleton with a given configuration:
(taken from the link)
src/app/core/user.service.ts (constructor)
constructor(@Optional() config: UserServiceConfig) {
if (config) { this._userName = config.userName; }
}
src/app/core/core.module.ts (forRoot)
static forRoot(config: UserServiceConfig): ModuleWithProviders {
return {
ngModule: CoreModule,
providers: [
{provide: UserServiceConfig, useValue: config }
]
};
}
src/app/app.module.ts (imports)
import { CoreModule } from './core/core.module';
/* . . . */
@NgModule({
imports: [
BrowserModule,
ContactModule,
CoreModule.forRoot({userName: 'Miss Marple'}),
AppRoutingModule
],
/* . . . */
})
export class AppModule { }
I would think the main difference is that Angular components, modules and services use decorators from the angular package.
E.g. @Component()
does this:
* Component decorator allows you to mark a class as an Angular component and provide additional
* metadata that determines how the component should be processed, instantiated and used at
* runtime.
This is straight from the source code which you can look up.
The things you pass into this is also quite angular-specific. Other than that, no there should not be a big difference.
If you interface with a component which needs initialization, you should not use the JS constructor. It will execute slightly earlier than ngOnInit
and could cause problems since this is how angular works.
If you write custom modules then you can of course just do things conventionally.
A way to initialize modules is the forRoot
convention:
Here you basically create a singleton with a given configuration:
(taken from the link)
src/app/core/user.service.ts (constructor)
constructor(@Optional() config: UserServiceConfig) {
if (config) { this._userName = config.userName; }
}
src/app/core/core.module.ts (forRoot)
static forRoot(config: UserServiceConfig): ModuleWithProviders {
return {
ngModule: CoreModule,
providers: [
{provide: UserServiceConfig, useValue: config }
]
};
}
src/app/app.module.ts (imports)
import { CoreModule } from './core/core.module';
/* . . . */
@NgModule({
imports: [
BrowserModule,
ContactModule,
CoreModule.forRoot({userName: 'Miss Marple'}),
AppRoutingModule
],
/* . . . */
})
export class AppModule { }
edited Nov 15 '18 at 23:15
answered Nov 5 '18 at 3:13
mchl18mchl18
894313
894313
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
add a comment |
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
So I actually wonder that if there is such a thing like ngOnInit provided or available for an Angular Module, rather than angular component.
– 千木郷
Nov 15 '18 at 0:37
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
There is. Itt is called the forRoot convention. Many modules do it and here is the doc: angular.io/guide/singleton-services#forroot will update the answer with that
– mchl18
Nov 15 '18 at 23:08
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53133142%2fshould-the-angular-module-be-a-empty-javascript-module%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
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
Required, but never shown
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
Required, but never shown
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
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown