-
Notifications
You must be signed in to change notification settings - Fork 1
Description
At the moment, to define a query we create a multi method and then methods on that:
(defmulti get-by
(fn [by _ & _] by))
(defmethod get-by :test-id [_ selector & [scoped]] (query :getByTestId selector scoped))
(defmethod get-by :text [_ selector & [scoped]] (query :getByText selector scoped))
This is a little cumbersome, so how can we simplify this while preserving the API?
For example, while we could in theory make a macro which is similar to how the new matcher macro works:
(defquery get-by-text "getByText")
it's not ideal because it changes the external API from (get-by :text ...)
to (get-by-text ...)
, so whatever the solution is should keep the current API, while also allowing extensibility, so that users can define their own queries such as (get-by :i18n ...)
.
An additional consideration, which might not necessarily need to be implemented as part of this improvement, is that the way we implement get-by
etc. is a little different than the vanilla testing-library
implementation, such that (get-by :text "hello world")
by default looks for "hello world" on screen
, and can optionally take a container as the second argument:
(get-by :text "hello world" (within (get-by :text "parent")))
But some queries like getByRole
take a large range of options, so should we allow for maybe passing in the container or options as the second argument and then if there are three assume the order is value options container
?
(get-by :role "button" (within (get-by :text "parent")))
(get-by :role "button" #js {:busy: true} (within (get-by :text "parent")))