Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[OverflowList] Implement more efficient logic to avoid triggering React setState depth limit #3792

Closed
eshlin opened this issue Oct 24, 2019 · 1 comment · Fixed by #5355
Closed

Comments

@eshlin
Copy link

eshlin commented Oct 24, 2019

Environment

  • Package version(s): @blueprintjs/core: ^3.18.1 (but potentially seen on all versions since the OverflowList was introduced)

Feature request

The OverflowList is very convenient and useful for auto-magically figuring out how many elements to display in cases where the width is dynamic, but we've run into a few unexpected issues with the list, due to how it determines how many items fit. Specifically, in cases where we potentially have a long list of repeating items (e.g. circle avatars, tags, etc.), we've run into unexpected application crashes when the setState calls end up exceeding the React setState depth limit of 50, causing the application to crash with an error message of:

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.

Note that this depth limit was changed from 1000 to 50 in React 16.5.0 (facebook/react#13163)

Typically in these cases, we didn't anticipate that the overflow list would attempt to render more than 50 items, so we usually end up resolving by pre-filtering the items so the length is below 50, but it can often be difficult to figure out the OverflowList is the cause, given the generic React error that's shown.

Potential ideas for resolving include:

  1. Changing the "search" for the visible items to take a binary search approach, which should make it much harder to hit the depth limit of 50.
  2. As an alternative, the debugging confusion could potentially be alleviated if we were able to detect the issue in the component itself and throwing a clearer error.
@andersHj
Copy link

Hi, we experienced this today when our overflow list hit more than 49 items that overflowed, and our page suddenly broke.

Created a sandbox to reproduce the problem:
https://codesandbox.io/s/blueprint-sandbox-forked-sgtiv?file=/src/index.tsx

In the docs it says about the overflowRenderer:

Callback invoked to render the overflowed items. Unlike visibleItemRenderer, this prop is invoked once with all items that do not fit in the container.

But to me it looks like the overflowRenderer triggers way to often. For example in the codesandbox example it initially runs about 50 times (x2), first with 1 item in the overflow list, then 2 then 3..... 49.

For now as a workaround to get our page running we just have to make sure we do not put to many items into the OverflowList component, but would be nice with a fix, or some info about the limitations in the docs, as this took us by surprise :)

@adidahiya adidahiya added P2 and removed P3 labels Apr 27, 2021
matt-gold pushed a commit to matt-gold/blueprint that referenced this issue Jun 6, 2022
…partition cycle to increase collapsible elements from 50 to 2^50.

Fixes palantir#3792
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants