-
Notifications
You must be signed in to change notification settings - Fork 16
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
Add explicit focusOptions
support for ReactFocusLock
#63
Conversation
Hey. Thank you for your contribution and the wonderful debugging journey. Wondering what would be the best approach here:
One of the reasons to prefer more abstract solutions - easier to correct "default behaviour" on a major version bump. Thoughts? |
I think I'd lean towards a boolean to match native behavior over a Totally understand the difficulties of balancing flexibility vs abstraction. I can update my PR on Monday with whatever API you prefer. |
Proposal sounds reasonable. What about actually matching underlying primitive as |
I'm good either way! I pushed up the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let me handle the rest
Thanks a million! I don't have merge/write access to merge the PR as a heads up. |
Released in |
closes #62
As of 2.7.0, react-focus-lock has supported a
focusOptions
prop, primarily for allowing consumers to passpreventScroll
to the initial focus event. react-focus-on unfortunately has not exposed passing that prop directly toreact-focus-lock
, which potentially leads to scroll jumping issues that cannot be overridden (see theKashey/react-focus-lock#162 for more info).I looked but couldn't see any meaningful unit tests to write/update to include this new prop - please feel free to ping me if there are!