Consider this scenario: Your business needs to display your financial trend analysis in a report. Perhaps you want to show quantitative comparisons between multiple products, or maybe you need to list salaries paid to specific employees. To present your data in each of these scenarios, you need a table or table-like structure.
Using HTML tables is the easiest way to construct and display a table. However, HTML table code can quickly become disorganized as it grows, and it often becomes difficult or impossible to properly maintain. Additionally, HTML tables aren’t very responsive on our web pages and cause excessive scrolling as they grow in size. Browsers are also mostly unable to load HTML tables incrementally, which slows down page rendering.
HTML tables are appropriate when they display data that is small, simple, and straightforward. However, to make the table interactive — that is to add the ability to sort, filter, add custom cells, or insert images — a datagrid is a much better option.
We have many types of datagrids to choose from to meet our requirements. In this article, we’ll review what a datagrid is, and explore some important considerations while selecting a datagrid.
What is a Datagrid?
A datagrid is a JavaScript UI component that lets us pull data from a local or remote data source and arrange it in a grid. It also lets us add functionality to manipulate the data or its display properties, like sorting, filtering, paging, and scrolling.
A datagrid and an HTML table are visually similar to each other but are structurally different and more complex in function. The main difference between datagrids and HTML tables is that we can add interactivity to the data in datagrids, which is tedious and sometimes impossible in HTML tables.
Datagrids have the following advantages over HTML tables:
-
Datagrids are optimized for high performance. They’re very responsive and can also handle large amounts of data without performance degradation.
-
We can customize datagrid cells to our specifications, including implementing much of the common functionality that we find in Excel like cell merging, start sizing, and cell freezing.
-
We can also make datagrids editable by providing the functionality to create, update, and delete data right in the grid itself.
-
They are generally screen-reader friendly, and as such are more accessible to the visually impaired.
-
Datagrids separate the user interface from the data layer. The way data is fetched and processed stays separate from how it’s displayed on the interface. This allows us to present it in multiple ways with minimal effort. Separating the layers in this way allows for easier code maintenance. Additionally, since the data layer is separate from the UI, we can implement faster and more efficient retrievals to make the user interface feel more agile and responsive.
-
We can reuse data with different datagrid templates regardless of which framework they are written in.
Write Your Datagrid or Use a Datagrid Library?
Now that we know that the datagrid is a much better choice than HTML tables, the next question is whether we implement a datagrid or use a datagrid library.
The consensus best practice is to use a readymade, customizable datagrid library instead of spending time and effort building a custom-made datagrid — there’s no need to reinvent the wheel.
Datagrids can get very complicated very fast. We have to write a lot of code to add and implement functionalities like paging, sorting, and filtering, and much of it is more complex than it may appear at first. Functionalities like date pickers, buttons, sorting, paging, links — and many other features based on functionality in Excel — become whole components in themselves.
Some appear deceptively simple and may present an unpleasant surprise when we find we must commit more coding than we expected. Implementing a date picker, which seems like a simple component at first, requires thorough testing to catch edge cases.
Maintenance in general becomes complicated as we start to add many common elements to the grid. To write this functionality correctly, we might have to add many external libraries and functions, introducing a list of dependencies we must maintain going forward.
A datagrid with a comprehensive suite of features, then, is a collection of different UI components, each of which uses its own libraries and dependencies. Maintaining such an eclectic collection of functions and libraries can be extremely difficult.
As a datagrid’s functionality grows, performance becomes a major factor as well. A poorly optimized datagrid can slow down our application enough to make it seem broken. In extreme cases, it may provide no added performance over an HTML table.
Accessibility compliance is another dimension of development we can often overlook. Lack of adherence to these standards can quickly make maintenance difficult. To stay in compliance with modern web standards, we may have to extensively refactor our code, including updating every UI component and feature in our datagrid.
Implementing a fully optimized and feature-rich datagrid is a big project in itself. Unless our application features a purpose-built, unique grid as its main element, it’s inefficient to code and implement our own datagrid when it is just one component of our webpage.
This is especially true when we can choose from many perfectly written and well-tested datagrids with all the necessary functionalities already available, such as the Wijmo FlexGrid.
Which Datagrid Library to Use?
We see that instead of implementing a custom datagrid, it’s a much better idea to save ourselves time and work by using a third-party datagrid library. However, with hundreds of options available to choose from, we should first narrow our options to single out a library that not only serves our present use cases.
We want to make sure it can also be adopted as our standard for other applications we may need to develop in the future. There are a few factors to consider.
Functionality and Performance
Our first major consideration is framework support. The datagrid library should be able to provide support for various commonly used frameworks and languages like JavaScript, TypeScript, Angular, React, and Vue.js. Wijmo FlexGrid has broad support for these major frameworks.
Loading our datagrid should be a snappy process, and it shouldn’t slow down our application — even when we supply it with large datasets. Before choosing a datagrid library, we should test the library for its performance under heavy data loads. FlexGrid is a very compact solution, which makes its performance exceptionally fast and reduces bloat in our application.
Datagrids generally process and display large amounts of data. To ensure smooth performance, our datagrid library should have virtual scrolling.
This ensures that the grid shows only those columns that are visible, and doesn’t render or fetch the rest until they are needed. FlexGrid virtualizes its data by default, so this feature is always on in the background:
We should look for a full-featured datagrid that has functionality like sorting, record filtering, and paging right out of the box. We should be able to plug in our data and have the functionality work without needing to change our project code. In FlexGrid, for example, the sorting and filtering of records is built-in:
Paging is equally trivial to implement:
FlexGrid also provides convenient search functionality:
Robustness, Accessibility, and Support
Our database should be able to accept a versatile range of data types and be able to perform under a wide range of conditions. It should support data binding and let us use the same library to visualize multiple types of data. We would also like to be able to handle null values and perform basic data validations on our inputs.
The datagrid library should be compliant with accessibility requirements and should never break screen readability, including when viewed on a mobile screen. FlexGrid is naturally responsive and looks great on any screen size.
To make localization easier and allow input in a language that can’t be represented easily on a QWERTY keyboard, our library should support an Input Method Editor (IME). This feature is especially important to make our grid accessible to the large populations of Japanese, Chinese, and Arabic-language users online, among others.
Of course, sometimes our functionality breaks. We should be able to quickly and easily find solutions while minimizing downtime. Our datagrid library should have enterprise-level support so that we can safely use the library in our production-level applications.
It’s critical to have clear and detailed documentation about every feature and functionality in the datagrid. This feature alone can determine if a library is suitable: The quality of documentation available to us will affect development and maintenance at every step.
We have access to an intuitive and thorough FlexGrid documentation guide, alongside guides for other Wijmo components.
When we evaluate the entire list of best-practice considerations, only a few libraries stand out.
Wijmo FlexGrid
One excellent example of a robustly written and well-featured datagrid is the Wijmo FlexGrid. The Wijmo FlexGrid is lightning-fast, has no dependencies, and allows us to safely implement a huge number of commonly needed functions with a minimum of maintenance.
FlexGrid is a mature component, released in 1996, and has found mainstream success for most of its history. Microsoft licensed FlexGrid in 1998, and over the years, it has been honed and perfected to a high-performing feature-packed datagrid.
FlexGrid offers most of the features we outlined as necessary for our datagrid. It also features other proprietary functionality, like automatically building tree-view from hierarchical data sources, and custom-built charts for financial analysis.
It also has a suite of basic data validation checks like Automatic Type Coercion, CollectionView-Based Validation, Event-Based Validation, and Data Maps. We can also easily export our data in PDF format or as an Excel-readable file.
If we need more specific information, we can easily find details in the documentation or head over to FlexGrid’s demo page for a more guided experience.
Conclusion
In this article, we’ve seen that a datagrid is a better choice than a mere HTML table whenever we want to either display tabular data with more than a basic level of complexity, or add any functionality.
We explored the downsides of “reinventing the wheel” by implementing a custom-built one instead of a datagrid library, and then we looked at the features considered critical for a datagrid library, and we found that the Wijmo FlexGrid library handily met our needs.
