Roadmap for V2.0

[nihgwu]

Here is the wishlist I'd like to have for the next major version:

• [x] Don't use Grid for table header
• [x] Replace react-virtualized with react-window #12
• [x] remove deprecated lifecycles #10
• [x] Dynamic row heights #170
• [ ] Make virtualization configurable
• [ ] A11y
• [ ] UT
• [ ] plugin support
• [ ] rewrite with TypeScript
• [ ] support custom children key

Breaking changes:

• [ ] use rollup to bundle package
• [ ] omit placeholders in rowRenderer
• [ ] rename tagName to as or elementType
• [ ] rename scrollToPosition to scrollTo
• [ ] rename headerRenderer to headerRowRenderer
• [ ] rename headerRenderer for Column to headerCellRenderer
• [ ] move AutoResizer to a separate package

Nice to have:

• [ ] better size calculation to support cell with borders #149

[Gervwyk]

Hi @nihgwu ! I'm liking BaseTable so far! However it will only be useful for me if we have dynamic row heights. Where can I start to make this happen? I see it's dependant on #102, but it looks like that can still be a while.

[nihgwu]

I'm sorry @Gervwyk I'd say I won't start working on that until that PR is merged, I'm lot expert on this field, do you have any other ideas?

[Gervwyk]

No me neither. Just started looking at some of the code, do you think it would be possible to just achieve this via CellMeasurer? Similar to the way it's done in react-virtualized?

[nihgwu]

I think CellMeasurer is too heavy, that's why I didn't support that when BaseTable is built on react-virtualized

[zmitry]

What do you thing about configuring react-draggable and make it lazy loadable ?

[nihgwu]

@zmitry any concern about that? I do have the plan to remove the dependency on react-draggable

[zmitry]

@nihgwu it's used only for column resizer so it might be useless for some cases where you don't need that feature. I don't mind to have it as dependency but it takes 1/3 of the table bundlesize, so it might be quire useful to be able to import it lazily only if you use it. If you want to remove that will solve my usecase also.

[Nokecy]

大佬 打算什么时候出新版本啊~~~~~

[nihgwu]

@Nokecy I don't see any MUST to bump the major version soon, until the dynamic row height dependency is resolved

[elevator3]

First of all I just wanted to say that I really really like the react-base-table but am unable to use it right now for the following reasons. It also seems to me that those are issues that everyone will benefit from…

• Lack of documentation. The examples are great but they do not describe well what are the additional options or full usage of the particular feature. Not as easy to figure whatever you are looking at especially for the more complicated examples.

• I am not sure who is using the ellipsis in the cells and why would that be a default other than the table not being able to support auto row heights.

• If you use the rowHeight to modify the row height of the whole table the performance when displaying hundreds of rows, which is something that is supposed to be better, goes out of the window.

Please understand this is not a criticism of what you currently have but a request to make it easier for people to understand and start use it with enough basic features out of the box.

[nihgwu]

Lack of documentation. The examples are great but they do not describe well what are the additional options or full usage of the particular feature. Not as easy to figure whatever you are looking at especially for the more complicated examples.

I definitely agree with you that documentation is important for a component and BaseTable is really bad on that, I'll try my best to add more in the future

I am not sure who is using the ellipsis in the cells and why would that be a default other than the table not being able to support auto row heights.

I don't make something like EllipsisText as default to make BaseTable irrelevant to any ui libraries, so you are free to choose the component with the style aligned to your application, you can use react-texty or other components as your wish, you just need to customize the TableCell via components https://autodesk.github.io/react-base-table/examples/tooltip-cell

If you use the rowHeight to modify the row height of the whole table the performance when displaying hundreds of rows, which is something that is supposed to be better, goes out of the window.

Sorry I don't understand your statement here

[elevator3]

Lack of documentation. The examples are great but they do not describe well what are the additional options or full usage of the particular feature. Not as easy to figure whatever you are looking at especially for the more complicated examples.

I definitely agree with you that documentation is important for a component and BaseTable is really bad on that, I'll try my best to add more in the future

I am not sure who is using the ellipsis in the cells and why would that be a default other than the table not being able to support auto row heights.

I don't make something like EllipsisText as default to make BaseTable irrelevant to any ui libraries, so you are free to choose the component with the style aligned to your application, you can use react-texty or other components as your wish, you just need to customize the TableCell via components https://autodesk.github.io/react-base-table/examples/tooltip-cell

To your point here. The problem is that if you have more text in a cell than the cell is able to visualize using the height of the cell/roll right now the table defaults to showing "some text..." This seems to be currently the default behavior. All I am saying is that this could be useful possibly for 10% of the people that are using the table. In essence you are forcing the other 90% to customize the table for this critical feature out of the table by telling them to use another library. This is bad experience right from the start. Why not allow for easy customization for both options ( the text to wrap and automatically extend the height of the cell/row vs. to show the "..." ).

If you use the rowHeight to modify the row height of the whole table the performance when displaying hundreds of rows, which is something that is supposed to be better, goes out of the window.

Sorry I don't understand your statement here < Table // rowHeight={130} - good performance rowHeight={130} - bad performance / >

[nihgwu]

@elevator3 Sorry for the late response, I missed your reply somehow, for your first point, I'd internally more then 90% of our teams/products are using fixed row height, I do want to support dynamic row height which automatically stretch/shrink on the cell's content, it's the 4th item in the roadmap, the feature in react-window is still experimental, and still not available in any stable release, I know I can use the same strategy as react-virtualized does using CellMeasurer, but it's too heavy and I don't want to use. Maybe I will make is available in virtualized=false mode, which is the 5th item in the roadmap.

For the second, I don't see any difference by switching the the rowHeight between 130 and the default value, why rowHeight={130} performed bad?

[gyurcigyurma]

My wish (or maybe already exists?) that if XHR response has no exact "children" key, then I don't have to transform it. My problem that I call a public API, which sends a tree-structure and the master key is "details" which is a collection. So I just rename all "details" to "children". So expecting like this (note the childrenAccessorKey):

              <BaseTable
                  width={width}
                  height={height}
                  columns={tableColumns}
                  data={dataToRender}
                  expandColumnKey='code'
                  childrenAccessorKey="details"
                  rowHeight={40}
                />

Sorry maybe this is an existing feature but I couldn't find.

[nihgwu]

@gyurcigyurma that's not on the list, will add it, thanks

[jamesonhill]

Is there a WIP for this? I'm forking this project to add dynamic row height support for a project i'm working on. If I can add that support in a matter consistent w/ the v2 api, I would prefer to do so.

[nihgwu]

@jamesonhill sorry I'm a bit busy those days, will start the work next month, the challenge to add dynamic row height support in master(v1) is that we are calculating the total height to support infinite loading, we should use another mechanism in the next version

[jamesonhill]

@nihgwu Sounds good. I will make an attempt at dynamic row heights in our fork. If we can get it working I'm happy to help w/ v2 once you have the time to begin it.

[jamesonhill]

@nihgwu Is it worthwhile for me to open a PR adding Typescript type declarations? If you'd rather wait until V2, I can add them to @DefinitelyTyped instead for V1.

[nihgwu]

@jamesonhill I'm not ready to add type declarations in V1 as I have little knowledge on TS right now, and I'm not going to add something I'm not familiar with, sorry. So I'd prefer to add them to DefinitelyTyped for now

[nihgwu]

Hey @jamesonhill are you still interested in the TS type declarations, I'm going to do it in V1, and based on @sskiswani 's work in #93, I'm pretty new to TS, so if you can help to make it better that would wonderful BTW, does the dynamic row height work well in your apps?

[jamesonhill]

@nihgwu yes i can help w/ the TS types & conversion. I didn't get around to submitting a PR to @DefinitelyTyped, but I have a good start on them in our repo that I can bring over. So far so good w/ dynamic row heights. I've implemented it on one of our more basic grids (only displays & sorts data, no frozen cols or anything fancy) and it works well. Working on a more complex instance w/ resizing & freeze currently.

[nihgwu]

cool, I just release a new version v1.10.5 within #192 which I think should be the last part for the dynamic row height feature

[jamesonhill]

I'll open a WIP PR later today w/ the start of the typings for V1.

[abubakir1997]

Any plans on including grouping by one or more columns? Just like in material table https://material-table.com/#/docs/features/grouping

[nihgwu]

@abubakir1997 it won't be a builtin feature, you can implement it by yourself like this https://autodesk.github.io/react-base-table/examples/multi-header

[jamesonhill]

For V2, would you consider making the params for unflatten and flattenOnKeys an object? Since there are multiple default params, it makes it kinda awkward IMO to only pass single param.

For example, with unflatten(array, rootId = null, dataKey = 'id', parentKey = 'parentId'), if I want to just provide a custom parentId I would have to do unflatten(array, undefined, undefined, myParentId).

It would be nicer DX IMO if I could do something like unflatten(array, { parentId: someOtherId }).

[nihgwu]

@jamesonhill good idea

[gjthompson1]

I'm not sure if this has come up before. But the package doesn't really handle a large number of columns well. Or maybe I am doing something wrong....?

If you play around with this you can see that with 1,000 columns it performs well but with base table just cranking the number of columns up to 1,000 here https://autodesk.github.io/react-base-table/playground scrolling down becomes very clunky.

Update: Scratch that just found this - https://github.com/Autodesk/react-base-table/issues/36

This is free for me to use to I'm not complaining or anything but just some feedback as a prospective user of the library. I came here looking for a "high performance" table component. My application essentially allows any input data shapes e.g. could be 10 x 18,000,000 or 2,000 x 2,000. Typically datasets are longer than they are wide but you do encounter them especially ~100's of columns, ~1,000 is rarer but happens. As a result this library isn't really usable (at least for my purposes). It's easier to selectively render the length based on some server call but the width is a challenge. Most component library tables choke with columns ~100+.

[jamesonhill]

@gjthompson1 react-virtualized supports horizontal virtualization, while this one does not. Doesn't seem like an apples to apples comparison.