I would like to know if anybody knows a more efficient way to show / hide columns in a table powered by angularjs:
I have a large table (20+ columns, 1000000+ rows) and implemented a feature to show / hide columns based on user preferences. I do this via ng-if on every table cell. This triggers a large watcher count on initial load of the table and the angular digest cycle is going crazy with more then 4000 watchers on a single page.
My main idea to solve the performance problems was to reduce the watcher count. For this purpose I use this library that does nothing else then disabling watchers that are not in the viewport. So far so good, performance got better, but what if I would add more and more features to the table? It looks like this show / hide columns feature will be my performance bottleneck forever (and according to chromes angularJS digest timing analyses it is).
Conclusion: ng-if doesn't look like a good approach to show / hide columns because of the high watcher count and bad performance. Does anybody know a smarter solution to show / hide columns?
Edit: I already have pagination of 200 rows per page, however the problem still persists and of course I aim for a scalable solution.
You can try with CSS classes applied to the all table cells and respective header cells with different class names.
EG: column-1, column-2 ect
Define the class definitions in the angular string and place in between style tag as expression
EG:
In controllers js
$scope.columnStyleDefs = '.column-1{display:none},.column-1{display:table-cell},...';
You can chnage "columnStyleDefs" as necessary when user change their preferences
In html template
<style>
{{columnStyleDefs}}
</style>
I home this may help you for the above assignment.
Related
How can I detect if a Table will trigger a new page and conditionally do things that make the printed experience better?
For example, if I have a table that must span a page break (despite intelligent use of the break-before / break-inside CSS properties), can I detect this and do something like re-render the column headers? Is there a way that I can detect the size of my output as it is rendered to understand if I'm in a page break zone, and then conditionally reform my html to accomodate?
I'm currently programming in Angular - but any JS/HTML/CSS based solution I'll be able to adapt.
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.
Hi fellow Javascripters,
I am using both Angular and D3 in my project (no jQuery, which I intend to keep this way). One thing that I want to support is to enable users to play with 'raw' tabular data. So, data from a CSV is loaded into my app and displayed in a plain old fashioned table (currently with Angulars ng-repeat). However, I now want to be able to animate that columns of the table get reshuffled. So, as a simple example, I would programmatically want to switch column 2 with column 4 and this transition must be D3-like. Furthermore, easily dragging whole columns to other positions should be possible.
Since I am not really experienced with working with jqLite inside Angular directives, my preference would go out to a solution based on D3. I can then see two possible solutions:
Render all of the data in a regular table using the D3 append functionality. Whenever column order changes, somehow reconstruct the table and create a smooth transition.
Simulate a table with div's and css (not looking forward to that though), to enable easy repositioning of data.
Since both solutions are far from trivial (I would say), I would really like to have some opinions. Do you see any other solutions for me? And if one of these two solutions seems right for you, how would you go about implementing them?
Thanks in advance!
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.