It’s one of those gray areas where “can” and “can’t” don’t really live. It’s more of the land of “easier” vs. “harder”, but maybe a 10,000-meter overview of the problem all this was designed to solve is in order.
Compiled languages like C get written in source form in
*.c files. The compiler turns those into object code
*.o files. A linker mashes all those
*.o files together into an executable. At that stage, especially when third-party libraries get involved, a naïve linker runs into a “dead code” problem, whereby a bunch of useless cruft gets put in the executable.
NgModule was born.
The Angular people decided (and this probably makes sense) that putting the intermodule entry point documentation stuff into the
@Component decorator would be a bad idea, because it isn’t just individual components that need to get managed that way - pipes and services do as well, and in many cases, in groups.
If anybody’s still awake at this point, one last bit about overloaded terminology. There are two senses of “import” here, and to further complicate matters, “inject” often gets thrown into this blender as well.
import something at the top of a TypeScript file, that’s a source code level thing that says to the transpiler “yo, in order to properly process this file, you’re gonna need to read that one over there”. This can be individual components if you wish.
When you add something to the
imports stanza of an
NgModule, the transpiler doesn’t really care. It’s the bundler that takes that into account when deciding which of your code gets put in the same
.js file that is loaded at runtime. This can’t be individual components, and must be other
When you inject something into the constructor of a component or service, that’s a hint to the dependency injection system (DI) that operates at runtime. This predates the notion of
NgModule and doesn’t work for individual components because the semantics don’t really make any sense for it to.
Hope that sort of answers your question.