Selecting a LocationStrategy for path construction

A simple but important choice for your application is which type of LocationStrategy you want to make use of. The following two URLs are equivalent when their respective LocationStrategy is selected:

PathLocationStrategy: foo.com/bar
HashLocationStrategy: foo.com/#/bar

Note

The code, links, and a live example of this are available at .

How to do it...

Angular 2 will default to PathLocationStrategy. Should you want to select HashLocationStrategy, it can be imported from the @angular/common module. Once imported, it can be listed as a provider inside an object literal:

[app/app.module.ts]      import {NgModule} from '@angular/core';   import {BrowserModule} from '@angular/platform-browser';   import {RouterModule, Routes} from '@angular/router';   import {RootComponent} from './root.component';   import {DefaultComponent} from './default.component';   import {ArticleComponent} from './article.component';   import {LocationStrategy, HashLocationStrategy}      from '@angular/common';         const appRoutes:Routes = [     {path: 'article', component: ArticleComponent},     {path: '**', component: DefaultComponent},   ];      @NgModule({     imports: [       BrowserModule,       RouterModule.forRoot(appRoutes)     ],     declarations: [       DefaultComponent,       ArticleComponent,       RootComponent     ],     providers: [       {provide: LocationStrategy, useClass: HashLocationStrategy}     ],     bootstrap: [       RootComponent     ]   })   export class AppModule {}

With this addition, your application will transition to prefix #/ to all application-defined URLs. This will occur in transparence with the rest of your application, which can use its routing definitions normally without having to worry about prefixing #/.

There's more...

There are tradeoffs for each of these strategies. As the Angular documentation notes, once you choose one, it is inadvisable to switch to the other since bookmarks, SEO, and user history will all be coupled to the URL strategy utilized during that visit.

PathLocationStrategy:

Here, the URLs appear normal to the end user
The server must be configured to handle page loads from any application path
This allows the hybrid server-side rendering of routes for improved performance

HashLocationStrategy:

Here, the URLs may look funny to the end user.
No server configuration is required if the root domain serves index.html. This is a good option if you only want to serve static files (for example, an Amazon AWS-based site).
It cannot be easily intermixed with hybrid server-side rendering.

Configuring your application server for PathLocationStrategy

Angular is smart enough to recognize the browser state and manage it accordingly once bootstrapping occurs. However, bootstrapping requires an initial load of the static compiled JS assets, which will bootstrap Angular once the browser loads them. When the user initially visits a root domain, such as foo.com, the server is normally configured to respond with index.html, which will in turn request the static assets at render time. So, Angular will work!

However, in cases where the user initially visits a non-root path, such as foo.com/bar, the browser will send a request to the server at foo.com/bar. If you aren't careful when setting up your server, a common mistake you may commit is having only the root foo.com path return index.html.

In order for PathLocationStrategy to work correctly in all cases, you must configure your web server to set up a catchall route for all the requests that have paths intended for the single-page application's route in the client, and to invariably return index.html. In other words, visiting foo.com, foo.com/bar, or foo.com/bar/baz as the first page in the browser will all return the same thing: index.html. Once you do this, postbootstrap Angular will examine the current browser path and recognize which path it is on and what view needs to be displayed.