tannerlinsley

The force is strong with this one!

Thanks!

I wrote React Table and have never heard of those.

So no, React Table is not a reimplementation.

If you are not operating within the React Framework, I can totally agree with this. I used Ag-Grid before I built React Table and it shines as a JS-only datagrid. Start using React however, and I don't believe that is the case.

I would actually say that if you like React-Table, you likely wouldn't want to use Ag-Grid for the very reasons that React Table exists.

Had someone asked if there were similar tables libraries, I would have expected this response and welcomed it. Ag-Grid is a great library and their free-tier is very robust, but I don't see how the above comment is anything more than a drop-in marketing attempt.

I'm terribly sorry that you ended up in Canvas land for tables. I built and maintained Chart.js for a while, so I know how hard it can be to work with.

As for React Table, I have never run into a situation where drawing a table to canvas has ever been necessary. I guess I'll consider myself lucky, but I would still love to hear your use-case in a more structured format. Maybe a blog post?

- React Table is not an HOC - React may still show educational materials about HOC's but hooks replace their use-cases in almost every situation. - I don't see how HOC's are attempting to draw more separation of concerns between the traditional Markup/Logic/Style debate. They were simply the best solution at the time for creating reusable logic.

Yep! You're getting it now! Take a look at the examples and see just how easy it is to spin up your own table with React Table :)

I would say the "separation of concern" you're referring to is typically centered around (and definitely grew out of) the idea that styles, logic and markup should be in separate files or logical systems (html, css, js). The react ecosystem doesn't preach or empower this, and since React Table is built on that React, it also does not.

Hooks are a proper interface for modularization of logic, in the same way that components modularize markup (and potentially styles, eg css-in-js).

Since React Table v7 is just a collection of hooks, it is no more an attempt at separation of concerns than the core React hooks are.

In similarity, it is merely a utility that encapsulates configuration, state and side-effects into a modular unit that can be used to build your UI. Sounds exactly like React if you ask me.

By team, I think you mean me. I'm flattered! :)

Being a headless UI library doesn't necessarily mean that it has no business being in charge of your UI, it's more about the way that you interact with the API. If you look closely at React Table, it absolutely does take charge of your UI via prop-getters and inversion-of-control integrated into your table markup.

There are plenty of table libraries that do exactly what you are referring to by handling the things you want to "outsource" pertaining to UI-specific features. Ag-Grid comes to mind here, which is a fantastic library and might do what you're looking for. However, the main takeaway here is that markup-bound APIs that are designed to be totally "in charge of your UI" may not always get out of the way when you need them to. Take it from a maintainer who has seen hundreds and hundreds of "issues" and "feature requests" that essentially amount to "how can I take back control of the [markup, styles, scrolling, pagination, resizing magic, frozen columns, etc]".

It's true that there is a bit more work involved in managing this on your own, but you're not really on your own after all. Fostering a good community of examples and resources around a low-level library like React Table v7 relieves most of that pain and you'll find that the amount of work to build and control your own table markup and styles is not only easy, but liberating.

Also, I don't really think it's fair to generalize structure/pagination/sorting/filtering as trivial tasks. Conceptually they are all very simple, for sure. But, marrying all of these features together in a way that is extremely performant across all of the many flexible permutations of features is very difficult. Ask any table library author and they will likely tell you that those 4 seemingly simple tasks are the ones that complicate everything else by a magnitude of difficulty.

Thanks for your feedback!

I've toyed with that idea for a long time now. I go back and forth, but as of today, I don't feel like that would do much good with the success I've seen people having with the examples. Sure, v6 was popular because it was very AG-grid like and included everything you could ever want and just dropped right in. But IMO, that led to most of its long-term and difficult problems, mainly issues around "How do I style this", "How can I rearrange this", "How can I extend it to do this". I find it much easier to show people how to make their own table component in an 80 line example, then extend it in userland to fit their needs.

I'm always open to the idea though.

So does React-Form ;) https://github.com/tannerlinsley/react-form

That's very strange. Can you file an issue or send me more info on how to replicate that issue?

Thanks! Be sure to get your company to sponsor me on Github if you can!

This is how I envisioned things from the beginning. Some people may want a quick drop-in library, since that's what they're used to, but in reality, copying and pasting an example into a `component/Table.js` file is essentially the same thing. The only thing it's missing is styles, which are implemented so differently these days, it's almost impossible to ship standard table styles without compromising the majority of users in some way.

I'm happy with the low-level + examples approach.

- Exporting to excel is simple. You are provided the final data model after all processing/filtering/sorting/etc is done, and you are free to use whatever means you want to provide that data to your users, eg. The 'xlsx' npm package could do this easily.

- Searching/Filter is quite advanced. You can search/filter on any derived model of the data regardless of the display or format of that data.

- Sorting can also be 100% customized and can be configured to use any derived sorting mechanism that you choose or build, regardless of display or format.

"Plain old HTML" is great. And guess what, because React Table is headless, you can render your tables using standard HTML table elements (table,thead,tbody,tr,th,td,tfoot,etc...).

Html elements on their own, however, are not capable of sorting, filtering, grouping, selection, nested header generation, (insert any feature from React Table here), let alone making all of those things perform well together.

I started work on react-charts last year, but became distracted with other OSS projects. I plan on revisiting this ecosystem very soon. In my experience with all of the libraries mentioned in this thread, some of them came close to feeling like they belong in the react ecosystem, but a lot of them missed the point on the "why" of react, usually by becoming too non-declarative, relying on other libs for DOM manipulation, or not striking the right balance between configuration and modularization. Maybe someday we'll have a great library that feels just as good to use as react itself. I hope that day comes soon.

TL;DR - React-Move 2.0 is a merge of Steve Hall's Resonance library into React-Move.

- Mind boggling performance - Amazing stability - A simple and even more powerful API - Delays, staggers, and complex transition groups - Multi-step Transitions - Animation lifecycle hooks

Example Here: https://codesandbox.io/s/j4mv3lvj6v?from-embed

That's very sad! React-Move may implement very simple animation "concepts" that you could perform on your own, but there is immense value in the reusable API that React-Move exposes. If you were to utilize d3-interpolate, or a tweening library directly, you would still need to: handle proper react-lifecycle updates, animation-frame batching, detect when to reanimate, provide a deterministic and reusable api that promotes good composition, support as much of the ecosystem as possible, and at the same time keep dependencies and component footprint as small as possible. React-Move provides all of these things in a battle tested package that, given its rapid growth, has already proved its suitability for the majority use-case and general animation needs of React users.

On the topic of hardware acceleration, there are a some good perks to using class-based/keyframe CSS animation, but you immediately forfeit any ability to utilize dynamic run-time values. It's also important to note that even though React-Move's animation loop is being executed in Javascript instead of the browser's GPU thread, doesn't mean React-Move doesn't utilize hardware acceleration. By mapping these interpolated values to hardware-accelerated css properties, you are in fact using hardware-accelerated transitions, albeit at the speed of the JS thread.

If all of these amazing features aren't your cup of tea, then I would most definitely suggest that you roll your own solution. :)

Cheers!

FYI, just added support for custom easing functions. :)

Just to confirm, React-Move DOES WORK in react-native!!! :)

uarn add react-move or npm install react-move. Take your pick

That's an interesting idea. Would love to see a proof of concept!

You should try and let me know!

Custom interpolation is on the way, along with custom easing functions. As for the staggering, It would be fairly trivial to add some more customization to the parameters that go into it. Join this slack org and maybe we can chat about it? https://react-chat-signup.herokuapp.com/

You will almost always get better performance with CSS, unless you are using something like GSAP (which actually beats hardware accelerated CSS in some case). There are times though when you need animation to be dynamic, and React can be difficult to use with the more established framework agnostic animation libraries. This is also still a very young project, so I'm sure there are optimizations to be had. At some point, you will always be able to overwhelm the browser thread with too much to animate in under 16ms. I hope to get as close to (or under) that target as React and RAF will allow. As for the size, you may be right compared to standalone animation libraries. I am mostly comparing it to something like React-Motion (30kb I think?)

Hahaha, what can I say, it sounds so nice :)

We're still working on some edge cases that will result in frames dropped. There will soon be a way to prioritize frame rate over duration precision and visa versa. Stay tuned!

Everything but React :)

Unfortunately react-storybook is not very mobile friendly. I would suggest using the Codepen demo instead. Here is the full screen link for that: http://codepen.io/tannerlinsley/full/dWYEwd/