We are using jgGrid and it works perfectly fine. Let me explain how the grid is setup, we are fetching json data from server, loadonce: true.
Now we want to update the grid every 20 seconds, so
setInterval(function () {
$("#jqGrid").setGridParam({ datatype: 'json', page: 1 }).trigger('reloadGrid', [{ current: true }]);
}, 20000);
This is working fine. Issue is that, it entirely refreshes the grid, we want to update the data which is changed. I mean if there is change in only one cell of a column, only that cell should be changed.
Having entire grid refresh is causing issue on sorting and search filter. It replaces everything after 20 seconds.
Thanks in advance
The most simple way to solve your problem would be the usage of beforeProcessing callback which returns false if the data are not changed. It will prevent reloading of the grid in case if the data returned from the server are unchanged (compared with the previous response). I described the scenario in details in the answer. The main problem is: how to determine that the returned data are the same. In the referenced old answer I calculated MD5 cache from the data on the server side and set the value as Etag. Alternatively you can use CryptoJS to make the calculation on the client side. The 3-d parameter of beforeProcessing callback is jqXHR, which is a superset of the XMLHTTPRequest object. It contains for example responseText property, which simplifies MD5 calculation. By usage of jqXHR.getResponseHeader("ETag") you have access to the ETag HTTP header.
Reloading of the whole grid makes typically no performance problems. It's important, that modification of one cell of the grid follows to reflow or probably changing position of another elements on the page. Reloading of the whole grid is implemented as one assigning of <tbody> of the grid (if you use fill the grid correctly and if you use gridview: true option). It seems to many additional work, but it could be more quickly on the practice as sequential changing of multiple cells in multiple rows of the grid.
In any way I'd recommend you to start with implementing beforeProcessing callback, which returns false in case of unchanged server data. Only if you would have some real performance problem then you should analyse the performance problem detailed, and probably make more deep changes in your existing code.
Related
Using ag-grid-community 22.1.1 version in Angular 7
If we go by official docs then client side model should load only the records available or set in pagination size. But that does not happen. When browser makes a request it waits till all the records are loaded and response is returned before the view starts rendering.
Can someone explain is my understanding wrong from the below wordings
Here are more detailed rules of thumb.
If you are not sure, use default Client-Side. The grid can handle
massive amounts of data (100k+ rows). The grid will only render what's
visible on the screen (40 rows approximately, depending on your screen
size) even if you have thousands of rows returned from your server.
You will not kill the grid with too much data - rather your browser
will run out of memory before the grid gets into problems. So if you
are unsure, go with Client-Side Row Model first and only change if you
need to. With Client-Side, you get sorting, filtering, grouping,
pivoting and aggregation all done for you by the grid. All of the
examples in the documentation use the Client-Side model unless
specified otherwise.
Link to official docs explaining different row models and when to use what.
Based on that if am expecting my api is going to return 500 records and my [paginationPageSize]="40"
Should't it load 40 records and render,although in background it can still load all other remaining records to the browser cache. But it looks like it is waiting for whole set of records to load to browser cache and then starts rendering which is impacting the performance.
The below is the line confusing the most
The grid will only render what's
visible on the screen (40 rows approximately, depending on your screen
size)
ag-grid and for that matter any grid, in client side model, will fetch all the records first and then starts rendering in browser. But, it will only render the numbers of rows which fit into the visible view. This is for a very good reason.
Consider a scenario where the user of your application is searching/filtering on a certain field in the grid, if grid does not have all the data with it at that time (it is still fetching from server in background) it may return Not Found even though matching record(s) exist(s) in the data which is yet to come. Same problem would be there for sorting,grouping etc. operations.
This link on ag-grid doc states clearly
By default the grid expects you to provide all the data up front. In
other words, your application loads the full set of data into the
client and then passes it in its entirety to the grid. This is in
contrast to Server-Side Data where the data is mostly kept on the
server and loaded into the grid in parts.
Now, the reason it renders 40 or so record in view is because creating and rendering HTML for all rows will make the page very slow or unusable.
You need to opt for server side model if you wish to fetch data in chunks from server. But then it involves more work to implement filtering,sorting etc.
I have a data grid which is bound to a ItemFileReadStore. In my case, I have a "prioritize" column to shift the rows up-down as per user's selection. The prioritization order is stored in DB table. Currently I have achieved it by sending AJAX request on each Up-Down arrow click and getting the updated data in JSON object and reloading the entire data in the data grid.
But I think that's too much of data carrying. what I am looking for is: after updating the data in DB, if the update was successful, I would just pass a success flag to the calling JS method and I would update the data locally in the store at client side. That would make the response faster and will take less network load.
I know it can be done in ExtJS (http://docs.sencha.com/extjs/3.4.0/#!/api/Ext.data.Record-set) but not sure how to get in Dojo. I went through the documentation but could not find anything helpful.
Can anyone please guide me thought this?
It would be much easier to answer if you define what is your resource behind.
I had an exact problem and solved it with JsonRest together with dgrid.
From your question I have understood that you are sending AJAX requests to a DB and this means that you have (hopefully) a small REST API in between.
If so, I would suggest to switch from ItemFileReadStore to dojo/store/JsonRest which actually does not harm your existing data manipulation architecture but even greatly improves it.
dojo/store/JsonRest will do exactly what you are looking for and even more. Any small change in store will be handled gallantly as you mentioned, without expensive update of entire data.
Sorry if it doesn't solve your problem.
I've been fruitlessly been trying to get jQuery.dataTables to allow me to update the data in the table using Javascript. I know this has been discussed on SO before, but I haven't been able to make any of the solutions I've seen work.
I have a parameter called data that represents the data to display in the table. It is passed into a function.
I would have thought that the way to update the data would be like this:
// I checked that the new data is returned by $table.data() afterwards
$table.data(data);
// Now that the data is updated, redraw the table.
$table.fnDraw();
Nothing seems to happen when the above code runs. What am I doing wrong?
I have no trouble using fnUpdate to update the data in individual rows, so I find this particularly perplexing.
Update: After giving this some more careful research, I found that I can almost achieve the desired result by doing the following:
$table.fnClearTable();
$table.fnAddData(data);
$table.fnDraw();
However, the problem with the above is that the user loses his place in the pagination and has to navigate back to the page he was on.
Well this was the issue i faced back then Allan suggestion worked high time for me.
Try this :
Using the new API you would call draw() with the parameter false. In the old API you would use fnDraw likewise (and also in fnAddData use the parameters to not redraw).
Let me know just in case .
Coming from Python/Java/PHP, I'm now building a website. On it I want a list of items to be updated in near-realtime: if items (server side) get added to or deleted from the list, this should be updated on the webpage. I made a simple API call which I now poll every second to update the list using jQuery. Because I need some more lists to be kept updated on the same page I'm afraid this will turn into more than 10 server calls per second from every single open browser, even if nothing gets updated.
This seems not like the logical way to do it, but I don't really know how else to do it. I looked at Meteor, but since the webpage I'm building is part of a bigger system I'm rather restricted in my choices of technology (basic LAMP setup).
Could anybody enlighten me with a tip from the world of real-time websites on how to efficiently keep a list updated?
You can use WebSocket(https://code.google.com/p/phpwebsocket/ ) technology.
but php is not the best language for implement it
A way to work this is using state variables for the different types of data you want to have updated (or not).
In order to avoid re-querying the full tables even if the data set in them has not changed in relation to what a particular client has displayed at any given time, you could maintain a state counter variable for the data type on the server (for example in a dedicated small table) and on the client in a javascript variable.
Whenever an update is done on the data tables on the server, you update the state counter there.
Your AJAX polling calls would then query this state counter, compare it to the corresponding javascript variable, and only do a data-update call if it has changed, updating the local javascript variable to what the server has.
In order to avoid having to poll for each datatype separately, you might want to use an JS object with a member for each datatype.
Note: yes this is all very theoretical, but, hey, so is the question ;)
This is an ajax questions. I have a table this table shows users information at certain time depending on what settings the user sets.
Now in some cases a user will see the information right away and in some cases they won't it all depends on when they want to see the information.
Now what should I do?
Should I do? do a post and post their data and then do a ajax get after to get the table and render it?
*I probably could it all in the post but unless some huge performance gain is gained I rather not otherwise I have to do mix "success/fail" messages and the table to be rendered all in the same response.
So each one seems to have pluses and minuses.
Ajax way
don't have to worry about having a
JavaScript solution that queries the
database to figure out what their
timezone is and then determine if the
row should be added or not and any
other headaches that comes with
javascript dates.
Each row could potential have a
different style to. This would
mean I would have to possibly do a
query to the database and figure it
out or have hidden field in the page
for easy access. With Ajax way I
would not have to worry about it.
don't have to worry about making a
manual row in javascript/jquery
syntax what can be a pain to do if
you have many columns.
Javascript way
Problem less of a performance hit
since only have to potentially make
one new or do nothing. Where
otherwise I have to generate a new
table regardless and if it has lots
of rows in it that could be slow.
Have to rebind all jquery plugins
that would be on the table. Or use
jquery.live for everything else.
So I am not sure to me it seems like a hard choice.
Unless I misunderstand what you want to do, why not do both in one solution?
Return a JSON response, so, when a user logs in, you post the information using an ajax call, and just return the data from the database. I tend to return either data or an error message, but you could have two objects in your json string, one for a possible error message and the other being the data that is being returned.
The javascript then can process the data as is needed.
So, you do both, it isn't an either/or decision.