wrapper context is not shared with `renderHook`
@Lucatonello ci sta già lavorando.
Dal 2/12/2024.
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 35/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Ferma
- Stack tecnologico
- javascript, react
Direzione di ricerca
Inizia dal comportamento del wrapper di renderHook e dalle asserzioni waitFor mostrate nell'issue. Traccia il modo in cui chiamate renderHook separate montano i rispettivi wrapper, quindi confrontalo con una singola chiamata renderHook contenente più funzioni hook. L'implementazione dovrebbe stabilire un modo supportato per testare in modo indipendente istanze di hook correlate, oppure documentare la limitazione e l'approccio di test consigliato.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
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.
- Lingua principale
- JavaScript
- Stelle
- 19.7k
- Fork
- 1.2k
- Metriche di merge delle PR
- Nessuna PR unita negli ultimi 30g
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di testing-library/react-testing-library
-
fireEvent.select does not wrap its automatic native focus in actForse già presa @sergioperezcheco l’ha presa 4 giorni fa. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
-
bug: calling configure() without reactStrictMode resets it to undefined, silently disabling strict modeForse di nuovo libera @suhailopensource l’ha presa 74 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
testing-library/react-testing-library#1466 · 1 commento ·
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
testing-library/react-testing-library#1459 · 2 commenti ·
-
perf: optimize container lookup with early exitForse di nuovo libera @Ch-Abhinav-Chowdary l’ha presa 300 giorni fa e non c’è nessuna pull request aperta. Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 35/100
testing-library/react-testing-library#1430 · 1 commento ·
-
`fireEvent.mouseEnter` does not forward `relatedTarget` (relatedTarget is the window instead)Forse già presa @swarnim02 l’ha presa 318 giorni fa. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 55/100
Tutte le issue di testing-library/react-testing-library
Issue simili
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
XRPLF/xrpl-dev-portal#4000 ·
I maintainer di solito rispondono entro 1 giorno
-
accessibility good first issue
Difficoltà 1/5 1-3 ore Idoneità per principianti 92/100
I maintainer di solito rispondono entro 1 giorno
-
[BUG] Bubble chart series name is not XML-escaped in the embedded workbook (xl/tables/table1.xml)Aperta
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 94/100
-
Content:Learn needs triage
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
I maintainer di solito rispondono entro 1 giorno
-
enhancement good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
anoopcodehack/DevBoard#609 ·
I maintainer di solito rispondono entro 1 giorno