-
Notifications
You must be signed in to change notification settings - Fork 6.8k
refactor: clean up remaining hammer.js usages #17268
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
Conversation
Now that none of the components use Hammer.js anymore, we can clean up the remaining usages from the project.
c22012b
to
0d7a183
Compare
* Adjusts configuration of our gesture library, Hammer. | ||
* @deprecated No longer being used. To be removed. | ||
* @breaking-change 10.0.0 | ||
*/ | ||
@Injectable() | ||
export class GestureConfig extends HammerGestureConfig { |
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.
Note that we can also get rid of all of this code and the one in gesture-annotations.ts
, but it got exported through material/core
so it's technically public API. If we don't consider it public we can remove it now, otherwise we need to wait for v10.
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 think a few people actually provide the GestureConfig
manually. e.g. to work around a bug: #4595 (comment), or if they use it to access the slide
or longpress
events.
I think the impact is very low if we remove it, but I could also see waiting for it until we have worked out the migration schematic.
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.
There are ~18 references to GestureConfig
in Google. I think we need need some more intelligent schematic work here. Let's discuss at the team meeting tomorrow.
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.
Nice 🎉
@@ -197,8 +197,7 @@ export declare const MAT_OPTION_PARENT_COMPONENT: InjectionToken<MatOptionParent | |||
export declare const MAT_RIPPLE_GLOBAL_OPTIONS: InjectionToken<RippleGlobalOptions>; | |||
|
|||
export declare class MatCommonModule { | |||
constructor(sanityChecks: any, _hammerLoader?: HammerLoader | undefined); | |||
_checkHammerIsAvailable(): void; | |||
constructor(sanityChecks: any); |
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.
This looks like it could be a breaking change if someone manually passes a HammerLoader
. I know that this is a rare edge case, but better to talk about it than accidentally missing it.
I'm happy leaving it like that, but could also see having a fake parameter like you did in some other PR (with injecting ElementRef
)
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.
Hmm, good point. My thinking when removing it was that it was optional already.
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.
Of all the things people could manually instantiate or extend, MatCommonModule
would be the strangest. I'm okay just removing this.
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.
Yeah, I just wanted to raise awareness. As mentioned above, I'm fine with that either.
* Adjusts configuration of our gesture library, Hammer. | ||
* @deprecated No longer being used. To be removed. | ||
* @breaking-change 10.0.0 | ||
*/ | ||
@Injectable() | ||
export class GestureConfig extends HammerGestureConfig { |
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 think a few people actually provide the GestureConfig
manually. e.g. to work around a bug: #4595 (comment), or if they use it to access the slide
or longpress
events.
I think the impact is very low if we remove it, but I could also see waiting for it until we have worked out the migration schematic.
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.
LGTM, I think this can go in now and we can follow up with our next steps after tomorrow's team meeting
@@ -197,8 +197,7 @@ export declare const MAT_OPTION_PARENT_COMPONENT: InjectionToken<MatOptionParent | |||
export declare const MAT_RIPPLE_GLOBAL_OPTIONS: InjectionToken<RippleGlobalOptions>; | |||
|
|||
export declare class MatCommonModule { | |||
constructor(sanityChecks: any, _hammerLoader?: HammerLoader | undefined); | |||
_checkHammerIsAvailable(): void; | |||
constructor(sanityChecks: any); |
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.
Of all the things people could manually instantiate or extend, MatCommonModule
would be the strangest. I'm okay just removing this.
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Now that none of the components use Hammer.js anymore, we can clean up the remaining usages from the project.