This PR introduces modes of "verification" for interaction commands.
elementAtPath: if this exact node is not visible or attached to the dom, this mode will re-lookup the element at the given jsPath to click on any refreshed node instead.
exactElement: will verify that the exact node is visible in the dom, can be clicked, and IS clicked
none: will lookup the element position once (or use an existing getComputedVisibility or getBoundingClientRect) and scroll/mouse/click on that location. No verification is performed.
NOTE: in the course of creating this mode, the relationship between Interactor and plugins was changed slightly. The "Interactor" does far less logic now. It is more of a simple lookup and coordinates move/click module. The one part of the new structure I couldn't quite resolve in this PR is that verification is "driven" by the plugin. It seems like that should be the responsibility of the Core library, not the plugins. At the moment, plugins decide how and what they will do for verification.
This PR introduces modes of "verification" for interaction commands.
elementAtPath: if this exact node is not visible or attached to the dom, this mode will re-lookup the element at the given jsPath to click on any refreshed node instead.exactElement: will verify that the exact node is visible in the dom, can be clicked, and IS clickednone: will lookup the element position once (or use an existing getComputedVisibility or getBoundingClientRect) and scroll/mouse/click on that location. No verification is performed.NOTE: in the course of creating this mode, the relationship between Interactor and plugins was changed slightly. The "Interactor" does far less logic now. It is more of a simple lookup and coordinates move/click module. The one part of the new structure I couldn't quite resolve in this PR is that verification is "driven" by the plugin. It seems like that should be the responsibility of the Core library, not the plugins. At the moment, plugins decide how and what they will do for verification.