Skip to content
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

feat(auto-place): scroll canvas to new element #1437

Closed
wants to merge 1 commit into from
Closed
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 11 additions & 3 deletions lib/features/auto-place/BpmnAutoPlace.js
Original file line number Diff line number Diff line change
@@ -1,18 +1,26 @@
import { getNewShapePosition } from './BpmnAutoPlaceUtil';
import { getNewShapePosition, getScrollOffset } from './BpmnAutoPlaceUtil';


/**
* BPMN auto-place behavior.
*
* @param {EventBus} eventBus
*/
export default function AutoPlace(eventBus) {
export default function AutoPlace(eventBus, canvas) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you maybe explain, why this is a bpmn-js but no generic diagram-js concern?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One could imagine this is a general create behavior. Elements created are always moved into sight. Or what exactly do you refer to here @pinussilvestrus?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see the benefits of moving this PR to diagram-js, since we also moved the AutoPlace behavior there with bpmn-io/dmn-js#470

This would also add this feature to DMN modeling, which makes sense to me

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we have two things here

a) is it a diagram-js concern? I'd vote for yes
b) is this an auto-place (only) behavior? Good question, I'd expect that this also happens on creating any kind of element, no matter when this happens (auto-place, creating from the palette, ...)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAIK, auto-place is the only way we can currently place elements outside of the viewbox. When creating elements from the pallet, the drag operation automatically scrolls the canvas already

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@marstamm We could argue that is the case, even though we do allow anyone to model via API: https://cdn.statically.io/gh/nikku/2021-token-simulation/v0.0.2/presentation.html#22

Used by some of our side projects, e.g. https://github.com/bpmn-io/bpmn-js-cli and https://github.com/nikku/bpmn-js-cli-modeling-dsl.

We could argue that auto place is the natural higher level API that ships with such behavior. People and robots (cf. WASDENN) are free to implement this this in a similar fashion.

Copy link
Member

@nikku nikku Apr 21, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One idea: Can we make this "ensure visible" / scrollToNode a thing on the canvas in diagram-js? Scroll to an element is a common use case people ask us about on our forums. It is also being used in our search feature already. Moving it into a shared place and exposing it as an API would allow a broader user base to benefit.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great Idea, let's move it into the canvas 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@nikku , I'm not sure if we should replace the behavior in the search feature, as the current implementation is "center on screen" and not "scroll until visible". On the other hand, changing the behavior would closer resemble a text search, as no scrolling is happening when the element is already visible. What do you think?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

On the other hand, changing the behavior would closer resemble a text search, as no scrolling is happening when the element is already visible.

I think it makes a lot of sense to scroll a little bit less. The search result display is already very verbose. So 👍 from my perspective to scroll until visible only.

We may also consider to add a little bit more padding around the to be visible element. It does make sense to show it with context (i.e. what is behind). Would appreciate your input / if you experiment with it a little bit.

eventBus.on('autoPlace', function(context) {
var shape = context.shape,
source = context.source;

return getNewShapePosition(source, shape);
});


eventBus.on('autoPlace.end', function(event) {
var viewBox = canvas.viewbox();
var shape = event.shape;
Comment on lines +19 to +20
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just some personal preference: let's try to stick with our current style

var viewBox = canvas.viewBox(),
    shape = event.shape;

also maps to other examples below


canvas.scroll(getScrollOffset(shape, viewBox));
});
}

AutoPlace.$inject = [ 'eventBus' ];
AutoPlace.$inject = [ 'eventBus', 'canvas' ];
22 changes: 22 additions & 0 deletions lib/features/auto-place/BpmnAutoPlaceUtil.js
Original file line number Diff line number Diff line change
Expand Up @@ -135,4 +135,26 @@ export function getDataElementPosition(source, element) {
};

return findFreePosition(source, element, position, generateGetNextPosition(nextPositionDirection));
}

/**
* Always have the new element in frame
*/
export function getScrollOffset(element, boundingBox) {
var elementTrbl = asTRBL(element);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

cf. above, I'd stick with the current style of multi-variable declaration

var bbTrbl = asTRBL(boundingBox);

// Bigger padding to accommodate the context pad
var paddingRight = 80;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

where do we get this value from?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's the css width of the context-pad (72px) + additional padding

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok got it, thanks for the clarification 👍

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I also discussed it with @philippfromme and we decided to make the padding consistent (80 to all sides) to cover most use-cases

var padding = 10;

var dRight = Math.max(0, elementTrbl.right - bbTrbl.right + paddingRight);
var dLeft = Math.min(0, elementTrbl.left - bbTrbl.left - padding);
var dBottom = Math.max(0, elementTrbl.bottom - bbTrbl.bottom + padding);
var dTop = Math.min(0, elementTrbl.top - bbTrbl.top - padding);

var dx = dRight || dLeft;
var dy = dBottom || dTop;

return { dx: -dx, dy: -dy };
}
68 changes: 68 additions & 0 deletions test/spec/features/auto-place/BpmnAutoPlaceSpec.js
Original file line number Diff line number Diff line change
Expand Up @@ -4,6 +4,7 @@ import {
} from 'test/TestHelper';

import autoPlaceModule from 'lib/features/auto-place';
import { getScrollOffset } from 'lib/features/auto-place/BpmnAutoPlaceUtil';
import coreModule from 'lib/core';
import labelEditingModule from 'lib/features/label-editing';
import modelingModule from 'lib/features/modeling';
Expand Down Expand Up @@ -255,6 +256,73 @@ describe('features/auto-place', function() {

});


describe('scroll handling', function() {

it('scrolls element into view', function() {

// given
var element = { x: 0, y: 0, width: 20, height: 20 };
var viewBox = { x: 100, y: 100, width: 100, height: 100 };

// when
var scrollArguments = getScrollOffset(element, viewBox);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So we are testing the util, but not the actual event handler? Is this intended?


// then
expect(scrollArguments.dx).to.equal(110);
expect(scrollArguments.dy).to.equal(110);

});


it('does not scroll when inside bounds', function() {

// given
var element = { x: 10, y: 10, width: 10, height: 10 };
var viewBox = { x: 0, y: 0, width: 100, height: 100 };

// when
var scrollArguments = getScrollOffset(element, viewBox);

// then
expect(scrollArguments.dx).to.equal(0);
expect(scrollArguments.dy).to.equal(0);

});


it('adds padding', function() {

// given
var element = { x: 0, y: 0, width: 10, height: 10 };
var viewBox = { x: 0, y: 0, width: 100, height: 100 };

// when
var scrollArguments = getScrollOffset(element, viewBox);

// then
expect(scrollArguments.dx).to.equal(10);
expect(scrollArguments.dy).to.equal(10);

});


it('adds more padding on the right', function() {

// given
var element = { x: 90, y: 10, width: 10, height: 10 };
var viewBox = { x: 0, y: 0, width: 100, height: 100 };

// when
var scrollArguments = getScrollOffset(element, viewBox);

// then
expect(scrollArguments.dx).to.equal(-80);

});

});

});


Expand Down