Perform actions on device

[rolfb]

It would be nice to perform gestures, swipes and taps on the device without having to find an element first.

Use case:

• Auth0 login using in-app browser.
• Scroll on device/screen
• Tap approximate location of input field
• typeText when keyboard shows
• submit using typeText?

[LeoNatan]

Do you mean, calling these on the device object itself? I was thinking about that myself recently.

It makes sense on one hand. On the other, these APIs, I feel, encourage bad practices. Understandably, some things cannot be tested with Detox due to technical limitations, and those would greatly help. I fear, however, that people would use those APIs instead of properly using byId() and co.

I guess people cannot be saved from themselves, and the greater benefits of this will outweigh the downsides.

The point to point API is still to come. It's a missing link in many requests.

There is also the question whether Earl Grey, our internal iOS infrastructure, allows for such "decentralized" actions. I am not sure. On Android, I don't even have an idea how that system works. Greater minds will chip-in on that.

[eflath]

My two-cents: I understand the concern that broad, top-level APIs like this could encourage bad practices, but they could also unblock certain potential users who would otherwise not be able to use the detox at all. For example: my app has a bunch of long React Native list views and I need to be able to scroll them. scrollTo() and scroll() are essentially useless in these cases so I pretty much can't use detox at all for this app. If i could just scroll by swiping somewhere on the screen on the other hand...

[LeoNatan]

In what way is Detox useless for list views?

[eflath]

I'm referring to
#103
and #164

some combination of these two issues had made it impossible to scroll list views in my app via detox. After typing this yesterday, though, i tried applying this PR as a patch https://github.com/wix/detox/pull/458/files as suggested in the second thread. That works for me so we're unblocked, but still not an ideal situation.

The broader point being: this is a young and still evolving library so features will be lacking. Providing more generic gesture APIs could help unblock users while a proper version of the requested feature can be designed and built.

Also, a (maybe contrived) example of a UI that would want a general swipe gesture (from point x,y to point x', y') would be a drawing app.

[Nick-Lucas]

Please revisit this. It's hugely painful trying to scroll around when you can't be sure what elements are on screen or whether their scroll-point has fallen off the edge of the screen.

We have a pretty complex form with collapsible sections (hit continue and see the next section) and so we can end up in random scroll positions after a section collapses. Having a robust way to reset to the top or (separate idea from this issue) scroll directly to an element would be very helpful.

[Nick-Lucas]

We found a solution to this problem that should work with any Detox version.

We overlay a non-interactable view over the entire app, which means the app is still usable, but you can match on that view and swipe against it. In our complex forms we can now robustly swipe back to the top and then swipe down slowly, searching for a particular element.

// The overlay
const TestingAppPane = () => (
  <View
    testID="TestingAppPane"
    style={StyleSheet.absoluteFill}
    pointerEvents="none"
  />
)

// Root app render
export default () => (
  <Provider store={store}>
      <AppContainer />

      // IS_TESTING is used just so it doesn't show up in production
      // but it shouldn't cause any problems anyway
      {IS_TESTING && <TestingAppPane />}
  </Provider>
)

[LeoNatan]

This will not be implemented for the time being. If scroll position is uncertain, first that's a big UX problem for you users, and second, you can use the whileElement() to scroll your container scroll view until the target view is visible.