nonsense
Bell out of town building!
In fact, I feel that this is nothing to be taken out alone, but a little idle recently. But this technique is also very useful.
1. The reason for writing this article is that I see a misconception about state management (correctly called data management or front-end database management).
2. Use Axios to optimize interface requests and cancel repeated requests. There’s a better way.
Eliminating interface duplication is actually a very good optimization sometimes on a project, but a very bad one. See the article, haha
First, the type of data cache
1, localStorage
The size is 5M, the file storage level, the browser cache does not disappear if the browser is not cleaned
2, sessionStorage
Size 5M, memory level, but lost when the current TAB is closed
3, Cookie,
In terms of 4097 bytes, the front end can manipulate (the back end can define data that cannot be manipulated), but it is generally defined by the back end, and newer browsers are gradually discarding this feature
4, with IndexedDB
Minimum 250MB, file level (transaction support, an alternative to WebSQL), need to clean the browser cache. It usually doesn’t, mainly because the browser doesn’t work as a client. You can use it as a local client, such as electron
5. Memory storage
It’s variable storage, which is kind of off limits, depending on how much memory you have
6,…
And then there’s webSql and all of that, in many ways. That’s the mainstream
Ii. How do I use these stores for my daily projects
1, common situation or early
In the front end has not been too developed before, in fact, the front end storage data should be memory storage as the main way. But as soon as the memory store is refreshed, it’s gone.
Later, in addition to cookies, browsers support sessionStorage, localStorage, WebSQL and other ways, the front end slowly know that the original browser can store data. This is the foundation of a client-oriented front end.
But in many front-end beginners, are directly take localStorage API directly up. This page needs, let me write one, that page needs me to write one. The project got bigger and bigger and I don’t know where to write another one. And then when you run the debugging, you find that the previous storage is overthrown. Just as var variables were promoted to global variables before, such a front end would not be a big project
2. Think about front-end storage (unified management of front-end data) from back-end development experience
Storage on the back end is actually a little easier to understand, memory storage, hard disk storage
Then the main tool is the database, divided into memory database and file database. MySql belongs to the file database and Redies belongs to the memory level. All are viewable and relatively uniform. The backend looks at database fields before writing data, and then operates on the data store based on the data. But the front end is a mess
That front end can also do a unified database? The answer is definitely yes
3, from the modern front end frame can reverse the previous project (wheel capacity)
1. Store front-end state management of REdux, VUex, etc., from react, Vue framework, which is a set of aggregable and manageable JS memory
Ps: A lot of people who don’t have a deep understanding of the front end take this as state management, poking fun at those who don’t understand the management, front end and back end. Isn’t this a natural front-end database
2, with the existing plug-ins, vuex persistence, Redux persistence, this state library into a front-end database?
3. Standardize the contract for the project
Although the front-end project database problem is solved, there is a need for conventions. The convention is that you can no longer write to storage directly when operating apis such as localStorage. You must access the vuEX and other capabilities to operate data from the VUEX and other state libraries. So from a data storage perspective, it’s pretty clear.
4. Reverse previous projects
For modern frameworks such as Redux and VUex, it is very convenient to cooperate with persistent storage such as localStorage. But without Redux and Vuex? It’s actually pretty simple.
Take vuex for example, vuex is a JS file, you define this JS file data storage add, delete, change check API, and then combined with localStorage not good.
I will not write the code, god all understand, small white can search localStorage unified management scheme.
Vue project VuEX + Vuex-PersistedState. All data operations use VUEX
React redux+redux-persist Vue go with what I recommended above.
Use variables to optimize your interface requests
Here’s the big part. It’s really easy.
1, talk about interface request optimization, cancel repeated requests
When can repeated requests occur?
Hands shake, accidentally request twice in a row. In the old project, there was a data interface, such as the classification interface, which was used in many places.
The first case should be solved by throttling and anti-shaking design patterns. What about the second? It’s not an exception. It should be done.
2. Eliminate the disadvantages of repeated requests
If it’s a new project, you’ll need fewer data interface requests. Naturally, this is not likely to happen. But what about one of your old projects?
Personal example: I worked on a two-year old front-end project at Cloud Ask. Maybe the initial project is too small to have these problems. But as the project grows, there are several basic data fetching interfaces in the page. Such as province, such as classification and authority and so on. A former colleague used Axios’ intermediate interception capability to cut off repeated requests directly. All right? Multiple direct failures in the project. Helpless to give up performance optimization for business.
3. Use the front-end database capability to cache the interface data in advance and store it in VUEX and other places
The idea is very good, but the previous people did not use this set, the cost of your access to this management scheme is at least three js file change levels. What do you do?
4, clever use of JS files and declare variables
Principle: JS memory variable ability and JS file cache ability
1. First of all, the variables you declare need to be exported in a JS file. You will find that you can retrieve variable values stored in this file everywhere. Can you get the value after you change it?
2, the basic short time will not change the data of the interface data, after the request to store the data in the JS file variables, when repeated requests, determine whether the variable has a value, there is a direct value. Does that mean the interface won’t go through the background interface the next time a request comes in?
5. Practice code (code from the project)
This is code from one of my projects, where one place is a cascading component. Component needs to select video data, script data. Cascaded components are used in many places. But loading a component every time causes the interface to request data, which is a big problem. Users will feel stuck. In fact, the product did not think, I added the function. alas
The code is vue2 code
First declare a store.js file
Import Vue from 'Vue' const Store = vue.Observable ({AllVideo: new Map(), // All videos, AllDrama, new Map(); New Map(), // All scripts, * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * } export { Store, Mutations }Copy the codeImport functions in cascading components
import { Store } from 'store'
Copy the codeComponent part, eliminate redundant logic and processing, present a simpler structure for everyone
<script> import { Store } from '.. /store' export default { data() { return {} }, methods: Async getAllVideo() {try {let materialType = this.materialType materialType = materialType === 3? 2: This. materialType // Returns if there is data in memory, Get (materialType) if (typeData) return Promise.resolve(typeData) // Request interface const typeData = Store.allVideo. get(materialType) if (typeData) return Promise.resolve(typeData) // Request interface const result = await Service.VideoServer.videoList({ data: { corpId: this.$store.state.userInfo.corpid, filterStatus: [1], page: 1, size: 2000, }, }) const records = result.data.records ?? [] // materialType (materialType, materialType, materialType, materialType) videoList) return Promise.resolve(videoList) } catch (e) { return Promise.reject(e) } }, }, } </script>Copy the code6. Precautions
In fact, it’s as simple as that, and it’s easy to optimize requests off the page. There will be no overall adverse effects.
Note: this is the main part of your own extra storage, memory storage, with the refresh will be lost. But the storage stays in the page’s memory until the page is refreshed. Use with care, do not cause memory leaks.