6.28 Work Summary:
Today’s biggest harvest is to achieve the antD Table component of the Table head at the top. The so-called table top position is that the table head can be placed at the top with the sliding wheel when the table length is infinite. < span style = “box-sizing: border-box; color: RGB (51, 51, 51); line-height: 20px; font-size: 14px! Important; white-space: normal; word-break: break-word! Important;” Note that the top should be set to top: XXX px! Important; Otherwise, the set property has no effect. The execution stack does not correspond to setState’s callBack. So I decided to switch to useLayoutEffect and call the variables in useEffect to render the page after all the data was completely changed. You’ll feel a lot better. Today a new function was used to listen for the entire page rendering
UseEffect (()=>{if(page === 1){getData()}else if(page > 1 && moreLoading){getData()} }, [page, moreLoading, tags]) model in the case of useUpdate (() = > {the if (deepEqual (anchorDetail, brandId. Current)) {return; } else { brandId.current = anchorDetail; if (page ! == 1){ getAnchorInfo(); setPage(1) }else { getAnchorInfo(); getCollectId() } } }, [anchorDetail]); If page === 1, then the page will go to another getPage, and there will be no bugs. This is probably the best way to write it so far. Better to deal with setState, but it does have to be hooksCopy the code
6.29 Work Summary:
Today, an attempt was made to refactor the previous code, using the new DVA to manage the entire state of the previously logically complex nesting of multiple components. In fact, it is very complicated, because table data is not only affected by data, but also hasMore,page,loading, etc., so I really need to use DVA to manage, I need to have multiple parameter variables to save, in fact, the gain is not worth the loss. The best thing for me to think about is using useReducer and Content. If I encounter this scenario again next time, I will definitely try it. Here’s how to handle general and asynchronous state in DVA:
- The general
state:{ ... count:1 }, reducer{ addCount(state){ const {count} = state return {... state,count:count+1} } }Copy the code
- special
state:{ obj:{} }, effect{ *fectchObj({payload},{call,put}){ const res = yield call(()=>{ fetch(url) },payload) if(res && res.status === 0){ yield put({ type:"saveObj", payload:res }) } } }, reducer{ saveObj(state,action){ return {... state,obj:action.payload || {} } } }Copy the code
6.30 Work Summary:
Today, I met a requirement that I need to reload a new page when the page jumps, and in the new page, if the previous page is in the login state, then the new page also needs to be in the login state. I have never met this requirement before, and I feel a little confused after encountering it. Watching the source code before the implementation, I just know what the idea is to do this: First of all, I need to go to the page to jump to find whether THE page I want to log in is in the login state, if it has logged in, then I do not need to log in again. If that side is not logged in, then I need to get the interface that I need to call to jump to that side, and when I call that interface, the browser will remember the logged in state and will be logged in on the new page. I could not solve this requirement before. I also called the login interface, and found that the login interface had been in the login state in the new page, but I still could not achieve the login state. I was at a loss as to why it happened (and I still don’t know why it happened). So I came up with another idea. Before I log in, I do a pre-loaded login with the page, windows.open(url), so that first the page opens up with a blank page, and then we can pass the URL that we’re going to use as a login request, and then the browser itself remembers the request to send. To render the page after the next request to the page, but in order to prevent too fast rendering page can not be used with timer. (Later, I thought it would have been better if we had used promise.) And here’s what I learned today:
- Know how to create a new page in a page:
- windows.open
- Make an A tag out of dom and click
const anchor = document.createElement("a")
const body = document.querySelector('body')
anchor.href = window.URL.createObjectURL(url)
anchor.download = filename
Copy the code
- Know the TWO-DIMENSIONAL code scanning is actually will produce a unionId(may also be other), through this Id to the database to find whether there is the same Id, if there is a return, there is no ignore
7.1 Work Summary:
Today I learned a tip: we can make the img image remain centered by adding the attribute object-fit:cover to it. The biggest thing I did today was to reconstruct all the Table components, put the request and all kinds of data in the components, and then pass them through the outside with a URL, and then transfer all kinds of query parameters through an object. If it needs to be changed, an object comparison method will be used to write in useEffect. This refactoring is the most satisfactory way I’ve written so far. After that, if all parameters that need to be changed are changed in the parameter object, the Table component will compare and request itself, and no longer need to manually determine various conditions. Come by tomorrow and I’ll refactor
7.2 Work Summary:
Today I wrote before all the two sides of the reconstruction, along with the Input components are also reconstructed, really realize the componentization of good, many complex components before we do not need to write more than twice. The experience brought by this summary, we will directly adopt the encapsulation strategy in the future if meeting the following conditions:
- Repeated three or more times in code
- Most of the code is the same except for the request part
- We should try to encapsulate as many components as possible in a project that are clearly organized, no matter how small, in order to unify the code
- More than 400 lines of code, or more than one useState definition of state, this is generally the use of state too much, see, not say, encapsulation