Unlike traditional Drag and Drop transformers. DFlex project has promised a more realistic way of DOM transformation effect where elements are not always positioned in one dimension represented in one array vertically or horizontally. But to support two dimensions there are multiple steps that had to be done, one of them is redefining the threshold and adding more accurate position detectors.
The first release of the threshold was depending on two-point that determines the dragged position. One for the top(Y) position and the other for the left(X) position. The definition worked great but had some limitations when it’s expanded for layout and scroll containers. One of the limitations was the ability to add indicators for each direction. Depending on two points was accurate but also hard to develop and debug, especially when scaling to detect out of the parent container. There was something broken with it, it was not standard. The abstract object has four directions. Its threshold and its parent threshold should be defined with four indication flags. That was not the only flaw, there was another one, the question of multiple layouts each one should have its own indicator. If the dragged is out, does it mean it’s out from its position? Or its parent position? And can we know which direction the dragged left? To answer these questions DFlex has to transform to a new API with a brand new threshold design.
The new release has a strict definition of each movement and a special threshold
store connected to each layout. Simply if there’s
isOut: true it’s now
possible to tell from what and in which direction.
The Drag movement has some enhancement mechanism or the common sense of any movement. While it is fluid, if it has an effect then it should be done in order. To detect, let’s say leaving outside the container DFlex depends on the internal index of each element and mouse direction that tells where the dragged is heading. It’s good, but also buggy.
Depending on the mouse movement is tricky. You can tell that the mouse is moving up but really how you can turn the visual detection into a program. What if there’s a sudden change in the movement? What is the acceptable margin of error? And what’s the cost of any potential enhancements? The answer is clear, the solution should not be related to the mouse movement at all.
That can be done with the new threshold. If the indicators are correct, then there’s no need to depend on the movement with all the fatigue it has. Left from the top, means we know accurately where the mouse is heading. Depending on the position is a better solution for the interactive movement.
One of the changes that are related to V3 is releasing under MIT License. The previous GPL License seemed discouraging and confusing to a lot of people. All these changes and new releases will focus on more robust transformation mainly targeting grid containers. Or, not all drag and drop is a simple todo list.