Err: "Maximum update depth exceeded" with version 7.1.0

[keebeegee]

Describe the bug (required)
"Maximum update depth exceeded. This can happen when a component repeatedly calls setState inside componentWillUpdate or componentDidUpdate. React limits the number of nested updates to prevent infinite loops." when building table

Provide an example via Codesandbox! (required)
https://codesandbox.io/s/busy-merkle-58ii6?file=/src/react-table-component.js

Steps To Reproduce (required)
Run code

• OS: Win/Ubuntu
• Browser Chrome, FF
• Version 7.1.0

[devrsw]

I'm also experiencing this with 7.1.0.

[etodanik]

Same here. Seems to be happening on all the 7.x versions.

[Andreeh]

Don't forget to either wrap columns inside useMemo or define columns outside the component.

This means that every option you pass to useTable should be memoized either via React.useMemo (for objects) or React.useCallback (for functions).

See Option Memoization for more info.

[DrSecant]

I seem to be having an issue similar to this, though the error only occurs when a state change happens in a parent component. I have a setup like this:

class TopLevelComponent extends React.Component {
    ...
    makeChange(newValue) {
        this.setState({ value: newValue });
    }

    render() {
        return (<Child makeChange={makeChange} ... />)
    }
}

class Child extends React.Component {
    ...
    render() {
        return (<Grandchild makeChange={this.props.makeChange} ... />)
    }
}

function Grandchild({ ..., makeChange }) {
    ...
    return (
        <table ...>
            <thead ...>...</thead>
            <tbody ...>
                {rows.map(
                    return (<tr ... onClick={() => makeChange(row.values)}>...</tr>
                )}
            </tbody>
        </table>
    );
}

I know this is very simplified and I am not certain that this will help without the context of the code segments I have omitted, but the files are relatively complex and I wasn't sure how else to go about simplifying it. Basically, the onClick (and, more specifically, the subsequent call to setState) triggers this "Maximum update depth exceeded" error. I should note that the setState does not affect any of the props supplied to the Child or Grandchild components. And this behavior only occurs with newer versions. Before, I found that installing react-table version 7.0.0-rc.16 alleviated the problem, but now that I have found a bug with table expansion in IE (which appeared to be fixed in newer versions), this solution is no longer acceptable.

Any assistance would be appreciated and I can provide more details if necessary; I'm sort of reaching the end of my rope here.

[shennan]

For me, I had forgotten to include an empty array argument (or a dependency array) in the useMemo call. Without this, useMemo is seemingly useless.

See the documentation:

If no array is provided, a new value will be computed on every render.

[DrSecant]

I can't believe I missed that! That was also my problem. Many thanks

[SteinGabriel]

Thanks @shennan, that was the issue for me as well.

[etodanik]

@Andreeh for me memoizing everything didn't fix the issue. I still keep running into this issue as soon as state changes.

Of course, if I set a [] memo dependency array it would work , but then I can't change the state at all.

The moment I change state in the parent, it all breaks down.

[etodanik]

Alright.. so in my case I had a custom hook function that I forgot to add useCallback to. Works now.

[andrickd]

In any 7.x version I see this error when using the useSortBy & usePagination hooks unless I set the following properties to false:
autoResetSortBy: false, autoResetPage: false

None of the advice in this thread resolves it - my columns and data are already properly memoized, my component renders twice if the state of the above two properties equals false, otherwise it will render over 50 times until the referenced maximum depth error occurs... this line of code appears to be where it begins: https://github.com/tannerlinsley/react-table/blob/0bcf87a216eab7b5994c99972da19de6822d5d0e/src/publicUtils.js#L148

My data does not change following the initial render so these two properties are relatively meaningless for me so I can use the above workaround, but it seems that somehow the useTable hook is causing my component to re-render when it likely should not. I've spent over a day going over my code and checking it against examples here and as best I can determine I'm not doing anything prohibited.

[lamualfa]

You must wrap your columns and data inside useMemo or useCallback. I fixed your sandbox. Please close this issue. See my forked:

https://codesandbox.io/s/elastic-blackburn-wm864

[MaximBG]

You must wrap your columns and data inside useMemo or useCallback.

In my application data is dynamic and changes over time and in some places even column headers do. Is there a solution for my case?

[tannerlinsley]

It's okay if your columns and data change over time, as long as their references are not changing every render. useMemo with the proper dependencies and you'll be fine

[chinanderm]

It's okay if your columns and data change over time, as long as their references are not changing every render. useMemo with the proper dependencies and you'll be fine

It isn't that simple, it seems. What @andrickd mentioned about having to disable library functionality in order for a bug to not occur can't simply be ignored here. Their suggestions allow the many re-renders to not occur but remove needed functionality.

[dwome]

With an empty dependency array the logic for pagination cannot work properly. Is there any workaround to get the row selection working with real dependencies?

[inimist]

In any 7.x version I see this error when using the useSortBy & usePagination hooks unless I set the following properties to false: autoResetSortBy: false, autoResetPage: false

None of the advice in this thread resolves it - my columns and data are already properly memoized, my component renders twice if the state of the above two properties equals false, otherwise it will render over 50 times until the referenced maximum depth error occurs... this line of code appears to be where it begins:

https://github.com/tannerlinsley/react-table/blob/0bcf87a216eab7b5994c99972da19de6822d5d0e/src/publicUtils.js#L148

My data does not change following the initial render so these two properties are relatively meaningless for me so I can use the above workaround, but it seems that somehow the useTable hook is causing my component to re-render when it likely should not. I've spent over a day going over my code and checking it against examples here and as best I can determine I'm not doing anything prohibited.

I was having same issue. For me it started when I started to use manualPagination with server side pagination. There is no use of either useMemo or callback, columns defined outside of component. In addition to setting autoResetSortBy: false, autoResetPage: false I also had to set autoResetExpanded: false since I had to use useExpanded feature as well.

[humoyun91]

For anyone who is struggling with similar issue when used useRowSelect hook just enable autoResetSelectedRows in main options which is passed to useTable

[clarkj99]

I know this is probably a stale issue, but I resolved a similar problem by separating the table instantiation into two steps. The codesandbox included by the OP defines the table like this:

 const {
    getTableProps,
    getTableBodyProps,
    headerGroups,
    rows,
    prepareRow
  } = useTable(
    {
      columns,
      data
    },
    useSortBy
  );

For me, destructuring directly from the useTable hook caused the "Maximum update depth exceeded" error. Doing it in two steps eliminated the error.

const tableInstance = useTable(
    {
      columns,
      data
    },
    useSortBy
  );

const {
    getTableProps,
    getTableBodyProps,
    headerGroups,
    rows,
    prepareRow
  } = tableInstance;

Hope this helps.

[theutkarshsoni]

Thanks, @andrickd for your solution. Save my dark night.

[yue-su]

I fixed the issue by wrapping the data in useMemo as well. I thought it was the columns but it turned out that I recompute the data in every render as well.