Cach viet review sp load render
Standardizing client-side routing through a brand new API which completely overhauls building single-page applications. Show
Single-page applications, or SPAs, are defined by a core feature: dynamically rewriting their content as the user interacts with the site, instead of the default method of loading entirely new pages from the server. While SPAs have been able to bring you this feature via the History API (or in limited cases, by adjusting the site's hash part), it's a developed long-before SPAs were the norm—and the web is crying out for a completely new approach. The Navigation API is a proposed API that completely overhauls this space, rather than trying to simply patch History API's rough edges. (For example, Scroll Restoration patched the History API rather than trying to reinvent it.)This post describes the Navigation API at a high level. If you'd like to read the technical proposal, check out the Draft Report in the WICG repository. Example UsageTo use the Navigation API, start by adding a
0 listener on the global
1 object. This event is fundamentally centralized: it will fire for all types of navigations, whether the user performed an action (such as clicking a link, submitting a form, or going back and forward) or when navigation is triggered programmatically (i.e., via your site's code). In most cases, it lets your code override the browser's default behavior for that action. For SPAs, that likely means keeping the user on the same page and loading or changing the site's content. A
2 is passed to the
0 listener which contains information about the navigation, such as the destination URL, and allows you to respond to the navigation in one centralized place. A basic
0 listener could look like this:
You can deal with the navigation in one of two ways:
This example calls
7 on the event. The browser calls your
8 callback, which should configure the next state of your site. This will create a transition object,
9, which other code can use to track the progress of the navigation. Both
7 and
6 are usually allowed, but have cases where they're unable to be called. You can't handle navigations via
7 if the navigation is a cross-origin navigation. And you can't cancel a navigation via
6 if the user is pressing the Back or Forward buttons in their browser; you should not be able to trap your users on your site. (This is being discussed on GitHub.) Even if you can't stop or intercept the navigation itself, the
0 event will still fire. It's informative, so your code could, for example, log an Analytics event to indicate that a user is leaving your site. Why add another event to the platform?A
0 event listener centralizes handling URL changes inside an SPA. This is a difficult proposition using older APIs. If you've ever written the routing for your own SPA using the History API, you might have added code like this:
This is fine, but not exhaustive. Links might come and go on your page, and they're not the only way users can navigate through pages. E.g., they may submit a form or even use an image map. Your page might deal with these, but there's a long tail of possibilities which could just be simplified—something that the new Navigation API achieves. Additionally, the above doesn't handle back/forward navigation. There's another event for that,
6. Personally, the History API often feels like it could go some way to help with these possibilities. However, it really only has two surface areas: responding if the user presses Back or Forward in their browser, plus pushing and replacing URLs. It doesn't have an analogy to
0, except if you manually set up listeners for click events for example, as demonstrated above. Deciding how to handle a navigationThe
8 contains a lot of information about the navigation that you can use to decide how to deal with a particular navigation. The key properties are:
9 If this is false, you can't intercept the navigation. Cross-origin navigations and cross-document traversals cannot be intercepted.
0 Probably the most important piece of information to consider when handling the navigation.
1 True if the navigation is same-document, and the hash is the only part of the URL that's different to the current URL. In modern SPAs, the hash should be for linking to different parts of the current document. So, if
1 is true, you probably don't need to intercept this navigation.
3 If this is true, the navigation was initiated by a link with a
4 attribute. In most cases, you don't need to intercept this.
5 If this isn't null, then this navigation is part of a POST form submission. Make sure you take this into account when handling the navigation. If you only want to handle GET navigations, avoid intercepting navigations where
5 is not null. See the example on handling later in the article.
7 This is one of
8,
9,
0, or
1. If it's
1, then this navigation cannot be cancelled via
6. For example, the
4 function used in the first example could be something like this:
InterceptingWhen your code calls
5 from within its
0 listener, it informs the browser that it's now preparing the page for the new, updated state, and that the navigation may take some time. The browser begins by capturing the scroll position for the current state, so it can be optionally restored later, then it calls your
8 callback. If your
8 returns a promise (which happens automatically with async functions), that promise tells the browser how long the navigation takes, and whether it's successful.
As such, this API introduces a semantic concept that the browser understands: an SPA navigation is currently occurring, over time, changing the document from a previous URL and state to a new one. This has a number of potential benefits, including accessibility: browsers can surface the beginning, end, or potential failure of a navigation. Chrome, for example, activates its native loading indicator, and allows the user to interact with the stop button. (This doesn't currently happen when the user navigates via the back/forward buttons, but that will be fixed soon.) Navigation committingWhen intercepting navigations, the new URL will take effect just before your
8 callback is called. If you don't update the DOM immediately, this creates a period where the old content is displayed along with the new URL. This impacts things like relative URL resolution when fetching data or loading new subresources. A way to delay the URL change is being discussed on GitHub, but it's generally recommended to immediately update the page with some sort of placeholder for the incoming content:
This not only avoids URL resolution issues, it also feels fast because you're instantly responding to the user. Abort signalsSince you're able to do asynchronous work in an
7 handler, it's possible for the navigation to become redundant. This happens when:
To deal with any of these possibilities, the event passed to the
0 listener contains a
2 property, which is an
3. For more information see Abortable fetch. The short version is it basically provides an object that fires an event when you should stop your work. Notably, you can pass an
3 to any calls you make to
5, which will cancel in-flight network requests if the navigation is preempted. This will both save the user's bandwidth, and reject the
6 returned by
5, preventing any following code from actions such as updating the DOM to show a now invalid page navigation. Here's the previous example, but with
8 inlined, showing how the
3 can be used with
5:
Scroll handlingWhen you
7 a navigation, the browser will attempt to handle scrolling automatically. For navigations to a new history entry (when
2 is
9 or
0), this means attempting to scroll to the part indicated by the URL fragment (the bit after the
5), or resetting the scroll to the top of the page. For reloads and traversals, this means restoring the scroll position to where it was last time this history entry was displayed. By default, this happens once the promise returned by your
8 resolves, but if it makes sense to scroll earlier, you can call
7:
Alternatively, you can opt out of automatic scroll handling entirely by setting the
8 option of
7 to
0:
Focus handlingOnce the promise returned by your
8 resolves, the browser will focus the first element with the
2 attribute set, or the
3 element if no element has that attribute. You can opt out of this behavior by setting the
4 option of
7 to
0:
Success and failure eventsWhen your
7 handler is called, one of two things will happen:
These events allow your code to deal with success or failure in a centralized way. For example, you might deal with success by hiding a previously displayed progress indicator, like this:
Or you might show an error message on failure:
0 The
3 event listener, which receives an
4, is particularly handy as it's guaranteed to receive any errors from your code that's setting up a new page. You can simply
7 knowing that if the network is unavailable, the error will eventually be routed to
3. Navigation entries
9 provides access to the current entry. This is an object which describes where the user is right now. This entry includes the current URL, metadata that can be used to identify this entry over time, and developer-provided state. The metadata includes
00, a unique string property of each entry which represents the current entry and its slot. This key remains the same even if the current entry's URL or state changes. It's still in the same slot. Conversely, if a user presses Back and then re-opens the same page,
00 will change as this new entry creates a new slot. To a developer,
00 is useful because the Navigation API allows you to directly navigate the user to an entry with a matching key. You're able to hold onto it, even in the states of other entries, in order to easily jump between pages.
1 StateThe Navigation API surfaces a notion of "state", which is developer-provided information that is stored persistently on the current history entry, but which isn't directly visible to the user. This is extremely similar to, but improved from,
03 in the History API. In the Navigation API, you can call the
04 method of the current entry (or any entry) to return a copy of its state:
2 By default, this will be
05. Setting stateAlthough state objects can be mutated, those changes are not saved back with the history entry, so:
3 The correct way to set state is during script navigation:
4 Where
06 can be any . If you want to update the state of the current entry, it's best to perform a navigation that replaces the current entry:
5 Then, your
0 event listener can pick up this change via
08:
6 Updating state synchronouslyGenerally, it's better to update state asynchronously via
09, then your
0 listener can apply that state. However, sometimes the state change has already fully applied by the time your code hears about it, such as when the user toggles a
11 element, or the user changes the state of a form input. In these cases, you may want to update state so these changes are preserved through reloads and traversals. This is possible using
12:
7 There's also an event to hear about this change:
8 But, if you find yourself reacting to state changes in
13, you may be splitting or even duplicating your state-handing code between the
0 event and the
13 event, whereas
09 would let you handle it in one place. State vs URL paramsBecause state can be a structured object, it's tempting to use it for all your application state. However, in many cases it's better to store that state in the URL. If you would expect the state to be retained when the user shares the URL with another user, store it in the URL. Otherwise, the state object is the better option. Access all entriesThe "current entry" is not all, though. The API also provides a way to access the entire list of entries that a user has navigated through while using your site via its
17 call, which returns a snapshot array of entries. This could be used to, e.g., show a different UI based on how the user navigated to a certain page, or just to look back at the previous URLs or their states. This is impossible with the current History API. You can also listen for a
18 event on individual
19s, which is fired when the entry is no longer part of browser history. This can happen as part of general cleanup, but also happen when navigating. For example, if you traverse back 10 places, then navigate forwards, those 10 history entries will be disposed. ExamplesThe
0 event fires for all types of navigation, as mentioned above. (There's actually a of all possible types.) While for many sites the most common case will be when the user clicks a
21, there are two notable, more complex navigation types that are worth covering. Programmatic navigationFirst is programmatic navigation, where navigation is caused by a method call inside your client-side code. You can call
22 from anywhere in your code to cause a navigation. This will be handled by the centralized event listener registered on the
0 listener, and your centralized listener will be called synchronously. This is intended as an improved aggregation of older methods like
24 and friends, plus the History API's methods
25 and
26. The
27 method returns a object which contains two
6 instances in
29. This allows the invoker can wait until either the transition is "committed" (the visible URL has changed and a new
19 is available) or "finished" (all promises returned by
5 are complete—or rejected, due to failure or being preempted by another navigation). The
32 method also has an options object, where you can set:
In particular,
38 could be useful to, for example, denote a particular animation that causes the next page to appear. (The alternative might be to set a global variable or include it as part of the hash. Both options are a bit awkward.) Notably, this
38 won't be replayed if a user later causes navigation, e.g., via their Back and Forward buttons. In fact, it will always be
05 in those cases. Demo of opening from left or right
1 also has a number of other navigation methods, all which return an object containing
29. I've already mentioned
45 (which accepts a
00 that denotes a specific entry in the user's history) and
47. It also includes
48,
49 and
50. These methods are all handled—just like
47—by the centralized
0 event listener. Form SubmissionsSecondly, HTML
53 submission via POST is a special type of navigation, and the Navigation API can intercept it. While it includes an additional payload, the navigation is still handled centrally by the
0 listener. Form submission can be detected by looking for the
5 property on the
2. Here's an example that simply turns any form submission into one which stays on the current page via
5:
9 What's missing?Despite the centralized nature of the
0 event listener, the current Navigation API specification doesn't trigger
0 on a page's first load. And for sites which use (SSR) for all states, this might be fine—your server could return the correct initial state, which is the fastest way to get content to your users. But sites that leverage client-side code to create their pages may need to create an additional function to initialize their page. Another intentional design choice of the Navigation API is that it operates only within a single frame—that is, the top-level page, or a single specific
60. This has a number of interesting implications that are , but in practice, will reduce developer confusion. The previous History API has a number of confusing edge cases, like support for frames, and the reimagined Navigation API handles these edge cases from the get-go. Lastly, there's not yet consensus on programmatically modifying or rearranging the list of entries the user has navigated through. This is currently under discussion, but one option could be to allow only deletions: either historic entries or "all future entries". The latter would allow temporary state. E.g., as a developer, I could:
This could be perfect for temporary modals or interstitials: the new URL is something that a user can use the Back gesture to leave from, but they then cannot accidentally go Forward to open it again (because the entry has been removed). This is just not possible with the current History API. Try the Navigation APIThe Navigation API is available in Chrome 102 without flags. You can also try out a demo by Domenic Denicola. While the classic History API appears straightforward, it's not very well-defined and has a large number of issues around corner cases and how it has been implemented differently across browsers. We hope you consider providing feedback on the new Navigation API. References
AcknowledgementsThanks to Thomas Steiner, Domenic Denicola and Nate Chapin for reviewing this post. Hero image from Unsplash, by Jeremy Zero. |