Elaborating on change events
Closed this issue · 3 comments
Working on #15 and #16 had me thinking about removing .do.check and .do.select altogether.
Since we try to emulate real user behavior, the natural way of interacting with selects and checkboxes/radiobuttons is .do.click (in case of selects it's two clicks: one for select, another one for option). This gives us a benefit of firing all necessary events automatically.
This is also consistent with clicking on buttons and links, since there is no special methods to interact with every possible control or DOM element.
The only reason to keep .do.select is code brevity (two clicks, don't repeat select selector), however, it could be sacrificed for better design.
Are there any objections against removing them?
Seems like selects can't be opened by dispatching the MouseEvent. I need to investigate, closing for now.
Note, we don't need to emulate user everywhere. Only where needed for testing. Some sugar was added because it's convenient, but nobody force you to use it. Probably, it will be enougth to add warnings to docs about emulated events.
OK, selects are not responding to synthetic DOM events. I guess the .do.click won't do the job, then.
In order to achieve the same effect with clicks as the user gets when he interacts with browser it should use PhantomJS sendEvent, but this requires getting mouse coordinates (which is kinda doable, but IMO isn't worth the hassle).