• Using Hashed vs. non-hashed URL Paths in Single Page Apps
  • Viduni Wickramarachchi
  • The Nuggets translation Project
  • Permanent link to this article: github.com/xitu/gold-m…
  • Translator: zenblo
  • Proofread by: JohnieXu

Hash urls versus normal urls for single-page applications

The following two routing modes are supported in a single page application:

  • Hash URL path – We use # (hash) to separate the URL path so that the browser recognizes that it is just a virtual fragment.
  • Normal URL path (non-hash URL path) – The server needs to intercept the request and return index.html.

In this article, you’ll learn the pros and cons of both approaches, and you’ll help you choose a better approach for your own application.

Common URL path

From their appearance, you can determine that the following are common urls.

https://mysite.com/dashboard
https://mysite.com/shopping-cart
Copy the code

advantages

  • Ordinary urls look clean enough.
  • These types of urls have better advantages when it comes to SEO.
  • By default, Web application scaffolding using frameworks such as Angular also supports this functionality.
  • Server services in modern development frameworks, such as Angularng serve) supports this feature.

All in all, plain urls are a better choice in terms of what they support. But these advantages come at a cost.

challenge

When we consider using plain urls in single-page applications, you need to configure the Web server to enable it to run.

  • The Web server needs to be configured to provide index.html for the SPA routing path.
  • It is impractical to whitelist every SPA routing path in a Web server, so you need to provide a separate routing pattern for the API to distinguish it from SPA routing (for example, / API /* routing addresses are assigned to the API interface for use).
  • You need to be careful when defining URL path links in a SPA, because it can cause the entire page to reload.
  • In some cases, such as hosting front-end and back-end services separately, you will need gateways to perform server-side path-based routing.

Hash URL path

The hash URL will take the following format, with the parts separated by a hash (#) called fragments or anchors.

https://mysite.com/#/dashboard
https://mysite.com/#/cart
Copy the code

If you started using SPA a few years ago, URL hash paths were common at that time. In the past few years, however, things have changed. SPA has become the standard for Web development, and tools and technological advances support it. That’s why it’s hard to see a URL scheme that isn’t known for hash urls and plain urls. However, there are several advantages to hash urls that are worth knowing.

advantages

  • Browsers do not treat the hashed path fragment as a separate page. This behavior of the browser is ideal for single-page applications because refreshing the page reloads index.html.
  • Defining links with hashes on the front end is safe because it does not reload the page.
  • The server configuration is simple and it is easy to distinguish between apis and front-end requests (though we still need to plan the front-end resource path).

disadvantages

The biggest drawback of hash urls is that they are not beautiful.

  • Some users may think that such a web address is unusual.
  • Not the best for SEO.

Otherwise, this is easiest for a SPA to implement.

Handle URL paths in SPA

Today, almost all modern SPA frameworks include a routing module with built-in support for handling changes to path fragments after urls or hashes.

Of course, it is possible to develop a custom routing solution to track URL changes in a SPA without using the routing modules built into modern frameworks. To implement a custom router, use the following browser API.

  • History API- You can directly access the history interface of the browser. It allows you to do URL manipulation without generating a hash. It has features such asback(),forward(), which allows you to navigate to the previous state or the next browsing history based on the browsing history.
  • Location API 和 onHashChangeEvent listener – in this method, the browseronHashChangeFires every time you see a hash change in the URL. You can easily manage hash changes without using this method to communicate with the server.

conclusion

You can use hash urls or plain urls for a single page application. Given the pros and cons of both approaches, you’ll probably agree with me that both approaches are technically feasible.

Even if you use a generic URL for your application, any single-page application framework or library will support it. Therefore, you don’t have to worry about the complexity of routing. However, you may need to explore server-side Settings to support this setting.

I hope this article provides an overview of using both types of urls and deepens your understanding. If you have any questions, feel free to comment below.

The type of URL you choose to use is up to you!

If you find any mistakes in your translation or other areas that need to be improved, you are welcome to the Nuggets Translation Program to revise and PR your translation, and you can also get the corresponding reward points. The permanent link to this article at the beginning of this article is the MarkDown link to this article on GitHub.

The Nuggets Translation Project is a community that translates quality Internet technical articles from English sharing articles on nuggets. The content covers Android, iOS, front-end, back-end, blockchain, products, design, artificial intelligence and other fields. If you want to see more high-quality translation, please continue to pay attention to the Translation plan of Digging Gold, the official Weibo, Zhihu column.