And on that note, Tanner has put together a bunch of example CodeSandboxes for the various features [0] . For our own app, I basically copied most of the default rendering logic from those, applied styles to match the rest of our app, and we've been adding some additional APIs to the grid from there to suit our needs.
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 wish more open source code took this approach. Rather than install something that is designed to be a black box that I don’t need to understand and can’t adapt, so often I would prefer to get a well designed, battle tested starting point, but be able to adapt and change that code in the future if I want to.
I did see someone suggest that maybe R-T v7 should ship with a component that implements the v6 API on top of the v7 implementation, but that would add a noticeable amount of overhead to the API and I'm not sure how much benefit there would be.
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.
Comments
And on that note, Tanner has put together a bunch of example CodeSandboxes for the various features [0] . For our own app, I basically copied most of the default rendering logic from those, applied styles to match the rest of our app, and we've been adding some additional APIs to the grid from there to suit our needs.
[0] https://github.com/tannerlinsley/react-table/blob/master/doc...
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.
I wish more open source code took this approach. Rather than install something that is designed to be a black box that I don’t need to understand and can’t adapt, so often I would prefer to get a well designed, battle tested starting point, but be able to adapt and change that code in the future if I want to.
I did see someone suggest that maybe R-T v7 should ship with a component that implements the v6 API on top of the v7 implementation, but that would add a noticeable amount of overhead to the API and I'm not sure how much benefit there would be.
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.