React Table v6 unable to get data since 6.11.2 update

[prathmeshphuke]

Uncaught (in promise) TypeError: Cannot read property 'forEach' of undefined.

React table unable to get the data since last update & throwing above error.

Issue since: Version 6.11.2

Not reproducible till Version 6.10.3

[BarishSarac]

I have the same issue. Yesterday I was getting some .length error, today I am getting forEach error..

[rlueder]

Error below for reference method.js line 168.

var hasHeaderGroups = false;
columns.forEach(function (column) {
    if (column.columns) {
        hasHeaderGroups = true;
    }
});

version 6.10.3 works as expected.

@deklanw @De-Santa I noticed you both have forks with fixes for react-table just wondering what the history is behind the fix? It seems related to what we're seeing with two latest versions (6.11.2 and 6.11.3). Thanks!

[TimMouskhelichvili]

I have the same issue.

[keegandonley]

I've had to pin to 6.10.2 in order to restore functionality

[tannerlinsley]

The default installation for react-table is now version 7-beta. You'll need to lock into a v6 version from here on out to keep using it as you are.

[adambowles]

Big disagree that you'd leave people on the last major semver with a broken deploy. What about newcomers that don't want to install a beta right away? They'll get 6.11.2 and it won't work.

[tannerlinsley]

Yeah, I agree it's not perfect. Unfortunately there was an accidental deploy with the beta to the @latest tag from some automated releases CI stuff I was working on so now we can't go back. We ran into some issues with version 6.11.1, and so to alleviate the situation, we decided to revert and rerelease the last known stable release from 6.10.x as 6.11.2.

It's mucky and bad I know, but it's the way forward for now. I'm possibly only days away from removing the "beta" label, so I'm trying not to beat myself up about it.

[tannerlinsley]

With that said, 6.11.2 should be working just fine. I'll go and double check the examples to make sure we didn't miss something.

[De-Santa]

Error below for reference method.js line 168.

var hasHeaderGroups = false;
columns.forEach(function (column) {
    if (column.columns) {
        hasHeaderGroups = true;
    }
});

version 6.10.3 works as expected.

@deklanw @De-Santa I noticed you both have forks with fixes for react-table just wondering what the history is behind the fix? It seems related to what we're seeing with two latest versions (6.11.2 and 6.11.3). Thanks!

@rlueder My fork includes only deprecated react lifecycle warnings fix. And I`m using v6.8.6 in my project due to issues in later versions

[pallymore]

sorry folks, it was me (again). temporary fix here: https://github.com/tannerlinsley/react-table/pull/1699 😞

[BarishSarac]

Latest version still have an error for me. 6.10.3 works fine when I update to 6.11.2 I get this error. TypeError: Cannot read property 'forEach' of undefined

@tannerlinsley marking v7 without proper testing will only cause you more headache and people considering to drop using this react-table. Stuff happens so it's okay @pallymore, but I hope you guys test and release v7 as stable. Performing well v7 will be a great remedy as well as quick fix that will make many people happy.

[pallymore]

@FlyRocketDrones the changes have been merged but I don't think it has been released to npm yet.

for now let's stay on 6.10.3

I haven't looked at v7 code yet but I hope there will be unit tests 😅

[tannerlinsley]

V7 will definitely have a better training story around them. It already has snapshot tests for all of the basic features and plugins. After we get to RC, we’ll convert those to real UI tests using RTL.

I’ll get a release out later today. I’m currently on the go.

Tanner Linsley On Dec 4, 2019, 10:06 AM -0500, Yurui Zhang notifications@github.com, wrote:

@FlyRocketDrones the changes have been merged but I don't think it has been released to npm yet. for now let's stay on 6.10.3 I haven't looked at v7 code yet but I hope there will be unit tests 😅 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.

[LudovicF42]

Same issue on 6.11.1 and 6.11.2

[joshsylvester]

Yeah, I agree it's not perfect. Unfortunately there was an accidental deploy with the beta to the @latest tag from some automated releases CI stuff I was working on so now we can't go back. We ran into some issues with version 6.11.1, and so to alleviate the situation, we decided to revert and rerelease the last known stable release from 6.10.x as 6.11.2.

It's mucky and bad I know, but it's the way forward for now. I'm possibly only days away from removing the "beta" label, so I'm trying not to beat myself up about it.

I'm not sure what is happening here - but 6.11.2 is still broken, so the "re-release" might not have worked the way you had hoped. Would it be possible to look into why 6.11.2 is still broken?

As far as only focusing on v7 and not fixing what's currently out there @latest you're assuming that every user who uses react-table will be able and willing to either use a -beta version, and / or upgrade their code to v7 right away when it is released. If you're following semver going to 7.0.0 would be for a "breaking change" - and not something that people who use your product can take lightly.

In a production environment blindly updating to a new release or beta version is not a viable option when daily builds are already failing. If and when we'd be willing to upgrade to a beta version, it would be a lengthy task to upgrade and re-validate all functionality - which doesn't fix the error that you are forcing on to your end user by not fixing the problem that you introduced. Rolling back to 6.10.2 may work as a stopgap, but only if you're only using react-table and not any other packages that also reference react-table@^6.x.x.

It's disheartening to hear that this team seems unwilling to fix their own mistake.

[tannerlinsley]

I'm not sure what is happening here - but 6.11.2 is still broken, so the "re-release" might not have worked the way you had hoped. Would it be possible to look into why 6.11.2 is still broken?

I'm issuing a fix for it today.

As far as only focusing on v7 and not fixing what's currently out there @latest you're assuming that every user who uses react-table will be able and willing to either use a -beta version, and / or upgrade their code to v7 right away when it is released. If you're following semver going to 7.0.0 would be for a "breaking change" - and not something that people who use your product can take lightly.

Yes, @latest is currently the beta, which for newcomers to React Table is stable enough to learn, use, and invest their time. For those who not greenfield, v6 is still available and aside from a few regressions in recent PR's, is still great and following semver in a safe manner.

React Table v7 should be out of beta very very soon and yes, it is indeed a breaking change at the very least. I don't expect people to take it lightly if they're using v6, but I've offered ample instruction and roadmap around a year now since I started v7 to avoid issues and heartbreak. I've continued to let people contribute to v6 and keep it around for as long as possible, but some of those commits involved retrofitting v6 to work with newer versions of react. Because of this mixture, I've had to roll back a few things (long-term support is messy in general, especially when people using the latest version of React or Preact want to use libraries that are still using "deprecated" lifecycle methods). In the end, there is still nothing stopping anyone from locking into a specific patch version or even forking the library and maintaining long-term support themselves.

In a production environment blindly updating to a new release or beta version is not a viable option when daily builds are already failing. If and when we'd be willing to upgrade to a beta version, it would be a lengthy task to upgrade and re-validate all functionality

No-one using v6 is being forced to upgrade to v7.

Which doesn't fix the error that you are forcing on to your end user by not fixing the problem that you introduced.

A regression in a patch version is not forceful, but I realize many people do not lock their dependencies down to the patch level. Ultimately I am responsible for these regression, regardless of who PR's or commits them. Thus, I'm currently working on a fix for this issue.

Rolling back to 6.10.2 may work as a stopgap, but only if you're only using react-table and not any other packages that also reference react-table@^6.x.x.

The fix will be a 6.11.x version so this shouldn't be a problem.

It's disheartening to hear that this team seems unwilling to fix their own mistake.

I don't believe I've ever refused to fix a regression bug of this nature. I simply stated that I don't plan on offering extended long-term support for v6. If bugs are unintentionally introduced in v6 during the communities efforts to extend its life, then I'm happy to step in (like I am doing now) and do my best to either revert (which I already tried earlier this week) or intervene (doing right now).

Again, sorry for the delay in getting this fixed (I have a startup that will always take priority over my free-to-use open source libraries 😉), and thanks for your patience.

[tannerlinsley]

Please upgrade to 6.11.4 to confirm the issue is fixed or not.

[pallymore]

thanks @tannerlinsley

Just upgraded to 6.11.4 - I haven't noticed any issues in my use-cases: sorting, filtering, re-sizing, changing pages, changing page sizes. if anyone else is still having issues it'd be great if you could provide some guidance on how to reproduce them.

[tannerlinsley]

1/2 👍

[tannerlinsley]

One more to go... 👀 Don't be shy!

[joshsylvester]

Thanks @tannerlinsley, for the response and the new build. My apologies if I misconstrued earlier responses to suggest that this might not be fixed - I was merely re-requesting that it be fixed for reasons that had not been brought up earlier in the discussion.

Thank you for taking the time to address the issue.

(still testing, waiting on our build server)

[tannerlinsley]

Closing this as it appears to be fixed from a few more offline messages I received. Comment for reopen if this is not the case in your scenario. Thanks!

[rlueder]

Issue is closed but just wanted to confirm 6.11.4 fixed it for me. Thanks!

[kumarabhirup]

I see this error in v7 too. I need to use useGlobalFilter, so downgrading isn't an option for me. Any suggestions?

[MatheusKemer]

I see this error in v7 too. I need to use useGlobalFilter, so downgrading isn't an option for me. Any suggestions?

Did you find any solution for this error @KumarAbhirup?

[adventurini]

Also getting this error following the docs and the latest release. I am using NextJS.

[adventurini]

Also getting this error following the docs and the latest release. I am using NextJS.

Just in case any finds this... Cannot rename the data variable in the useTable hook. I was using it directly in a component with Apollo, which also uses data. Just create a new table component.

[tyteen4a03]

@tannerlinsley I'm not seeing 6.11.4 or 6.11.5 on react-table-6.

[mromanelli9]

Same problem with versions 7.5.0, 7.4.0 and 7.3.0. @adventurini solution worked, thanks.

[danieltodonnell]

@tannerlinsley This should either be re-opened or a new issue to cover it. If the variable passed in has the a different name it breaks the code in the same way.

Example:

  function Table() {
    const columns = React.useMemo(
      () => [
        {
          Header: "Column 1",
          accessor: "col1", // accessor is the "key" in the data
        },
        {
          Header: "Column 2",
          accessor: "col2",
        },
      ],
      []
    );

    const data2 = React.useMemo(
      () => [
        {
          col1: "Hello",
          col2: "World",
        },
        {
          col1: "react-table",
          col2: "rocks",
        },
        {
          col1: "whatever",
          col2: "you want",
        },
      ],
      []
    );

    // Use the state and functions returned from useTable to build your UI
    const {
      getTableProps,
      getTableBodyProps,
      headerGroups,
      rows,
      prepareRow,
    } = useTable({
      columns,
      data2 // LIBRARY BUG : MUST be named 'data'
    });

Results in :

[pallymore]

@danieltodonnell this PR was for v6 - I don't think any of the changes here made into v7 🤔

[danieltodonnell]

@pallymore - The bug still exists though, I'll make a new issue for it

[jsefiani]

@danieltodonnell Can you share the link please?

[sven09]

@jsefiani @danieltodonnell

please use as follows (It's not a bug):

      getTableProps,
      getTableBodyProps,
      headerGroups,
      rows,
      prepareRow,
    } = useTable({
      columns,
      data: data2 // MUST be named 'data' `<<<<`
    });

If pass in a json object you have to provide the required name "data" in case your data2 is not named "data".

[rjitsu]

I've got the same issue, and it happened randomly, as it was working before. Thought I did something in code, but that wasnt the case. tried downgrading. didnt work

[Mdakhib]

I've got the same issue, and it happened randomly, as it was working before. Thought I did something in code, but that wasnt the case. tried downgrading. didnt work

Did you got solution? I'm facing this issue in v7.7.0

[enyelsequeira]

I think this should be re-open, I am getting the same issue in version v7.7.0

[tannerlinsley]

Open a new issue with a codesandbox and we'll take a look :)