SolidJS Context API

[@M0du5Pwn3n5]

"In this video I will show you how to use context with TypeScript and make all of the errors go away"
"There will be this little error here, but you can just ignore that"

[@NativeNotify]

Lol I guess I should have said in all but one place. Before figuring out everything I used in this video, I was having typescript errors all throughout the app

[@CarloNyte]

😅 thought the same thing. The way to get ride of the props "error" is to create:
interface IGlobalContextProviderProps {
children: JSX.Element;
}
and then rewrite that line to be:
export function GlobalContextProvider(props: IGlobalContextProviderProps) ...

[@brunopanizzi]

Pretty good man! Just as a suggestion, I would prefer if you built the context first then the types, it's easier for beginners to follow if they never seen Accessor and Setter.

[@NativeNotify]

That would have been a better idea. I had never seen the Accessor and Setter before learning SolidJS Context either. If anyone else is reading this comment, know the Accessor and Setter is explained later in the video

[@Antebios]

This is very neat. I'm new to SolidJS and recently built my own method to store login state and info across my app. Is there an example on how to leverage this for user state? Does it work across tabs and sessions? Does it use localStorage?

[@Rundik]

What is the difference between this and just exporting the signals? If you're importing useGlobalContext and then destructuring things you need you might as well just import signals. It seems to be a lot of boilerplate for nothing

[@vmscode]

dependency injection, they explain it better here: ruclips.net/video/E3jYGTB50LE/видео.html&ab_channel=RyanCarniato
as far as I understand now it allows you to limit the scope to a subtree from the main DOM tree. Imagine you have a Canvas component that has children, you want to pass values around within the Canvas and it's children, but you don't want the state to be shared if you create multiple instances of the Canvas component across the app, using the context allows each instance of the Canvas component to have it's own state. (I'm learning it as well so take this with a grain of salt, Ryan and Dan Jutan explain it much better on the video...)

[@gunman479]

This is useful, thanks!

[@Ximaz-]

For anyone trying to deconstruct the props' children, don't. It will break your context and always return "undefined" once useContext is called. You can see such thing in the 713rd discussion in the Solid's Github repository.

[@maker_aleks]

I really do not understand why to wrap with context provider if you can just export/import store or signals across the app 🤔. It would have meaning if we don't need to import useGlobal context on the child component to cut some code, but on another side, it would make it a bit difficult to understand where the getter/setter came from. To make it more clear, all my stores are in separate files, then I just import them where needed. Could some one explain why to use Providers?

[@vmscode]

As far as I understand now, it's the dependency injection pattern, it allows you to limit the scope to a subtree within the main tree of the DOM hierarchy...in this video they talk about it: ruclips.net/video/E3jYGTB50LE/видео.html&ab_channel=RyanCarniato
Imagine you have a Canvas component that has children, you want to pass values around within the Canvas and it's children, but you don't want the state to be shared if you create multiple instances of the Canvas component across the app, using the context allows each instance of the Canvas component to have it's own state. (I'm learning it as well so take this with a grain of salt, Ryan and Dan Jutan explain it much better on the video...)

[@someshharshvardhan2419]

Good work 👍

[@NativeNotify]

Thanks!

[@oluijks]

Types and no non-null assertion...
export const GlobalContextProvider: Component = props => {...}
export const useGlobalContext = () => {
const context = useContext(GlobalContext);
if (!context) {
throw new Error("no context dude!");
}
return context;
};