Mobile terminal as an important entrance to the Internet, it has long been common for front end engineers to develop mobile terminal pages, and most of them are embedded in the client (APP, small program) H5 pages, that is, WebView

Once, I was asked a question by a colleague. He had a demand for a page embedded in the app of the client, and a function point was to intercept the return operation of the client, so as to realize the display and hiding of the shell layer in the page. The intercept point included the return button on the app page and the physical button of android, similar to the following:

Click on the shopping cart, shopping cart from the bottom of the page up to display an element, click on the mask layer, hidden layer close, this is very normal operation, and in addition, also need to implement a feature is, click on the screen or return key of the android machine physical return key, can also close the layer thickness, and ensure that the page does not jump

I smiled and asked him, which stupid PM asked for his needs? How does H5 block the operation of APP or even physical button? You didn’t tell him off at the time? Does the client side provide an SDK interface for intercepting returns? My colleague replied that SDK did not provide this capability, and he felt it was difficult to implement, but PM insisted on doing this function

So I hold anyway is not my demand, I am unimaginative zhang mouth to make a blind suggestion also has no relation to help others happy attitude to think for a while, who knows really let me think of a plan (I am not sure is not seen in any place before, in short is thought of), came back to verify once, is really feasible

The key point is that using the fact that a return action triggers a route change to simulate interception does not actually listen for or intercept on-screen or physical return key clicks

The routing configuration

Suppose that the route on the home page for simulating the interception return is /physicsBack, and there is a subroute /physicsBack/footerModal. When the route is /physicsBack, only the page is displayed. If the route is /physicsBack/footerModal, the bounce layer is displayed on /physicsBack

In this case, /physicsBack/footerModal is referred to as a subroute, but really we just want to use it as a routing capability that intercepts return operations, so you don’t really need to configure a page for this route. You could do that, and it would work, but it’s a little bit more cumbersome

I point /physicsBack and /physicsBack/footerModal to the same page, the main page, and then monitor the route to control the display and hiding of the shell layer

The route configuration is as follows:

 const router = new VueRouter({
  routes: [{
    path: '/physicsBack/(footerModal)? '.component: physicsBack
  }]
 })
Copy the code

/physicsBack/(footerModal)? Both /physicsBack and /physicsBack/footerModal are matched, so either route /physicsBack or /physicsBack/footerModal points to the physicsBack page. Even if the route switches back and forth between the two, the page does not change

Routing to monitor

Although switching between route /physicsBack and /physicsBack/footerModal does not cause a page switch, it stays on the physicsBack component all the way through. However, the Route can be monitored on the physicsBack component. Then, according to the monitored routing changes, the hidden and explicit of the shell layer can be controlled:

watch: {
  $route (to, from) {
    this.manageFooterModal(to.path, from.path)
  }
}
// ...
manageFooterModal (toPath, fromPath) {
  if (toPath === '/physicsBack/footerModal') {
    this.visible = true
  } else if (fromPath === '/physicsBack/footerModal') {
    this.visible = false}}Copy the code

When toPath is /physicsBack/footerModal, the route is switched to this location. It is specified that when the route is switched to this location, the bullet layer is displayed.

When fromPath is /physicsBack/footerModal, you should move back or jump from a page with an ammo layer, you should disable the ammo layer

You can also use vue-Router hook functions (beforeRouteEnter, beforeRouteUpdate, beforeRouteLeave) to achieve the same effect. These hook functions simplify the process even further, but the essence is the same. The purpose is to listen for and control routing, so even if you don’t want to rely on the capabilities provided by the framework, This can also be done by setting the native listener window.addeventListener (‘hashchange’, callback) or window.addeventListener (‘ popState ‘, callback)

In addition to routing, page elements must also be able to control the hidden and explicit aspects of the shell layer, such as clicking on an element to pop up the shell layer, so that it is appropriate for the real use of the scene

Similarly, the implicit display of the shell layer is actually controlled by route switching, so if you want to change the implicit display of the shell layer inside the page, it must be completed through route switching:

changeVisible () {
  if (this.visible) {
    this.$router.go(- 1)}else {
    this.$router.push('/physicsBack/footerModal')}}Copy the code

Since this actually takes advantage of the system’s return capability, the same effect can be achieved whether you use the screen return key or the physical return key in the browser or in the webView of the client app

The results are as follows:

We’ve made a Live Demo, so if you’re interested, you can try it out for yourself, and the code has been uploaded to Github

summary

The ability to simulate the interception of the return key via routing in this article is not only applicable to the shell example, but other return related operations are theoretically conceivable, such as return redirection, preventing users from quitting the page (what kind of stupid requirement is that) etc