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
chore(TS): IText types #8610
chore(TS): IText types #8610
Conversation
fixes flicker while calling `setDragImage`
Build Stats
|
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.
done
@@ -170,6 +168,7 @@ export class IText extends ITextClickBehaviorMixin<ITextEvents> { | |||
*/ | |||
_set(key: string, value: any) { | |||
if (this.isEditing && this._savedProps && key in this._savedProps) { | |||
// @ts-expect-error irritating TS | |||
this._savedProps[key] = value; |
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.
to add context around this, i think is because we mutate more state other than isEditing
when going editing mode.
I ll open a task to fix it seems it seems just wrong as a pattern.
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 agree
export abstract class ITextClickBehaviorMixin<EventSpec extends ObjectEvents> | ||
function isRightClick(button?: number) { | ||
return button === RIGHT_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.
in canvas file we define this function
function checkClick(e: TPointerEvent, value: number) {
return !!(e as MouseEvent).button && (e as MouseEvent).button === value - 1;
}
So on top of reusing it, i wonder why there we use value - 1
and here were are using value directly.
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.
Answer i found later: because here we are not inspecting e.button directly.
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.
it was previously e.button.
checkClick
is used on the native event before the synthetic event is fired by fabric. The synthetic event has the button
attr set and is e.button+1
. It is far from ideal that that values aren't identical. But that is what it is.
I thought we should use the button attr of the synthetic event or use checkClick
and made it clear we are checking
to avoid a right 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.
Ok somethin weird is going on here.
The old code was introduced 6 years ago to guard against NON LEFT CLICKS.
That was the intention.
The code seems wrong in that regard since the value of button for left clicks is 0
and so checking for !==1
was plain wrong.
On top of that UTs have mocked events so not really reliable.
To avoid mixing types with changes, i just kept the exact code that was there before, but what this code is doing should be investigated.
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.
_mouseDownHandler({ e }: TransformEvent) { | ||
if (!this.canvas || !this.editable || (e.button && e.button !== 1)) { | ||
_mouseDownHandler({ e, button }: TPointerEventInfo) { | ||
if (!this.canvas || !this.editable || isRightClick(button)) { |
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 see 2 things here ( and on _mouseDownHandlerBefore
):
- we move to evaluate the button option rather than the event.button.
- we changed from a
not a left click
to ais a right click
that leaves the middle click and other possible clicks in an new state ( i would definitely avoid that ).
On top of that it looks like we expose on the event this button value that is not the real button value from the event but more a fabricjs custom value. I wonder if we should remove that value completely and let people look at the event itself
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.
ok seems like we used to look at button because buttons
wasn't on IE. But that is a topic or another day.
I think the only important thing here is to change this isRightClick with a !isLeftClick
as it was before so we don't change behaviour
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 didn't mean to change behavior. It was unclear to me
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.
(e.button && e.button !== 1)
means to me:
value is not 0 (not left click) and not middle click => is right click
Why middle click is alright I didn't understand.
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 it is best you do it
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 just don't want to chane the behavioru in a typing PR.
I think the reason of being not a left click
is because by default fabric wasn't doing anything else with other clicks ( other than allowing for event firing ). So as long as it matters to us, right, middle and the other 2 clicks ( called 4 and 5 that are in some custom mouse ) we just don't do anythin.
Let me know if you have time to address that rightclick vs not left click, so that then i can merge. |
BTW I wanted to move all IText classes under a folder same as Object, makes sense IMO |
Renaming files or moving them is not a huge issue for me at this point in changes |
Motivation
part of removing ts-nocheck effort
Description
remove ts-nocheck for itext_behavior, itext_click_behavior, IText
Changes
smashed click behavior init methods into initBehavior
BREAKING: changed
getLocalPointer
signatureGist
first merge #8598
In Action