imperative fetching pattern

[seanbruce]

We know that use-query is declarative. It will trigger fetching/re-fetching when a new query instance is mounted(component mounted), query key changed or windows refocused etc. but what if I want a data fetching to happen at a specific time, like when clicking a button. here is what I do currently

function App() {
  const [searchStr, setSearchStr] = useState('');
  const {refetch} = useQuery({
    queryKey: ['some-data', searchStr],
    queryFn: async () => {},
    enabled: false,
    onSuccess(data) {
        // do something with data
    }
  })
  return <div>
    <input value={searchStr} onChange={e => setSearchStr(e.target.value)} />
    <button onClick={() => {refetch()}}>trigger fetching when use click button</button>
}

in the code above, the user can change searchStr freely without sending a new request until the button is clicked.

In our code, the use case above is rare, but it happens from time to time.

how do you guys solve imperative fetching ?

[TkDodo]

i think it's a perfectly valid example for a search form, that, when submitted, should trigger a fetch. The idea is still relatively simple / declarative: only set searchStr when the user submits the form. That means you might need some state-duplication, but it's actually good in this example because it is two different states:

1. the form state that represent the input field values. This is ephemeral client state, local to the form. can also be an uncontrolled input
2. the "applied" filter state - the current value once the user has clicked apply. This is what react-query is interested in. A good place to store this is in the url, because it's globally available, only changes when the user clicks submit, likely re-renders a lot of parts of the screen anyways, and you get sharable urls for free.

here is an example where i'm doing exactly that:

https://codesandbox.io/s/react-query-url-filtering-h0ikw?file=/src/App.tsx

also, your code will create a (disabled) cache entry for every key stroke, likely not what you want :)

[seanbruce]

thanks for the response tk😁.
The pattern you show in the example is basically the same way I am doing with our table search, but yours are better.
I have some table component state setup like this:

interface SearchState {
name: string;
draftName: string;
company: string;
draftCompany: string;
current: number;
pageSize: number
}

change current page and pageSize will trigger re-fetch immediately, but for name and company user can first change the draft version of them, then hit apply button which is used to apply draft to real search params. But I don't put search params on URL, so it's not sharable, I think I will adopt your solution, it's better.

but the pattern I described above is not for solving table search, It's not a good example, let me give another one.
say I have a modal in which I rendered a form. there is a button inside the form that when clicked will let the user input some value, then use the value to fetch some data from the back-end then use the data sent back by that request to set some form value. for me, this use case is an imperative thing.

[TkDodo]

there is a button inside the form that when clicked will let the user input some value, then use the value to fetch some data

so just to get the flow right:

• you click a button, in a dialog
• when the button is clicked, an input field is shown
• user types in that input field
• and when exactly does the fetch start? debounce? onBlur? another button click?

[seanbruce]

sorry for the terrible description.
input and button are placed side by side and fetch starts when clicking the button.

here is the demo:
https://codesandbox.io/s/optimistic-babycat-o3pcld?file=/src/App.tsx

[TkDodo]

okay but this is really the same example as I've shown in my sandbox:

• you have one search input
• when you click the button, you lift that temporary state "up"
• there, the query can pick it up and enable itself

[seanbruce]

yeah, so stupid I am. It's the same pattern😌

[alwyntan]

Hi, I have an additional follow-up question that is related to this. I'm looking to create a more dynamic component that allows for different custom useQuerys' to be passed into the component, and I'm wondering if that is an ok approach, or is there a better alternative.

Use cases are for things like Async Select components and Infinite lists. Eg. When a user types in an input, there's a debounce, the useQuery fires and populates the options. Or, when a user scrolls to the end of an infinite list, the useInfiniteQuery hook fires, and loads in more options.

For example, the setup I've done that works look something like this, but it doesn't feel right passing hooks down as props, as hooks should not be called conditionally:

// useUsers.js

export const fetchUsers = async (filterString) => {
    return (await axios.get('/user', { params: filterString})).data
}

export const useUsers = (filter) =>
    useQuery({
        queryKey: userQueryKeys.users(filter), // [{ scope: 'user', entity: 'list', filter: <filter> }]
        queryFn: (filter) => fetchUsers(filter),
        select: data => data.users,
    })

// Select.jsx

const Select = ({searchQueryHook}) => {
    const [filter, setFilter] = useState('')
    const { data } = searchQueryHook(filter)

    // debounce, inputs, etc that changes the filter when typed

    return <SelectComponent options={data} />
}

export default Select

// CreateEventForm.jsx

import useUsers from './useUsers'
import useEvents from './useEvents'
import useEtc from './useEtc'

const Form = () => {
    return (
        <div>
             <Select searchQueryHook={useUsers} >
             <Select searchQueryHook={useEvents} >
             <Select searchQueryHook={useEtc} >
        <div>
    )
}

export default Form

Is there a way to approach this better? I'm trying to avoid bloating the codebase with custom individual components like UserSelect, EventSelect, EtcSelect that calls the respective hooks in their files. This applies to infinite lists too.

[alwyntan]

I guess I could also export the queryParams and pass the queryParams as a prop instead by having a useQuery(params) in the Select component itself. Is that better?

// useUsers.js
export const fetchUsers = async (filterString) => {
    return (await axios.get('/user', { params: filterString})).data
}

export const useUsersParams = {
    queryKey: userQueryKeys.users(filter), // [{ scope: 'user', entity: 'list', filter: <filter> }]
    queryFn: (filter) => fetchUsers(filter),
    select: data => data.users,
}

export const useUsers = (filter) =>
    useQuery(useUsersParams)

[githorse]

Maybe I'm missing the intent of this question, but useQuery returns an imperative refetch function as part of the result:

const {data, refetch} = useQuery(...)

That's exactly what I was looking for, myself. (Probably an anti-pattern but I needed it for backwards compatibility with some old code.)