With the arrival of @NgModule, we suddenly had a more logical way of grouping our constructs and also a natural way of deciding what got to be exported or not. The following piece of code corresponds to the preceding facade code, but it uses @NgModule   instead:

import { NgModule } from '@angular/core';
import { TaskDetailComponent } from './task.detail.component';
import { TaskDetailsComponent } from './task.details.component';
import { TaskComponent } from './task.component';

@NgModule({
 declarations: [TaskComponent, TaskDetailsComponent],
 exports: [TaskComponent, TaskDetailComponent]
})
export class TaskModule { }

This would create the same effect and the construct is called a feature module. The exports keyword is what says what is publicly accessible or not. Getting access to what is publicly exposed looks a bit different though. Instead of typing:

import { TaskDetailComponent } from 'app/tasks/tasks';

We would need to import our feature module into our root module. This means our root module would look like the following:

import { TaskModule } from './task.module';

@NgModule({
  imports: [ TasksModule ]
  // the rest is omitted for brevity
}) 

This would now give us access to the exported components in the template markup. So in your upcoming app building, think about what belongs in a root module, what is part of a feature, and what is more common and used everywhere in the app. This is how you need to break apart your app, first in modules and then in proper constructs like components, directives, pipes, and so on.