1. The demand
In project development, the front-end inevitably encounters the need for routing cache. In a previous React project, after querying various data and plug-ins, I learned that React needed to work with React- Router for route caching, which caused many unexpected problems. So in the React project, we avoided receiving the need for a route cache.
Recently in the development of a VUE project, because vue has a native keep-alive component as well as include, exclude various apis to implement route caching. So we decided to take the plunge.
2. Hit the pit
At the beginning, we directly wrapped the router-view with keep-alive and added the route fullPath as the key value of the router-view. Then we used include to define the components that need to be cached.
And in the route customization meta to define whether keepalive requires cache fields to handle caching
For general projects, this is actually the way to handle caching. However, we are the management system corresponding to the B side, there will be menu page, Tab page, a route may need cache in different cases and do not need cache in two cases. KeepaliveList or $route.meta. Keepalive does not trigger component cache destruction or recaching. So we have to change the way to do it.
3. Clear the detail page cache
Our project will take the form of multiple tabs, something like thiselement-uiThe Tabs component of the
We configured the same routing under the same TABpageKeyRepresents a routing component under a TAB.
According to the configuration above, components A and B are under one TAB, and C is under another TAB.
After the router-view is wrapped with keep-alive, it can switch between different tabs, switch routes, and cache pages, but jump from the list to the details page under the same TAB. We need to clear the cache and re-query data every time the details page enters. Because of these two components that need different caching effects, we add a noCache field in the route definition, which defines the route of this field, indicating that the cache is needed when switching between different pageKey routes (representing different tabs), and when switching between the same pageKey routes (representing the same TAB), No need to cache and clean up.
After the query information, realize the vue store cache component to $vnode.parent.com ponentInstance. The cache, we had an a method using the vue routing hooks clear the cache.
When the detail page is opened for the first time and returns to the list page, the beforeRouteLeave hook function is called to clear the cache of the detail page.
4. Disable TAB cache clearing
Another problem is that each TAB has a close button. After clicking the close button on a TAB, all component caches of the same pageKey for that TAB should be cleared. Here we set the vuEX global variable in the close button event and add it to the global beforeRouteLeave judgment. If the global variable changes, it indicates that the close button was clicked. Then we clear the component cache list with the same pageKey inside the clearCache method.
5. Return the list cache query criteria and check the data
At this point, most of the caching problems have been solved, but our lovely product dad suddenly gave us a new requirement. When the details page jumps to the list page, we need the query condition of the list page to exist, and we need to revisit the query. At first we decided to consider a new solution to clean the list page cache and store the query criteria for the following table pages. Since the noCache field is not set on our list page, the conditional cache for the query list exists and we only need to retune the query interface.
Following this thread, we give the details page when it jumps back to the list pagemetaAdd a new objectbackSearchFields, inbeforeRouteLeaveIf captured infrom.meta.backSearch, the property is deleted and setto.meta.backSearch=trueAnd set a globalactivedIf the cache hook detects that routemeta.backSearchField, automatically calls the component definedmyOptionMethod is actually the component’s query method
6. Solution – CLEAR the cache of RANDOM URL numbers
This probably solves all of the business’s caching requirements. But in the recent development, because of the user’s SAO operation, broke out another bug of cache.
The trigger condition for us to clear the detail page cache is the jump between the same PageKeys, for example, the detail page jumps back to the list page, but the user enters the detail page by directly clicking the menu to enter other pages, and then clicking the list menu to re-enter the list page. The routes jump in the case of different Pagekeys. The detail page cache logic is not triggered.
We are paying attention to ourrouter-view keyThe fields are$route.fullPathSo we decided to giveurlAdd random numbers to solve this problem.
7. Conclusion
I haven’t found an industry-recognized caching solution yet, and we’re working on it. Our method may be cumbersome, but it is currently able to solve our development needs, if there is a big man can give us some valuable advice, we would be very grateful.