Cache a list of results under multiple keys?

[jennings]

I'm trying to decide on the best way to share cached data between two different queries, or if I'm going about this all wrong. Below is a description of the problem and the solution I'm considering, is this insane? Is there a better way to do this? I currently use SWR, but would gladly switch to React Query if it can solve this in a nicer way.

The problem

For the purpose of this question, our app is a file viewer. The user can view a list of files either by directory listing or by executing a search. Then, they can open a file in a viewer component. The queries return a list of files, and we use react-dnd to let the user drag and drop the file object onto the viewer component (DropTarget):

// The list of files can come from either component, meaning the list is cached under different keys:
function DirectoryListing(props) {
  const { data } = useQuery(["directory", props.id], fetchDirectory);
  return <>{data.map(file => <File file={file} />)}</>
}
function SearchResults(props) {
  const { data } = useQuery(["search", props.query], fetchSearch);
  return <>{data.map(file => <File file={file} />)}</>
}

// The File component is a drag source, sending the `file` in the payload
function File(props) {
  useDrag({ item: { type: "FILE", file: props.file } })
  // ...
}

// The drop target receives the `file` in the payload
function DropTarget() {
  useDrop({
    accept: ["FILE"],
    drop: (item) =>doSomething(item.file)
  })
}

However, there are Reasons™ that I'd like to stop sending the whole file in the drag object, and instead just send the file's ID. Then, the drop target would look up the item in the cache:

function DropTarget() {
  useDrop({
    accept: ["FILE"],
    drop: (item) =>{
      let file = queryClient.getQueryData( ??? )
      doSomething(file)
    }
  })
}

I know the docs suggest doing something like queryClient.getQueryData('todos')?.find(d => d.id === todoId), but I don't know the exact query key that was used. The query key used to display the list is different depending on whether I came from DirectoryListing or SearchResults. So, I don't know what would replace the "???" above.

My possible solution

I could also cache files under a key ["file", id]. I thought about setting this in the onSuccess handler:

function DirectoryListing(props) {
  const { data } = useQuery(["directory", props.id], fetchDirectory, {
    onSuccess: (data) => {
      for (const file of data) {
        queryClient.setQueryData(["file", file.id], file);
      }
    }
  });
}

Then I can queryClient.getQueryData(["file", id]) in the drop target.

So, that's the gist of my scenario, is this a reasonable solution? It feels like something I might regret later.

Additional information

Why can't you pass the whole file object?

This is a simplified description of our app. Once a file is dropped onto the DropTarget, the user can then copy the file from the DropTarget into a third area, let's call it the "Workspace".

The problem is that file might have been updated by the DirectoryListing. I'd like the latest copy of file to be used in Workspace. And Workspace isn't really structured in a way that makes it possible to call useQuery(["file", id]) there.

[TkDodo]

could you forward where you are coming from to the File component, like:

function DirectoryListing(props) {
  const { data } = useQuery(["directory", props.id], fetchDirectory);
  return <>{data.map(file => <File file={file} queryKey={["directory", props.id]} />)}</>
}
function SearchResults(props) {
  const { data } = useQuery(["search", props.query], fetchSearch);
  return <>{data.map(file => <File file={file} queryKey={["search", props.query]} />)}</>
}

Then the File component would know where to do the lookup and could forward that to useDrag. If prop drilling is not your thing, putting the current client state into a global client state manager or context would also allow the File component to just inject where it currently is.

[jennings]

This is an interesting way to do it. Passing the query key around makes me feel weird inside, but honestly it doesn't add any more coupling between DirectoryListing/SearchResults and the DropTarget than my proposal.

I forgot that DirectoryListing/SearchResults are actually paginated and I would use useInfiniteQuery, but it's probably not too difficult to hunt through the result set.

Thank you for your suggestion.