Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Epic] Standardizing Position Parameters Across APIs #4470

Open
7 tasks
asafkorem opened this issue Apr 25, 2024 · 0 comments
Open
7 tasks

[Epic] Standardizing Position Parameters Across APIs #4470

asafkorem opened this issue Apr 25, 2024 · 0 comments

Comments

@asafkorem
Copy link
Contributor

asafkorem commented Apr 25, 2024

Motivation

In recent discussions, we have identified inconsistencies in how position parameters are utilized across various APIs (thanks to @d4vidi). Some use element-space coordinates while others use normalized points (values in the [0,1] range).

List of methods and inconsistencies

Method Current Parameter Approach Documentation Link
tap Absolute points for all parameters Link
longPress Absolute points for all parameters GitHub issue (WIP)
longPressAndDrag Normalized points for all parameters Link
swipe Normalized points for all parameters (including offset) Link
scroll Normalized points starting points; absolute points for offset Link
scrollTo Normalized points for all parameters Link
getAttributes Android: pixels for all attributes Link

This inconsistency is confusing and necessitates a reevaluation. Establishing a standard is not straightforward, as there are scenarios where an element might expand its size on different screens (using normalized coordinates), whereas other elements, such as child elements, maintain their absolute size and position (e.g., 15 points from the left).

Suggested Approach

To address this issue, we have decided to unify and standardize the position parameters across all our APIs. The main approach is to support both absolute (e.g., tap({x: number, y: number}) in points) and relative (e.g., tap({normalizedX: number, normalizedY: number}) or percentages in string format, such as tap({x: '53%', y: '50%'})). This flexibility will enable users to choose the most suitable method for their specific use case.

I generally prefer to allow both number and string with percentages on the {x: string | number, y: string | number} params (as suggested by @noomorph), since it can enable more flexibility and allow mixed types (e.g. {x: 150, y: '50%'}.

TODOs

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants