-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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) Ts convert event mixins #8519
Conversation
Build Stats
|
17k less i broke something large |
Not really ready for review, but we can start to have a look |
only 12 UTs broken, seems very little. |
…js into ts-convert-event-mixins
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.
- fixed types by adding
pointer
,absolutePointer
,isClick
to some events. Hope I did it right. - Made me think that it is dangerous sending the cached points down to a subscriber. What if they are mutated down there?
- The
canvas_events
diff is impossible so I can only read it. - I suggest extracting all draggable logic to a subclass one day
Now of course tests fail
@@ -154,12 +173,39 @@ import { scalingEqually } from '../controls/actions'; | |||
return; | |||
} | |||
t.target.rotate(radiansToDegrees(degreesToRadians(curAngle) + t.theta)); |
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.
what is 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.
why not ?
t.target.rotate(radiansToDegrees(degreesToRadians(curAngle) + t.theta)); | |
t.target.rotate(curAngle + radiansToDegrees(t.theta))); |
src/canvas/canvas.class.ts
Outdated
} | ||
this._currentTransform = transform; | ||
// @ts-ignore | ||
this._beforeTransform(e); |
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.
moved because of 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.
reverted, should be moved one day
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 tried this as well, and there were too many moving parts. The real issue is that all this stuff is highly coupled together and the canvas without events would be a very tiny layer that doesn't make much sense. On the other hand canvas + canvs_events would be a 3000 line file
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
maybe we return to this and reshape it
'_onDragLeave', | ||
'_onDrop', | ||
] as const | ||
).forEach((eventHandler) => { |
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.
IMO this method should die in favor of the fat arrow syntax that binds the methods in class init
class Canvas {
boundForGood = () => {
this // is always a canvas instance
}
}
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 this an inversion of cause and effect and i don't want to do it.
Fat arrow do not have a THIS and so in order to be used in a class they get bound at constructor time, otherwise when you call class.method() you have no idea which the THIS is if you don't bind it.
So what happens is that you need to bind them to even work in a class, and so as a side effect, being bound, they work as event handlers.
Once those are written down as fat arrow, in 3 months someone wants to convert them to function, there is no written anywhere that those should be bound again.
In our case those methods are supposed to be event handlers, so they need to be bound to the class because they will be executed out of context, and so we bind them explicitly.
MDN is clear on the fact that arrow functions are not good for classes: https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Functions/Arrow_functions and the short hand syntax indeed make them not even more concise.
Those are useful exactly when you need an outside this for your expression ( forEach loops, map loops and so on ).
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.
* @param {Event} [e] Event object fired on wheel event | ||
*/ | ||
private _onMouseWheel(e: MouseEvent) { | ||
this.__onMouseWheel(e); |
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.
why is this wrapper needed?
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 isn't but i think it was done for similarities with other events
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 moved back _setupCurrentTransform
, nearly went mad because of it
Maybe it is best I squash my commits and force push |
Yes would be great if you can have a commit only i can read, without updating to latest master. |
9dc4797
to
f6540c9
Compare
Adding more data to events to satisfy generic types wasn't my preferred solution, but also is not performance relevant so i don't care.
We could generate new, i don't think should be a big deal, or we could find a way to make the cached pointer immutable. ( Object freeze or something like that )
|
Ok i see canvas_events become a new file. |
Couldn't, even when moving the file back. Too large a change. |
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.
@asturur take a look
for future large PRs I think we should try to keep history by renaming first and then changing files. But no sure that would have worked in this case since changes were too big.
@@ -833,10 +836,7 @@ export class Canvas< | |||
let pointer = this.getPointer(e); | |||
if (target.group) { | |||
// transform pointer to target's containing coordinate plane | |||
// should we use send point to plane? | |||
pointer = pointer.transform( | |||
invertTransform(target.group.calcTransformMatrix()) |
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 was wrongly migrated
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 is the error to be fixed by #8563
pointer = pointer.transform( | ||
invertTransform(target.group.calcTransformMatrix()) | ||
); | ||
pointer = sendPointToPlane(pointer, target.group.calcTransformMatrix()); |
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.
here
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.
should be sendPointToPlane(pointer, undefined, target.group.calcTransformMatrix());
I got extremely confused |
Co-authored-by: ShaMan123 <[email protected]>
Co-authored-by: ShaMan123 <[email protected]>
Motivation
Continuing the TS migration.
Description
Lots of things going on here.
Changes
Gist
In Action