You Might Not Need A Grid

The grid. The almighty grid. Even the omnipotent omnipresent omnivorous grid. No UI control is quite as powerful. At the end of the day, most applications are forms over data in some fashion. Since our data is stored in database tables, it makes sense that viewing it and editing it in tabular fashion feels natural. In the enterprise, most users outside of development are very familiar with Excel, so the grid puts them right back into an environment that they can understand and use without a learning curve. The grid is the cornerstone of many applications.

The Kendo UI Grid contains the full power of desktop grids but in pure HTML5 for the web. It’s truly a remarkable control and I have even seen applications where 98% of the functionality exists in a single Kendo UI Grid. The grid is more of a solution than it is a widget. It is often the “go-to” tool for those who have one, and the object of longing for those who don’t.

However, the grid has a time and a place. The truth of the matter is that there are many situations where a grid may seem like the obvious choice, but in truth, you don’t need one.

In this article, we’ll look at some of the common scenarios that you may come up against when working with data that could cause you to think you need a grid. A lot of those scenarios can be fulfilled using only the open-source Kendo UI Core. At a certain point, you will be much better off paying for a grid than trying to build all the functionality yourself. However, I think you will be surprised at what is possible with just Kendo UI Core.

Repeating Data

Grids are often used just as a container that repeats data in rows and columns. There is nothing wrong with this, but if that’s all you are doing, you may not need a grid.

HTML Tables are for repeating rows of data with columns. In fact, when you create a Kendo UI Grid from a div, it turns it into an HTML Table. As it turns out, Kendo UI will repeat data for any HTML element who’s source binding is set.

See the Pen Diurb by Burke Holland (@burkeholland) on CodePen.

Pretty Tables

Of course, that table is pretty raggedy looking. Kendo UI is gorgeous and there is no doubt that it makes your data look a whole lot more handsome. However, there are a lot of CSS frameworks out there and most of them contain great table styles. For instance, if we include Bootstrap in this example and add a class of table to the, um, table – the table starts looking quite a bit better and we didn’t have to write any CSS!

See the Pen xHJes by Burke Holland (@burkeholland) on CodePen.

 

Striped Odd Rows

Coloring every other row with a slightly different background makes tables much easier to read. The Kendo UI Grid does this for you, but Bootstrap will do it to the plain table as well. Just add table-striped class to the table.

See the Pen cbDir by Burke Holland (@burkeholland) on CodePen.

Note that this will not work on IE 8 or below because it uses the nth-child selector which is not supported in those browsers. The Kendo UI grid uses a variety of techniques to accomplish the striping so that it works back to IE 7.

Paging

You may have noticed that we’re only pulling back the first 20 rows in the table which is bound to a remote data source. Grids allow you to page through data, which allows you to let the server do the querying and keep the page light by only displaying the current rows. It may shock you to learn this, but you don’t need a grid to do that either! You do need Kendo UI Core though.

Kendo UI Pager

The Pager is actually a component that lives on its own in the Kendo UI Core framework. You can initialize it with a div and then bind it to the same data source as the table. And just like that you will have a paging hooked up. I reduced the number of items per page here to make the size of the table smaller for embedding.

See the Pen ncrys by Burke Holland (@burkeholland) on CodePen.

Show Loading While Paging

The grid automatically shows a loader when you are paging. We can show a loader on the table as well by calling kendo.ui.progress when the paging request starts and calling it again with false parameter when it finishes. The progress method expects two parameter:

  • The container where the progress indicator should be shown (must have position: relative set)
  • A boolean flag defining whether or not to show or hide the progress indicator

I wrapped the table in a div to serve as the container, although I could have specified the table directly. Now we get a nice progress indicator and the content gets grayed out while the request is in progress. This is a really nice feature that could have taken us a long time to do by hand with CSS, but Kendo UI Core provides it out of the box. You can use the progress indicator anywhere you like in your applications.

See the Pen CELnG by Burke Holland (@burkeholland) on CodePen.

Row Selection

Selection allows you to handle an event when a user clicks on a row. Its also a good idea to highlight the row so that the user knows that it was selected as well as handle the event.

We can bind the click event of each tr in the template to a model function. That function can toggle a class on all of the cells in the row to highlight them. It’s also possible to know if the row was selected or not by immediately checking for hasClass right after toggling the class. Isn’t chaining great! I love you jQuery.

See the Pen KtDzc by Burke Holland (@burkeholland) on CodePen.

 

Sorting

Sorting data in Kendo UI is really easy since you just call sort on the DataSource. Where it gets complicated is in keeping the UI up to sync with the existing sort object in the DataSource. Not only would we have to add icons to the grid to indicate the sort direction for each and every column, but we would have to keep the visibility of those images up to date as the user sorted and cleared sorts for multiple columns. The logic looks something like this:

  • User clicks on table header
    • Sort asc if sort is null
      • show up arrow
    • Sort desc if sort is asc
      • hide up arrow
      • show down arrow
    • Clear sort object is sort is desc
      • hide down arrow

We could add this functionality to the table that we created, but it would be a LOT of code and a quite tedious. At this point, you may need a grid. Strike that – you most definitely need a grid. The good news is that the Kendo UI grid does everything we have done up until now and much much more.

When You Definitely Need A Grid

Let’s get back to the above sorting issue. Since we’re going to be using a grid and not a plain HTML table, let’s replace all of the functionality that we have created already with a Kendo UI Grid component.

See the Pen dihFt by Sebastian Witalec (@sebawita) on CodePen.

That’s a whole lot less code since most of it is contained in Kendo UI, which means we didn’t have to hand code it. Furthermore, we can now add sorting with one line:

data-sortable="true"

See the Pen yjmze by Sebastian Witalec (@sebawita) on CodePen.

Grouping

Grouping data in the table is a common requirement to give more insight in the data. This quite often can be handled by sorting your data by the field you need to group by and then placing a separator each time you get a different value in the grouped by field.

This gets more complicated when you need to group by multiple fields and worse yet when you need to build functionality to allow the user to select group by fields while they view the data.

The Kendo UI Grid can achieve the above requirement with just one line of code. All you have to do is set data-groupable flag to true and you just saved yourself a lot of time that you can spend working on other features of your project.

In the example below you can drag and drop any column to the header of the grid, but the best way to test it is by grouping by ShipCountry and ShipCity.

See the Pen LrKjx by Sebastian Witalec (@sebawita) on CodePen.

Aggregates

There is more to working with grouped data than just presenting it nicely. Often grouping is followed with requirement to provide insight into each group via various aggregates.

Providing such functionality often requires building complex logic to calculate the values on either the client side or the server side. Then you need to update the UI to present the data for each group in your table. A few more tweaks around and you find yourself with quite a bulky code that might not be easy to follow or maintain.

Kendo UI provides you with an easy alternative that is very intuitive to implement and even easier to read. You can achieve it in 2 steps:

  • In the dataSource: implement schema model by providing the types of the fields you are dealing with (i.e. string, number, date);
  • In the grid definition: add aggregate details in the data-columns field. The bare minimum you need to include is:
    • field: the name of the field you want to aggregate on;
    • aggregates: list of aggregate you want to use. The supported aggregates are average, count, max, min and sum;
    • groupFooterTemplate: HTML template defining how the aggregate should be presented.

In the below example, just like in the grouping example above, drag country and/or city to the header to see aggregates in action.

See the Pen CjzED by Sebastian Witalec (@sebawita) on CodePen.

Editing

Where it can get really tricky is when you need to provide functionality to display large amounts of data and allow the user to modify it. Normally this would require building additional screens that show up when a record needs updating, hook events that update your grid with the data changes and sync the changes with the actual source of data.

Luckily for you Kendo Grid together with the DataSource object handles this for you with few lines of code, with clear separation of code required to perform CRUD operations on your data, validation rules on each data item and the presentation of the data.

In order to make it work you need to take it in few steps:

  • Setup transport of your DataSource to specify how to perform each of the required CRUD operation: Create, Read, Update and Destroy;
  • Specify the schema of the data model by listing the fields that should be included. For each field provide details like:
    • type: used to specify how the field should be presented in the UI and what sort of values it can take;
    • editable: used to allow/disallow for a field to be modified;
    • nullable: used to specify if the field is required;
    • validation: used to validate the value of the field.
  • In HTML on top of the usual data-columns and data-bind attributes required to create a grid you need to set the data-editable attribute to true.

This is enough to allow you users to start editing data inside your grid by simply selecting a call and entering the values.

See the Pen thoDi by Sebastian Witalec (@sebawita) on CodePen.

 

What we have so far:

Depending on the field type, the edit mode provides different edit controls:

  • Text => TextBox
  • Number => NumericUpDown
  • Boolean => CheckBox
  • Date => Date Picker

Fields with specified validation rules stop users of entering invalid data or even updating the values they shouldn’t be changing (like the ID field).

Add Create and Delete

In order to allow users to create new records just add data-toolbar= "['create']" to the grid definition. To delete records add { command: ['destroy']} to the data-columns definition.

See the Pen Kvicw by Sebastian Witalec (@sebawita) on CodePen.

 

Different ways to edit data

Instead of updating individual fields you can allow the user to update each record as a whole and then commit or cancel the changes.

This can be achieved by adding a new command { command: [edit]} to data-columns definition. Next you need to change the value of data-editable to either inline or popup. Let’s look at what each does.

Inline

Change data-editable to inline to allow users to update the record inside the grid.

See the Pen uedrK by Sebastian Witalec (@sebawita) on CodePen.

 

Popup

Change data-editable to popup to allow users to update the record in a popup.

See the Pen InGwD by Sebastian Witalec (@sebawita) on CodePen.

 

Adaptation

One of the biggest drawbacks to grids, is that they do not translate well to mobile devices. A DatePicker will often look fine on a desktop and work equally well on mobile. Grids, on the other hand, are designed to take advantage of the large real estate that desktop monitors afford. On mobile devices, they degrade as all the content and usability gets smashed together and piled up on top of itself.

There is a better way.

Mobile devices have their own opinions about how to handle complex operations. Usually this involves making use of multiple screens to show hierarchy and separate operations. The Kendo UI Grid offers an adaptable mode in which you can keep all of the desktop functionality, but in a grid that behaves more like a mobile application.

grid

To achieve this effect, we turn the grid’s mobile property on. Alternatively, we could set it to ‘phone’ or ‘tablet’ if we wanted to be more specific about where the Grid should behave like a mobile app and where it shouldn’t. Most tablets do an excellent job of displaying grids in their full glory.

You May Not Need A Grid

Grids are incredibly advanced and powerful, but you may not need one as badly as you think. If you are working with simple tabular data, Kendo UI MVVM will serve you just fine. Add in a little Bootstrap and you can make it quite pretty without much work.

If you’re needing robust editing, sorting, grouping, aggregating and adaptive data rendering capabilities, you most definitely DO need a grid and the Kendo UI Grid is right up your alley.

Download Kendo UI Core today to get going with Kendo UI MVVM, or grab a copy of Kendo UI Professional and go straight to the Grid.

Comments

  • Nanda Kishore

    Thanks for the detailed article. I am wondering if your grid supports hiding of chosen columns or merging of specified columns into one based on device/screen size. For example, I might want to hide unimportant columns like ‘Discontinued’ while viewing it on mobile. Or, I can as well combine it with other columns like show it as icon next to product name when viewed in mobile. Something similar to http://elvery.net/demo/responsive-tables/

    Do you support this? If not, do you have any plans to support it in future?