React-table: v7 Feedback & Ideas

[Grsmto]

Hi,
First, I'm trying v7, it's awesome to work with Hooks! Trying it for the first time so my comments might be wrong.

Describe the bug
This are more of an architecture comment than a bug:
If you disable useExpanded hook, the table breaks.
I know in userland you can't disable this hook but the fact that this happens, _(edit: actually you can)_ probably demonstrates wrong app design: I figured out this is happening because you're building initial state within the useExpanded hook (row.cells = ...).

Expected behavior
I think that adding or removing hooks should not break the entire component. Hooks should be encapsulated.

Codesandbox!
https://codesandbox.io/s/nk9rmym6m4

Solution
That initial state logic could be within useTable itself (tested and works fine).
I can provide a PR if needed.

[tannerlinsley]

I totally agree. I've done my best so far to make them isolated, but there are still some artifacts like this one you discovered. I'll rework that hook to be more isolated.

[Grsmto]

Hey,
Sorry to comment here again regarding v7 architecture but I don't know if you guys have an open discussion somewhere about it so I put my thoughts here:

Hook clashes

I think it needs a pattern for hooks clashes: currently the different react-table hooks APIs are mutating the different react-table props to expose the hooks API:
ex:

• column.getSortByToggleProps()
• column.getGroupByToggleProps()
• column.sortedDesc
• row.toggleExpanded()
  etc.

This approach has different issues:

• if you let user add custom hooks, it can quickly lead to clashes between properties/functions name.
• if offers poor API discoverability. It gets hard for the user to know what prop is where. You have to read doc etc.

Proposed solution:

• prop should be namespaced. A simple solution would be to just use the hook name:
  useGroupBy hook -> row|column|header.getGroupByProps()
  This way you avoid props clashes.
  Also I think everything should be under a get...Props() function instead of directly added to the objects like column.sortedDesc (is there any downside of doing this?).

Let me know if this helps, I would be happy to provide some more contributions if you guys are actually open to discussion!

Thanks!

[tannerlinsley]

This is valuable feedback. I'll definitely take it into consideration as I'm flexing the API over the next few weeks.

[tannerlinsley]

Some notes while it's on my mind:

• I will not be possible to add core hooks to the table system. (They could clearly mutate api.hooks to add their own anyway, but the idea behind the hook system is to have a common layer that multiple hooks can plug into without adding additional API the user has to know about during rendering.
• If we're designing a system that will encourage users to request more and more hooks to be added to the core, then we're doing something wrong. Up to this point, I don't think we are, because....
• The non-hook, renderer-facing api uses very generic prop getters for different parts of the table which are likely to either not change, or will cover most use-cases.
• As for the variables that are directly available on the model (or anything expensively calculated in the table for that matter) like column.sorted or column.sortedDesc are intended. These variables are only computed optimistically and via memoization, so their performance impact is negligible.
• The reason for the internal hooks plugin architecture is because data grids actually have 2 main phases of a render:
  
  
  
  1. Setup, change detection, memoization, immutable data transformation, materialization of the final API
  
  
  2. Pre-render modifications, inversion of control to the user, pre-rendering logic, anything that requires the final API
  
  

More to come.

[Grsmto]

• I will not be possible to add core hooks to the table system. (They could clearly mutate api.hooks to add their own anyway

Why not? For example when I have been experimenting with the v7, I have been adding a useSelectRow hook to add support for select/unselect and batch actions on the table. It's been working just great!
I feel like you miss an opportunity here to provide a "plugin-ready" table where users could add their own feature via hooks.

• If we're designing a system that will encourage users to request more and more hooks to be added to the core, then we're doing something wrong. Up to this point, I don't think we are, because....

Yeah that's why a plugin system is great, if a user needs more feature, he can just add it himself without spamming the maintainers.

I think the main issue at the moment with the architecture is that the hooks are mutating the data. I think that hooks should act more like "reducers" (as in Redux reducers for example), take the data as param and return new (mutated) data.
That way you could let the users add hooks without worrying for the table to break.
That's pretty much what the hooks are doing at the moment and I'm not sure why that mutation is necessary.

[tannerlinsley]

I think I see what you're referring to now.

The first api is a reducer pattern, which is essentially what produces the final API. It's started in the useTable hook, then reduced through each plugin hook. Each plugin is responsible for returning the newly decorated or changed API as a replacement. Nothing is mutated there.

As all of the hooks are being reduced down to the final API, an internal hooks: {} object is currently used to keep track of functionality that must be deferred and applied later (after the final API has been reduced). Maybe hooks is a bad name internally, since it conflicts with the actual React hooks vocabulary. I'll try and think of a better one. Anyhow, the mutations you're referring to like api.hooks.getTableProps.push(...) could easily be avoided by creating a method like api.addHook('getTableProps', fn). Still, this technically wouldn't protect a user from mutating the hooks list though, since it is a property of the api that is being reduced. Again, we could pull that list out and only pass down the addHook function, but I feel like it's a bit overkill right now.

Under those circumstances, I think you're very correct that in addition to adding more functionality to existing hooks (like adding a prop to a header) you'll also want to be able to add new hooks (and their accompanying methods) to the system like what you mentioned: <input {...row.getSelectInputProps()} />. That way the user would have a new method to call in their markup AND other hooks could extend that api by using api.addHook('getSelectInputProps', fn).

Did I miss anything?

[janewang]

[Feature] Could we have a hook for update entire columns? Right now we are bounded to cells and rows level updates. We want to pivot the table which would make it awesome, is this possible?

[Aj1402]

[Feature] We can add support for virtualized rendering when used without pagination, this can increase performance of rendering huge tables without pagination.

[gary-menzel]

@Aj1402 RT7 is headless - the developer using the library handles the rendering. The sample @tannerlinsley provided on codesandbox (https://codesandbox.io/s/m5lxzzpz69) shows how infinite scroll can be implemented by creating a hook. Check src/components/Table.js and look for useInfiniteScroll - as well as just clicking the buttons on the demo. I don't think it is guaranteed, but that hook may be supplied as part of a set of hooks in the production release.

[jackpope]

Are there docs in the works for v7? I realize it is still in alpha release but it will help get more usage and feedback. I am trying to bring v7 into my project (for the first time, never used prior versions) and am having to jump into the source to figure out how to use the APIs. For example, I'm trying to fire a callback when filters change and see onFilteredChange referenced in the docs/issues but don't see it in the code base.

[tannerlinsley]

Docs are still in the works unfortunately.

Also, the concept for handling changes to state have changed drastically from v6's onFilterChange:

// Hoist the table state out into your own code
const state = useTableState({ pageCount: 0 });

// Grab the piece of table state you want to watch
const [{ filters }] = state;

// Use an effect that triggers when it changes
useEffect(
  () => {
    // filters changed
  },
  [filters]
);

// Pass the hoisted state to the table
useTable({
  ...
  state,
  ...
})

Essentially, you hoist the table state out into your own code which allows you to watch it for changes with useEffect probably being the easiest way to do this.

[dbertella]

What is the best way to start and play with version 7, I'm looking forward to see all the possibility this rewrite will open and I would like to start testing it and possible contributing to it. I believe the only example out there is the code sanbox linked above, correct? Right now I'm trying to make a table with a nice treeview and I'm wondering if it can be a good feature for v7 and easier to implement instead of hacking something on top of v6 (I tried to use the HoC in v6 but is not doing a great job at the moment)

[gary-menzel]

@dbertella - it will definitely be easier (in some ways) to do a Tree View in V7 but, as with all tree data, it is going to depend on how your tree is organised. I am still learning V7 myself but hope to add a tree view example. You would need to write a hook to manage the state (i.e. nodes open/closed etc.) and would possibly also need to implement other hooks to manage what "sorting" or "filtering" means against your tree data. I recommend having a look at the useExpanded hook as it is currently used to do the pivoting node management.

[gary-menzel]

For others following along here, I have recently been able to get a pure <table>, <tr>, <td> renderer going but there are a few more changes to test and PR to the core before that could be released in a codesandbox.

[dbertella]

@gary-menzel thank you for the quick answer! I really want to dig into it now even more, I just find it difficult to figure out how to start. I guess I will start from the sanbox and get a simple version running, it might be nice to have a working example inside the repository perhaps.

[gary-menzel]

That's what I have done. Created a CRA, got the files from the codesanbox, installed the V7 ReactTable and then just poked in. I have not done much with hooks but the basic concept of them is simple to understand - it is just that the hooks for RT7 do a LOT. There are also some "bugs" still to iron out. It should be possible to remove a lot of the hooks and just get a basic table (and it will be) but there are a few dependencies still lurking between the hooks.

[gary-menzel]

@dbertella as far as an example in the repo - I think that will end up staying clean and there will be Wiki entries and codesandbox samples (easier than previously because you can have teams in codesandbox and bind things to github). I am also in the process of planning a e-book that will (hopefully) cover everything.

[Jessy-BAER]

Hi,

@gary-menzel
I try to use v7 with server side data and infinite scrolling but it doesn't work even here https://codesandbox.io/s/m5lxzzpz69 :)

// When sorting, filters, pageSize, or pageIndex change, fetch new data
  useEffect(() => {
    fetchData();
  }, [sortBy, filters, pageIndex, pageSize]);

pageIndex never changes

[gary-menzel]

I'm still learning V7 myself and have not yet gotten into how best to approach server-side (or infinite scrolling). @tannerlinsley would probably be the best one to help you out with this (although we are still also deciding what out-of-the-box hooks and renderers will be provided with V7 - maybe we can get something in that just works - or we might rely on some community input once the rest of the API has settled down).

[berdyshev]

I like the new hooks approach!

I'm curious if useExpanded should be used only for aggregation/pivoting but not expand/collapse of the rows to display details of the row?

btw, it seems that the row expanding is not working in the demo https://codesandbox.io/s/m5lxzzpz69 because row.toggleExpanded is not defined.

[tannerlinsley]

useExpanded is actually extremely lightweight, so it's okay to use it for simple row expansion. Its useGrouping that is responsible for aggregation/pivoting.

Yeah, I need to update the sandbox with what's in master.

[berdyshev]

@tannerlinsley thank you for your response. Can you please tell me how to use useExpanded for simple row expansion?

[tannerlinsley]

Remember, all of this is in alpha and pretty hazy right now, but essentially, using the useExpanded hook will give you various .toggle() methods and expanded state that you can use to control a row's expanded state. You can also read from a row's expanded state through properties on the row model like isExpanded.

That should be adequate for implementing any custom UI for expanded rows you want, inside or outside of your actual table.

[berdyshev]

@tannerlinsley thank you again. When do you plan to update the npm package and the demo with the latest code?

[revskill10]

Thanks very much for a great library. v6 is awesome for what i experimented.
For V7, it uses React Hooks. And i think this is a real deal for a React Datatable!
The real deal is in the simplicity, composability of Hooks, so let's prove it, right ?

Codesandbox is great and helpful, but it's not the best way to prove the change and improvement. Let's prove it in the README. Just give all API usage in a README , nothing more.

My experience with API design in general is that: If you can't put a working example in a README file, there's something more complicated than it should be.

I tried out current codesandbox examples for V7, and my feeling is like: oh my god, is this too complicated ? Or is it over-engineering, or am i too simple ? I don't know. The example doesn't hook me. I'm not sure about it, i want it to be more simple to use.

[berdyshev]

@tannerlinsley

using the useExpanded hook will give you various .toggle() methods and expanded state that you can use to control a row's expanded state. You can also read from a row's expanded state through properties on the row model like isExpanded.

As I understand there is no API to manage the rendering of the expanded rows, right? (_maybe I can help with it in case you want it to be a part of the library?_)

I ended up with something like this:

const MyTable = ({ expandable = false, renderExpandedRow, ...props }) => {
   const instance = useTable(props, ....);
   .....

   const renderRow = (row, index, style = {}) => {
    if (!row) {
      return (
        <Row {...{ style, even: Boolean(index % 2) }}>
          <Cell>Loading more...</Cell>
        </Row>
      );
    }
    prepareRow(row);
    const rowProps = row.getRowProps({ style, even: Boolean(index % 2) });
    const renderedRow = (
      <Row
        {...rowProps}
        expanded={row.isExpanded}
        onClick={() => {
          if (expandable) {
            row.toggleExpanded();
          }
        }}
      >
        {row.cells.map(cell => (
          <Cell {...cell.getCellProps()} className={cell.column.className}>
            {cell.render("Cell")}
          </Cell>
        ))}
      </Row>
    );

    if (row.isExpanded) {
      return (
        <React.Fragment key={rowProps.key}>
          {renderedRow}
          <Row
            {...rowProps}
            className={classNames(rowProps.className, "row--expanded")}
            key={`${rowProps.key}_expanded`}
          >
            {renderExpandedRow(row.original)}
          </Row>
        </React.Fragment>
      );
    }
    return renderedRow;
  };

  return <TableView ... />;
}

[tannerlinsley]

So maybe the example isn't very clear on this, but expanded rows are not nested in the model, they are flattened into list of total rows. When you look at each row, you will see row properties that denote the depth of the row, parents, etc. This makes it 10x easier to deal with nested data and not have to write recursive renderers.

React Table strictly does not provide any markup to the user for this reason. What you have here could work great for your specific use case, but might not be what someone else needs. If we were to add it to the API, we would be 10x-ing the API by adding the needed inversion of control points that any given user would need to fully customize it.

Ultimately the v6 API is massive and extremely bloated, and yet it still doesn't support a fully customized rendering option. v7 is half the size and supports an unlimited number of rendering options. This is a perfect example of why headless UI components are so great!

[berdyshev]

So maybe the example isn't very clear on this, but expanded rows are not nested in the model, they are flattened into list of total rows. When you look at each row, you will see row properties that denote the depth of the row, parents, etc.

I'm not sure but it seems you are talking about aggregation/grouping of the rows. But I'm trying to implement something like in this example https://codesandbox.io/s/github/tannerlinsley/react-table/tree/master/archives/v6-examples/react-table-sub-components.

[tannerlinsley]

Most of what I said remains the same. The expanded state that is used for grouping/aggregation can also be used for sub components. It all depends on how you choose to render the expanded state.

[berdyshev]

@tannerlinsley would you be able to publish the new version with the latest code, please?

[guru-florida]

My feedback: We've been using v6. I just reviewed the examples of v7 and I have some limited experience with hooks. I think v7 is looking awesome but it is also a huge sea-change from v6. So much so that IMO it should be a new github project not an upgrade from 6 to 7. I am concerned how many users of ReactTable are going to be surprised when they upgrade 6 to 7 on a whim and the API is completely changed. Not 30% changed, but 100%! lol. Could you instead create another github project and then refer ReactTable users to the new project going forward in the README? Maybe "React-Tabular" or "React-Cell" or "React-xcell" haha.

I think you could then adapt current ReactTable API to use the new v7 project as a dependency and provide the user visuals on top of the hooked ReactTable but would actually have a v6 compatible API. Basically swapping out the old v6 behavior code for the hook code. Existing ReactTable users would experience only a bump in the road going to v7 but would also have a stepping stone to switching to their own visual styles using hooks. Would this be the best of both worlds?

I have my doubts people on my team are going to understand hooks anytime soon, they can barely wrap their heads around React vDOM :(. It's unfortunate, but it is the truth of most developers and companies that like to hire cheap "talent" (but they do understand v6 React-Table).

This is food for thought. I really appreciate your work into ReactTable! Both v6 and v7 are awesome!!

[tannerlinsley]

@guru-florida that's good feedback. To help with your concern, my plans for v7 are not to only release what you currently see today as the v7 headless core, but also build and release a migration-centric kitchen-sink component along side it. This component's purpose will be to almost replicate the API and experience of the v6 component, but using the new v7 core under the hood. My hope is that this will help people migrate to v7, but easily be able to break out of the "training wheels" component when they are ready.

As for your concern with hooks, I feel obligated to put in my 2 cents: Hooks are React. I wouldn't consider them an addon or alternative syntax. They are core, just like the component API. While this may be painful, it shouldn't be any different than when people were forced to learn the HOC or render-prop patterns, except for they'll be learning core React patterns and utilities that will make their react code safer, faster, easier to write/compose/extract/share, and aligned with the rest of the React ecosystem. I know this can be a hard pill to swallow for companies or larger orgs with many employees, but trust me, your future selves will applaud you for learning and writing new code in React hooks ASAP.

Thanks for your feedback! Keep it coming!

[guru-florida]

@tannerlinsley Thanks. I wasn't aware of your migration plan and it's essentially the same thing so glad to hear.

I agree 100% with your second paragraph too but it's easier said than done in my case. I don't have control over who is hired so I have to deal with the hand I've been given. TL;DR version they just aren't that interested in learning it. Old habits. What can ya do right? ....just move on....so in 3 more days I move on to another company. for reals. haha :)

I already use HOC and hooks, etc so I loved the new v7 design immediately and would migrate to it now but no time with me gone in 3 days. I am sure I'll be using it on the next project though.

[AskAlexSharov]

Feedback:

• defaultState is not exported. Don't know how to define default state for own plugins.
• in column.Filter func, next method header.setFilter accepting arguments flipped way
• in column.Filter func, next field header.filterValue always empty

[Ciantic]

Have you considered TypeScript?

Having third party type definitions for a very important component like tables (data grids) can be a bit unnerving.

With official type definitions when user of the react-table updates the library, the user can be somewhat certain the update does not break the behavior since it type checks.

[tannerlinsley]

@Ciantic Yes, I have. A few things hold me back on that though:

• I simply am not good enough with TS yet to be productive compared to my current status quo.
• Using TS would severely limit the amount of people that would be able to contribute to the project, at least until TS gains the majority share of the JS ecosystem.

I have no qualms with moving to TS when the time is right, but in the meantime I will encourage integration tests for stability in its stead.

[tannerlinsley]

@AskAlexSharov, would you like to submit a PR to improve those experiences?

[dmitriigaidarji]

@tannerlinsley I am trying to sort desc on first user click. In v7 passing defaultSortDesc=true as a prop to the Table or Column only allows to flip between 'sort desc' and 'sort unset' states, which makes it impossible to sort ascending.

Is this a bug or am I misusing the property?

[tannerlinsley]

Sounds like a bug.

Tanner Linsley
On May 14, 2019, 6:11 AM -0600, Dmitrii Gaidarji [e-mail], wrote:

@tannerlinsley I am trying to sort desc on first user click. In v7 passing defaultSortDesc=true as a prop to the Table or Column only allows to flip between 'sort desc' and 'sort unset' states, which makes it impossible to sort ascending.
Is this a bug or am I misusing the prop property?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[dmitriigaidarji]

@tannerlinsley thanks for the quick response! I've fixed it for myself and shared the code for you #1341

[strass]

When do you think we will see docs for v7? I'd like to use it but it's a little overwhelming without any help or typescript bindings.

[tannerlinsley]

I'm writing the docs right now as I'm upgrading Nozzle from v6 to v7 in our next big release. Once we launch our next version of Nozzle, I'll consider its use-cases complete enough and the API design sufficient to finish the docs. Plan on a month.

[rssluca]

@tannerlinsley would you be able to publish the new version with the latest code, please?

Been digging into v7 code for a bit, keen to properly understand how to use the depth/path properties manually to aggregate rows into expandable sections. Would also like to display the parent row when group is collapsed. I saw groupByFn and aggregations properties in useGroupBy but not sure yet if they are related..

[eladbs]

@tannerlinsley
First, thanks again!
When copy&pasting table data to another place (word, excel, etc..) it is missing tabulation (table structure).
Will it be possible to add support for it in v7?
Is it even possible technically with css flex?!
Thanks!

[gary-menzel]

@eladbs The CSS Flex implementation will not work (with any page using it - not just only react-table) as the Office tools are looking for <table>, <td>, etc. That being said, RT7 allows you to create your own rendering - it's headless, rendering is done by the developer and there will be extra examples along with both the flex/div layout and one using table but anything is possible.

So, if you want people to be able to mark the page and copy into Word/Excel, then you can provide a renderer based on the traditional <table> tags.

[eladbs]

@gary-menzel Thanks for your reply!
You mean that I can render each component in the table with the appropriate table/td/tr/etc. to support that capability?

Somehow, I hoped that there will be built in support. I know it's hard or even impossible.

[gary-menzel]

@eladbs Rendering is completely isolated from the table engine itself (which is all based on hooks).

So, while RT7 will have some basic renderers in the box, the developer is ultimately able to decide how to render the table. RT7 essentially manages the composition of the data so that it fits the desired "shape" (i.e. the columns - and the page of rows).

It's not hard or impossible - it's just not really a design goal of RT7 to be opinionated about how to render tabular data. The big challenges with previous versions of ReactTable were that everyone wanted different outcomes from the rendering. So, RT7 provides that.

[eladbs]

@gary-menzel Cool. Thanks!
I'll take a look at RT7 and will try to accomplish that.

[ryanking1809]

I'm loving this headless architecture! Just a note, the codesandbox provided in the docs is a little buggy as it's not using the latest release, but I've managed to fix all the issues I was having by switching to the npm package.
Where can I find the latest code for future debugging? I seem to only be able to find alpha 2.

[Grsmto]

@ryanking1809 there is alpha 6 released on Npm https://www.npmjs.com/package/react-table.
Would be nice if you could provide that code sandbox link here maybe so other people can use it to debug etc.!

[ryanking1809]

Oh yes it can be found here https://codesandbox.io/embed/react-table-v7-sandbox-cr3eh
Just note the source in the react-table folder table needs to be upgraded for a more accurate reference. Where can I find the latest source in this repo?

[ggascoigne]

Just chiming in to say that I've spent a little while working with the V7 alpha-5, and have really come to appreciate the new approach. Very well thought out, and so much easier to extend (I wrote a basic useSelection hook to enable row selection) than in V6. I also love that I have complete control over the presentation. Thank you, this is fantastic, and to be honest, extremely usable even in its alpha form.

[Grsmto]

The latest source are on master on this repo yes afaik.

[Grsmto]

@ggascoigne interesting, I've built my own useSelection as well! I suppose it could be included in the library if already 2 people had to build it themselves.

[ryanking1809]

+1 for for row / cell selection!

[ryanking1809]

There's a bit of a bug when using pagination and grouping. The children of the grouped rows are filtered out due to the page limit. So if you expand the last row all the children will be displayed on the next page. I'm not sure on the best solution, perhaps applying pagination only to top-level rows would work.

[Grsmto]

@ryanking1809 that's funny but I did a PR to fix exactly this last week. It's actually not a bug but a feature haha.
cc @tannerlinsley
Check my PR for more details https://github.com/tannerlinsley/react-table/pull/1372

[ggascoigne]

@Grsmto I suspect that a standard useSelection might be a good idea. Since mine lives outside of the library it's a bit tied to its presentation since it injects a checkbox column, but I'd be happy to help work towards a more shareable version.

[Grsmto]

@ggascoigne ok, mine is only doing pure business logic, no UI. I'll setup a code sandbox and maybe open a PR then.

[ryanking1809]

@Grsmto oh perfect!

[brycejacobs]

Hey guys, really enjoying this hook rewrite. I'm going crazy with writing these plugins given how easy! Why not write a web socket pub / sub as a plugin for each row?????? (JK...jk)

Do you guys have any recommendations as far as the presentation layer? I know there's a clean line of demarcation when the plugin system was written, as to separate business logic from presentation...however there seems to be some crossover in situations that would need to modify both. How are you all recommending handling the cases that can't be separated cleanly?

Are you all making a base component such as in the Examples and passing props that trigger presentation changes that way? Or are you doing presentation changes in the hooks just not for the ones officially accepted under this project?

Also, has anyone tried to mix this up with render prop loaders and gauged performance?

Thanks again for the library, great experience so far and it's still alpha versioning!

[Grsmto]

As promised for whom is interested, you can find my useSelectRow hook and a working example with CodeSandbox in #1377

@brycejacobs I have been avoiding any presentation things in the hooks. I tried to make it "logic only" or at least versatile so it can work with a large number of UI cases. See the PR I did, that's what I'm using in production on a project and the hook is agnostic of the UI afaik.

[lishine]

As promised for whom is interested, you can find my useSelectRow hook and a working example with CodeSandbox in #1377

@brycejacobs I have been avoiding any presentation things in the hooks. I tried to make it "logic only" or at least versatile so it can work with a large number of UI cases. See the PR I did, that's what I'm using in production on a project and the hook is agnostic of the UI afaik.

I tried it now and,
The shortcoming currently is that the component above component with useTable does not have access to rows, where the selection data is stored.
For example filter and sort info is stored in state and the useTableState can be placed in the component above like in the server example. But useRows is not planned to be put in the component above.

[lishine]

Another thing is the onRowClick (it can also make it's way to this lib)
I pass the click with onRowClick to the component above.
But the click on the checkbox gets registered as well, need to be excluded, this is what I will add to my code now.

            <Row
                onClick={() => onRowClick({ index })}
                {...row.getRowProps({ style, even: index % 2, selected: row.isSelected })}
            >

[thecodejack]

It's been a while I have been using React Table v6 in my applications. But suddenly today when I visited thinking how can I use React table in right way for functional components, I see this(v7). Looks v7 in great shape. Just wanted to know when can this will done with full release from Alpha? Any ETA of same?

[etaiklein]

It would love web accessibility to be a first class concern for v7.

Here's some ideas about where to start

• Use semantic html elements in the sandbox (currently every element is a div)
• Create hooks that implement the ARIA grid role and ARIA treegrid role
• Associate the Data Cells with the Appropriate Headers using scope="row" and scope="col" attributes where appropriate

You can read more about table accessibility at:
https://webaim.org/techniques/tables/data
https://www.w3.org/WAI/tutorials/tables/
https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced

This will not just help people who rely on assistive technology to navigate the web, but also it allows power users to navigate tables to their preference. It also looks really good for the library and inspires confidence!

[tannerlinsley]

PR’s are always welcomed! ;)
On Jul 11, 2019, 10:06 AM -0600, Tai Klein [e-mail], wrote:

It would love web accessibility to be a first class concern for v7.
Here's some ideas about where to start

• Use semantic html elements in the sandbox (currently every element is a div)
• Create hooks that implement the ARIA grid role and ARIA treegrid role
• Associate the Data Cells with the Appropriate Headers using scope="row" and scope="col" attributes where appropriate

You can read more about table accessibility at:
https://webaim.org/techniques/tables/data
https://www.w3.org/WAI/tutorials/tables/
https://developer.mozilla.org/en-US/docs/Learn/HTML/Tables/Advanced
This will not just help people who rely on assistive technology to navigate the web, but also it allows power users to navigate tables to their preference. It also looks really good for the library and inspires confidence!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[matthewoates]

It would be great if onFetchData supported promises. That way we wouldn't need to explicitly handle the loading state and the error state ourselves.

[tannerlinsley]

onFetchData is deprecated and also unnecessary in v7. Take a peek at the sandbox for server side data or stay tuned for a more specific example.
On Jul 15, 2019, 6:49 PM -0600, Matt [e-mail], wrote:

It would be great if onFetchData supported promises. That way we wouldn't need to explicitly handle the loading state and the error state ourselves.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[powah]

Any guidelines how to implement server-side + infinite scrolling (sandbox example for this case is not working)? I think any documentation for v7 would be beneficial for the project (more potential contributions). It's hard to grasp lib concepts (how hooks are composed, etc.) only by looking at the code. Any ETA for the initial docs?

[tannerlinsley]

I'm writing the documentation right now. It's a big undertaking so be patient. It's gonna be great.
On Jul 17, 2019, 6:21 AM -0600, Aurimas [e-mail], wrote:

Any guidelines how to implement server-side + infinite scrolling (sandbox example for this case is not working)? I think any documentation for v7 would be beneficial for the project (more potential contributions). It's hard to grasp lib concepts (how hooks are composed, etc.) only by looking at the code. Any ETA for the initial docs?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[lpoulter]

Are the HOC's for v6 compatible with v7? I'd like to make a row selectable with SelectTable

[tannerlinsley]

The v6 HOCs are not compatible with this rewrite. V7 is essentially a brand new library with a very different architecture and concept
On Jul 18, 2019, 6:42 AM -0600, Laurie Poulter [e-mail], wrote:

Are the HOC's for version 6 compatible with v7? I'd like to make a row selectable with SelectTable
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[codepunkt]

Is there an easy way to provide a fuzzy-based filter for either all or a pre-defined subset of columns?

the goal is to have a single filter input, where the user can type in his filter string and based on that input only the rows are shown where the filtered string (fuzzy) matches the contents of the pre-defined (or all) rows.

The current way of defining filters on each column and basically combining them with a boolean __AND__ doesn't seem to do the trick - but maybe i'm missing something.

[powah]

@codepunkt sound like it should be OR not AND

[powah]

I think the only way to implement this currently is filter data in the parent component before giving it to react-table.

[ggascoigne]

Another option would be to create your own useFilter based upon the one in this repo and implement your own logic. Then use this new useFilter instead of the one in the main library.

[nmccready]

v7 is a great direction! It would be nice if useSortBy exported useMain as I truly only need sorting and little to none of the useTable. Not sure if this could be made more bare bones for sorting and maybe made it's own dedicated library or contributed to react-use.

My use case is in that the hook cares more about how to sort the data and less about Headers and Columns (already handled from the outside). Thoughts..?

[tannerlinsley]

@nmccready That's an interesting idea, however even the main hook in useSortBy itself is still based on the assumption that it's operating within React Table and its API. I think it would be very non-trivial to extract it's usefulness for usage outside of this context.

[nmccready]

I think it would be very non-trivial to extract it's usefulness for usage outside of this context.

You're right this is going pretty smoothly. I'll post back when I have a more polished solution.

[nmccready]

@tannerlinsley I noticed in the latest release alpha.16 the src/ is no longer published. This makes it very hard to consume this library in pieces without it. Also in in alpha.7 lib/ files did not match the source files for the ES5 compiled binaries.

[tannerlinsley]

In the latest alpha, you'll find I've readded src/**/*.js to the files list. If we end up needing lib/**/*.js files, I can also add those, but as of alpha.15, there shouldn't be any more files from v6 in the npm package.

[nmccready]

@tannerlinsley I ported the useSortBy hook here . I'm sure this could be extended / wrapped to fit your needs.

If you want me to PR something back to here I'd be happy to. It is working great thanks!

[powah]

@tannerlinsley can you please provide working server side example, let's say with pagination when useTableState is used in a parent component? I can't figure out why I get infinite rerendering.. after debugging it seems the cause is table state which I pass to child component responsible for the rendering. Somewhere ref equality is lost. Probably problem with the usage so working example would be a huge help. And thanks for your hard work!

[tannerlinsley]

@powah, Sure thing. Serverside examples are in the pipeline. I'm trying to get all of the client side examples and some snapshot tests of them done before moving on to server-side stuff. Hang tight!

[dmr]

This post has been open for a while. What can I do to get V7 released?

[tannerlinsley]

You can try the alpha, report missing use cases, write unit tests, or find bugs!
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech [e-mail], wrote:

This post has been open for a while. What can I do to get V7 released?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

[nmccready]

This post has been open for a while. What can I do to get V7 released?

❯ yarn info react-table
yarn info v1.16.0
{ name: 'react-table',
  description: 'A fast, lightweight, opinionated table and datagrid built on React',
  'dist-tags':
   { latest: '6.10.0',
     next: '7.0.0-alpha.18' },
  versions:
   [ '0.0.5',
     '1.0.0',
     '1.1.0',
     '1.2.0',
....
     '6.10.0': '2019-04-23T23:02:00.560Z',
     '7.0.0-alpha.3': '2019-05-21T20:38:44.827Z',
     '7.0.0-alpha.4': '2019-06-11T17:40:59.369Z',
     '7.0.0-alpha.5': '2019-06-11T17:41:34.599Z',
     '7.0.0-alpha.6': '2019-06-20T21:23:59.551Z',
     '7.0.0-alpha.7': '2019-07-15T17:29:46.048Z',
     '7.0.0-alpha.8': '2019-07-25T19:39:33.379Z',
     '7.0.0-alpha.9': '2019-07-26T16:32:33.216Z',
     '7.0.0-alpha.10': '2019-07-26T16:53:14.524Z',
     '7.0.0-alpha.11': '2019-07-26T17:11:31.925Z',
     '7.0.0-alpha.12': '2019-07-26T17:23:00.224Z',
     '7.0.0-alpha.13': '2019-07-30T16:23:37.539Z',
     '7.0.0-alpha.14': '2019-07-30T17:44:17.674Z',
     '7.0.0-alpha.15': '2019-07-30T20:10:16.559Z',
     '7.0.0-alpha.16': '2019-07-30T23:01:56.484Z',
     '7.0.0-alpha.17': '2019-07-31T18:27:54.731Z',
     '7.0.0-alpha.18': '2019-08-03T20:37:35.260Z' },

[tannerlinsley]

Also, if you find that you don't have time to help out on the project, or that you're simply just waiting for the next version to hit, you or the company you work for could always become a patreon supporter of the project. I have tiers from as low as $1 up to $500 / mo. Also to be noted, all patrons on any $100+ /mo plans get their logo in this project's readme with a link to wherever they want. The repo receives about 35k unique visitors every month.

[dmr]

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech @.*>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for your responses and thank you for investing time and effort into improving this!
I was looking into the alpha and I like it so far but I'll have to find more time to test it with more complicated use cases.

[tannerlinsley]

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech _@_.*>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Thank you for your responses and thank you for investing time and effort into improving this!
I was looking into the alpha and I like it so far but I'll have to find more time to test it with more complicated use cases.

My pleasure. Thanks for your support.

[tilanka]

You can try the alpha, report missing use cases, write unit tests, or find bugs!
…
On Aug 5, 2019, 2:05 AM -0600, Daniel Rech @.*>, wrote: This post has been open for a while. What can I do to get V7 released? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

Have been using this recently and thanks for all the effort you've put into this. One use case that I think is useful is a control that gives the user the ability to toggle columns off/on. This is especially useful on mobiles and smaller screens. This could be achieved via a plugin hook in the new architecture.

Was wondering if there is already anything in the pipeline like this?

[gary-menzel]

@tilanka The previous version (V6) did have the ability hide/show columns - assuming your column definitions were reactive or in your state management (so any change to the column definitions would cause a refresh). This is no different in V7 (although, hooks likely make the reactivity a little simpler).

Each column has a property on it that allows it to be shown or hidden (show: Boolean | Function). It is up to the developer to implement the UI for accomplishing changing/setting this (as each use case as to how best to do it needs to fit in with the design of the UI). react-table V7 is "headless" - meaning it actually doesn't product any markup - that is the developers responsibility.

I have you haven't yet done so, a read of the README on the code page will make this a little clearer as well as having a look at the V7 sandbox code examples. Although, there is probably no specific example of doing this at present.

[nouman91]

Can I use version 7 for production application?
Thank you for this awesome library. I loved the concept you can easily integrate it into any ui library. I am thinking to use this in production application. We have 4 to 5 core pages and each page has data grid. I am thinking to use this to solve all the client requirements. I see v7 is in active development. Is v7 stable?

[nouman91]

Can I use version 7 for production application?
Thank you for this awesome library. I loved the concept you can easily integrate it into any ui library. I am thinking to use this in production application. We have 4 to 5 core pages and each page has data grid. I am thinking to use this to solve all the client requirements. I see v7 is in active development. Is v7 stable?

@tannerlinsley I know you must be busy brother but would appreciate a reply. I am in a bit of hurry, my team did not do a good enough job with data tables, and I have to improve them in this sprint.

[jackpope]

@nouman91 Works great in production for me just make sure to lock your version as the alpha patch changes can be breaking.

[nouman91]

Thank you for your response @jackpope . But I see it is not stable. I used pagination with sorting, it is not working with it. Somehow it gets stuck into infinite render loop. I guess I have to create data table from scratch.

[powah]

Looks like it's not possible to use _useRowSelect_ together with server side (manual) pagination because data in that case is only the current page and you get same row indexes (paths) for all pages so if you go to the next page - same row indices are incorrectly preselected.

[tannerlinsley]

Looks like it's not possible to use _useRowSelect_ together with server side (manual) pagination because data in that case is only the current page and you get same row indexes (paths) for all pages so if you go to the next page - same row indices are incorrectly preselected.

Looks like we need a manual row index override for rows. This way you can provide the true row indices from the server, instead of relying on the manufactured ones. Thoughts? Also, please open a new issue to discuss this.

[tannerlinsley]

Closing this issue now, as it's getting pretty long and probably pinging a lot of people. If you have more feedback or questions, please file individual issues for them from here on out.

Thank you everyone!