How should it work in the end, can you please provide with examples?

@mgrybyk

@christian-bromann and I had a conversation about how to approach this. Essentially this is what we came up with.

The user will have to register a locator somewhere in their tests like so

browser.addLocatorStrategy(name: string, callback: (args: any[]) => HTMLElement))

When they want to use this strategy, they can call it as such:

browser.custom$(name: string, strategyArgs: any[]) => WDIOElement | WDIOElement[]

Any suggestions / concerns let me know.

Codecov Report

Merging #4603 into master will increase coverage by <.01%.
The diff coverage is 100%.

@@            Coverage Diff             @@
##           master    #4603      +/-   ##
==========================================
+ Coverage   99.39%   99.39%   +<.01%     
==========================================
  Files         203      207       +4     
  Lines        5251     5301      +50     
  Branches     1128     1145      +17     
==========================================
+ Hits         5219     5269      +50     
  Misses         29       29              
  Partials        3        3

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update a7e6a99...f56c46c. Read the comment docs.

@baruchvlz , I think might be better to create two methods:

browser.custom$(name: string, strategyArgs: any[]) => WDIOElement
browser.custom$$(name: string, strategyArgs: any[]) => WDIOElement[]

in such case it would be convenient to work with types and be predictable what you expect to get.
What do you think?

@CrispusDH Yea that makes sense, I'll add the commands.

@CrispusDH
Sorry, on second thought, having both custom$ and custom$$ might be confusing since you have to add the strategies before you use them. It would be better to consider renaming the command to something more explicit likeuseLocatorStrategy, this way its easier to understand while writing tests, and we always return one element since it depends on the script passed by the user.

Alternatively, we could add an extra flag to the command for selecting multiple elements.

useLocatorStrategy<T = any>(name: string, strategyArgument: T, multiple: boolean) => WDIOElement | WDIOElement[]

Adding a dynamic type will allow the user to pass multiple arguments to their script if they require extra logic.

I think useLocatorStrategy is a good name and its intuitive since the user will attach strategies via browser.addLocatorStrategy.

on second thought, having both custom$ and custom$$ might be confusing since you have to add the strategies before you use them.

In what way is this confusing?

It would be better to consider renaming the command to something more explicit like useLocatorStrategy

My concern is that it is not aligned with other command names such as react$/$$ or shadow$/$$

and we always return one element since it depends on the script passed by the user.

This is not ensured by the user script. If for whatever reason the script fetches multiple elements, multiple elements will be returned.

There is no real difference between custom$/$$ and useLocatorStrategy and you have a good point on keeping the methods consistent. I'll add the methods to both browser and element objects.

@baruchvlz can you rebase?