DEV Community: Infinite Table

Infinite Table React DataGrid version 3.0.0 released

Infinite Table — Wed, 04 Oct 2023 21:42:20 +0000

Version 3.0.0 is a release that brings a long awaited feature: cell selection. This allows the user to perform fined-grained cell selection, either via the cellSelection prop or via the Cell Selection API.

Version 3.0.0 highlights 🎉

1️⃣ support for single and multiple cell selection
2️⃣ cell selection using wildcards
3️⃣ cell selection API

1️⃣ Support for single and multiple cell selection

It's been a long-requested feature to implement cell selection.

We knew we needed to implement it, but we wanted to do it right while keeping it easy to understand.

In fact, we prepared some things in advance - namely selectionMode was there, it just needed to accept a new value: "multi-cell".

<DataSource<Developer>
  selectionMode="multi-cell" // <--- THIS
  primaryKey="id"
  data={[...]}
/>

The line above is all you need to do to enable cell selection. This allows the user to Click or Cmd/Ctrl+Click to select a specific cell and Shift+Click to select a range of cells. It's exactly the behavior you'd expect from a spreadsheet application.

Try Cmd/Ctrl+Clicking in the DataGrid cells below to see multiple cell selection in action.

Using a default selection

If you want to render the DataGrid with a default selection, you can use the defaultCellSelection prop.

const defaultCellSelection = {
  defaultSelection: false,
  selectedCells: [
    [3, "hobby"],
    [4, "firstName"],
    [4, "hobby"],
    [4, "preferredLanguage"],
    [4, "salary"]
  ]
};

The format for the uncontrolled defaultCellSelection (and also for the controlled cellSelection) is an object with two properties:

defaultSelection - boolean - whether or not cells are selected by default.
and either
- selectedCells - [string|number, string][] - only needed when defaultSelection is false
or
- deselectedCells - [string|number, string][] - only needed when defaultSelection is true

The value for selectedCells and deselectedCells should be an array of [rowId, colId] tuples.

The rowId is the id of the row (primaryKey), and the colId is the id of the column (the identifier of the column in the prop).

This object shape for the defaultCellSelection/cellSelection props allows you full flexibility in specifying the selection. You can specify a single cell, a range of cells, or even a non-contiguous selection. You can default to everything being selected, or everything being deselected and then enumerate your specific exceptions.

2️⃣ Cell Selection using wildcards

The above examples show how to select specific cells, but what if you want to select all cells in a column, or all cells in a row?

Well, that turns out to be straightforward as well. You can use the * wildcard to select all cells in a column or all cells in a row.

// All cells in row with id rowId3
// and all cells in hobby column are selected
const defaultCellSelection = {
  defaultSelection: false,
  selectedCells: [
    ['*', 'hobby'],
    ['rowId3', '*'],
  ],
}
<DataSource 
  selectionMode="multi-cell"
  defaultCellSelection={defaultCellSelection}
/>

Wildcard selection is really powerful and it allows you to select lots of cells without the need to enumerate them all.

For example, you can easily select all cells except a few.

Listening to selection changes

You can listen to selection changes by using the onCellSelectionChange prop.

If you're using controlled cell selection, you have to update the cellSelection prop yourself in response to user interaction - so onCellSelectionChange will be your way of listening to selection changes.

3️⃣ Cell Selection API

In addition to managing cell selection declaratively, which we encourage, you can also use the Cell Selection API to imperatively update the current selection.

We offer the following methods:

selectCell - selects a single cell, while allowing you to keep or to clear previous selection
deselectCell - deselects the specified cell
selectColumn - selects a whole column in the DataGrid
deselectColumn - deselects the specified column
selectRange - selects a range of cells
deselectRange - deselects the specified range of cells
selectAll - selects all cells in the DataGrid
clear - clears selection (deselects all cells in the DataGrid)
isCellSelected - checks if the specified cell is selected or not

Conclusion

We'd love to hear your feedback - what do you think we've got right and what's missing. Please reach out to us via email at admin@infinite-table.com or follow us @get_infinite to keep up-to-date with news about the product.

Talk soon 🙌

Grouping and aggregation in React - made easy by Infinite Table

Infinite Table — Mon, 28 Nov 2022 11:33:17 +0000

Check out our documentation on aggregations and let us know how easy it was to get started.

We're here to assist and help you to setup Infinite Table in your own React project 🎉

Use the comments below to ask any question, and if needed, we can even jump in a zoom call to help 🎆

Why Another React DataGrid?

Infinite Table — Mon, 21 Nov 2022 11:41:50 +0000

We've been working on finding better ways to display tabular data for over 2 decades now and collectively we have 35+ years of experience working on this.

It all began on the desktop with a great range of DataGrids and then we moved to the web and the <table /> component - yeah, we've been around for quite some while - all the while dealing with the same problems and requirements again and again.

This is the story of how we got to where we are today....

A (personal) History of DataGrids

This article is not meant to be a complete history of DataGrids.
Rather, it's personal reflections on the long journey the Infinite Table team have experienced while using and building components for displaying tabular data, culminating in Infinite Table, the modern declarative DataGrid for React.

Desktop Components

DataGrids have been around as long as any of us can remember.

They are a vital tool which allows business users to visualise, edit, manage and personalise their data.

Before Tim Berners-Lee and his colleagues changed the world for ever (and for a couple of decades after), "serious" business applications lived on the desktop.

This was accompanied and facilitated by a plethora of great DataGrids from the likes of DevExpress, Telerik, Syncfusion, Infragistics and others.

These products defined the feature-set that users came to expect in a DataGrid - row grouping, formatting, multiple sorting, pivoting etc.

And which any DataGrid worth its salt today needs to offer today.

For 2 decades and more these DataGrid repeatedly proved their worth in multiple changing desktop formats - MFC, WinForms, WPF and others.

Enter the Browser

And then the browser came along and, in time, everything changed.

While it really took until HTML5 to convince most power users to move from the desktop to the web, the need to display tabular data in the browser was there right from the start.

Initially the only way to show tabular data in the browser was to use the <table /> component, and it was this piece of code that made it happen:

table-layout: fixed;

this is telling the browser (see MDN) that it shouldn't compute the space available for all rows & cells in the table before rendering but instead size the columns based on the content of the first row. This is speeding up the rendering time by quite a lot, and it's the early solution to the problem of rendering large data-sets.

However, it was not perfect, and rendering large datasets was still a huge problem. Also, no fancy resizable / reorderable / stackable columns were available - at least not by default.

These shortcomings were obvious to developers dealing with massive datasets, so various groups and companies started coming up with solutions. One such solution came from Yahoo! as part of their larger widget library called YUI (it was back in the days when Y! was a big deal).

YUI DataTable

Enter YUI era - launched in 2006, the Yahoo! User Interface Library was a step forward in reusability and component architecture. With the release of YUI 3, it received a modernized set of components, and the YUI DataTable was probably the most advanced DataGrid solution out there. The component had a templating engine under the hood and allowed developers to customize some parts of the table. For its time, it was packed with functionality and was a great solution for many use-cases.

It had a rich API, exposing lots of events, callbacks and methods for things like moving columns around, getting the data record for a given row, adding rows and columns, etc - all imperative code. The API was powerful and allowed developers to build complex solutions, but it was all stateful and imperative - something very normal for its epoch, but something we've learned to avoid in the last few years.

Here's some code showcasing the YUI DataTable

var table = new Y.DataTable({
    columns: [
        { key: 'item', width: '125px' },
        {
          key: 'cost',
          formatter: '£: {value}',
          sortable: true
        },
    ],
    sortable: true,
    data   : data
}).render("#example");

// to programatically sort
table.sort({'cost': 'asc'});

Notice in the code above, the component had support for custom formatters via a template (in the style of Mustache templates). YUI DataTable was a great component, certainly lacking some features by modern standards, but it was amazingly rich for its time. In some respects, it's still better than some of the modern DataGrids out there. The major missing piece is virtualization for both rows and columns in the table.

A nice feature YUI DataTable had was the ability to separate the DataSource component and the data loading into a separate abstraction layer, so it would be somewhat decoupled from the main UI component.

var dataSource = new Y.DataSource.IO({
  source: "/restaurants/fetch.php?"
});

dataSource.plug(Y.Plugin.DataSourceXMLSchema, {
  schema: {
    resultListLocator: "Result",
    resultFields: [
      { key:"Title" },
      { key:"Phone" },
      { key:"Rating" }
    ]
  }
});
var table = new Y.DataTable({
    columns: ["Title", "Phone", "Rating"],
    summary: "Chinese restaurants near 98089",
});

table.plug(Y.Plugin.DataTableDataSource, {
  datasource: dataSource,
  initialRequest: "zip=94089&query=chinese"
});

Infinite Table is getting this a step further and splitting the data loading and the rendering into two separate components - <DataSource /> and <InfiniteTable />:

the <DataSource /> component is responsible for managing the data - fetching it, sorting, grouping, pivoting, filtering, etc and making it available via the React context to the UI component.
the <InfiniteTable /> component is responsible only for rendering the data. This means you can even use the <DataSource /> component with another React component and implement your own rendering and virtualization.

<DataSource<DataEntity> primaryKey="id" data={...}>
  {/* if you wanted to, you can replace
   <InfiniteTable/> with your own custom component */}

  <InfiniteTable<DataEntity> columns={...}> 
</DataSource>

This level of separation allows us to iterate more rapidly on new features and also makes testing 🧪 easier.

ExtJS 3

The next solution we've worked with was ExtJS version 3, which was built on the legacy of YUI 3. At the time, back in 2010, it was the most advanced DataGrid solution out there - used for some of the most complex applications in the enterprise world, from CMSs to ERP systems.

The ExtJS 3 DataGrid brought excellent product execution in a few areas:

the documentation was excellent for its time - very rich, easy to navigate and search, with useful examples. As a bonus, from the docs you had access to the source-code of all components, which was a nice addition.
it came together with a rich set of components for building complex UIs - grids, trees, combo-boxes, form inputs, menus, dialogs, etc. Powerful layout components were available, which allowed developers to build complex app layouts by composing components together - and everything felt like it was part of the same story, which it was.
enthusiastic community - the forums were very active and the community was writing lots of good plugins.

var grid = new Ext.grid.GridPanel({
  // data fetching abstracted in a "Store" component
  store: new Ext.data.Store({
    // ...
  }),
  // columns abstracted in a ColumnModel
  colModel: new Ext.grid.ColumnModel({
    defaults: {
      width: 120,
      sortable: true
    },
    columns: [
      {
        id: 'company', header: 'Company', width: 200,
        sortable: true, dataIndex: 'company'
      },
      {header: 'Price', renderer: Ext.util.Format.usMoney, dataIndex: 'price'},
      {header: 'Change', dataIndex: 'change'},
      {header: '% Change', dataIndex: 'pctChange'},
      {
        header: 'Last Updated', width: 135, dataIndex: 'lastChange',
        xtype: 'datecolumn', format: 'M d, Y'
      }
    ]
  }),
  viewConfig: {
    forceFit: true,
    // Return CSS class to apply to rows depending upon data values
    getRowClass: function(record, index) {
      var c = record.get('change');
      if (c < 0) {
        return 'price-fall';
      } else if (c > 0) {
        return 'price-rise';
      }
    }
  },
  sm: new Ext.grid.RowSelectionModel({ singleSelect: true }),
  // size need if not inside a layout
  width: 600, 
  height: 300,
});

Building on the legacy of YUI 3, the ExtJS added virtualization to make the DataGrid perform well for large datasets - it really made the component fly - since there was no framework overhead, and ExtJS was working directly with the DOM, the scrolling experience was pretty smooth.

Also ExtJS tried to make things declarative and you could describe most of your UI by nesting JavaScript objects into a root object. The idea was clever, but it was only applicable for the initial rendering and you had to write imperative code as soon as you wanted some changes after the initial render.

It was while working on a project with ExtJS 3 and exploring everything it had to offer that we had the great idea 😅 that we should start writing a DataGrid component.

We were digging deep into ExtJS source code, wrote a few plugins for it and then decided to take the challenge and build a brand new DataGrid 😱.

It was supposed to take us just a few short months 😅...

The React Revolution

We were quite far in building the DataGrid component, with a dedicated templating engine under the hood (by the way, it was really good in comparison to similar solutions at that time), virtualization implemented and major functionalities finished ... when JSConf EU 2013 happened.

JSConf EU 2013

We vividly remember watching Pete Hunt talk about ReactJS and rethinking best practices at JSConf EU 2013.

By the time the presentation was finished we knew we had to do something.

This declarative way of describing the UI got us hooked and we knew we had to drop what we were doing and adopt React for anything going forward. It proved to be the right decision and we were early adopters of React. It was astonishing to us how easy it was to learn React at the time - only taking a few hours to fully grasp the mental model and start building reusable components.

2013 was the year we switched trajectory and went full-React with all our new projects. We went back to the drawing board and started our first experiments with a DataGrid component in React.

While we were building the DataGrid in React we got side-tracked with other projects but we saw the same pattern again and again - people trying to implement the grid component again and again, in various projects. Most of those attempts either failed terribly or at best they were good-enough for a simple use-case.

AG Grid

It was around this time, in 2015, that AG Grid was launched.

And, wow, it was good - very good.

We immediately adopted it in all kind of projects while still trying to find time on the side to build our own DataGrid solution, the React way, with a fully declarative API.

We were inspired 🙏 by AG Grid, seeing the breadth of features it offers and its expansive growth.

It is a feat of engineering which illustrates just how much the browser can be pushed by extensive use of virtualization - being able to render millions of rows and thousands of columns is no small feat.

All this while keeping the performance similar as if it was rendering just a few rows and columns.

In the code above (taken from AG Grid getting started page), note that AG Grid is exposing its API on the gridOptions object.

The API is huge and allow you to do pretty much anything you want with the grid - in an imperative way, which is what you're probably looking for if you're not integrating with a library/framework like Angular or React.

After vanilla JavaScript and Angular versions of AG Grid, a React version was finally released.

It was a step in the right direction - to make AG Grid more declarative - though it was a thin wrapper around React, with all the renderers and API still being imperative and not feeling like the best fit inside a React app.

A few years later, AG Grid finally released a reactUI version, with tighter integration with React and a more declarative API ❤️

All this time other solutions popped up in the React community.

React Table

One such solution that got massive adoption from the community was React Table - now rebranded as TanStack Table.

It's growth began around 2018, around the time when headless UI components started to gain traction.

React Table was one of the first popular headless UI components to be released - in the same category it's worth mentioning Downshift (initially launched and popularized by Kent C. Dodds), which helped push headless UI components to the community.

React Table is a great solution for people who want to build their own UI on top of it.

Some of the benefits of headless UI approach you get from React Table are:

full control over markup and styles
supports all styling patterns (CSS, CSS-in-JS, UI libraries, etc)
smaller bundle-sizes.

This flexibility and total control come with a cost of needing more setup, more code and more maintainance over time. Also complex features that might already be implemented in a full-featured DataGrid will need to be implemented again from scratch.

However, we do think it's a great 💯 fit for some use-cases - we've used it ourselves successfully in some projects 🙏. But it's not for everyone, as in our experience, most teams today want to ship faster 🏎 and not spend time and mental energy on building their own UI.

Notice in the code above how you're responsible for creating the markup for the table, the headers, column groups,the cells, etc. You have TOTAL control over overy aspect of the component, but this means you have to own it!

At the other end of the spectrum is AG Grid a full-featured DataGrid that offers all this out of the box.

With Infinite Table, we're trying to strike a balance between these 2 very different approaches - by offering a declarative API that is easy to use and get started with, while still giving you the flexibility to customize the UI and the behavior of the component, via both controlled and uncontrolled props.

Let's take a look at an example of a similar UI, this time built with Infinite Table.

Infinite Table

All this time we kept an eye on other components out there to get inspired. We got fresh ideas from various teams and projects - either enterprise or open source - either full-fledged or headless components like react-table.

We've learned a lot from all these projects we've worked with and we've put all the best ideas in Infinite Table.

Infinite is the fruit of years of iteration, experimentation, failures and sweat on a product that we've poured our hearts in over the course of so many years. We've agonized over all our APIs and design decisions in order to make Infinite Table the best React DataGrid component out there.

We're aware we're not there yet, but we're here to stay 👋 and keep getting better. We want to work closely with the community at large and get fresh ideas from other projects and teams. We can all be winners when we work together and respect each-other ❤️

It's amazing what happens when you focus on a problem for such a long time (yeah, we know 😱). We wanted to give up several times but kept pushing for over a decade. The result is a component that we're proud of and is already starting to be used by enterprise clients across many industries (more on that in a later blogpost).

Here are some of the key areas where we believe Infinite Table shines:

Ready to Use

Infinite Table is ready to use out of the box - namely it's not headless. We target customers who want to ship — faster 🏎! We're aware you don't want to re-invent the wheel nor do you want to invest 6 months of your team to build a poor implementation of a DataGrid component that will be hard to maintain and will be a source of bugs and frustration. You want to ship — and soon!. If this is you and you are already using React then Infinite Table is written for you!

Feels like React - Declarative API

We want Infinite Table to feel at home in any React app. Everything about the DataGrid should be declarative - when you want to update the table, change a prop and the table will respond. No imperative API calls - we want you to be able to use Infinite Table in a way that feels natural to you and your team, so you can stay productive and use React everywhere in your frontend.

Let's take for example how you would switch a column from a column group to another:

function getColumns() {
  return {
    firstName: {
      field: 'firstName',
      width: 200,
      columnGroup: 'personalInfo',
    },
    address: {
      field: 'address',
      width: 200,
      columnGroup: 'personalInfo',
    },
    age: {
      field: 'age',
      columnGroup: 'about'
    }
  } as InfiniteTablePropColumns<DataType>
}

const columnGroups = {
  personalInfo: { header: "Personal info" },
  about: { header: "About" }
};

function App() {
  const [columns, setColumns] = useState<InfiniteTablePropColumns<DataType>>(getColumns)
  const [colGroupForAddress, setColGroupForAddress] = useState('personalInfo')

  const toggle = () => {
    const cols = getColumns()

    const newColGroup = colGroupForAddress === 'personalInfo' ? 'about' : 'personalInfo'
    cols.address.columnGroup = newColGroup

    setColumns(cols)
    setColGroupForAddress(newColGroup)
  }}
  const btn = <button onClick={toggle}> Toggle group for address </button>

  return <>
    {btn}
    <DataSource<DataType> data={...} primaryKey="id">
      <InfiniteTable columns={columns} columnGroups={columnGroups}/>
    </DataSource>
  </>
}

Note in the code above that in order to update the column group for the address column, we simply change the columnGroup prop of the column and then we update the state of the component. The table will automatically re-render and update the column group for the address column. This is a fully declarative way to update the table. You don't need to call any imperative API to update it - change the props and the table will reflect the changes.

Fully Controlled

React introduced controlled components to the wider community and we've been using them for years. It's were the power of React lies - it gives the developer the flexibility to fully control (when needed) every input point of an app or component.

All the props Infinite Table is exposing have both controlled and uncontrolled versions. This allows you to start using the component very quickly and without much effort, but also gives you the flexibility to fully control the component when needed, as your app grows and you need more control over the DataGrid.

Composable API with small API surface

When building a complex component, there are two major opposing forces:

adding functionality and
keeping the component (and the API) simple.

We're trying to reconcile both with Infinite Table so we've built everything with composition in mind.

A practical example of composition is favoring function props instead of boolean flags or objects. Why implement a feature under a boolean flag or a static object when you can expose a functionality via a function prop? The function prop can be used to handle more cases than any boolean flag could ever handle!

A good example of composability is the prop - it can be a column object or a function. It control the columns that are generated for grouping:

when it's a column object, it makes the table render a single column for grouping (as if was set to "single-column")
when it's a function, it behaves like is set to "multi-column" and it's being called for each of the generated columns.

<InfiniteTable 
  //...
  groupColumn= {{
    header: 'Groups'
  }}
/>

<InfiniteTable 
  //...
  groupColumn={() => {
    // this allows you to affect all generated group columns in a single place
    // especially useful when the generated columns are dynamic or generated via a pivot
    return {...}
  }}
/>

We've learned from our experience with other DataGrid components that the more features you add, the more complex your API becomes. So we tried to keep the API surface as small as possible, while still offering a rich set of declarative props as building blocks that can be composed to accomplish more complex functionalities.

Conclusion

We're very excited to share our Infinite Table journey with you ❤️ 🤩

After years in the DataGrid space and working and agonizing on this component, we're happy to finally ship it 🛳 🚀.

We're looking forward to receiving your feedback and suggestions.

We're here to stay and we're committed to improving Infinite Table and to make it your go-to React DataGrid component to help you ship — faster! All the while staying true to the community!

Infinite Table Monthly Update - August 2022

Infinite Table — Tue, 06 Sep 2022 11:23:41 +0000

At Infinite Table, we continued our work on preparing for our Autumn release, focusing mainly on adding new functionalities and documenting them thoroughly, together with enhancements to existing features.

Summary

We have implemented a few new functionalities:

row selection is now available
column rendering pipeline
group columns are now sortable

And we have updated some of the existing features:

group columns inherit styles and configuration
column hiding when grouping
group columns can be bound to a field
using the column valueGetter in sorting

Coming soon

We started working on column and context menus.
We will first release fully customizable column menus to show/hide columns and to easily perform other operations on columns.
This will be followed by context menus where you will be able to define your own custom actions on rows/cells in the table.

Don't worry, the menus will be fully customizable, the menu items are fully replaceable with whatever you need, or you will be able to swap our menu component with a custom one of your own.

New Features

Here's what we shipped in the month of August:

Row Selection

Row selection can be single or multiple, with or without a checkbox, with or without grouping and for a lazy or non-lazy DataSource - 😅 that was a long enumeration, but seriously, we think we got something great out there.

You can specify the selection via the rowSelection (controlled) or defaultRowSelection (uncontrolled) props, and listen to changes via the onRowSelectionChange callback prop.

This example shows how you can use multiple row selection with a predefined controlled value.

Go ahead and select some groups/rows and see the selection value adjust.

The example also shows how you can use the InfiniteTableApi to retrieve the actual ids of the selected rows.

Find out more on row selection - single vs multiple selection, grouped or ungrouped data, checkbox selection, lazy selection - read about all the possible combinations you can use to fit your needs.

Column Rendering Pipeline

The rendering pipeline for columns is a series of functions defined on the column that are called while rendering.

Most of those functions existed even before, but piping the return values from one to the other was not available. We think this is a big deal and opens up lots of use-cases.

All the columns that have render in their name, will be called with an object that has a renderBag property on it, which contains the values that the previous function in the pipeline returned.

For example:

const column: InfiniteTableColumn<T> = {
  valueGetter: ({ data, field }) => {
    return data[field] * 10
  },
  renderValue: ({ value, renderBag })=> {
    // accessing `value` here would give us the result from `data[field]`
    // but using `renderBag.value` would give us `data[field] * 10`, 
    // namely the result of the previous function in the pipeline
  }
}

Second example:

const column: InfiniteTableColumn<T> = {
  renderGroupIcon: ({ renderBag }) => {
    // we can use `renderBag.groupIcon` to have access to the default group icon and decorate it
    return <b style={{ padding: 10 }}>
      {renderBag.groupIcon}
    </b>
  },

  render: ({ renderBag })=> {
    // allows you to fully customize the end-result
    <>
      {renderBag.value}
      {renderBag.groupIcon}
      {renderBag.selectionCheckBox}
    </>
  }
}

These are all the properties available in the renderBag object:

value
groupIcon
selectionCheckBox

Here is the full list of the functions in the rendering pipeline, in order of invocation:

columns.valueGetter - doesn't have access to renderBag
columns.valueFormatter - doesn't have access to renderBag
columns.renderGroupIcon - can use all properties in renderBag
columns.renderSelectionCheckBox - can use all properties in renderBag
columns.renderValue - can use all properties in renderBag
columns.renderGroupValue - can use all properties in renderBag
columns.renderLeafValue - can use all properties in renderBag
columns.render - can use all properties in renderBag.

Additionally, thecolumns.components.ColumnCell custom component has access to the renderBag via useInfiniteColumnCell

Sortable Group Columns

When groupRenderStrategy is used, the group column is sortable by default if all the columns that are involved in grouping are sortable.

Sorting the group column makes the sortInfo have a value that looks like this:

const sortInfo = [
  { field: ['stack','age'], dir: 1, id: 'group-by', }
]

When groupRenderStrategy="multi-column", each group column is sortable by default if the column with the corresponding field is sortable.

In both single and multi group column render strategy, the columns.sortable property can be used to override the default behavior.

Updated Features

Here’s a list of Infinite Table functionalities that we enhanced in the last month:

Enhanced Group Columns

Group columns now inherit configuration from the columns bound to the field they are grouped by - if such columns exist.

In this example, the group column inherits the styling of the country column, because the country field is used for grouping.

The generated group column(s) - can be one for all groups or one for each group - will inherit the style/className/renderers from the columns corresponding to the group fields themselves (if those columns exist).

Additionally, there are other ways to override those inherited configurations, in order to configure the group columns:

use groupBy.column to specify how each grouping column should look for the respective field (in case of groupRenderStrateg="multi-column"
use groupColumn prop
- can be used as an object - ideal for when you have simple requirements and when groupRenderStrateg="single-column"
- as a function that returns a column configuration - can be used like this in either single or multiple group render strategy

Column Hiding when Grouping

When grouping is enabled, you can choose to hide some columns. Here are the two main ways to do this:

use hideColumnWhenGrouped - this will make columns bound to the group fields be hidden when grouping is active
use columns.defaultHiddenWhenGroupedBy (also available on the column types, as columnTypes.defaultHiddenWhenGroupedBy) - this is a column-level property, so you have more fine-grained control over what is hidden and when.

Valid values for columns.defaultHiddenWhenGroupedBy are:

"*" - when any grouping is active, hide the column that specifies this property
true - when the field this column is bound to is used in grouping, hides this column
keyof DATA_TYPE - specify an exact field that, when grouped by, makes this column be hidden
{[k in keyof DATA_TYPE]: true} - an object that can specify more fields. When there is grouping by any of those fields, the current column gets hidden.

In this example, the column bound to firstName field is set to hide when any grouping is active, since the group column is anyways found to the firstName field.

In addition, hideColumnWhenGrouped is set to true, so the stack and preferredLanguage columns are also hidden, since they are grouped by.

Group Columns Bound to a Field

Group columns can now be bound to a field, by leveraging the (obviously ...) property. This will make the group column render the value of that field for non-group rows.

In addition, you can now use columns.renderGroupValue and columns.renderLeafValue for configuring the rendered value for grouped vs non-grouped rows.

Column valueGetter in Sorting

Columns allow you to define a columns.valueGetter to change the value they are rendering (eg: when the DataSet has nested objects). Previously, this value returned by columns.valueGetter was not used when sorting the table. With the latest updated, the value returned by valueGetter is correctly used when sorting the grid locally.

What's the most useful feature for a DataGrid?

Infinite Table — Wed, 29 Jun 2022 20:59:03 +0000

As we're building https://infinite-table.com/ we know the it will be used in ways we haven't imagined yet - so we're developing the component with this flexibility in mind.

However, we're here to ask the community:

What do you want most from a DataGrid?

What's one feature that would immediately make you use Infinite Table?

How do you fetch and process your data

Infinite Table — Tue, 07 Jun 2022 10:32:00 +0000

Let's discuss - how do you fetch your tabular data?
Do you load it initially and then only do client side processing?
How do you sort - local or remote sorting? What about filtering?
Do you use grouping or pivoting - and if so, does it happen in the browser?
Keen to find out how other people do it 🤔

Navigating your react datagrid

Infinite Table — Tue, 07 Jun 2022 10:25:38 +0000

Using your keyboard to navigate around an app is crucial to moving fast and being productive.

With version 0.3.6 Infinite Table just added keyboard navigation to your favorite React DataGrid component.

Navigating table cells

By default, navigation is enabled for table cells - that means, as soon as the user clicks a cell, it becomes active and from that point onwards, the user can use arrow keys, page up/down and home/end keys to navigate.

Check out our documentation for keyboard navigation to see more demos and a complete reference guide.

Pro tip: when in cell navigation mode, you can use the Shift key to navigate horizontally in combination with page up/down and home/end keys.

In the example below, click a table cell and then use arrow keys to see keyboard navigation in action

Another nice feature of keyboard navigation for cells is that you can specify a default active cell - you do so by using defaultActiveCell=[2,0] - meaning the cell on row 2 and column 0 should be active initially.

Navigating table rows

Besides cell navigation, row navigation is also available. Switch to row navigation mode by specifying keyboardNavigation="row" - the rest is similar: user clicks a row, which becomes the active row. Using arrow keys, page up/down and home/end works as expected.

Having a default row set as active is also possible, via defaultActiveRowIndex={2} - this means the row at index 2 should be initially rendered as active.

Controlling active row/cell

Both cell and row navigation can be used as React uncontrolled and controlled behaviors.

In the controlled version, you have to use onActiveCellIndexChange (or onActiveRowIndexChange) to respond to navigation changes and update the corresponding index.

The example below demoes controlled cell navigation - initially starting with no active cell, and it updates the active cell as a result to user changes. This means you as a developer are responsible for updating the value when needed, as you no longer wish to leave this update to happen internally in the table. This makes controlled behavior excellent for advanced use-cases when you want to implement custom navigation logic.

Turning off keyboard navigation

Disabling keyboard navigation is done by specifying keyboardNavigation=false - this ensures the user can no longer interact with the table rows or cells via the keyboard.

Theming

There are a number of ways to customise the appearance of the element that highlights the active cell.

The easiest is to override those three CSS variables:

--infinite-active-cell-border-color--r - the red component of the border color
--infinite-active-cell-border-color--g - the green component of the border color
--infinite-active-cell-border-color--b - the blue component of the border color

The initial values for those are 77, 149 and215 respectively, so the border color is rgb(77, 149, 215).
In addition, the background color of the active cell highlight element is set to the same color as the border color (computed based on the above r, g and b variables), but with an opacity of 0.25, configured via the --infinite-active-cell-background-alpha CSS variable.

When the table is not focused, the opacity for the background color is set to 0.1, which is the default value of the --infinite-active-cell-background-alpha--table-unfocused CSS variable.

To summarize, use:

--infinite-active-cell-border-color--r
--infinite-active-cell-border-color--g
--infinite-active-cell-border-color--b to control border and background color of the active cell highlight element.

See below a demo on how easy it is to customize the colors for the active element highlighter

Enjoy

Thanks for following us thus far - we appreciate feedback, so please to let us know if keyboard navigation is useful for you or how we could make it better.

Please follow us @get_infinite to keep up-to-date with news about the product. Thank you.

Grouping and aggregating your data like a pro 🚀

Infinite Table — Thu, 26 May 2022 08:12:21 +0000

In most modern apps, you need to be able to visualise your data in multiple different ways. One useful approach to seeing data is by grouping it. What is the average salary by country? How many sales did we have this year? What was the biggest sale we had last quarter? All are common questions that can be easily answered by grouping and aggregating data.

Infinite Table can help you group your data easily, both locally and with a remote data-source.

Let's suppose your app is a developer marketplace and you have a list of developers defined by this TypeScript type:

type Developer = {
  id: number;
  firstName: string;
  lastName: string;
  country: string;
  city: string;
  currency: string;
  preferredLanguage: string;
  stack: string;
  canDesign: 'yes' | 'no';
  hobby: string;
  salary: number;
  age: number;
};

let's define a function to load the data source from the server

const dataSource = () => {
  return fetch(
   'https://infinite-table.com/.netlify/functions/' + 
   'json-server/developers1k-sql'
  )
    .then((r) => r.json())
    .then((data: Developer[]) => data);
};

Ok, so let's define our DataSource component to use the data function above - we'll use the id property as the primary key.

import { DataSource } from '@infinite-table/infinite-react'

<DataSource<Developer>
  data={dataSource}
  primaryKey="id"
/>

But wait, we need to actually render the table, inside the DataSource.

const columns: InfiniteTablePropColumns<Developer> = {
  firstName: {
    field: "firstName"
  },
  preferredLanguage: {
    field: 'preferredLanguage'
  },
  salary: {
    field: 'salary'
  },
  country: {
    field: 'country'
  }
};

<DataSource<Developer>
  data={dataSource}
  primaryKey="id"
>
  <InfiniteTable<Developer> columns={columns} />
</DataSource>

Let's visualise what we have to this point

Now let's add the interesting part - the grouping. Grouping is a prop of the DataSource

const groupBy = [{ field: "country" }];

<DataSource groupBy={groupBy} ... />

This would indeed group all the data, but in addition to that, we want to have some aggregation - let's find out the average salary by country. For this, we'll use aggregation reducers, defined as an object with multiple keys, on the DataSource. If you're familiar with Array.reduce, those should sound familiar - the job of those aggregation reducers is to ...well, reduce 😉 ... the whole datasource to a single value (also the groups inside the datasource to single values).

function sum(a: number, b: number) {
  return a + b;
}
const aggregations = {
  avgSalary: {
    field: "salary",
    initialValue: 0,
    reducer: sum,
    done: (total, arr) => Math.floor(
      arr.length ? total / arr.length : 0
    )
  }
} as DataSourcePropAggregationReducers<Developer>;

In the above snippet, we're saying we have an aggregation, with the id of avgSalary, that's computed based on the salary field. The initial value of the aggregation is 0, and the reducer function is the sum function. We also have a last step, described by the done function, which does some post-processing, computing the average.

Also, because the country column is grouped by, we'll remove it from the list of columns that we want to show.

We're almost there, so hang on - we'll only add 1 more thing - let's try to format the salary column a bit better. We can use the valueFormatter property for the salary column, and we want to format the numbers by using Intl.NumberFormat. Also, for group rows, we want the value to have Avg: ... prepended, while non-group rows will remain untouched.

  const numberFormatter = new Intl.NumberFormat();

  // the salary column
  {
    field: "salary",
    valueFormatter: ({ value, rowInfo }) => {
      value = numberFormatter.format(value);
      return rowInfo.isGroupRow ? `Avg: ${value}` : value;
    }
  }

We finally got to the end, ... that was quite a ride, so thank you for following along. For more in-depth documentation, see Infinite Table grouping page.

Follow us along our infinite journey (pun intended) as in the next posts we'll be exploring more ways to group data, strategies for grouping, remote integration, pivoting and more, to make visualising data easier than never.

Oh, and by the way, check out Multiple sorting for your React project if you haven't already.

Multiple sorting for your React project

Infinite Table — Tue, 24 May 2022 20:55:51 +0000

https://infinite-table.com/ is a new alternative for React projects that helps you display huge amounts of data, by using full virtualization.

In this demo, I want to show you how easy it is to have your data-source sorted using multiple fields.

We'll use a data-source that lists developers, with their first name, last name, age, country, city, salary and a few other fields

First, you need to import the InfiniteTable component and the DataSource component

import {
  InfiniteTable,
  DataSource,
} from '@infinite-table/infinite-react';

Next, since the component is built in Typescript, you can define the type of your data-source items, so let's define the TS type for that

type Developer = {
  id: number;
  firstName: string;
  lastName: string;
  country: string;
  city: string;
  currency: string;
  preferredLanguage: string;
  stack: string;
  canDesign: 'yes' | 'no';
  hobby: string;
  salary: number;
  age: number;
};

The next thing we have to do is define a function to load the data from the server, and that's as easy as a fetch request

const dataSource = () => {
  return fetch('https://infinite-table.com/.netlify/' + 
    'functions/json-server/developers1k'
  )
    .then((r) => r.json())
    .then((data: Developer[]) => data);
};

Now we're ready to render the DataSource component - please note it accepts a generic type, so it will be rendered as <DataSource<Developer> .../>

<DataSource<Developer>
  primaryKey="id"
  data={dataSource}>
/>

And where's the table component? Well, we'll nest it inside the DataSource. But first we need some columns for the table, so let's define a map of columns

const columns = {
  id:       { field: "id", defaultWidth: 80 },
  name:     { field: "firstName"},
  stack:    { field: "stack" },
  language: { field: "preferredLanguage" },
  country:  { field: "country" },
};

You can define any columns you want, and even map more columns to the same field from the DataSource - but that's for another article.

Now that we have the columns, we're ready to render the table as well,

<DataSource<Developer> primaryKey="id" data={dataSource}>
  <InfiniteTable<Developer> columns={columns} />
</DataSource>

Oh, and let's add sorting. Sorting is a concern for the data-source, so that should be a prop of the DataSource component.

<DataSource<Developer>
  primaryKey="id"
  data={dataSource}
  defaultSortInfo={[
   { field: "stack", dir: 1 },
   { field: "preferredLanguage", dir: 1 },
   { field: "country", dir: 1 }
 ]}
>
  <InfiniteTable<Developer> columns={columns} /> 
</DataSource>

The sorting is multiple sorting - so we're using an array - it clearly sends a message that there are multiple sorting properties being applied. For single sorting, use an object. Also, note the prop is called defaultSortInfo, as it's uncontrolled.
You could use the controlled sortInfo, but that's useful when you want to sort the array yourself, but just communicate to the table the sorting order, in order for it to show the correct UI details for sorting. But that's another story.

See the code in action below, and find out more about it at infinite-table.com