testing-library / testing-library/react-testing-library

wrapper context is not shared with `renderHook`

Open
#1,344 4 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
JavaScript
Stars
19.7k
Forks
1.2k
Avg merge
3d 16h
Merged PRs (30d)
1

Description

I have a hook that does some complicated things with state[^1]. Specifically, it works like this:

const [pizza, setPizza] = usePizza()
console.log(pizza)
// { my: { slice: "slice22" }, other: { slice: "slice19" } }

const [slice] = usePizza(pizza => pizza.my.slice)
console.log(slice)
// "slice22"

When the user calls setPizza, a new pizza object gets set globally. But the second instance of the hook usePizza(pizza => pizza.my.slice) does not re-render unless that "slice" of the global pizza object specifically changed. (In other words, if pizza.my.slice returns the same value as before ("slice22"), any component using that hook will not re-render.)

This property of not re-rendering unless necessary is a critical part of the hook. I want to test it. To do that, I need to do something like this:

const wrapper = (
  ... common context here (from Tanstack Query)
)

// for the moment, let's pretend I have methods `.toHaveRenderedOnce` and `.toHaveRenderedTwice`

test('it only re-renders a slice when it changes', () => {
  const {result: fullPizza} = renderHook(() => usePizza(), {wrapper})
  const {result: mySlice} = renderHook(() => usePizza(pizza => pizza.my.slice), {wrapper})
  const {result: otherSlice} = renderHook(() => usePizza(pizza => pizza.other.slice), {wrapper})

  const updatedPizza = { my: { slice: "slice22" }, other: { slice: "slice55" }}
  const [pizza, setPizza] = fullPizza.current
  setPizza(updatedPizza)

  await waitFor(() => {
    expect(fullPizza.current[0]).toEqual(updatedPizza)
  })

  // my slice did not change; it should render once
  await waitFor(() => {
    expect(mySlice.current[0]).toEqual("slice22")
    expect(mySlice).toHaveRenderedOnce() // notional
  })
 
  // other slice changed; it should render twice
  await waitFor(() => {
    expect(otherSlice.current[0]).toEqual("slice55")
    expect(mySlice).toHaveRenderedTwice() // notional
  })
})

There are (at least) two problems here. The first is that there's no way to check how many times the hook rendered, but that's a different problem (for which I may have a rudimentary solution).

The second problem, and the subject of this issue, is that it seems that the wrapper context is not shared between my two hooks. This line does not work:

await waitFor(() => {
  expect(otherSlice.current[0]).toEqual("slice55")
})
// this value is never picked up when I change it in the other hook

So, even though the wrapper itself is the same instance, the two hooks don't seem to be sharing the same React context. I can do this instead:

const {result} = renderHook(() => [
  () => usePizza(),
  () => usePizza(pizza => pizza.my.slice),
  () => usePizza(pizza => pizza.other.slice)
], {wrapper})

This solves the wrapper issue; changes in usePizza() are reflected in the other slice (usePizza(pizza => pizza.other.slice)). But unfortunately now all three instances of the hook are rendered in tandem, so they always all have the same number of renders. I can't verify that usePizza(pizza => pizza.my.slice) doesn't re-render.

I suppose it makes sense that the context is isolated between different calls to renderHook, or we might leak state in between tests. But then how can I test this functionality? Is there a way using this library to test that a change inside one hook instance either does or does not trigger an update/re-render in another related hook instance?

[^1]: Specifically, I'm using Tanstack Query's select data transformation, similar to the idea of useContextSelector.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the renderHook wrapper behavior and the waitFor assertions shown in the issue. Trace how separate renderHook calls mount their wrappers, then compare that with the single renderHook call containing multiple hook functions. Done should establish a supported way to test related hook instances independently, or document the limitation and recommended testing approach.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
frontend, testing
Issue type
Feature
Difficulty
4/5
Estimated time
3-5 days
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.