Why this library so overcomplicated?

[SNPR]

First of all, I love this library and I still use v6 on my old project.

Last week we started a new project with TypeScript and React and I decided to use v7 for the table creation.
I spent about 3 full workdays and I still don't understand how to create simple table with TypeScript.

I have just one question - why this library API so difficult to understand in contrast to v6?

[tannerlinsley]

Where v6 shipped with an opinionated UI on top of it, and buried more of the logic inside of its core, v7 instead, exposes that core logic and expects you to build your own UI on top of it.

While this may seem more "complicated", it is no way "over"-complicated. In fact, it is the same complexity and amount of logic, or less in some scenarios, than v6. The architecture of incrementally adding hooks to the base useTable hook to extend its functionality is awesome and yes, is still a challenge with Typescript, but seeing how this is not a Typescript-first library, that's expected.

I didn't write, maintain the types, nor do I use them, so I can't begin to understand why it would take you 3 days to create a simple table when the same is possible without Typescript in about 5 minutes by copying and pasting any of the examples into your codebase.

I'm sorry this has been your experience and I encourage you to contribute to the 3rd party community types in Definitely Typed if this is important to you.

[omridevk]

As a new user of this library, I do have to somewhat agree with @SNPR, needless, the say the "headless" library approach was a brilliant move and v7 is really freaking awesome. I do think the documentation does cover the whole story and I do see it is a work in progress so that's also freaking awesome!
I am also using typescript with react-table, and I think most of the typing issues comes from the hooks, which are not well typed. Not that I am TS expert or anything, but my experience so far was to throw "any" where the types are wrong and perhaps declare the type myself (won't happen since these are really complicated types).
And I do believe making a table with all these rich features will result in a complex being, but luckily they provide so many examples.
Anyway not sure where I am going with this, but I kinda agree with @tannerlinsley at the end, the it is not over complicated, (we also used v6 in our workplace) and the same, if not more amount of code was needed to create a selected table, while in v7 this was a breeze.
v7 is a really brilliant move! a freaking job well done!

[SNPR]

@tannerlinsley thank you for your answer. I don't have any complaints about your library. Thank you and all maintainers for this great tool!

Probably, this library became too complex for junior frontend developers :-)
I still don't understand how React hooks works and maybe here's the problem.
A lot of magic everywhere :-)

[jonasandero]

Maybe I am throwing gasoline in the fire here, but is there any particular reason that this project is not migrated to TypeScript?

[gargroh]

I am guessing, its author's wish(may be...he do not want to invest his time in dealing with types and solve problem in js), if anybody wants to use in TS it has its types in DT.

[tannerlinsley]

A few quick thoughts (I don't have a lot of time today, so this is from the hip)

• v7 is more like a "core" library, not a UI component. It's utility that allows you to build tables in React in general. The component layer that existed in v6 was a good component, but a bad utility. You had to fight with it to get it to do complex things. I'm currently working on something like v6 for the future. Not sure when it will be released, but it will likely shape a better future for react-table in general.
• I don't use TS in my daily work, so naturally I don't write quickly/well with it. This doesn't mean that the code I write doesn't use "types", they are just unfortunately implicit and stored in my brain (and the various object shapes and API contracts that I have designed). In the future this may change, but until then this does a few things:
  • TS users are free to contribute to the types as they wish. Don't demand, contribute.
  • Non-TS users are welcome to contribute to this library. No intimidation.
  • Tests are prioritized over types. DX is great, but reliability is more important right now.

[tannerlinsley]

This is outdated. Typescript all the way. V8 is awesome.

[calebfaruki]

Documentation is still bad. Just try to understand how filtering works as a newcomer to this library. Documentation does little more than regurgitate what can be explained by a TypeScript linter. More energy should've been spent on actual use cases.

Don't believe me? Read this: https://www.reddit.com/r/reactjs/comments/v5ghuk/i_cant_understand_reacttable_v8_is_it_just_me_or/

[KevinVandy]

@calebfaruki Writing good docs takes lots of time. Yes, the docs are still lacking in a few areas (especially filtering), but they are getting better. It's taken hundreds of hours of my free time to just update the docs to where they are now over the past few months with the new guides and examples. No one else wants to spend their free time writing docs. It takes a lot of expertise with the library, and someone willing to do it. If there are more out there willing to help? I'd love it, but most usually disappear right away after expressing interest.

[calebfaruki]

What's the preferred way to submit examples to you? I implemented a simplistic radio filter that doesn't use the filterFns approach if that is at all interesting.

[PerWiklander]

As a new user with an existing table implementation i LOVE the simplicity of just adding some hooks and suddenly my own table UI has sorting, filtering and fast windowed scrolling of 10 000 rows.
👍 💯

[cadupedroni]

I find this library amazing, but depending on what you want to do.
Whether you add a new beautiful, delete, add a react-suggest component in some column, for example, the documentation although at first paracer good,and it is very confusing, you end up not understanding how it works.

And when you find an example in the codesandbox, you always say damn it was how you had to write the code, wow because the documentation is no longer simple to understand.

So I honestly think the library is amazing but the documentation needs to be simpler, because once you understand how things work they get relatively easier over time.

[eashish93]

v8 is more complicated and too much exposed than v7. Just the basic table example is too much and also I feel the naming in v7 is much better. Why like useReactTable/useVueTable etc instead of just useTable.

[tannerlinsley]

Why like useReactTable/useVueTable etc instead of just useTable

Because it supports more than one framework... 😜

[earonesty]

if you're not using typescript, for whatever reason, the documentation doesn't say how to create a table...

[KevinVandy]

Comments like this confuse me. Just ignore the Typescript syntax if you don't want to use it. You'll just won't get the great auto complete features that TS brings.

[loktar00]

Glad I saw this.. I was thinking the same thing and decided to randomly check google to see if others found this way too complex.

I'd love to use it but it's just not straight forward, the docs nor the examples are really that good at explaining what's going on.

I can get a simple table displaying easy enough but then you want to add filtering and the demo just explodes in complexity. Has a lot of fantastic features but just incredibly way too complex to implement.

[tannerlinsley]

The docs need work for sure. But the examples are not that complex. Can you be more specific?

[loktar00]

Yeah I definitely want to be constructive let me get some examples together to more appropriately show what I mean.

[Florinstruct]

I agree with the documentation being really lacking at this point. With a library this hard to use and impossible to guess, the documentation needs to be extra good. Just two things from the top of my head:

1. The examples don't show any code. I need to use the unlabeled dropdown in the top left of the pseudo-VSC, and go Editor > Toggle sidebar. Then, I need to navigate to the file currently being used. Repeat every time you navigate to another example!
2. Many (most?) people will want to use this to build a generic Table component. The opinionated types and code from the examples are no help with that. Maybe there's an example for separating data from logic / markup somewhere on this page, but I couldn't find it.

[tannerlinsley]

1. This could be better. I'll work on configuring the editor better or just getting some 'Open in..." links up.
2. Agreed. There should be an example that shows how to do this.

[christianJessMark]

I love the power of this library, but I find the documentation very frustrating to work with, lacking and mainly defaulting to examples in codesandbox.

I would like to contribute, but I feel an overarching strategy for where to take the docs is needed.

I would almost rather use a less powerful/performant library with great docs.

[tannerlinsley]

If I were to provide an overarching strategy for documentation, it would be similar to the documentation for query and router. Guide-like and building up from first principles. I will admit, doing this with a table library is much harder than it seems, given the API surface area is very large and very flat.

I do have plans whether it is myself or Kevin Vandy or perhaps a different contributor altogether to coordinate and update the documentation for table very soon

[christianJessMark]

I'm very pleased to hear that! And I realize it's an enormous task