https://github.com/henriqueinonhe/use-debug-concurrent
A hook to debug React concurrent features. Attach callbacks to high and low priority renders.
https://github.com/henriqueinonhe/use-debug-concurrent
concurrent concurrent-mode debug hook react usedeferredvalue usetransition
Last synced: 8 days ago
JSON representation
A hook to debug React concurrent features. Attach callbacks to high and low priority renders.
- Host: GitHub
- URL: https://github.com/henriqueinonhe/use-debug-concurrent
- Owner: henriqueinonhe
- License: mit
- Created: 2023-09-03T19:27:47.000Z (almost 3 years ago)
- Default Branch: main
- Last Pushed: 2023-09-03T20:24:52.000Z (almost 3 years ago)
- Last Synced: 2025-07-30T11:38:44.128Z (11 months ago)
- Topics: concurrent, concurrent-mode, debug, hook, react, usedeferredvalue, usetransition
- Language: TypeScript
- Homepage:
- Size: 22.5 KB
- Stars: 0
- Watchers: 1
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
- License: LICENSE
Awesome Lists containing this project
README
# Use Debug Concurrent
A hook that helps you debug React concurrent features like `useTransition` a `useDeferredValue` by _hooking into_ (no pun intended) concurrent rendering lifecycles, i.e. high priority and low priority render phases.
Debugging components that use concurrent rendering is tricky because they render (at least) twice, once due to the high priority update and another due to the low priority one and they may render even more times before comitting if low priority renders are interrupted.
This can make things very confusing when we want to inspect (e.g. log to console) values during render, especially because some values will differ between high and low priority renders.
With this hook, you can pass callbacks that will only run in a specific render phase, so you can easily inspect values and debug your components.
If you want to dive deeper into concurrent rendering or how this hook works, check [this article](https://blog.codeminer42.com/everything-you-need-to-know-about-concurrent-react-with-a-little-bit-of-suspense/#debugging-concurrent-rendering).
You can check a live demo here: https://stackblitz.com/edit/react-wzwn93
## Installation
```sh
npm install use-debug-concurrent
```
Types are already included.
## Usage
```jsx
import { useDebugConcurrent } from "use-debug-concurrent";
export default function App() {
// This state will be updated by
// HIGH priority updates
const [filter, setFilter] = useState("");
// This state will be updated by
// LOW priority updates
const [delayedFilter, setDelayedFilter] = useState("");
const [isPending, startTransition] = useTransition();
useDebugConcurrent({
onFirstRenderStart: () => console.log("First render started"),
onFirstRenderEnd: () => console.log("First render ended"),
onHighPriorityStart: () => console.log("High priority render started"),
onHighPriorityEnd: () => console.log("High priority render ended"),
onLowPriorityStart: () => console.log("Low priority render started"),
onLowPriorityEnd: () => console.log("Low priority render ended"),
});
return (
{
setFilter(e.target.value);
startTransition(() => {
// Here we're triggering the low
// priority update that will
// change `delayedFilter`'s value
setDelayedFilter(e.target.value);
});
}}
/>
);
}
const List = memo(({ filter }) => {
const filteredList = list.filter((entry) =>
entry.name.toLowerCase().includes(filter.toLowerCase()),
);
return (
-
{item.name} - ${item.price}
{filteredList.map((item) => (
))}
);
});
```
## Caveats
### First renders are ambiguous in terms of priority
When the component renders for the first time, we cannot know whether that render is a high priority or low priority render just by looking at the component itself, we would need to understand what **triggered** the render in the first place, which comes from higher up in the component tree.
For instance, a component could be conditionally rendered by a parent component, and that parent component could be re-rendered by either a high priority or low priority update, which would make the child component's first render have the same priority as the parent's.
This is why we have two callbacks for first renders, `onFirstRenderStart` and `onFirstRenderEnd`.