In a web application, URLs were only the file and directive locations on the server you are trying to reach. They used to map to physical files. After the introduction of various URL routing techniques on the server-side to handle and enhance routing, some of the methods allowed you to configure an application to accept request URLs that do not map to physical files. This decoupled the map between file and URL, Now, a request URL is simply the URL a user enters into their browser to find a page/functionality on your web site.
In a single-page application, there is only one path to the entry file. After bootstrapping the application, instead of going to the server to get a new page, you change what the user sees by showing or hiding parts of the screen that correspond to certain components. As users perform application tasks, they need to switch between the different views you define. You use the Angular Router to apply this type of navigation on your application.
Angular does not generate & handle server-side redirections.
To handle the navigation in Angular from one view to the next, you use the Angular router. The router enables navigation by interpreting a browser URL as an instruction to change the view.
When the router navigates to a new component view, it updates the browser’s location and history with a URL for that view. As this is a strictly local URL the browser won’t send this URL to the server and will not reload the page.
Angular supports two different routing strategies:
PathLocationStrategy — the “HTML5 pushState” style. (example: “http://example.com/page1”)
HashLocationStrategy — the “hash URL” style. (example: “http://example.com/#/page1”)
If you are using the PathLocationStrategy for modern browsers, they support history.pushState, a technique that changes a browser’s location and history without triggering a server page request. The router can compose a “natural” URL that is indistinguishable from one that would otherwise require a page load.
In this case, the server needs to redirect all traffic to index.html so Angular can take over to handle path on UI. For example: Imagine your app navigated to the URL https://example.com/page1/page2 where your app is located on https://example.com/. If you now try to reload your app, it won’t work because the web server does not find the path /page1/page2/ because the path is generated only in the browser by Angular.
To prevent this bug, you have to inform your server to redirect all traffic to index.html. On Apache servers, you can to this by appending a .htaccess file to your production server.
What is .htaccess?
.htaccess is a configuration file to be used on web servers running Apache Web Server software. When an .htaccess file is placed in a directory ‘uploaded via Apache Web Server’, the .htaccess file is detected and executed by the Apache Web Server software. These .htaccess files can be used to change the configuration of the Apache Web Server software to enable / disable additional functions and features offered by the Apache Web Server software. These features include basic redirects, routing functions, for example, if a 404 file not found error occurs or for more advanced functions such as content password protection or image hotlink prevention.
For Angular purposes, you need to use redirects. Redirects enable us to direct web site visitors from one document within your web site to another.
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -f [OR]
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} -d
RewriteRule ^.*$ - [NC,L]
RewriteRule ^(.*) index.html [NC,L]
</IfModule>To flow all server traffic to Angular, jut place the .htaccess file next to your app’s index.html on your web server.