UPDATE: March 5th, 2014 – I have too many things going on in my life right now to really give SlickGrid support and development the time and attention it deserves. I am not stopping it, but I will most likely be unresponsive for some time. Sorry.
Do you use SlickGrid? Add your site to the Used By!
Want to show your appreciation? Hit Donate! :)
It is an advanced component and is going to be a bit more difficult to learn and configure, but once you realize its full potential, it will blow your mind!
GitHub Issues are for bug reports only. Please use the appropriate forum.
Please see Rules of conduct
When reporting bugs, please be specific (details are described in the above “Rules of conduct”):
1. Include the version of SlickGrid.
2. Include the reproduction steps. Describe about expected behavior & actual behavior.
(If possible, post code on jsfiddle.net).
3. Use proper English that everybody can understand.
SlickGrid utilizes virtual rendering to enable you to easily work with hundreds of thousands of items without any drop in performance. In fact, there is no difference in performance between working with a grid with 10 rows versus a 100’000 rows. This is achieved through virtual rendering where only what’s visible on the screen plus a small buffer is rendered. As the user scrolls, DOM nodes are continuously being created and removed. These operations are highly tuned to provide optimal performance under all browsers. The grid also adapts to the direction and speed of scroll to minimize the number of rows that need to be swapped out and to dynamically switch between synchronous and asynchronous rendering.
It does a few other things to maximize performance, such as dynamically generating and updating CSS rules, so that resizing a column does not change the grid DOM tree and only causes one reflow, and loading cell editors asynchronously to maximize keyboard navigation speed.
The key difference is between SlickGrid and other grid implementation I have seen is that they focus too much on being able to understand and work with data (search, sort, parse, ajax load, etc.) and not enough on being a better “grid” (or, in case of editable grids, a spreadsheet). It’s great if all you want to do is “spruce up” an HTML TABLE or slap a front end onto a simple list, but too inflexible for anything else.
Data is complicated. It has business rules. It has non-intrinsic properties. Editing one property of an element can lead to cascading changes modifying other properties or even other elements. It has dependencies. What I’m saying, is that dealing with data is best left to the developer using the grid control. Trying to fit all of that into the grid implementation and API will only limit its applicability and add considerable bloat.
SlickGrid takes a different approach. In the simplest scenario, it accesses data through an array interface (i.e. using “dataitem” to get to an item at a given position and “data.length” to determine the number of items), but the API is structured in such a way that it is very easy to make the grid react to any possible changes to the underlying data.
While this may not be immediately obvious from what you see in the examples and in the code, the key use of the grid is in MVC applications where the grid is wired to respond to events in the Model. In our application we have spreadsheet component of a Gantt chart, and the Model is a “filtered” view of the tasks (rows) in the original datasource. Suppose you collapse or expand a parent task or enter some text in a Quick Filter textbox. The Model then recalculates which rows are now visible, compares that with what was visible before and fires two events – onRowCountChanged & onRowsChanged. The latter one tells all subscribed Views, such as the grid, that the rows in specific positions changed. The grid then only has to invalidate/remove those rows and call grid.renderViewport() to make sure that whatever is in the viewport is visible. The onRowCountChanged event triggers the recalculation of the virtual canvas – grid.resizeCanvas(). Together, this pattern makes for an incredibly efficient, flexible and, most importantly, scalable implementation.
Rather than listing all the browsers that SlickGrid works on, I will concentrate on the ones that don’t.
IE6 is explicitly NOT supported. While some people have made SlickGrid work with IE6, I am not going to merge those changes in or spend any time testing on IE6 and trying to make it work. If you have to support it, I feel your pain, but I don’t want to share it.
Opera seems to be having some issues with synchronized scrolling of column headers and a vertical page scrollbar appearing when scrolling the grid content vertically. I haven’t been able to figure out why in the amount of time I was willing to spend on it. If you have an idea, let me know.
Big thanks to JetBrains who have supported SlickGrid and other open-source projects by providing a free license for their awesome WebStorm IDE.