Open asafkorem opened 1 year ago
Guys I once again feel like stressing that to me it seems like this has good potential in leveling-up the project, that goes beyond introducing a set of sorting API's. With that, I'm referring to taking a subtle step towards semantic/idomatic-detox.
I think that while @vidmantas0010 (who has originally reported this internally - Kudos!) would appreciate a sorting API, he would in fact love to specify a matcher in a much more human-friendly, mental-load-free way, such as by.type('list')
or even by.type('root-list')
(oversimplified suggestions). I think there's an opportunity here, where we could introduce API's that would be less flexibly but potentially much more powerful.
While the latter suggestion could in fact be implemented by us, I do think it would make an abuse of the API. As a more practical suggestion, I think something like this might be closer to an actual API -
by.type('list').filterBy('root');
In any case, this definitely deserves further discussion. Side note: We'd likely be better off using the description+title to specify the problem rather than the solution-implementation specifics.
@noomorph @asafkorem
Describe your idea
At present, there is a lack of consistency between iOS and Android regarding the ordering of elements when matching multiple elements using a single matcher. To address this, we are proposing a feature that introduces new element APIs to define sorting order. For instance:
Alternatively, this could be implemented through typed APIs:
This feature arises from the challenge of distinguishing between multiple elements with similar attributes using standard matchers, without the atIndex(i) method. The inconsistency of indices across platforms often requires multiple attempts to accurately match the target element. By enabling sorting based on size or axis position, either individually or in a combination, matching can be made more explicit.