why-did-you-render VS use-context-selector

Check out why-did-you-render. It may tell you some more information.

It's a combination of many things, but imo one of the worst is all the footguns regarding state and the rerenders they cause

https://emnudge.dev/blog/react-hostage

It's so easy, that we monkey patch react to debug it https://github.com/welldone-software/why-did-you-render

Plus the vdom... Isn't great, the bundle size puts react at an inherit disadvantage, and the community has a knack for over reliance on bloated packages

When we implemented the MVP of the fintech app, we had a quite complicated form. At that time, I was still young and inexperienced. And eventually, we realized that our project was slowing down. We had to spend additional hours figuring out the reason. We had many unnecessary re-renders because we ignored basic rules related to props in React. I wanted to do everything possible to avoid such situations in the future. So, I added to the project linters like this and an additional starting configuration to package.json to run why-did-you-render. In short, this plugin issues a warning if something is re-rendered unnecessarily and suggests how to avoid it. Also, we included running Lighthouse in headless mode. Some people say that premature optimizations are bad, but for me, it's a principle: do it right from the start.

maybe somethin like https://github.com/welldone-software/why-did-you-render

This might help you out a bit.

Use jotai, or as someone else mentioned, zustand. React Context out of the box requires a very deliberate mental model due to a lack of tooling around selecting slices of state. This is why packages like react-context-selector exist: https://github.com/dai-shi/use-context-selector

Unless I've missed it, context doesn't have selector IIRC. You'd have to use a third party solution useContextSelector

How does this differ from https://github.com/dai-shi/use-context-selector?

you can always split out context state or use a library to help with rerender issues like https://github.com/dai-shi/use-context-selector, or just switch to jotai or something else if you want something more ergonomic or better design patterns.

If you don't want to swap out useContext, you could always use useContextSelector, which helps you limit what props in the context should rerender the component.

I wouldn't call this easy

It wouldn't be clear to anyone learning Context API either. At least, not using official docs. Because Context API is not supposed for state management, and if you for some unknown reasons try to roll your own state management on top of it, you have to use tricky libraries to work around the issues resulting from such abuse.

Any time anything in the context changes, any component that is consuming it will re-render. If you use it for frequently changed values, this library is needed to reduce unnecessary re-renders.

Use of this implementation of useContextSelector

Another technology I use regularly is Redux. But this time I wanted to manage the global state in a simpler and clearer way just using React hooks. I decided to go with a simple useReducer combined with theuseContextSelector hook which will avoid the whole application’s re-render caused by the native useContext hook.