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

Handle esc key in settings #4702

Merged
merged 4 commits into from
Feb 25, 2025
Merged

Handle esc key in settings #4702

merged 4 commits into from
Feb 25, 2025

Conversation

nicodh
Copy link
Member

@nicodh nicodh commented Feb 24, 2025

partly solves #4128

@nicodh
Copy link
Member Author

nicodh commented Feb 24, 2025

Simplified solution instead #4205 which has too many changes that have impact on all dialogs and the behaviour of buttons etc.

Copy link
Member

@Simon-Laux Simon-Laux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

code LGTM, did not test

@Simon-Laux
Copy link
Member

just noticed that the event listeners are not cleaned up again, useEffect functions should return a callback for cleanup.

@nicodh
Copy link
Member Author

nicodh commented Feb 25, 2025

just noticed that the event listeners are not cleaned up again, useEffect functions should return a callback for cleanup

As you see I noticed that too and added an AbortController which will remove the eventListener if window.__settingsOpened is false or settingsMode === 'main'
But I can additionally call it in a return function

@Simon-Laux
Copy link
Member

As you see I noticed that too and added an AbortController which will remove the eventListener if

ok the point is yours. maybe add a comment about that it removes the event listener, I didn't knew that new web feature and assumed it would just stop the event listener.

@Simon-Laux
Copy link
Member

Simon-Laux commented Feb 25, 2025

but still what happens when you leave the settings, there is still a leak, better call the abort controller in the cleanup function. But then again I wonder why you don't just use the proven pattern that we use elsewhere for event listeners in use effects:

pseudo code

useEffect(()=>{
/* condition can early return here*/

const method = () => {
/* or it can go here, it doesn't need to use ref, because use effect is re run if the vars change because they are mentioned below */
logic for event handler goes here
}
addListener("onkey", method)
return ()=>{removeListener("onkey", method)}
},[vars for conditions])

Copy link
Member

@Simon-Laux Simon-Laux left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there are currently some issues and questions that need to be resolved first before we merge it see previous comment and also I wonder why there are two use effects and listeners now

@nicodh
Copy link
Member Author

nicodh commented Feb 25, 2025

But then again I wonder why you don't just use the proven pattern that we use elsewhere for event listeners in use effects:

Didn't see that, so of course that is simpler and easier. I adapted the listener in useEffect

@nicodh nicodh merged commit f979e9f into main Feb 25, 2025
12 checks passed
@nicodh nicodh deleted the fix-4128-escape-in-settings branch February 25, 2025 09:33
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants