Purpose

If you are looking for an opinionated style guide for syntax, conventions, and structuring Angular applications, then step right in.

The purpose of this style guide is to provide guidance on building Angular applications by showing the conventions we use and, more importantly, why we choose them.

Style Vocabulary

Each guideline describes either a good or bad practice, and all have a consistent presentation.

The wording of each guideline indicates how strong the recommendation is.

Do is one that should always be followed.Always might be a bit too strong of a word.
Guidelines that literally should always be followed are extremely rare.
On the other hand, we need a really unusual case for breaking a Do guideline.

Consider guidelines should generally be followed.
If you fully understand the meaning behind the guideline and have a good reason to deviate, then do so. Please strive to be consistent.

Avoid indicates something we should almost never do. Code examples to avoid have an unmistakeable red header.

File Structure Conventions

Some code examples display a file that has one or more similarly named companion files. (e.g. hero.component.ts and hero.component.html).

The guideline will use the shortcut hero.component.ts|html|css|spec to represent those various files. Using this shortcut makes this guide’s file structures easier to read and more terse.

Naming

Naming conventions are hugely important to maintainability and readability. This guide recommends naming conventions for the file name and the symbol name.

General Naming Guidelines

Style 02-01

Do use consistent names for all symbols.

Do follow a pattern that describes the symbol’s feature then its type. The recommended pattern is feature.type.ts.

Why? Naming conventions help provide a consistent way to find content at a glance. Consistency within the project is vital. Consistency with a team is important. Consistency across a company provides tremendous efficiency.

Why? The naming conventions should simply help us find our code faster and make it easier to understand.

Why? Names of folders and files should clearly convey their intent. For example, app/heroes/hero-list.component.ts may contain a component that manages a list of heroes.

Application Structure

Have a near term view of implementation and a long term vision. Start small but keep in mind where the app is heading down the road.

All of the app’s code goes in a folder named app. All content is 1 feature per file. Each component, service, and pipe is in its own file. All 3rd party vendor scripts are stored in another folder and not in the app folder. We didn’t write them and we don’t want them cluttering our app. Use the naming conventions for files in this guide.

LIFT

Style 04-01

Do structure the app such that we can Locate our code quickly, Identify the code at a glance, keep the Flattest structure we can, and Try to be DRY.

Do define the structure to follow these four basic guidelines, listed in order of importance.

Why? LIFT Provides a consistent structure that scales well, is modular, and makes it easier to increase developer efficiency by finding code quickly. Another way to check our app structure is to ask ourselves: How quickly can we open and work in all of the related files for a feature?

Locate

Style 04-02

Do make locating our code intuitive, simple and fast.

Why? We find this to be super important for a project. If we cannot find the files we need to work on quickly, we will not be able to work as efficiently as possible, and the structure will need to change. We may not know the file name or where its related files are, so putting them in the most intuitive locations and near each other saves a ton of time. A descriptive folder structure can help with this.

Flat

Style 04-04

Do keep a flat folder structure as long as possible.

Consider creating fodlers when we get to seven or more files.

Why? Nobody wants to search seven levels of folders to find a file. In a folder structure there is no hard and fast number rule, but when a folder has seven to ten files, that may be time to create subfolders. We base it on our comfort level. Use a flatter structure until there is an obvious value (to help the rest of LIFT) in creating a new folder.

T-DRY (Try to be DRY)

Style 04-05

Do be DRY (Don’t Repeat Yourself)

Avoid being so DRY that we sacrifice readability.

Why? Being DRY is important, but not crucial if it sacrifices the others in LIFT, which is why we call it T-DRY. We don’t want to type hero-view.component.html for a view because, well, it’s obviously a view. If it is not obvious or by convention, then we name it.

Overall Structural Guidelines

Style 04-06

Do start small but keep in mind where the app is heading down the road.

Do have a near term view of implementation and a long term vision.

Do put all of the app’s code in a folder named app.

Consider creating a folder for each component including its .ts, .html, .css and .spec file.

Why? Helps us keep the app structure small and easy to maintain in the early stages, while being easy to evolve as the app grows.

Why? Components often have four files (e.g. *.html, *.css, *.ts, and *.spec.ts) and can clutter a folder quickly.

Overall Folder and File Structure

src

app

+heroes

hero

hero.component.ts|html|css|spec.ts

index.ts

hero-list

hero-list.component.ts|html|css|spec.ts

index.ts

shared

hero.model.ts

hero.service.ts|spec.ts

index.ts

heroes.component.ts|html|css|spec.ts

index.ts

shared

app.component.ts|html|css|spec.ts

main.ts

index.html

…

While we prefer our Components to be in their own dedicated folder, another option for small apps is to keep Components flat (not in a dedicated folder). This adds up to four files to the existing folder, but also reduces the folder nesting. Be consistent.

Components as Elements

Style 05-03

Why? Components have templates containing HTML and optional Angular template syntax. They are most associated with putting content on a page, and thus are more closely aligned with elements.

Why? Components are derived from Directives, and thus their selectors can be elements, attributes, or other selectors. Defining the selector as an element provides consistency for components that represent content with a template.

Why? It is easier to recognize that a symbol is a component vs a directive by looking at the template’s html.

Use HostListener and HostBinding Class Decorators

Style 06-03

Do use @HostListener and @HostBinding instead of the host property of the @Directive and @Component decorators:

Why? The property or method name associated with @HostBinding or respectively @HostListener should be modified only in a single place – in the directive’s class. In contrast if we use host we need to modify both the property declaration inside the controller, and the metadata associated to the directive.

Why? The metadata declaration attached to the directive is shorter and thus more readable.

Providing a Service

Style 07-03

Do provide services to the Angular 2 injector at the top-most component where they will be shared.

Why? The Angular 2 injector is hierarchical.

Why? When providing the service to a top level component, that instance is shared and available to all child components of that top level component.

Why? This is ideal when a service is sharing methods or state.

Why? This is not ideal when two different components need different instances of a service. In this scenario it would be better to provide the service at the component level that needs the new and separate instance.

Data Services

Separate Data Calls

Style 08-01

Do refactor logic for making data operations and interacting with data to a service.

Do make data services responsible for XHR calls, local storage, stashing in memory, or any other data operations.

Why? The component’s responsibility is for the presentation and gathering of information for the view. It should not care how it gets the data, just that it knows who to ask for it. Separating the data services moves the logic on how to get it to the data service, and lets the component be simpler and more focused on the view.

Why? This makes it easier to test (mock or real) the data calls when testing a component that uses a data service.

Why? Data service implementation may have very specific code to handle the data repository. This may include headers, how to talk to the data, or other services such as Http. Separating the logic into a data service encapsulates this logic in a single place hiding the implementation from the outside consumers (perhaps a component), also making it easier to change the implementation.

Recent Posts: <CONTENT /> v.6

Lets have a look on what we have on this article: Setting up Apache 2 in Linux Subsystem for Windows 10 Setting up MySQL Server in Linux Subsystem for Windows 10 Setting up PHP in Linux Subsystem for Windows 10 Visual Studio Code and PHP Extensions Few tweaks to work on PHP, Visual Studio Code …

There are some good pointers and excellent tips in Web Development and Advanced Techniques with Linux on Windows (WSL) that are useful if you’re using WSL as part of your dev toolkit. Getting the same envs, including PATH, running across both systems is handy. It’s cool to be able to develop in Windows and test …

Virtually nowhere to be found were the 90 percent of lawyers who practice outside biglaw, the business clients who do not run mega-corporations, the access-to-justice community, or those disenfranchised from the legal system. — Five Days, Two Conferences, One Echo Chamber | LawSites https://www.lawsitesblog.com/2019/02/five-days-two-conferences-one-echo-chamber.html