Repository navigation
Roadmap for V2.0 #3
Description
Activity
- pinned this issue
on Apr 3, 2019 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?
I think
CellMeasureris too heavy, that's why I didn't support that whenBaseTableis built onreact-virtualizedWhat do you thing about configuring react-draggable and make it lazy loadable ?
@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.
大佬 打算什么时候出新版本啊~~~~~
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.
Reacted by Danielly Costa and Mike Lischke-
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
EllipsisTextas 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 theTableCellviacomponentshttps://autodesk.github.io/react-base-table/examples/tooltip-cellIf 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
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
EllipsisTextas 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 theTableCellviacomponentshttps://autodesk.github.io/react-base-table/examples/tooltip-cellTo 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
/ >15 remaining items
@jamesonhill good idea
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 - #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+.
@gjthompson1
react-virtualizedsupports horizontal virtualization, while this one does not. Doesn't seem like an apples to apples comparison.@gjthompson1 This is my thoughts on this kind of questions #36 (comment), and there is a workaround actually #36 (comment), you will find it works well with 1000 columns, and I believe there is space for further optimization, I simply made some changes on the example here #36 (comment)
Reacted by Glendon Thompson@nihgwu very nice, yeh that seems to be much smoother. Thank you!
Need this version 2 release
Reacted by cameronevansIt has been more than two years since I created this ticket, a lot of things have changed, for example I'm not the admin of this repo anymore, so I can't land any changes(I revoked my 2FA to Github, I emailed to opensource@autodesk.com for the permission but no response for quite a long time). Although I don't work for the project which I created this component for, but I always have the willing to make the wish-list come true. Thanks for the abandonment of IE(the only reason I used three tables to achieve frozen columns), those features could be accomplished in a super simple way and much better performance(using
position: sticky, and also unblocks a lot of wonderful features which are hard to implement before, like sticky header on window scrolling, I made a simple demo from scratch, but it's more a toy in my spare time
Does that mean we should not rely on this library any more? @nihgwu
@kaleem-elahi No, even I don't use this component much as I leave the previous project, but it's a baby of mine, so I will keep on improving it(and it's still heavily used in the projects I worked on), and actually there are not much blocking issues for the current version, and I'll ask for the permission to access this repo for better maintenance, what I wanted to say is that for the next major version it's going to be a completely rewrite so it won't arrive soon
Reacted by Alexander Kachkaev, Alexey Stratan, Kevin Do, Turner, WeiSheng_ and Justin Yip@nihgwu any luck regaining admin/maintainer rights for this repo?
@jamesonhill not yet, I'll contact my ex-colleague for help, seems the open-source email address is abandoned
Reacted by Alexander KachkaevHi everyone, how about just forking the project and creating a new package?
Hey @nihgwu was curious if getting rid of the multiple grids for frozen columns would be in this roadmap? I started looking into it and have it working but some of the snapshots need to be updated. Also is this still your vision for 2.0 or have new features come into mind since its been awhile? Thanks for the awesome grid btw! :)
Here is the wishlist I'd like to have for the next major version:
Gridfor table headerreact-virtualizedwithreact-windowreplace react-virtualized with react-window #12Breaking changes:
rollupto bundle packagerowRenderertagNametoasorelementTypescrollToPositiontoscrollToheaderRenderertoheaderRowRendererheaderRendererforColumntoheaderCellRendererAutoResizerto a separate packageNice to have: