React-table: Err: "Maximum update depth exceeded" with version 7.1.0

Created on 26 May 2020  路  13Comments  路  Source: tannerlinsley/react-table

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

Most helpful comment

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.

All 13 comments

I'm also experiencing this with 7.1.0.

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

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.

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.

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.

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

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

@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.

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

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.

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

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?

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

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dwjft picture dwjft  路  3Comments

mellis481 picture mellis481  路  3Comments

pasichnyk picture pasichnyk  路  3Comments

mlajszczak picture mlajszczak  路  3Comments

esetnik picture esetnik  路  3Comments