chore(TS): controls #8400

ShaMan123 · 2022-10-29T05:40:51Z

Motivation

Description

Migrating controls:

modularize
type
consumed normalizePoint into getLocalPoint

Proposed Changes for Follow Up

As discussed previously I want to make the Control class bound to an Object. This will make existing Control signatures redundant since fabricObject will be a class property. This means controls will no longer be shared, another over discussed topic I advocate. In purpose I didn't do it in this PR (as @asturur requested not to over refactor) so we can migrate most of controls with no major disagreements. Something worth looking at is that there are 2 signatures XXX(eventData, control, fabricObject) and XXX(eventData, fabricObject, control). That is weird. But if we agree on bound controls both will become XXX(eventData). If not we should change them for consistency.
Refactor wrappers to behave like middleware? mutating context and passing it on to the next action. This will remove any need to create wrappers in run time, seems to be easier to understand and reduces code.

const skewX = (...params) => [
   isLocked, // flag context somehow to disable next calls
   saveOrigin, // stores origin on context,
   prepareSkewingTransform, // mutates context
   skewObject, // uses the mutated context and set the result value
   restoreOrigin, // uses the mutated context
   fireEvent // uses the action result
].reduce((context, action) => action(context), prepareContext(...params))

progress progress(): position major progress fix(): flip cleanup no multiply good state! fix(): successive skewing cleaup

@luizzappa

commited @luizzappa suggestion

asturur · 2022-10-29T22:58:14Z

src/mixins/object_geometry.mixin.ts

-      return this.canvas.viewportTransform;
-    }
-    return iMatrix.concat() as TMat2D;
+    return this.canvas?.viewportTransform || (iMatrix.concat() as TMat2D);


i m not sure we are transpiling those yet.
But the issue is that if undefined is not involved those becomes longer.
if typeof canvas !== 'undefined' rather than a simple if this.canvas

please elaborate
I lack the knowledge

What is the diff between this syntax and obj?.[key] ?

none, but where we use obj?.[key] we were already looking for undefined ( ex: the overrideStyle object ). Here we want just to check if canvas is falsy in any way.

obj.first?.second const temp = obj.first; const nestedProp = temp === null || temp === undefined ? undefined : temp.second;

If we land on supported browsers that do not support the ?. all those equality check get added in the codebase. I just don't like to think all that stuff gets added in.

Not a big issue anyway

asturur · 2022-10-29T23:01:04Z

Seems all good to me apart:

the extra this argument in the renderCircle and renderSquare control
~~the renaming of the cursor style functions~~
i have to look into that getActionFromCorner

src/controls/controls.actions.ts

asturur · 2022-10-29T23:18:33Z

Regarding the tasks you proposed , piping the function is a well known pattern as good as another, there is no reason to change it, it allows for reusability, keeps functions with a single concerns, is newish ( added in 4.0 ) i don't see the reason to change it, is just added chaos.

Regarding sharing or no, that is really a no.
You can still make NON shared controls if you want, creating them new for each object. but if you embed that in the code in the library you can't do the contrary anymore. Why add this limitation?

I m totaly happy with a control set that is able to render itslef moving from object to object rather than many copies of it one per object.

ShaMan123 · 2022-10-29T23:25:59Z

Regarding sharing or no, that is really a no.

We will remain disagreed on this topic
The why is because it is very unintuitive. The same as the discussion we had on default values. Exactly IMO. A dev wanting a change to propagate should loop over existing objects. Elsewise it is a reactive mobx kind of thing.
I view controls as part of Object, you view it as a separate layer as far as I can tell.
A dev mutating that object will never understand that he changed the entire app.

ShaMan123 · 2022-10-30T06:35:54Z

src/controls/rotate.ts

+    curAngle = Math.atan2(y - pivotPoint.y, x - pivotPoint.x);
+  let angle = radiansToDegrees(curAngle - lastAngle + theta);
+
+  if (target.snapAngle && target.snapAngle > 0) {


ShaMan123

Added isLocked util, not very useful but at least it makes it simple to find all the locking logic
Extracting to a wrapper will cause too many unnecessary code changes

ShaMan123 · 2022-10-30T07:29:12Z

Regarding sharing or no, that is really a no.

We will remain disagreed on this topic The why is because it is very unintuitive. The same as the discussion we had on default values. Exactly IMO. A dev wanting a change to propagate should loop over existing objects. Elsewise it is a reactive mobx kind of thing. I view controls as part of Object, you view it as a separate layer as far as I can tell. A dev mutating that object will never understand that he changed the entire app.

@asturur I have a compromise.
If we expose a class ControlSet that is basically a set of controls.
The class will hold the original control set ref as follows:

class ControlSet {
  defaultControls: Record<string, Control>;
  controls: Record<string, Control>;

  constructor(controls: Record<string, Control> = {}) {
    this.defaultControls = controls;
  }
  getControl(key: string) {
    return this.controls[key] || this.defaultControls[key];
  }
  setControl(key: string, control: Control) {
    this.controls[key] = control;
  }
}

This is a win win solution.
For your side no one will touch this ControlSet class, but continue as previously by mutating the ref that was passed to the ControlSet (and if necessary could pass a new ControlSet to the object).
For my side the dev can use setControl and is safeguarded from unwanted sharing. No need for a gotcha/documentation/issues.
We keep what you want and make it intuitive.
I hope I convinced you.
Awaiting your response.

And I can fix the derivation of textbox controls with this approach

ShaMan123 · 2022-10-30T07:36:52Z

And I can fix the derivation of textbox controls with this approach

A win-win-win you-me-textbox

class ControlSet {
  defaultControls: Record<string, Control> | ControlSet;
  controls: Record<string, Control>;

  constructor(controls: Record<string, Control> | ControlSet = {}) {
    this.defaultControls = controls;
  }
  getControl(key: string): Control {
    return (
      this.controls[key] ||
      (this.defaultControls instanceof ControlSet
        ? this.defaultControls.getControl(key)
        : this.defaultControls[key])
    );
  }
  setControl(key: string, control: Control) {
    this.controls[key] = control;
  }
}

const objectControls = new ControlSet(defaultControls);
const textboxControls = new ControlSet(objectControls);
textboxControls.setControl('mr', new Control({}));
objectControls.setControl('a', new Control({}));
textboxControls.getControl('a');

And then on each Object we do the same so when using setControl it changes only the object, while changing the objectControls.defaultControls will change all

new ControlSet(objectControls)
new ControlSet(textboxControls)

ShaMan123 · 2022-10-30T07:59:28Z

It also allows use to move control logic from interactivity.
Things like control visibility etc.

class BoundControlSet {
  constructor(controlSet: ControlSet, object: FabricObject) {
    this.controls = controlSet;
    this.object = object;
  }
  getVisibility(...) {
    
  }
  setVisibility(...) {
    
  }
}

This is a better pattern IMO for making interactivity optional and typed. We encapsulate the logic in dedicated classes instead on FabricObject

ShaMan123

Thinking of defaultControls
I think they should be assigned in the interactivity mixin.
And that textbox should subclass the mixin.
And that we use applyMixins for it instead of subclassing

Not sure though
Thoughts?

asturur · 2022-10-30T11:10:17Z

@ShaMan123 i want to do the TS migration, i don't want to do refactors. There is a lot of work to do and the more we do because we think is necessary, the later we can go back to features and website and docs

I disagree on TS and classes the more i write them. peace.

If we want to finish the ts migration we stick to that, we take notes on what we would like to see changed, we organize them and for now we move on head down on the goal

Even the isLocked wrapper wasn't an idea i would have chased now.

ShaMan123 · 2022-10-30T12:08:42Z

I understand.
These are notes for us to discuss.
Ideas.
Do you prefer I put them elsewhere? Do you prefer not hearing them?
I don't understand

ShaMan123 · 2022-10-30T12:32:08Z

So if I understood you, my comments are throwing you off.
So if I put everything in a discussion(s) that what be better?

asturur · 2022-10-30T19:32:07Z

So if I understood you, my comments are throwing you off. So if I put everything in a discussion(s) that what be better?

How can i know that you put them in the PR because you want to discuss them somewhere else another day?
If i see them in the PR i think you want to address them now.

asturur · 2022-10-30T20:10:20Z

let's skip getActionFromCorner check up and let's merge this.
I checked and i don't have much memories apart that it was a slimdown of the previous function that was there since long.
The idea was to move Drag in the realm of controls too, so this is probably a safe change

ShaMan123 added 30 commits October 12, 2022 10:50

WIP

ed66b81

Merge branch 'master' into fix-skewing-controls

0e5305a

Merge branch 'master' into fix-skewing-controls

c4633cb

fix skewing

e30dd32

progress progress(): position major progress fix(): flip cleanup no multiply good state! fix(): successive skewing cleaup

Update controls_handlers.js

465149f

Update CHANGELOG.md

95b8b39

fix(): use set

06cdb64

Update object.class.ts

793df67

Update controls.actions.ts

c6f000d

ws

d4996d1

fix(): flip assignment

606df66

goldens

cdc2c5e

revert(): svg stuff

c1f21d1

cleanup

aa48a3b

Update object.class.ts

4e84453

fix(): restore compensateScaleForSkew

5ee4741

cleanup

cf395b4

cleanup compensate

22abcc6

rename

3f4720a

WIP compensation

dc482f5

progress!

fc70ee9

revert

6ec0e26

refactor

14c7713

cleanup

7f6e7a3

refactor(): axis keys

601c363

refactor skew handlers

f4f6635

minor fix + rename

040d459

compensationFactor only for skewY

902a7ca

commited @luizzappa suggestion

fix(): anchoring origin

4a28d67

rename for clarity

7512123

asturur reviewed Oct 29, 2022

View reviewed changes

ShaMan123 commented Oct 29, 2022

View reviewed changes

src/controls/controls.actions.ts Show resolved Hide resolved

ShaMan123 added 6 commits October 30, 2022 01:27

normalizePoint

032cc27

optional textbox controls

58af5c6

review changes

e083787

Update controls.render.ts

00baf49

Update controls.render.ts

d765524

Update rotate.ts

310abfb

ShaMan123 commented Oct 30, 2022

View reviewed changes

ShaMan123 added 2 commits October 30, 2022 09:00

Update scaleSkew.ts

c19df4c

isLocked

0839306

ShaMan123 commented Oct 30, 2022

View reviewed changes

asturur approved these changes Oct 30, 2022

View reviewed changes

asturur merged commit d55fabc into master Oct 30, 2022

asturur deleted the ts-controls branch October 30, 2022 20:17

ShaMan123 mentioned this pull request Oct 31, 2022

chore(TS): finalize interactivity #8404

Merged

frankrousseau pushed a commit to cgwire/fabric.js that referenced this pull request Jan 6, 2023

chore(TS): convert controls class and handlers (fabricjs#8400)

3ff8704

asturur mentioned this pull request Sep 9, 2023

Fix a regression in wrap with fixed anchor #9326

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

chore(TS): controls #8400

chore(TS): controls #8400

ShaMan123 commented Oct 29, 2022 •

edited

Loading

asturur Oct 29, 2022

ShaMan123 Oct 29, 2022

ShaMan123 Oct 29, 2022

asturur Oct 30, 2022

asturur commented Oct 29, 2022 •

edited

Loading

asturur commented Oct 29, 2022

ShaMan123 commented Oct 29, 2022 •

edited

Loading

ShaMan123 Oct 30, 2022

ShaMan123 left a comment •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading

ShaMan123 left a comment

asturur commented Oct 30, 2022

ShaMan123 commented Oct 30, 2022

ShaMan123 commented Oct 30, 2022

asturur commented Oct 30, 2022

asturur commented Oct 30, 2022

chore(TS): controls #8400

chore(TS): controls #8400

Conversation

ShaMan123 commented Oct 29, 2022 • edited Loading

Motivation

Description

Proposed Changes for Follow Up

asturur Oct 29, 2022

Choose a reason for hiding this comment

ShaMan123 Oct 29, 2022

Choose a reason for hiding this comment

ShaMan123 Oct 29, 2022

Choose a reason for hiding this comment

asturur Oct 30, 2022

Choose a reason for hiding this comment

asturur commented Oct 29, 2022 • edited Loading

asturur commented Oct 29, 2022

ShaMan123 commented Oct 29, 2022 • edited Loading

ShaMan123 Oct 30, 2022

Choose a reason for hiding this comment

ShaMan123 left a comment • edited Loading

Choose a reason for hiding this comment

ShaMan123 commented Oct 30, 2022 • edited Loading

ShaMan123 commented Oct 30, 2022 • edited Loading

ShaMan123 commented Oct 30, 2022 • edited Loading

ShaMan123 left a comment

Choose a reason for hiding this comment

asturur commented Oct 30, 2022

ShaMan123 commented Oct 30, 2022

ShaMan123 commented Oct 30, 2022

asturur commented Oct 30, 2022

asturur commented Oct 30, 2022

ShaMan123 commented Oct 29, 2022 •

edited

Loading

asturur commented Oct 29, 2022 •

edited

Loading

ShaMan123 commented Oct 29, 2022 •

edited

Loading

ShaMan123 left a comment •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading

ShaMan123 commented Oct 30, 2022 •

edited

Loading