-
Notifications
You must be signed in to change notification settings - Fork 276
Closed as not planned
Labels
Description
Describe the Feature
Allow to add custom queries in render call. Similar to RTL API.
Possible Implementations
Option 1 (RTL-like):
- Provide a new
queriesoption torender&withinfunctions as in RTL,. - Since RTL API requires you to import original
queriesif you want to retain them (and you generally want this), so we probably need to provider such export. - Correctly managing TS types might be the most difficult part of the task since we would want
renderandwithinoutput to be typed with the actual queries passed - Implementation might consider changing way we internally export the queries from
bindXxxQueriesto named particular queries, e.g.bindGetByText: (instance) => (text, options) => ReactTestInstanceor event introducing "unbound" queries (getByText: (instance, text, options) => ReactTestInstance) as in Dom Testing Library if that simplifies the exposed API / type management - Following RTL we should also export
makeQueriesinternal utils, so that users need only to preparequeryAllvariant of the query.
Option 2 (roll our own API):
- We could probably simplify the API surface by accepting list of additional queries only in
queryAllByverb and then invokingmakeQueryinternally. - We could automatically forward all built-in queries and only append new queries from the user. That we we would keep the strong typing for built-in queries with potentially more lax typing of user provided queries (more usage
anyfor query predicate / options). - This options seems to have much better trade off between lower increasing code complexity & niche popularity of the feature. However it is not API compatible with RTL.
Option 3 (expose generic query function accepting user predicate):
- We could expose a full set of queries (
get, etc) forByPredicatequery accepting a function(instance: ReactTestInstance) => boolean. - User then could define his own predicates and feed them to our
getByPredicate, etc queries. That would give user total flexibility in types of built queries: number of accepted params, typing, logic, etc - These custom queries would do thing like filtering our composite components for the user, so he can focus on query logic.
- Pros: least increase of code & API surface complexity, proper typing for all queries
- Cons: not compatible with RTL, but seems so good that we can suggest RTL to add it ;-)
- Quick and dirty POC implementation of this option: feat: predicate query #973
Related Issues
- Initial implementation attempt: Adding support for extending with custom queries #573 but the code is stale. Should be easy to re-apply. Some implementation and tests can be salved from that PR
thymikee, MattAgn and voisinhugo