Shulou(Shulou.com)06/03 Report--

This article mainly introduces the layui table data change processing methods, has a certain reference value, interested friends can refer to, I hope you can learn a lot after reading this article, the following let the editor with you to understand.

Table data change generally includes several contents: add, modify, delete, move. One of the problems often faced in development is how to synchronize the data to the node after the change. Personal advice has always been to use table overloading, whether it is url mode or data mode actually need to be overloaded, url overload will naturally re-request the background to get the latest data, data mode is generally the operation of data Then re-render it with a new data.

At the same time, we will consider how to minimize requests, probably the deepest feeling is the update operation, in order to update this record and reload the entire table, it does not feel worthwhile to request data, so generally speaking, you can use the obj.update method in the tool event of the table to update.

However, many shortcomings will be found in the specific use. This paper mainly deals with these deficiencies and gives a tablePlug.update method, and then derives add, remove and move, and adds a new method to update statistical row data.

Test page: comprehensive test page flow load table test page regularly refresh table test page

1. Update

As mentioned above, obj.update (data) has many limitations, but its advantage is that it updates the data with the minimum modification cost. It updates the data of the keys in the data in the parameters, and does not update the entire row, let alone the nodes of the entire table. The disadvantage is that there is something wrong with the underlying implementation logic:

1. By traversing the data, update the value of the key recorded in the cache cache, and then update the content of the td according to the configuration information of the cols. However, if you want to update the toolbar column, it is not possible. Currently, only templet is parsed, so if you want to update the toolbar, you can only set it to templet, and it is theoretically possible to add a field to this column.

2. The toolbar column may not be updated even if it is changed from field to templet, because the internal implementation logic first determines whether the original data has this key, so if the field name is not found in the original data, it cannot be updated later with obj.update, which is a big limitation.

Because take our project as an example, if the data given to us by the backend does not have the value of this key in the original record, he will not give a key:'', then it will be impossible to use the key of obj.update later, unless we use parseData to do an artificial initialization of the data given by the background before rendering to add the corresponding key, but you can imagine how troublesome it is.

3. The data is updated one by one, and then the corresponding td is updated by updating a value, but there is another risk in this, that is, traversing the object is unordered, such as update {a: 1, bcols 2}. If the value of the b field is used in the cols of the a field, it will be displayed again.

So if the traversal order is to update the value of a first, and then start to update the td content of a, at this time, the value of b in cache is still old, not the 2 you want to update, and when the b field is updated, he cannot say that he detects that other fields have used this field to update each other's content again, which leads to the wrong result of a.

4. The corresponding data of a value statistical row of the updated statistical column is not recalculated.

To sum up, the implementation of obj.update is still too idealized and too simple, there is no problem with a record that each key is independent in terms of data, but it is not so when it comes to the display of the page, because the content of the page is not always a simple value display of a single field, but also carries out some special processing.

So you need a templet to convert and customize, so it is normal that multiple fields will be used in a td, and the buttons of the toolbar will also decide whether some of the buttons are displayed or not according to the state of the data.

So I think that to update this data can not be an independent small unit update, but first update this row of data and then in the update this row, rather than traversing the update key one by one updated, and then look at the larger, the actual record of this table is also a whole.

Also can not say that you changed this record other records must be unchanged, do not rule out the td of a field he will do according to the current page of the same field what to deal with reality, such as statistical rows, so the current idea is to directly update the value to cache, and then call the table internal rendering tr td content.

The approximate code:

The front is to do some processing for the parameters to make the parameters more flexible, the most important thing is to update the part of the cache in the second half, and the most important method of renderData:

Its function is to parse and render the data in cache again, and to deal with whether it is moving data or not, and to click on that record by default, but the core is to render cache and call renderData inside table.js.

Use the scene:

1. Knowing which record the current editor is modifying, you can take a look at one of the most commonly used scenarios, that is, click to edit and pop up a form and then modify and submit. After completion, you hope not to re-request the API to be updated to the data and page.

Gif is very difficult to record. You can test the effect by using the edit button in the test example.

The updated data called is in the form of:

TablePlug.update (id of the table instance, index of the current tr, newData)

2. If you do not know a record in the current trIndex, there must be a restriction that it must be a table with a primary key, and the updated data must contain the field of the primary key, otherwise you do not know which record is being updated.

TablePlug.update ('demo', {id: 10002, username:' virtuous'})

3. If you update multiple records at one time, this parameter trIndex is meaningless, and it is useless to add it. Because it is updating multiple records, you can write it this way.

TablePlug.update ('demo', [{id: 10002, username:' virtuous'}, {id: 10006, username: 'thief', age: 18, sign: 'uncle'}])

On this test page, you can take a look at the "integral zeroing" and "female score plus 100th" test buttons in the header toolbar, as well as the execution methods of the events behind them.

4, more capricious, as long as the input of a tableId,update will render the current data according to the cache, this is very practical, for example, if you think the logic parameters in my update are not satisfied with the logic of the modification of cache, you can use your own better way to deal with cache, and finally implement tablePlug.update ('demo') to provide higher freedom, and the possibility of expansion.

II. AddData

The records added by addData are the data records that have been returned by requesting the API to complete, which is different in nature, so don't be confused.

The code of specific addData:

In data mode, you actually add some records to data, and then reload it again.

/ / add a single record: tablePlug.addData ('demo', {id: newId, username:' A'}); / / add multiple records tablePlug.addData ('demo', [{id: newId1, username:' B'}, {id: newId2, username:'C'}])

There is a comprehensive example of addData to see how table's data mode can be used in conjunction with stream loading to make a stream loaded table.

Https://sun_zoro.gitee.io/layuitableplug/testTableFlow

III. Del

It is safe to add and delete actual personal suggestions or reload, regardless of whether it is url or data mode, so the corresponding processing method for deletion is similar to the actual addition, except that the trouble of deletion is that data mode needs to delete the specified record in the original record.

And it is possible to turn on the checked state memory, and if the state memory is deleted, it is necessary to adjust his state; or to make it easier to use, the parameters are also processed

1, delete the specified subscript data, you can view the toolbar of the table row in the delete button listening processing, but note that if the table is in url mode, the current test page is written in json files, so reload will not be effective.

So to test in data mode, do not worry about this. If the url is the actual service interface, the data is returned at the backend. Generally, the query will not come out again after the deletion is successful, unless there is a problem with the backend interface.

2. Delete some specified records. This usually comes in two forms, but the same requirement is that it must be a table with a primary key.

/ / id collection tablePlug.del ('demo', [1 id 2, 3 id:4 4]); / / object array tablePlug.del (' demo', [{id:2: 1, name: 'name1'}, {id:2}, {id:4}])

According to which kind of data is more convenient to use, you can refer to the batch deletion method of the test page.

IV. Move

This process is basically similar to update. Just reposition the data in cache, and then call the method of renderData inside the component to re-render it.

Then a method of moving up and down is derived for convenience.

Effect.

In theory, you can use some drag-and-drop events or other plug-ins to call tablePlug.move ('demo', form, to) in the event; you can change the order arbitrarily.

Limit: pay attention! This is only for data movement, there will be no changes in a single data record. If there is a click sorting in the original data, then the sorting state will be removed by default after moving, because the current sorting rules may not be satisfied after moving, so it is recommended not to match with sort when using mobile. If there is a sort and the so-called mobile will initiate a request to change the data. So the suggestion is to use the request interface to get two new data and then use update to update their location.

5. RenderTotal

After the record is updated, if there are columns in statistical rows that need to be counted, then the values generally have to change. Another more important role is that you can customize statistical rules instead of your own summation, you can customize certain calculation functions, or you can directly customize the returned content like templet, including asynchronously reading the data you want to display.

The code is roughly as follows:

As can be seen from the implementation code, you can add a totalFormat setting to the field configuration of cols. You can set a rule that is sum if not set. (currently, only sum is added. Other rules will be added later or by themselves, such as average.

The maximum and minimum, but I think the main meaning is that you can customize the method, which is commonly used), or you can set a method that can return the result directly if it is not asynchronous. If it is asynchronous, it can also be executed when you get the final desired result:

TablePlug.renderTotal (tableId, field, res)

Such as the following:

If it is usually practical, you don't have to call it yourself. Inside the plug-in, you will execute it in the renderDone callback:

Parameters are also relatively free, different combinations will have different effects.

/ / trigger to update statistics renderTotal (tableId) for all columns of a table; / / trigger to update data renderTotal (tableId, fieldName) for a field in a table; / / update statistics for a field in a table as valuerenderTotal (tableId, fieldName, totalValue)

VI. Refresh

I have made a modification to the intelligent reload before, that is, when executing the table.reload, I will judge whether it is just a re-request for data or a reload based on the passed option. I think the effect is good.

However, for partners with obsessive-compulsive disorder (pursuing), it is not good enough in some scenarios, that is, those that are refreshed regularly, that is, on the one hand, the scroll bar will return to top:0,left:0, and others, such as the mouse will lose focus when operating the paging component, and add a tablePlug.refresh to see if it can meet the requirements.

Let's first look at the effect:

What was done behind the incident:

Form config:

The realization idea behind it.

Modify Class.prototype.pullData of table to support refresh mode

When renderData, it is necessary to deal with some details according to whether or not refresh. Another limitation is that the total amount in the returned data should remain unchanged. If there is a change, it will still renderData and re-render the page component.

Another limitation is that this kind of refresh form does not recommend adding any more buttons, ah, edit, because it will always change, basically, it is mainly used to make a table that is simply used for display, such as some frequently changing data, visits, stock dynamics and so on.

Use:

/ / start the automatic refresh function of form demo, tablePlug.refresh every 500ms ('demo', 500); / / cancel the automatic refresh tablePlug.refresh of form demo (' demo', false); / / stop the automatic refresh tablePlug.refresh (false) of all forms that have automatic refresh enabled Thank you for reading this article carefully. I hope the article "how to deal with data changes in layui forms" shared by the editor will be helpful to you. At the same time, I also hope that you will support us and pay attention to the industry information channel. More related knowledge is waiting for you to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.