I'm developing a single page app that fetches data from the back-end to an AngularJS controller and then shows them in some grids and charts and stuff like that using KendoUI. Then I want to generate reports of these grids and I want it to be print-friendly; still fine.
The problem is that I want to add a footer row at the end of each printed page, that contains sum of all rows in that page, which I can't, because I got no idea about how many pages it takes and how many rows would fit in a page after printing.
I tried different ways like creating PDFs but the other issue is that most of pdf libs don't support UTF and that's something that I need.
What I want is: to have the number the of row elements in each "Printed" page, then I would calculate the sum row and add it to that "page". In fact I need something like "page-break event" or something like that, as the whole job would take place in JS runtime. But there seems no way to do this when printing HTML directly, Because the browser is the one that deals with the printer.
So the only way I found is to fix row heights and calculate how many rows each page contains, And hope that users don't change the paper size.
Is there any way?
PS. I wonder why I didn't find anyone with this issue. Because it's very common in report generators to calculate total of values in a page when printing.
Related
This question already has answers here:
Angular many rows grid performance in Chrome browser
(2 answers)
Closed 4 years ago.
I have a problem with Angular 6 performance issue. In the page there is a large table which has 100 rows and each row has 100 columns. Then this page is kind of laggy when I trying to use libraries like ng-select or ng-bootstrap datepicker, etc. Even if those libraries has no data exchange with the table. Which means even if the ng-select is just embedded in the HTML and has no data filled, the open and close of the ng-select drop down is laggy, takes about 0.5 sec to load. Same with other libraries. When I reduce the table to 10 rows, the lagging issue is improved significantly. Why does this happen?
Another observation is that when I use native tags of the HTML such as select option, it is not laggy at all, it react instantly. How to improve the performance in my situation? Thanks!
Code is basically something like this.
app-component:
<ng-select></ng-select>
<row-component *ngFor="let basket of baskets"></row-component>
row-component:
<div *ngFor="let apple of apples">
blah blah blah
</div>
It could also just be an issue of how many DOM elements that are being created and displayed on the page. You could try and use row virtualization which only renders rows that are displayed on the screen.
The fact that using ng-select makes the website more laggy than native html tags makes me think that the additional event listeners from the angular components have also decreased the performance of your webpage.
Ag-Grid has a great article about how they optimized displaying entries in a table. https://www.ag-grid.com/ag-grid-performance-hacks/
Do you use any library for the table like Angular Material?
One possible (and very common) solution is virtual scrolling:
https://material.angular.io/cdk/scrolling/overview#virtual-scrolling
There are a couple of things you may want to consider:
First, do you need to display all 100 columns at once? Is it possible for you to break up the columns into more manageable chunks, and maybe use a tabbed interface (Something like the Angular Bootstrap Tabset https://ng-bootstrap.github.io/#/components/tabset/examples) and group related columns into tabs to reduce the amount of columns you have to display on one page.
Second, there will be a performance issue when you get over a certain number of rows, which is where paging the data would be a good option (again, maybe look at Bootstrap paging https://ng-bootstrap.github.io/#/components/pagination/examples). You can set a hard limit - maybe 40 rows per page, or set the row limit dynamically by getting the browser window size, subtracting the amount of space you need for menus etc., and dividing the rest by the row height to determine how many rows will fit in the space you have available, and use that as your page size. This way you'll always only have to display a subset of the columns, and only as many rows as will fit on the screen without scrolling, and you should find your performance improves dramatically.
I have a table with thousands upon thousands of rows with 4 cells in each.
https://streamable.com/pywk9
You can see above my table is very big (no idea if its showing very well the laggy scrolling).
I understand this is because the browser has to actually render everything and with large datasets it could take time.
Is there a way WITHOUT pagination to make it more bearable?
Perhaps some way to render content ONLY shown in browsers view like a certain angularJS component (without needing angularjs)
A table that size is useful to nobody, you say you don't want to paginate but why? Pagination is a usability feature for a reason. Just implement pagination and searching. A grid with more than a few thousand rows is not going to be useful to anyone.
If you really need to have the table that big and scrollable then the technique used is to remove the item that are not in view out of the DOM. As you scroll you create DOM objects for the items as they come into view and remove them as they move out of view. This way there are not thousands of DOM objects the browser has to deal with.
I have a use case where there are thousands of items on a list shown to the user. They are loaded a small batch at a time and I see the network traffic going in and out, I see data getting loaded. I see the DOM getting bigger, but the list itself in the UI stops updating (Chrome).
When I examine it, I see thousands of items in the code, when I select the items through console and make it count them, I see the proper number. But in the page itself, I don't see these items get displayed. The list uses drag-and-drop to put items from it into another list (and load additional data about them).
Not using jquery.datatables at the moment, but been meaning to migrate to them a long time ago. I can’t find a good example, though, everything I see uses pagination to split, but what if this is not an option?
How can I pinpoint what it is that is preventing the items from display? The number of entries will vary between 500 and 20 000.
Never mind. everything works as intended, duh. I was stupid and missed something very obvious: things had "display: none" for a very good reason about which I totally forgot (has to do with the core logic of the application). Next time hit me with a stick so I could remember to pay more attention.
Not sure what you meant by saying 'DOM getting bigger' but 'don't see items get displayed'.
Typically JS has a main thread which will handle functions/callbacks as well as view-refresh. So if you operation is blocking , the view will not be refreshing.
As for the pagination is not an option thing, you can consider using DOM-lazy-Loading mechanism where you only put what should be in the current viewport into the dom. As user scroll, you calculate the scroll height dynamically to add/remove items to/from the DOM. One thing to remember is you typically need to define a fixed height for your rows so that you could do the calculation. This lazy-loading way is a common way of solving this type of problem and is widely used by different frameworks like GXT, angular-gird..etc.
I have a big HTML table (~10K rows, 4 columns, text only) dumped from a database. I'm experiencing poor performance when opening it in Chrome/Firefox.
I do not have direct access to database, so it is impossible to load page by page. All data is static HTML.
Does pagination with some jQuery plugin help improve performance in this case? Any other suggestions?
When applicable, setting table-layout: fixed helps in reducing rendering time a lot. The slowness is mostly caused by the fact that in the default table layout method, the browser has to parse and process the entire table, calculating width requirements for all cells, before it can render any part of the table.
Fixed layout tells the browser to set column widths according to the first row (paying attention to any CSS that may apply to it). This may, of course, result in a mess, if the widths are not suitable for other rows. For a data table where rows are generally very similar, the widths can probably be set suitably.
This does not change the issue that very few people, if any, are going to read all the 10,000 rows. People will probably be looking for some specific data there. It might be better to set up a search form that lets the user get just what he wants.
I had a similar problem and made a jQuery plugin:
https://github.com/lperrin/infinitable
To use it, you can load all your data with Ajax call, turn it into a huge array, and pass it to the plugin.
It basically hides cells that are not visibles, while making it easy to sort or filter cells. There are other solutions to achieve that, but this one has no dependencies besides jQuery.
The project contains a demo with a table containing 100,000 elements.
Pagination would most certainly solve this problem. You could also try initially setting the table style to display: none. Although the pagination should likely take effect before the browser attempts to render the table.
You could also store the table in a separate html file, do an ajax call to the document, and implement live scrolling. Although, this depends on how you expect the user to explore the data. If jumping to a particular rage like 100-199 is useful, a paginated table would be ideal.
I would like to display to user a table which contains ~500,000 rows.
The table should be calculated based on a file (i.e. the table is known at the beginning, and does not change).
I guess that building the HTML text of this table is not a good idea in terms of memory performance.
So how can I build such table ?
I would like user to be able to scroll the table using a vertical scroll bar. Is it possible to build on the fly only the visible part of the table ? I'm afraid to see delays because of this.
Is it a better idea to use server side programming rather than Javascript ?
I'm not restricted to any server side programming language, so any advise would be appreciated !
Send the first 250-ish rows to the user, as he scrolls down, perhaps past row 200, fetch the next 250 rows, append to the table and so on.
This is a (ui) design pattern known as "Infinite scroll".
Displaying 500,000 rows all at once to a user is a bad idea. Consider other options:
allow user to download file as CSV
show paginated (still not very useful)
provide filtering mechanisms (by date etc.) to allow the user to only see the data they need
If the users really needs to see all that data at once, then viewing it in the browser is one of the worst ways to do that - they should be using a tool made specifically for viewing data, like Tableau.
Classic example of where to use ajax.
Use javascript in combination with a server side script.
This really is a case for server-side pagination, I would say, maybe in combination with Ajax. A HTML table with 500.000 rows is going to crash a lot of browsers.
You're not specifying which server side technology you work with. If you update your question, I'm sure people will be able to give you some pointers.
Try this:
Clusterize.js
Tiny plugin to display large data sets easily
https://clusterize.js.org/
Is it possible to build on the fly only the visible part of the table ?
If you build a "fake" scroll (e.g. jquery slider) you can retrieve parts of the table instead of the whole.