Reactabular 1.0.0-rc5 out - Feedback welcome!

To keep this manageable, I’ll be opening a separate issue per release candidate from now on. You can still see the old changes at #148 if you are interested.

This release focuses on performance. I noticed especially column resizing started to get laggy with large amounts of data so I fixed that. The performance tweaks lead to API improvements and I refactored the API more than I had in mind. But that’s good as it’s a little easier now. Main changes below:

• Pushed calculation to Table.Provider as much as I could. Smaller gains, but still nice to do. Now it splits up the data per header and body in a better way so there’s less to calculate.
• Implemented shouldComponentUpdate for Table.Body and table row. There’s no cell level optimization yet as I feel this helps quite a bit already. And it certainly fixed the resize issue. Note that you should not mutate data you are passing to Reactabular. After this change that simply won’t work anymore as then it won’t be able to perform the check reliably.
• As a result I had to simplify the editing interface. The gotcha is that you should stash your editing state within the data you pass to the table. I still have to fix the Excel example to work like this. That’s for the next RC.
• Pushed data resolution (i.e. property: 'foo.bar' ) to a separate function. If you are using data like this, you will have to resolve the data before passing it to Reactabular. Even though this is more work for you, it cleans up the internals a notch.
• Made highlight work as a combination of a function you apply over your data (good name anyone?) and a filter. The former attaches highlighting annotation to the data while the filter uses it. As a result the filter declaration is simpler and you don’t need to pass the property name to it anymore. But you need to remember to apply the highlighter to your data.

The system still supports cell.resolve internally. I hope to do the same with this as with property resolution (foo.bar) and extract it out of core. The advantage of doing this is that it will clean up search/highlight/sort and avoid work (only single pass). Most likely this has to rely on some sort of convention. Perhaps I’ll use a similar idea as I used with highlight. It could use the same auxiliary structure even now that I think of it.

If you have any ideas or find issues, please open separate issues so it’s easier to track. I feel we are close to a final release as the problems seem to be getting smaller. After the 1.0 release it’s a good time to think about splitting this up into smaller packages. The current structure is somewhat modular already so that shouldn’t be a big problem.

You can install the release candidate through npm i reactabular@rc5.

[bebraw]

Not a separate issue, but could you elaborate a bit on what you think resolving functions will look like? I have a handful of cases where my resolving logic is more involved than what _.get would do (e.g. resolving a bunch of time/date data from rowData into a string such that it’s sortable, and then format-ing it into a totally different look for display) … just curious what you have in mind. Anything that brings us closer to the single-pass-pipeline ideal I’m obviously very supportive of! 😃

I expect cell.resolve will remain. I’ll do a separate pass for those so you’ll get another variant of the current resolve except that it won’t touch the values and generates separate ones instead.

This gets us to single pass system and allows me to drop direct cell.resolve calls from the core logic. It still has to do a lookup but it can avoid the function calls.

Even the single pass system can be optimized further I think, but that’s another problem. We might need to expose a cell iterator and then do some sort of fusion over those while mapping all input or so.

[bebraw]

Closing as rc6 is out (#167).