The library is good and I love what you have done. An additional option could be to allow an X and Y point relative to the element that should be clicked instead of calculating the point randomly.
This would help when
more control on the exact click point is required
implementing a custom random point selection method
performing additional checks on a selected point before the click is done
For example, this would allow checking if the point that will be clicked is indeed the element that must be clicked, is active and not occluded by some other elements; thereby making the action predictable. This would also solve/provide a robust alternative for Issue #120 #109 where users can implement their own method to select the point.
So the MoveOptions interface can include
{
/** X and Y points relative to the top-left corner of the element */
clickDestination: {X: number, Y: number}
}
The library is good and I love what you have done. An additional option could be to allow an X and Y point relative to the element that should be clicked instead of calculating the point randomly.
This would help when
For example, this would allow checking if the point that will be clicked is indeed the element that must be clicked, is active and not occluded by some other elements; thereby making the action predictable. This would also solve/provide a robust alternative for Issue #120 #109 where users can implement their own method to select the point.
So the MoveOptions interface can include
and the destination calculation would be
If you approve, I can submit a pull request.