flakiness casued by atIndex

[OisinOKeeffe]

Description

When using atIndex(0) on a list of items in iOS the element being returned is the last item in the list not the first. Without knowing the exact number of items in the list it then becomes difficult to match the first item.

Any action you try and perform on this action you need to first ensure that it is visible before that action is performable. Similarly you may want to confirm that not only does the first item in the list exist but also that it is visible without scrolling.

This functionality may be by design, I don't know, but if it is there shouldn't there be a manner to access the first element? I'm loving using detox but this particular issue is causing me some flakiness. I poked around in the ios expect.js file and ran a few tests to see if there was some undocumented way to access the number of matched elements but I wasnt able to find anything.

To be clear, I think a case can be made for it returning either the first or the last (inverted lists) what the ask here is that you can specify which one OR minimally reverse the array of elements if needed.

I apologize if there is already some super easy way to do this that I have missed but I've scoured SO, issues and repository code for clues and came up empty.

Steps to Reproduce

I think description above is enough

Detox, Node, Device, Xcode and macOS Versions

Detox: v7
Node: 8.9.1
Device: any iOS device (didnt confirm functionality on android)
Xcode: 9.2
macOS: 10.13.2

[LeoNatan]

We could say this API is "broken by design" because the system decides the order by how subviews are positioned in the hierarchy. An "array of items" from you is translated to native views by RN internal and the system maintains these views in a hierarchy. When detox runs, it can (and will) only inspect the native hierarchy. When you specify atIndex, the underlying systems gets an array of subviews and applies this index to that array. But there are no assurances that the view order will match in any way the logical input order (and indeed, often doesn't).

You can get a feel how "broken by design" the API is by the fact that iOS and Android produce completely different results.

What are you attempting to achieve? Could it not be achieved by using testID?