File naming conventions for components

Naming all components .component.ts isn’t describing them good enough. We should introduce different kinds of components to angular-cli to simplify getting started with the different kinds of components.

The component types I currently use are:

*.component.ts A view component which only takes in data via inputs and always has changeDetection: ChangeDetectionStrategy.OnPush

*.container.ts A container component (Smart component) that usually doesn’t have inputs and instead uses services and RxJS to supply data to view components.

*.route.ts A component that is part of the router. It’s a lot like a container component when it comes to mindset. It usually has an injected private route: ActivatedRoute. This component also doesn’t get included in the app.modules.ts but in the app-routing.module.ts. Thus containing all route specific things in the routing module.

Suggestion

As you can see there are many different kinds of components that potentially could have different default imports and different filename suffixes.

By having these blueprints available and by standardizing the naming conventions of them the apps produced by angular-cli would look more alike.

Implementation

As a first step we could allow using custom suffixes:

ng generate component dashboard route

//
installing component
  create src/app/dashboard/dashboard.route.scss
  create src/app/dashboard/dashboard.route.html
  create src/app/dashboard/dashboard.route.spec.ts
  create src/app/dashboard/dashboard.route.ts
  update src/app/app.module.ts

And as a second step we could create the blueprints for the component types that people most want.

Is this something that could be considered?

[skorunka]

Were there any updates on this? I like that idea to have more different types of components. Renaming is an option, but it just wastes developer’s time, when cli could do that instead?

[delasteve]

The CLI adheres to the style guide on the Angular website.

https://angular.io/styleguide#!#naming

Do use conventional type names including .service, .component, .pipe, .module, .directive. Invent additional type names if you must but take care not to create too many.

As @Meligy said, it’s going to add a bit of complexity for not much benefit. We currently have a limited set of blueprints, and have to create new ones for each new type people request. This is why we only implement the ones listed in the style guide.

I could see a feature where you are able to create your own blueprints or adopt others’. This would be when the add-on system is created, though.