Use Controls to implement node resizing

[Heathermcx]

I have added a ResizeControl which is an ExecutableControl and has an IResizerProvider. Each ResizeControl added to a node adds a 'resizer' which is by default, a small box at the corner of the node. When the resizer is dragged, the node resizes. IResizeProvider provides the position of the resizer and also the behavior for the node when the resizer is dragged. I have included four default implementations of IResizeProvider - one for each corner of a node.

[JEDII29]

When can we expect merge this feature to develop?

[kyctarnik]

I don`t think it must be part of core. There is 2 reasons.

1. You have leaked an abstraction in the line "public string? Class => _resizeProvider.Class;" in ResizerProvider.
   Your "provider" now know about view.
2. You are introducing a new concept that this framework does not operate with
3. You do not need provider to make resize. You need only one behavior.
4. If you change the scale while changing the node size, you will catch a bug with the node size.
5. The position should be determined by control, not behavior (in my understanding). Or, even better, it must be transmitted from the outside.
6. You forgot about "Snap to grid" option.

@zHaytam am I right?

[vivek-dhanade]

Hey, any updates on Node Resizing feature?

[zHaytam]

I don`t think it must be part of core. There is 2 reasons.

1. You have leaked an abstraction in the line "public string? Class => _resizeProvider.Class;" in ResizerProvider.
   Your "provider" now know about view.
2. You are introducing a new concept that this framework does not operate with
3. You do not need provider to make resize. You need only one behavior.
4. If you change the scale while changing the node size, you will catch a bug with the node size.
5. The position should be determined by control, not behavior (in my understanding). Or, even better, it must be transmitted from the outside.
6. You forgot about "Snap to grid" option.

@zHaytam am I right?

You make a lot of good points to be honest.

The thing is, your provider is handling the resizing and setting the size, and the renderer sets the CSS width/height, but the assumption of the whole library is that sizes change based on content, that's why we use a resize observer to capture changes.

1. I think the usage of node.ControlledSize = true should be the default for this type of nodes, which is why im thinking, what if we had a clear way to differenciate dynamic nodes (where the size depends on the content, thus requiring ResizeObserver) vs static/controlled nodes (where the size is programmatically controlled/node is resizable)?
2. I would like to not include any UI things in the code library, as @kyctarnik pointed out, the class property tells us that this is web related, when it can't be the case forever, maybe in the future this library could work on a different platform (e.g. mobile?)

[zHaytam]

Having dynamic nodes VS static/controlled nodes would also make it possible to have a set of known nodes/shapes that you often see in other libraries as static/controlled and do a lot of things, so maybe that's worth working on, what do you guys think?

[peterharding93]

I just looked at doing this myself or using this solution, and here is my conclusion:
I think that the question 'What size should the div be' is best left with the HTML/CSS. Your resize observer is pretty good and works well. I would look to just use CSS and Styles to set the div size.
I just did a quick test in css { resize: both; overflow: hidden;}. It almost worked.. the problem is that the drag behavior still runs. I couldn't find a way to stop propagating the events if one hits the resize handle.

I tried a few things. I expect adding a little interceptor (see below) to intercept the events should work. But I'm not quite there.
Something to do with blazor.web.js OnGlobalCapture being bound with Capture:true.. This is a little bit more complex than I thought. I'm going to leave it for now.
I could modify the drag behavior to not start if we hit the drag corner - but that seems kind of messy.
It is reasonable to use controls to resize the div, and then still run the size observer. But it seems we are reinventing aspects already built into HTML.

<div class="interceptor" onmousedown="event.stopImmediatePropagation();" pointerdown="event.stopImmediatePropagation();">
   ab
</div>

::deep div.diagram-node {
        resize: both; /* allows horizontal+vertical resize */
        overflow: hidden;
        min-width: 100px;
        min-height: 80px;
        max-width: 400px;
        max-height: 300px;
}
::deep div.diagram-node div.interceptor {
    background-color: lightgray;

    position: absolute;
    bottom: 0;
    right: 0;
    width: 20px;
    height: 20px;
    z-index: 10;
    overflow: hidden;
}