- Switching to Angular(Third Edition)
- Minko Gechev
- 506字
- 2021-07-02 15:23:35
The new router
In traditional web applications, all the page changes are associated with a full-page reload, which fetches all of the referenced resources and data and renders the entire page onto the screen. However, requirements for web applications have evolved over time.
Single-page applications (SPAs) that we build with Angular simulate desktop user experiences. This often involves incremental loading of the resources and data required by the application, and no full-page reloads after the initial page load. Often, the different pages or views in SPAs are represented by different templates, which are loaded asynchronously and rendered on a specific position on the screen. Later, when the template with all the required resources is loaded and the route is changed, the logic attached to the selected page is invoked and populates the template with data. If the user clicks on the refresh button after the given page in our SPA is loaded, the same page needs to be re-rendered after the refresh of the view completes. This involves similar behavior: finding the requested view, fetching the required template with all referenced resources, and invoking the logic associated with that view.
The template that needs to be fetched, and the logic that should be invoked after the page reloads successfully, depends on the view selected before the user clicked on the refresh button. The framework determines this by parsing the page URL, which contains the identifier of the currently selected page, represented in a hierarchical structure.
All the responsibilities related to the navigation, changing the URL, loading the appropriate template, and invoking specific logic when the view is loaded, are assigned to the router component. These are some quite challenging tasks, and support for different navigation APIs required for cross-browser compatibility makes the implementation of routing in modern SPAs a nontrivial problem.
AngularJS introduced the router in its core, which was later externalized into the ngRoute module. It allows a declarative way for defining the different views in our SPA, by providing a template for each page and a piece of logic that needs to be invoked when a page is selected. However, the functionality of the router is limited. It does not support essential features, such as nested view routing. This is one of the reasons most developers preferred to use ui-router, developed by the community. Both the AngularJS's router and ui-router route definitions include a route configuration object, which defines a template and a controller associated with the page.
As described in the previous sections, Angular changed the building blocks it provides for the development of SPAs. Angular removes the floating controllers and instead represents views as a composition of components. This necessitates the development of a brand new router, which empowers these new concepts.
The core differences between the AngularJS router and the new Angular router are as follows:
- The new router is component based, ngRoute is not. The new Angular router associates a component with the individual routes or a module in case of lazy-loaded routes.
- There is now support for nested views.
- 高手是如何做產(chǎn)品設(shè)計的(全2冊)
- 自己動手寫搜索引擎
- 復(fù)雜軟件設(shè)計之道:領(lǐng)域驅(qū)動設(shè)計全面解析與實戰(zhàn)
- Learning Cython Programming(Second Edition)
- 工程軟件開發(fā)技術(shù)基礎(chǔ)
- 深入淺出Electron:原理、工程與實踐
- 數(shù)據(jù)結(jié)構(gòu)(Java語言描述)
- 深入理解Java7:核心技術(shù)與最佳實踐
- Mastering C# Concurrency
- 編程與類型系統(tǒng)
- 微服務(wù)從小白到專家:Spring Cloud和Kubernetes實戰(zhàn)
- 零代碼實戰(zhàn):企業(yè)級應(yīng)用搭建與案例詳解
- Clojure Polymorphism
- 基于GPU加速的計算機視覺編程:使用OpenCV和CUDA實時處理復(fù)雜圖像數(shù)據(jù)
- Java EE項目應(yīng)用開發(fā)