jqxGrid Evaluation Findings

[rheathParticipant]

I’m a developer on a visualization tool and I’ve been trying to find a good grid control for a while. I started using DataTables, then switched w2ui, but the bugs and limitations with both caused lots of headaches.

I’ve just evaluated the jqxGrid (3.9.1) alongside the Sencha Ext JS grid. As I have production quality integrations of each of the four grid controls that can run interchangeably in my app (including a broad automated test set) I thought I’d write up some detailed feedback about my getting started experience. Hopefully it proves useful to others in my situation.

To summarize my findings – the jqxGrid is currently the best grid out there for my needs and that’s why I’m buying a license this week.

Even though jqxGrid is awesome, there are obviously things some of the other grid controls do better. For each of the suggestions and issues below, I’ve tried to include brief details of any workaround I’ve managed to find. Please take these suggestions for to jQWidgets developers in the spirit they are given – from someone who is a big fan of your software that is looking forward to seeing these controls get even better in the future.

I realize that many of the suggestions are probably on your todo list already, and may be technically hard to implement. Hopefully you see a couple of new things though. I’m also sure a few are already supported, but I’ve just missed them.

My Use Case

• The grid shows user data in a single page visualization tool.
• There may be 1 row of data or 1000s, there may be 1 column or dozens – it’s up to the user.
• The data is often grouped, with a per column summary of the values shown for each group.
• Preview images sometimes need to be shown in rows.
• The control needs to size to maximize use of the available space.
• The data is already available in JavaScript.
• Column names are often long.
• Paging is not acceptable to the users – they are used to Excel-like tools.

Including the Library

• Very easy.
• Particularly liked the ability to only include the JS files needed to avoid bloat.

Appearance

• Looks modern.
• Nice approach to applying themes to controls.
• Sane DOM structure is easy to style (unlike some of the other grids).
• The grouping functionality isn’t as pretty out of the box as some of the other grids, but can be styled
• Suggestion: It would be nice to have a css class or an attribute when a row is a grouping summary row to make it easier to style (and select in tests)

Documentation & Examples

• Excellent examples showing a good range of functionality.
• Documentation was pretty good.
• Suggestion: I struggled to find a good definition of everything that can be defined for a column though. Suggest you add them to the API page.

Performance

• The quickest feeling of all the grids.
• The initial load is fast.
• Scrolling of large datasets is quick.
• The only negative is scrolling of rows containing images. There is no pre-load of next / previous x rows (unlike the other grids) which creates a noticeable delay loading my images when users scroll.
• Suggestion. Create the elements for the x rows before and after the displayed rows elsewhere in the DOM and reparent them on scrolling.

Configuration

• Excellent range of config options. With only a couple of options missing for me.
• Nice out-of-the-box row and cell selection models and configs.
• Suggestion: It would be nice to have a column header wrapping flag. See ‘Wrapping Column Headers’ below.
• Suggestion: rowsheight works well for me, but it would be nice to be able to set a separate height for the grouping rows.

Methods

• Methods to do everything I wanted.
• Different to the other tables when selecting a row as you need to go from your data to a bound row, rather than just used the id property specified on the source. It is a little less clean, but you get used to it quickly.
• Suggestion: Add a selectrows call to select multiple rows (hopefully with better performance when you need to select 1000s of rows programmatically.

Available Events

• I could attach listeners to everything I wanted to (sort, move column, resize column, etc) except a scroll event.
• On scroll I need to hide a detailed hover preview for the current row. As the rows are reused, I can’t get a suitable event from the raw element. As a workaround I fire my own (throttled) scroll event whenever a cellsrender is called, but as cell contents are sometimes cached once first shown, it only works some of the time.
• Suggestion: Add a scroll event to bring the grid in line with the other grids.

Rendering Flexibility

• Excellent.
• Row height is easily controllable (needed if one of the columns is showing images).
• The cellsrender works very well and allows more control than the other 3 tools.
• Suggestion / Bug: The groupsrenderer is called too aggressively with all the visible group cell contents being updated every time the grid is scrolled, even by 1px horizontally.

Grouping

• The grouping functionality didn’t meet my need as a need for a per column summary (it does a single summary that spans all columns.
• The jqxTreeGrid wasn’t suitable as it renders to the DOM very differently and doesn’t reuse group rows with large data sets. Paging wasn’t suitable as the parents rows end up not visible due to being on previous pages.
• Luckily, the jqxGrid grouping functionality reuses existing rows with a cell for column still in the DOM (but the first cell is just made very wide). Unfortunately the groupsrenderer function does not have a reference to these cells or even the current cell element (which would allow access the other cells relative to the first).
• To work-around this I return a span from the groupsrenderer with a unique id. I pass this id and the data to a setTimeout-like delayed callback which finds the span and updates all of the grid cells in the row. It works pretty well, but looks bad when you start scrolling due to the groupsrenderer being called too aggressively (see Rendering Control section above). In addition something is going on that causes the delayed callback not to be called until your mouse exits the scroll bar control.
• Suggestion: Enhance the groupsrenderer to allow an array of values to be returned. These should be applied to individual columns. Hopefully the DOM being already of the right structure makes this easier. As the jqxGrid is way more awesome than the jqxTreeGrid for those using larger data sets, I can imagine this being popular.
• Suggestion: The left expand / collapse arrows should stay visible on the left when there is a horizontal scroll bar.

Testing

• I have a wide set of Selenium tests that run. My Selenium selectors for interacting with the grid are just as clean, or cleaner, than the other three table implementations.

Data

• As my data is already in JavaScript arrays this was very easy to get into the grid.
• If a property wasn’t available on the first data record, it was not rendered on the grid for data records 2 onwards, even though the column was defined. The solution is to define the datafields on the dataadapter, duplicating the column definitions. I can imagine this is easy to miss if you work with less sparse data sets.
• Suggestion: Default to the column definitions for the grid data setup if the datafields are not available on the DataAdaptor.

Touch

• Demos work well on iPad
• Demos partially work on Windows 10 touch (Dell XPS 15).
• – Scroll bars work, but not the drag scroll from anywhere in the grid that is nice on iPad
• – Column reordering works on Firefox, but not Chrome or Edge
• Selection works well
• Scrolling is slow / problematic in my app, but I need to build a standalone example to investigate if this is an issue with my particular jqxGrid configuration or something else. I’ll blame ‘something else’ for the moment.
• Suggestion: Support drag scroll on Windows touchscreens as is done for iPad.
• Bug: Column reordering on Chrome and Edge does not work on Windows 10 Touchscreens

Wrapping Column Headers

This is important for my customers as column headings can be very long and the first 20 characters are often the same (something similar to us_california_sandiego_measure1). I worked around this by setting the CSS

.tableview .jqx-grid-column-header {
    white-space: normal !important;
}

.tableview .jqx-grid-column-header > div > div:nth-child(1) {
    margin-top: 2px !important;
    margin-bottom: 2px !important;
}

And calling

var heights = [];
this.gridEl.find('.jqx-grid-column-header span').each(function() {
    heights.push($(this).height());
});
this.gridEl.jqxGrid('columnsheight', d3.max(heights) + 6);

on the first render, column resize and table resize.

Suggestion: Make this a supported feature.

For anyone that tried to make the header cells non-absolute using CSS and gets the text wrapping working that way (which I managed to do initially), it’s important to know the row selection code uses the column heading ‘left’ declaration to work out what cell was clicked. Going to a relative display broke row selection.

Misc Bugs

Missing CellRenderer Param

Bug: If I click two or three times on the resizer between the column headers the 5th parameter on the cellsrender is not passed (the row data). This parameter isn’t documented anywhere so calling it a bug may be a stretch! It is useful and present on all other calls though.

Table Width

Bug: I set a min width on table columns, but rely on the control to size itself nicely to the space available. Usually the control does an excellent job, but if the column headers are long then the control adds a horizontal scroll bar when the data could be easily fitted into the width available.

Overall, I’m extremely impressed. Hopefully the above info is useful for others in the future.

Thanks,

Richard

Summary

TODO

[rheathParticipant]

Summary of suggestions and bugs. Most are not critical, but would be nice to bring jqxGrid in line with the best bits of other grid controls.

Suggestions

1. Enhance groupsrenderer to allow per cell group summaries
2. CSS class to grouping summary row
3. Add column definition options to documentation API
4. Preload x rows before and after currently displayed rows
5. Column header wrapping
6. Separate height for grouping summary rows
7. Selection of multiple rows in a single call
8. Scroll event
9. Pin grouping expand / collapse arrows to left
10. Default to column definitions if datafields not on adapter
11. Support drag scroll for Windows touch, like iPad

Bugs

1. Call groupsrenderer less aggressively
2. Ensure horizontal scrollbar isn’t shown unless needed
3. Column reordering broken on Windows touch in Chrome & Edge
4. Missing cellrenderer param (sometimes)

Let me know if I can provide any more feedback.

[Peter StoevKeymaster]

Hi rheath,

Text wrap in columns header can be achieved by implementing the column’s renderer callback function.

Best Regards,
Peter Stoev

jQWidgets Team
http://www.jqwidgets.com

[rheathParticipant]

Hi Peter,

With the renderer callback, I needed to add the <br> breaks myself. Is this the approach you are referring to? For me, this meant calculating the width of text to see where the breaks needed to go. As calculating the width of text is slow (unless you’re using a fixed width font!), I found it was better to let the browser wrap the text naturally and then set the height.

Another useful trick is, I used zero-width spaces (&#8203) to hint where the browser should wrap long, non-space-containing strings. In my case this is after _ and on camel case. This would allow

California_San_Diego_MeassureOne3 to be wrapped like this when space was tight

California_
San_Diego_
Measure
OneTwo3

and

California_San_Diego_
MeasureOneTwo3

when there was more width.

In situations where you know your column names, widths and grid size, I can see the column renderer callback being fine, but as my grid size and columns are dynamic, I needed to get a bit more creative to match the behavior elsewhere!

Thanks,

Richard

[Author]

Posts