t/98: Extracted rect position utility from BalloonPanelView.

[oleq]

Requires #130.
Requires ckeditor/ckeditor5-utils#106.

Closes #98.

[oleq]

Or maybe we should move BalloonPanelView#limiter back to the argument of attachTo?

[Reinmar]

It depends on whether you'll be changing object to which the balloon is attached and the limiter. I think they go in pairs, so setting both at once makes more sense to me. If you'll decide to leave it separately then on the limiter change the balloon should reposition it self, of course. But that would also leave it unclear why the anchor is set through attachTo() and limitter through a setter.

[oleq]

More in https://github.com/ckeditor/ckeditor5-ui-default/pull/134/files#r90674230.

[oleq]

Prototyping contextual toolbar I already learned that this is not the best way of configuration.

1. First of all, a contextual toolbar must bring 3 new positions to BalloonPanelView.defaultPositions without affecting the prototype of the entire class. this.positions should rather contain actual functions than strings or BalloonPanelView.defaultPositions should become this.defaultPositions.
2. Secondly, it turned out that positions may change a lot with each attachTo, like this

editor.listenTo( viewDocument, 'click', () => {
	if ( viewDocument.selection.isCollapsed ) {
		balloonPanelView.positions = [ 's' ];
	} else {
		balloonPanelView.positions =  [
			viewDocument.selection.isBackward ? 'backwardSelection' : 'forwardSelection'
		];
	}

	balloonPanelView.attachTo( viewDocument.domConverter.viewRangeToDom( viewDocument.selection.getFirstRange() ) );
} );

so probably attachTo should accept options object which would be merged with some default options, like

balloonPanelView.attachTo( {
	target: viewDocument.domConverter.viewRangeToDom( viewDocument.selection.getFirstRange() ),
	positions: [
		viewDocument.selection.isBackward ? 'backwardSelection' : 'forwardSelection'
	]
} );

mimicking getOptimalPosition API.

[Reinmar]

Please don't use import *. That may (although, shouldn't) deoptimise tree shaking and it's unsafe because it cannot be well transpiled AFAIR (the module consumer has no knowledge about its content). I've just checked that we get this:

define(['exports', '../view.js', '../template.js', '../../utils/dom/position.js', '../../utils/dom/tounit.js'], function (exports, _view, _template, _position, _tounit) {
	'use strict';

	Object.defineProperty(exports, "__esModule", {
		value: true
	});

	var _view2 = _interopRequireDefault(_view);

	var _template2 = _interopRequireDefault(_template);

	var _tounit2 = _interopRequireDefault(_tounit);

	function _interopRequireDefault(obj) {
		/* istanbul ignore next */
		return obj && obj.__esModule ? obj : {
			default: obj
		};
	}

The position doesn't go through interop. But perhaps it's not a big deal...

[Reinmar]

Bleh, I've just noticed that these are tests :D So ignore my comment, please.

[oleq]

You're welcome! ;-)