Selector.oneOf

[rtfeldman]

@avh4 proposed:

some way to write a query that will find the button when given a, and the input when given b:

a = div [] [ button [] [ text "Click me" ] ]
b = div [] [ input [ type_ "button", value "Click me" ] ]

The use case would be writing a reusable function to detect equivalent UI elements—e.g. a fancyButton function that queries for buttons with either the class smallFancyButton or largeFancyButton.

He proposed two potential APIs. One was:

Query.find
    [ Selector.oneOf
        [ [ tag "button", text "Click me" ]
        , [ tag "input", attribute "type" "button", attribute "value" "Click me" ]
        ]
    ]

The other potential API he proposed was:

case Query.toResult <| Query.find [ tag "button", text "Click me" ] of
    Err _ ->
        Query.find [ tag "input", attribute "type" "button", attribute "value" "Click me" ]
    Ok single ->
        single

The oneOf API seems like a good choice to me.

[avh4]

Rather than oneOf, it should probably have a better name to indicate that the first match will be the one that's used.

A downside of the oneOf approach is that we have to define how it would look in error messages (including the case of nested oneOfs). The toResult approach would leave that up to the caller to define how unmatched queries are handled.

[rtfeldman]

Rather than oneOf, it should probably have a better name to indicate that the first match will be the one that's used.

Hm, should that matter? It seems to me that if the test author is relying on that ordering, this function is not the right tool for the job!

[rtfeldman]

A downside of the oneOf approach is that we have to define how it would look in error messages (including the case of nested oneOfs). The toResult approach would leave that up to the caller to define how unmatched queries are handled.

To me, this is a point in favor of oneOf.

The way I see it, if we take the time to make nice error messages for oneOf, we can save many people the time it would take to handcraft their own error messages for toResult on a case-by-case basis. That adds up to a lot of saved time for a lot of people!