Some questions about the provider

[bigbigDreamer]

When using react-router-dom, multiple routes correspond to multiple Providers. If a key is not added, it will lead to abnormal state behavior, meaning the state will not be cleaned up when the page is unmounted. By adding a key, the state of the Provider will automatically reset when the page is unmounted.

eg:

<BrowserRouter>
    <Route><Provider>{pageChildren}</Provider><Route>
    <Route><Provider>{pageChildren}</Provider><Route>
    <Route><Provider>{pageChildren}</Provider><Route>
<BrowserRouter>

to

<BrowserRouter>
    <Route><Provider key={route.path}>{pageChildren}</Provider><Route>
    <Route><Provider key={route.path}>{pageChildren}</Provider><Route>
    <Route><Provider key={route.path}>{pageChildren}</Provider><Route>
<BrowserRouter>

[bigbigDreamer]

I just have some doubts and haven't thoroughly investigated.

[dai-shi]

Adding key seems the right solution.

[bigbigDreamer]

I will try to reproduce it later.

[bigbigDreamer]

Code SanBox Demo
Hello, @dai-shi, I have successfully reproduced this scenario in CodeSandbox. The /app route has a key added, so every time you navigate into it from the nav and then go back, the atom can reset. The /home route does not have a key added, so every time you navigate into it from the nav and then go back, the atom does not get cleared.

I'm not sure if this is an issue or if there's a problem with my usage. I would like to ask for your help.

[dai-shi]

I assume it's the same behavior as a native React Context.
Jotai Provider is a simple wrapper around React Context. It's only a few lines of code.
So, the question is if react-router-dom works with native React Context without Jotai.

[bigbigDreamer]

I assume it's the same behavior as a native React Context. Jotai Provider is a simple wrapper around React Context. It's only a few lines of code. So, the question is if react-router-dom works with native React Context without Jotai.

Sure, I can confirm this because in the hundreds of projects I've worked on, it's almost always in this form. Let me dive deeper into debugging the state transition behavior.
Thank you for your response. I'll comment here with any updates later.

[bigbigDreamer]

I have added logging for re-renders in the Provider source code (useEffect execution indicates a re-render).

---

1. Without adding a key: The page does not trigger re-renders upon each entry, reusing the App's Provider.
2. With a key added: The page re-renders every time because the different keys bypass React's rendering optimization.

---

When using the same Provider component, it seems that React reuses it.

In other words, the APP Provider manages the internal Provider. Unless a key is added manually, React's rendering mechanism will reuse it.

The above steps are my preliminary investigation into this issue. The accuracy of my conclusions is still uncertain. I hope you can help verify my steps and assumptions.

It seems that your initial response was entirely correct; adding a key is the right choice, especially in scenarios with an APP-level Provider where the Page Provider might only serve as a dynamically added or removed page element.

---

My goal is to isolate:
For an application, the APP Provider manages the global state of the entire application (cleared when the entire site is closed), while the Page Provider manages the page-level state (cleared when the page is unloaded). Further down, there is more granular control, such as at the component level.

[bigbigDreamer]

Thank you again for taking the time to answer my question despite your busy schedule.

[bigbigDreamer]

I can also encapsulate a Provider with a key as a common component for reuse.

import { useRef } from 'react';
import { Provider } from 'jotai' ;
import { nanoId } from 'nanoid';
export default function WrapperProvider({ children, ...props }) {
    const scopeKey = useRef(nanoId(7)).current;
    return <Provider {...props} key={scopeKey}>{children}<Provider>
}

[dai-shi]

Also check out https://github.com/jotaijs/jotai-scope which may or may not be related.

[bigbigDreamer]

It meets the requirements. I took a look, and the core part seems to be dynamically creating context within the function.
It's somewhat like a singleton or multi-instance, but not exactly. Let me take a look, thanks.

It looks like declarative scope collection. I have used recoil before, which automatically collects internally. If it automatically collects the atoms used in child components, is that feasible?

Additionally, it seems that adding a key to the Provider can also achieve this effect. Would there be any side effects?

[dai-shi]

If it automatically collects the atoms used in child components, is that feasible?

I don't know how Recoil works, but Jotai doesn't have such a capability and thus it's not feasible to do something in jotai-scope. But, it might not be completely impossible.

Would there be any side effects?

If adding key works for you, it's much simpler and less error-prune.

[bigbigDreamer]

Get, thank u very much～