wrapper context is not shared with `renderHook`
@Lucatonello đang làm issue này rồi.
Từ ngày 2/12/2024.
Đánh giá
- Độ khó
- 4/5
- Thời gian dự kiến
- 3-5 ngày
- Mức phù hợp với người mới
- 35/100
- Loại issue
- Tính năng
- Độ rõ ràng
- Khá rõ ràng
- Mức độ hoạt động
- Đình trệ
- Công nghệ
- javascript, react
Hướng nghiên cứu
Bắt đầu với hành vi của wrapper renderHook và các assertion waitFor được nêu trong issue. Theo dõi cách các lời gọi renderHook riêng biệt mount các wrapper của chúng, sau đó so sánh với một lời gọi renderHook duy nhất chứa nhiều hàm hook. Khi hoàn tất, cần thiết lập một cách được hỗ trợ để kiểm thử độc lập các instance hook có liên quan, hoặc ghi lại giới hạn và phương pháp kiểm thử được khuyến nghị.
Do mô hình lập chỉ mục viết ra từ nội dung của issue.
Mô tả
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.
- Ngôn ngữ chính
- JavaScript
- Star
- 19.7k
- Fork
- 1.2k
- Chỉ số merge pull request
- Không có pull request nào được merge trong 30 ngày
Chuẩn bị môi trường
- Không có Dockerfile hay tệp Docker Compose
- Có mẫu pull request
- Đọc hướng dẫn đóng góp
Bắt đầu từ đâu
- Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
- Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
- Fork repository và làm thay đổi trên một nhánh.
- Mở pull request có tham chiếu số hiệu của issue.
Issue khác của testing-library/react-testing-library
-
fireEvent.select does not wrap its automatic native focus in actCó thể đã có người làm @sergioperezcheco đã nhận 2 ngày trước. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 88/100
-
bug: calling configure() without reactStrictMode resets it to undefined, silently disabling strict modeCó thể làm lại được @suhailopensource đã nhận 72 ngày trước và không có pull request nào đang mở. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 35/100
testing-library/react-testing-library#1466 · 1 bình luận ·
-
Độ khó 4/5 3-5 ngày Mức phù hợp với người mới 30/100
testing-library/react-testing-library#1459 · 2 bình luận ·
-
perf: optimize container lookup with early exitCó thể làm lại được @Ch-Abhinav-Chowdary đã nhận 298 ngày trước và không có pull request nào đang mở. Đang mở
Độ khó 1/5 Dưới một giờ Mức phù hợp với người mới 35/100
testing-library/react-testing-library#1430 · 1 bình luận ·
-
`fireEvent.mouseEnter` does not forward `relatedTarget` (relatedTarget is the window instead)Có thể đã có người làm @swarnim02 đã nhận 316 ngày trước. Đang mở
Độ khó 3/5 1-2 ngày Mức phù hợp với người mới 55/100
Tất cả issue của testing-library/react-testing-library
Issue tương tự
-
[Bug]: [MCP/CLI] Bare loopback IP addresses (127.0.0.1:port) and hosts with ports fail to navigate due to erroneous scheme inferenceCó thể đã có người làm @alok-108 đã nhận hôm nay. Đang mở
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 78/100
microsoft/playwright#43263 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
bug traffic
Độ khó 2/5 Dưới một giờ Mức phù hợp với người mới 74/100
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 65/100
processing/p5.sound.js#123 ·
-
Độ khó 1/5 1-3 giờ Mức phù hợp với người mới 82/100
PhilflowIO/dav-mcp#146 ·
Maintainer thường phản hồi trong vòng 1 ngày
-
Độ khó 2/5 1-3 giờ Mức phù hợp với người mới 70/100
career-ops-hq/career-ops#4910 · 2 bình luận ·
Maintainer thường phản hồi trong vòng 2 ngày