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

feat(useBodyScrollLock): supports optional lock pointer events #1652

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

serkodev
Copy link

This PR allows users to pass the following state to useBodyScrollLock to optionally lock scrolling and pointer events:

interface UseBodyScrollLockState {
  scroll?: boolean
  pointerEvents?: boolean
}

This change remains backward compatible since it still supports boolean. When set to true, both scroll and pointerEvents are locked as before.

Why

In my project, I needed to lock the body scroll. However, using VueUse’s useScrollLock caused some issues. For instance, after locking the body scroll and manually setting the body’s padding-right, opening and closing a Radix Dialog would clear the padding-right.

To address this, I decided to use Radix’s useBodyScrollLock for locking the body scroll. By default, it will set pointerEvents to none, which prevents clicking on any elements.

While a workaround like the one below exists:

const locked = useBodyScrollLock()
locked.value = true
nextTick(() => {
  document.body.style.pointerEvents = ''
})

It didn’t feel intuitive to me. I believe that "scroll locking" should not disable all pointer events. Therefore, I’ve added an option for pointerEvents in useBodyScrollLock so that users can choose whether to lock pointer events or not.

@serkodev serkodev changed the title feat: useBodyScrollLock supports optional lock pointer events feat(useBodyScrollLock): supports optional lock pointer events Feb 23, 2025
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.

1 participant