proivder with root_scope

[huang12zheng]

1. provide_context(cx, set_toggled) is not required.
2. There is a RootScope
   if use_context::<WriteSignal<bool>>(cx) is None, one is created in RootScope
   otherwise, return the existing one in ancestor.
3. it can initialize the state(such as signal) outside of component.
   Of course, instead of returning a value directly, it is a closure with runtime/context

Because of my low level, I was just an idea, and I felt like I didn't have a clue about the implementation.
Though I always wanted to make it happen

[gbj]

Hmmm.... This is an interesting idea. It would certainly solve the issue of panicking if you forget to provide the context.

However, overall I think it makes the flow of programs harder to reason about, because sibling components — or even "third cousin once-removed" cousins — gain the ability to provide context to one another.

Imagine some silly tree like the below:

RootComponent
|_ HomePage
  |_ Settings
    |_ UserSettings
      |_ use_context::<Signal<String>>()
  |_ BlogPost
    |_ Comments
      |_ EditComment
        |_ use_context::<Signal<String>>()

To me, the idea that these will implicitly be the same signal is troubling. And the fact that the behavior if you reorder the components is also troubling.

This would also limit use_context to T: Default, which does not include signals, or some DefaultWithContext that users would have to additionally implement, in order to create an object to stash in the context in the "didn't find it" case.

[huang12zheng]

This would also limit use_context to T: Default
I mentioned in point three, it's a closure. |cx| create_signal(false);

Of course, your mention of Default that makes me think about:
closures may not be necessary, and thank you for that.

the idea that these will implicitly be the same signal is troubling
This is indeed from:
If there is no provider, panic occurs
Go to:
If you want something different, you need a new provider.

The most obvious is that each item in a List should be wrapper a ProvidedScope and call closures. It make no longer access the upper level scope, and avoid using the default in root.

I often find myself placing state in the page or even at the root level.
This makes the code in the page grow significantly.
This is where my third point comes in. I want to move the state outside of the component and create it using closures or, as you mentioned, the Default.
Then, I can use multiple providers to communicate to the underlying components, saying, "Hey, here's the state you need."

At this point, I end up needing multiple providers, which can be tedious and frustrating. So I've been wondering, why can't I just directly access them? As long as it's not an instance and it's a provider, I should be able to use it