# Page route monitor

Start from base library version 3.5.5. Please remaining backward compatible.

This guide mainly explains from the base library version 3.5.5 From the available Page Route Event Listener Method of use. If you need to understand the basic information such as the type and logic of page routing, you can refer to Page routing。

Because each routing can trigger multiple page lifecycles for multiple pages at a time, when a certain lifecycle of a page is triggered, it is often difficult for a Mini Program to determine why it was triggered, making it difficult to make some responses to the route rather than the page. An example is when the Mini Program is reloaded reLaunch When routing, the Mini Program may need to reset some global state to ensure that the subsequent logic works properly, or simulate an effect similar to a restart. However, the reverse inference from the page life cycle reLaunch Is more difficult, because even if all the current pages are destroyed at a certain moment, it is not necessarily by reLaunch Caused by (or possibly a redirect when there is only a single page redirectTo）。This set of interfaces can help handle such scenarios.

# All listening and triggering timing

For example, in a redirectTo The listening and processing logic is triggered in the following order in

1. wx.onBeforeAppRoute
2. wx.onBeforePageUnload
3. The Old Page [onUnload]((Reference/api/Page#Lifecycle callback function)) life cycle
4. The old page is destroyed, in which the page itself and all custom components in the page detached The life cycle is recursively triggered
5. The old page pops up the page stack, which starts at this point getCurrentPages Interface can no longer get to the old page
6. [wx.onAfterPageUnload](<(wx.onAfterPageUnload )>)
7. wx.onBeforePageLoad
8. Creates a new page, in which the page itself and all custom components in the page created The life cycle is recursively triggered
9. The new page is pushed into the page stack, at which point it begins getCurrentPages Interface can get to the new page
10. Mount the new page, in which the page itself and all the custom components in the page attached The life cycle is recursively triggered
11. New page [onLoad]((Reference/api/Page#Lifecycle callback function)) life cycle
12. New page [onShow]((Reference/api/Page#Lifecycle callback function)) life cycle
13. wx.onAfterPageLoad
14. wx.onAppRoute
15. (New page pushed when animation is complete)wx.onAppRouteDone

For other routes, you can combine Page routing The specific routing logic in the.

# Routing event ID

To identify the same routing event in multiple listening callbacks, the framework generates a unique instance of the Mini Program for each individual routing event. ID, called Routing event ID. In all page routing listeners, the event arguments carry a character string routeEventId, indicates that this routing event ID。The Mini Program can do this by reading the callback in the routeEventId, to correlate different callbacks triggered by the same route at different time nodes. For example:

const redirectToContext = {}
wx.onBeforeAppRoute(res => {
  if (res.openType  === "redirectTo") {
    redirectToContext[res.routeEventId] = { startTime: new Date() }
  }
})
wx.onBeforePageUnload(res => {
  const context = redirectToContext[res.routeEventId]
  if (context !== undefined) {
    context.from = res.page.is
    context.data = res.page.data
  }
})
wx.onAfterPageLoad(res => {
  const context = redirectToContext[res.routeEventId]
  if (context !== undefined) {
    console.log(
      `A "redirectTo" Route replaced Page "${context.from}" to "${
        res.page.is
      }", which is started at ${context.startTime.toString()}`
    )
    res.page.setData(context.data)
    delete redirectToContext[res.routeEventId]
  }
})

In this example, we use routeEventId Connected once. redirectTo Page creation and page destruction in: Data from the old page is recorded when the page is destroyed and applied to the new page.

# Possible use cases

1. Route reporting, easy to restore the user path:

   wx.onAppRoute(res => {
     myReportAppRoute(res.timeStamp, res.openType,  res.path, res.query)
   })
   

2. When the Mini Program starts cold or hot, reset all states:

   wx.onBeforeAppRoute(res => {
     if (["appLaunch", "reLaunch", "autoReLaunch"].includes(res.openType )) {
       myGlobalState.reset()
     }
   })
   

   This can solve some common scenarios, such as the Mini Program is currently in the background, the user scans the code to start the hot, triggering autoReLaunch State cleanup is performed when.

3. A network request is made before a new page is created, so that the first screen of the page is created and the network request waits in parallel:

   const pageRequestData = {}
   wx.onBeforePageLoad(res => {
     pageRequestData[res.routeEventId] = new Promise((resolve, reject) => {
       wx.request({
         url: `https://mysite.wechat.qq .com /page-data?path=${res.path}&param=${res.query.param}`,
         success(res) {
           resolve(res)
         },
         fail(res) {
           reject(res)
         }
       })
     })
   })
   wx.onAfterPageLoad(res => {
     pageRequestData[res.routeEventId]
       .then(Data => {
         res.page.setData(Data)
       })
       .catch(err => {
         console.error("page Data init error", err)
       })
   })
   

   When pages are complex, page creation takes time. This takes advantage of the page creation time to wait for network requests to return, allowing business data to be applied to the page and presented to the user more quickly.