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

Popover onClose runs in the loop after closing the popover #7115

Closed
1 of 2 tasks
maxiadlovskii opened this issue Nov 12, 2024 · 5 comments
Closed
1 of 2 tasks

Popover onClose runs in the loop after closing the popover #7115

maxiadlovskii opened this issue Nov 12, 2024 · 5 comments
Labels
Fixed patch Completed issues that will be published with next patch (1.0.X)

Comments

@maxiadlovskii
Copy link

maxiadlovskii commented Nov 12, 2024

Dependencies check up

  • I have verified that I use latest version of all @mantine/* packages

What version of @mantine/* packages do you have in package.json?

7.13.4, 7.13.5

What package has an issue?

@mantine/core

What framework do you use?

create-react-app (CRA)

In which browsers you can reproduce the issue?

Chrome

Describe the bug

In case the onClose callback depends on some state value and then changes it, then, after first closing of the popover, on close callback runs in the loop.
I attached a link to codesandbox. Just open and close popover and you will see how updates count. When I open Popover again, it stops counting. a

If possible, include a link to a codesandbox with a minimal reproduction

https://codesandbox.io/p/sandbox/mantine-popover-bug-forked-dst5wp?file=%2Fsrc%2FApp.tsx

Possible fix

In my opinion, somewhere in the code, you run onClose when the callback is updating because of some dependencies state update

Self-service

  • I would be willing to implement a fix for this issue
@maxiadlovskii
Copy link
Author

maxiadlovskii commented Nov 12, 2024

In my example in codesandbox, you even can press the Count button, when the popover is closed. That would run in the loop an onClose. That means that if from any place of the application, I change some of the onClose dependency, it triggers onClose call

Screen.Recording.2024-11-12.at.15.48.51.mov

@minosss
Copy link

minosss commented Nov 13, 2024

In your example, the onClose and onOpen will be changed in every re-render.

So it will be called in a loop.

// use-popover.ts
useDidUpdate(() => {
    if (!_opened) {
      options.onClose?.();
    } else {
      options.onOpen?.();
    }
}, [_opened, options.onClose, options.onOpen]);

Cache the callbacks

<Popover
  onClose={useCallback(() => {  setCount((c) => c+1); }, [])}
  onOpen={useCallback(() => {}, [])}
/>

@maxiadlovskii
Copy link
Author

maxiadlovskii commented Nov 14, 2024

In your example, the onClose and onOpen will be changed in every re-render.

So it will be called in a loop.

// use-popover.ts
useDidUpdate(() => {
    if (!_opened) {
      options.onClose?.();
    } else {
      options.onOpen?.();
    }
}, [_opened, options.onClose, options.onOpen]);

Cache the callbacks

<Popover
  onClose={useCallback(() => {  setCount((c) => c+1); }, [])}
  onOpen={useCallback(() => {}, [])}
/>

My callback onClose use useCallback. From your code example

// use-popover.ts
useDidUpdate(() => {
    if (!_opened) {
      options.onClose?.();
    } else {
      options.onOpen?.();
    }
}, [_opened, options.onClose, options.onOpen]);

I see that mantine run onClose even when the callback is updated. That is not right. Because onClose might have different dependencies, which might be changed independently to popover from other places of application. Update of onClose callback shouldn't run it.
You should run onClose only when _opened updating to false.

@minosss
Copy link

minosss commented Nov 16, 2024

If you are talking about trigger logic, it might be so, it depends on the author.

My choice is to manage the state within the current component as much as possible. If the callback function needs to use some state, I would use ref instead of modifying the callback function.

rtivital added a commit that referenced this issue Nov 16, 2024
@rtivital rtivital added the Fixed patch Completed issues that will be published with next patch (1.0.X) label Nov 16, 2024
@rtivital
Copy link
Member

Fixed in 7.14.1

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Fixed patch Completed issues that will be published with next patch (1.0.X)
Projects
None yet
Development

No branches or pull requests

3 participants