Roadmap

[hassankhan]

Hi @glittershark, just wanted to know what the future of the project is? I remember you saying there were some changes you wanted to make and I was wondering what they were.

[alisman]

This component meets a lot of our requirements and I think has a strong future. But we need to able to render components easily inside of data-driven table (that is, when data property is used, not Tr/Td). There are currently two PRs that meet this need, mine and another one. Either one would be great!

[hassankhan]

Just wanted to say that we all love this project (hands-down the best data table library for React IMO) and we just want to make sure it receives the care it deserves 😄

[alisman]

Let me second @hassankhan. Every other datatable we've tried seems consumed with solving edge case problems. We just wanted a standard HTML table with some added features like sorting, filtering etc. Long live reactable

[hassankhan]

Pinging @glittershark

[hassankhan]

I'm only being persistent because there are some issues that I would love to see addressed, and I just want to be assured that any work I do will get merged/released soon. For starters I'd love to see the warnings go away for once and for all, and secondly I'd love to see a re-do of pagination, either like #4 or by passing a paginatorComponent prop to <Table />. There are some PRs and issues floating around on the topic, so it'd be great to get an update and plan accordingly.

[glittershark]

So, in the last few months the time I've had to maintain this has waned a little bit as work has been taking up more and more of my time. Let's see if I can address the specific things you're asking for:

• rendering rows in components: absolutely want this, but it's fairly difficult to achieve given how Reactable actually needs a fully rendered sub-tree in order to parse through child data. I took a crack at it a while back, and ran into some fairly unsurmountable issues. I'd accept a working patch though
• rendering components in the data prop: this one's a non-goal, as I don't feel like it provides much value (calling .map on an array is easy). The data prop was always intended as a kind of ramp-up to the full sub-tree rendering, which I would consider the "primary" interface to Reactable. I've been thinking about reworking the docs to make that clear for a while now.
• Pagination re-do: this one's been necessary basically since day 1 (thus why #4 is such a low-numbered issue). Probably top of the list at the moment.

[glittershark]

As far as things not already mentioned in this thread:

• People keep asking for colspan and rowspan - I'm not sure how it'd work with sorting and pagination, but if someone can come up with an API that makes sense I'm open to it
• Async loading of data is something I keep waffling on, as I'm not entirely sure Reactable provides a lot of value there given how idiosyncratic a lot of APIs can be. That said, I think the majority of real-world use cases for a data table involve async data loading so I could see moving into that space at some point

[hassankhan]

Awesome, thanks for the response! I've started work on a branch. There's a fair few changes, mainly:

• Using Lodash for any data transformations
• Using newer version of React
• Using Webpack
• Making the code a little friendlier
• Using slightly more idiomatic React

Ideally, I want to get it back to feature parity using the test suite. That said, there's quite a few ways of passing data into a <Table /> 😮 . Once I get that out of the way, I think there might be a few other things worth considering:

• Should Reactable keep supporting the multiple ways of passing data? While its flexible, it makes things quite complex internally as we have to parse all the child nodes to get a complete picture. If we were to only receive data through <Table />, we could get rid of a lot of logic.
• Make the filter input a separate component and provide a filterComponent prop.
• Add stricter PropTypes validation - this might break a few things as well.

[glittershark]

The only thing I'm against in that list is using Lodash - I'd rather not force that dependency on any upstream consumers. We as library authors have the burden of doing all the stuff that libraries like lodash make easy manually, so that application developers don't have to 😄

[glittershark]

In the same vein, I'm fine with internal complexity, especially given how good the test coverage is (should be basically 100%). The entire point of libraries imo is to be complex so you don't have to.

[alisman]

I'm not sure I understand the resistance to custom components in data (or specified in column object). The alternative would seem to be specifying all columns in markup even if only one column necessitated component rendering (a button, say). I think people expect to be able to just hand some data to a datatable component and maybe do some limited customization.

[hassankhan]

@glittershark True, but I feel there's no point in reinventing the wheel for simple things like checking types etc., and using Webpack and ES6 imports we can specifically only require the functions we need and use tree-shaking to exclude unused code. We need not even require Lodash as a dependency, rather a few functions from it listed as separate devDependencies. When we bundle for distribution, the consumer only gets whats necessary.

In terms on internal complexity, I don't feel that the codebase is very welcoming to new contributors or that it lends itself to extension very well, even with near 100% test coverage. I've spent the past few days trying to figure out the best way of parsing/storing the data internally and its not terribly obvious from looking at the code. While libraries are supposed to be complex, they don't have to be more than need be 😄

@alisman Currently I'm focusing on getting the branch up to parity, once I'm done we'll see what, if any changes, get made to either this repo or our fork.