-
-
Notifications
You must be signed in to change notification settings - Fork 445
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
Fix types and remove use of deprecated browser event prop #1910
Conversation
@@ -67,10 +67,10 @@ const Link = forwardRef<unknown, InertiaLinkProps>( | |||
ref, | |||
) => { | |||
const visit = useCallback( | |||
(event) => { | |||
(event: React.MouseEvent) => { |
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.
Shouldn't this be a mouse or keyboard event? Tabbing onto a link/button and pressing "enter" can trigger a click
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.
I lied. It's still a mouse event. Carry on 😅
Thanks for all your work on this! Lots of learnings over the past few days for me 💪 |
@shengslogar me as well, thanks for collaborating with me on it! |
Thanks guys!! |
In #1910 (d53b2b3), we switched to passing `event.nativeEvent` to `shouldIntercept` in an attempt to consistently always pass native browser events to this framework-agnostic helper. This actually introduced a bug though, because `currentTarget` is _different_ on React's synthetic event vs. the underlying native event. The correct value for `currentTarget` lives on the synthetic event. Since we are no longer relying on `event.which` (and this is the only property we used to be concerned with that was not included on the React synthetic event), we'll simply move back to passing the React synthetic event to `shouldIntercept`.
In #1910 (d53b2b3), we switched to passing `event.nativeEvent` to `shouldIntercept` in an attempt to consistently always pass native browser events to this framework-agnostic helper. This actually introduced a bug though, because `currentTarget` is _different_ on React's synthetic event vs. the underlying native event. The correct value for `currentTarget` lives on the synthetic event. Since we are no longer relying on `event.which` (and this is the only property we used to be concerned with that was not included on the React synthetic event), we'll simply move back to passing the React synthetic event to `shouldIntercept`.
In #1910 (d53b2b3), we switched to passing `event.nativeEvent` to `shouldIntercept` in an attempt to consistently always pass native browser events to this framework-agnostic helper. This actually introduced a bug though, because `currentTarget` is _different_ on React's synthetic event vs. the underlying native event. The correct value for `currentTarget` lives on the synthetic event. Since we are no longer relying on `event.which` (and this is the only property we used to be concerned with that was not included on the React synthetic event), we'll simply move back to passing the React synthetic event to `shouldIntercept`.
Thanks to some crafty sleuthing by @shengslogar (#1908 (comment)), there are a few things to clean up after #1908:
shouldIntercept
from the React adapter was the React synthetic event, which does not have all the properties of the underlying native event. It seems wise to keep the intercept helper function framework-agnostic, so this change now passes theevent.nativeEvent
toshouldIntercept
.event.which
property is deprecated. The purpose it previously served for evaluatingMouseEvent
eligibility is now covered by the newly-introducedevent.button
check.visit
function and expanded theonClick
prop signature (since this is a polymorphic element, this may not always be anHTMLAnchorElement
).