[Question] Future plans, roadmap, data lazy loading, paging

[MirKml]

Hello guys.
Your component is nice, we are using it extensively. But this year we are watching some uncertainty in development of this package. Answer please our questions, we are considering switch to another component and clarifying current development state and future plans help us a lot.

Current master seems to without any significant work, even bugs and pull requests are leaving untouched. Most of new work is currently in next and canary branches, all seems to is rewritten and refactored into Typescript.

• What are differences between these branches - next, canary? Canary is for some experiments, which are later merged into next?
• Do you have any time estimate about release new stable version?
• Are you plan any new major features for this new versions?
• Our major missing features is some way of data lazy loading or "lazy" pagination. Grid itself for millions of rows has good performance, but to have these amount of data loaded into app is problem - memory, performace. We need some kind of data lazy loading or pagination support. Are you plan any support for these feature, directly or in component API? If yes, do you have any time estimation?

[jwallet]

Here at work we use the canary version since you guys did a great work reworking the css.

We are just questionning the need of removing old api of #1762 (row selection), I don't think it costs a lot to leave it, if the prop is not given, react won't render it. We have to render our lists with checkbox to select rows (customer demands) and we use a wrapper on the Row so we can handle the onClick, when clicking on the row it redirects the user to the item route. We also use this same row wrapper to add row actions at the end of the line (one thing that was missing in the api, it appears on :hover).

(old list component before use of rdg)

If we can add some stuff here:

nice to fix

• responsive custom headerRenderer so we don't need to have our component Connect to redux-store (rdg doesn't update headerRenderer props after mount)
• onRowClick with the native clickEvent in the props (current: (id, row, colum) => )
  edit: looks like it was added (example13-all-features.js, tag version canary.3+

nice to keep

• use of checkbox to select row, since the api offers to use a custom RowRenderer and it breaks the use of the new row selection.
  edit: added in canary.3+ ? by adding SelectColumn in columns array from import { SelectColumn } from 'react-data-grid'

nice to have

• row actions at the end of the line
• headerActions (gear box) / context menu for header, so we can select columns to display

[qili26]

@MirKml
Thanks for the long msg and here are the replies for each of your question.

What are differences between these branches - next, canary? Canary is for some experiments, which are later merged into next?

1. master is current v6 which was written in pure javascript and it has some buggy codes for selection, performance and etc. For maintenance perspective, the code is really hard to maintain.
2. next is the current most latest alpha version, this branch added the typescript support which means if you also use typescript in your project, you don't need to install the @types/react-data-grid separately as that file was not maintained directly by RDG. It also has some small fixes, but as far as I remember, it doesn't have any break changes.
3. canary version is based on next branch which aggressively removed some APIs that doesn't make any sense, and improved the performance vastly, in addition, it cleaned the existing css issue a lot with removing bootstrap. It also added new features like summary row and fixed some bugs like select all checkbox.

Do you have any time estimate about release new stable version? Are you plan any new major features for this new versions?

If you are still using v6 and planning to keep using this lib, you could start using the latest alpha which has the type support. If you just started a new project, maybe you could just start by canary. Though I don't know when, but the canary branch will eventually be merged into next. Moreover, I don't know if @amanmahajan7 wants to release v7 with current next and then release v8 with the canary features yet.

Our major missing features is some way of data lazy loading or "lazy" pagination.

I believe for the grid itself, it doesn't need to support the pagination. The reason is that for RDG, it takes the data that you give and renders it. So, you could just implement or reuse any pagination lib and place it beneath the grid and pass the filtered data to RDG. By doing so, you had more controls for styling and features you want to have in the pagination.

[qili26]

@jwallet
The row selection API was designed with flaw and had so many different versions to instruct the grid that the row selection feature was enabled. In addition, given by it's not React-ish, it was redesigned to be simple and straightforward. Row selection is not just about single selection, it handles selecting all, shift + selecting multiple rows, so I believe it still makes sense for RDG to provide it natively. Though with that being said, it can still always be customized based on your business needs.

responsive custom headerRenderer so we don't need to have our component Connect to redux-store (rdg doesn't update headerRenderer props after mount)

This indeed is a problem and so as the old APIs like column.formatter allows you to directly pass a JSX.Element. I believe the road map was to fix Editor to be React-ish first and then head back to centralize the cell renderer to make sure HeaderCell is normalized as a regular Cell.

nice to have

• row actions at the end of the line
• headerActions (gear box) / context menu for header, so we can select columns to display

• Could you be more specific for the row actions at the end of the line?
• This is indeed a nice to have feature. However I don't know if we want to directly support show / hide column like this. As eventually that piece of UI will just mark the column to be visible or invisible, which means the state is still in your app, and it's the upper level's responsibility to filter out the columns and then pass to the RDG, as RDG is trying to hold as less state as it could to just be a representing layer. One suggestion at the moment would be adding a button above the grid like a tool bar help action, and you can implement a simple dropdown to toggle the columns.

[jwallet]

• row actions at the end of the line

* Could you be more specific for the `row actions at the end of the line`?

something which stays over the line when scrolling horizontally (like absolute position) to show actions buttons (icons) (insert, delete, move), pretty much like using the contextual menu but for quick access.
btw, like this screenshot shows, we found a way to show it using rowRenderer, and the use of the contextual menu addon made it easier to show all actions, probably will remove on-line actions since it's buggy when scrolling in favor of the menus

[MirKml]

Thanks for answers.

[qili26]

@MirKml
I created a PR for the "lazy loading", it's used for lazy loading but a more general API. I believe we can still achieve it in the onScroll callback with some hack without the new API, so at the moment you could mimic what's inside for the lazy loading if you are using v7 alpha or v6.

#1824