default location to hash allow path via ExtraOptions

[robwormald]

From @gdi2290 on June 21, 2016 1:5

the default location should be HashLocationStrategy while PathLocationStrategy could be set via ExtraOptions

Copied from original issue: angular/vladivostok#96

[akorchev]

I can't agree more. HashLocationStrategy should have been the default. Reasons?

1. PathLocationStrategy fails when the end user refreshes the browser. Not a problem of angular or PathLocationStragegy - this is how the history API works. However having a broken app by default is wrong in my book.

Let's be honest here. Most of the people using angular will not implement server-side rendering of their angular components. This means that when your end users refresh their browser they will get a 404 (or a redirect to the home page if you play it smart).

Please make HashLocationStrategy the default and allow people to skip fragment stripping. If somebody wants badly "pretty urls" she can do the extra mile of supporting server side rendering and enabling it.

The documentation is also misleading.

Almost all Angular 2 projects should use the default HTML 5 style. It produces URLs that are easier for users to understand. And it preserves the option to do server-side rendering later.

It should say that you must implement server-side rendering if you want to fully support the HTML5 routing style.

This Tour of Heroes tutorial suffers from the same problem. Open the live demo in plunker, load it in a separate window, navigate anywhere and refresh the browser ... 'NOT FOUND'.

[zoechi]

@akorchev server-side rendering is not related to PathLocationStrategy at all.
It is HTML5 pushState support that is required by the server.
The server just needs to redirect requests to non-existing files to index.html.

[PatrickJS]

Having html5 pushState as the default forces new users to learn/know about build tools. The concern here is mostly for developers who are new to angular2 and/or even client-side web development. It's also a lot easier to reason about single page apps when you understand that it's loading one page (the index.html) and we're using javascript to fake routes with the hash. Having the html5 pushState forces the developer to know more about how servers work. If a new developer is also setting up a server in node/express for the first time, it's also easy to fall into common pitfalls of making sure they don't serve everything as index. For example, a new developer may mess up the order and now all of the assets are serving the index.html this can lead to recursive requests. Where of the index.html loads a resource that loads yet another index.html

[akorchev]

I know that one could add a redirect to index.html. However I am not sure this is the right choice because

1. One may actually want to handle 404 on the server side by displaying a 404 page. Yeah it can be handled at the client side too. Probably not ideal from SEO point of view though.
2. In some cases one cannot set a redirect at all - jsbin, codepen, plunkr, gh-pages. Most online demos that show routing with path location strategy will be broken.
3. One needs to keep a whitelist of static urls (assets) and avoid redirecting.
4. As @gdi2290 said this isn't friendly to the novice developer at all. It also isn't explained in the documentation. It just says that path location strategy is better.

[vsavkin]

It is a breaking change, so we cannot make until the end of 2017. And I don't think this the cost justifies the benefit here. Closing this issue.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}