Code review request: Optional context Provider pattern
I'm trying to find a context pattern that works with/without having to wrap context Provider in app tree.
The expected behavior: When there's context Provider in the app tree, consuming component receive states relative to Provider. Otherwise, the states should be scoped locally to the consuming component.
What would you like to suggest the following code. Any cons?
Thank you 🩵
ref: https://discord.com/channels/722131463138705510/1210366012881506304
5 Replies
Looks good 👍
I don't see any cons other than why not just not use context if you know there will be no provider
That way it's more explicit and clear to the reader if it's scoped or not
I agree it's more explicit. However i'm aiming for writing an adapter for solidjs as third party library author. Let's just say a routing library that expose it's reactive states, the adapter is basically just a solidjs hook that sync to the
createSignal. I wanna give the users a choice to use with/without context depends on their performance needs. So with context, router's states are synced with the context, better performance. Without context, every consuming components will try to sync with their own Signals, could result in slow performance and timing issues that came along with, since multiple reactive updates happens in parallel, however yet, this is not a problem if user's app is small and no need for performance, also if they changed their mind later, they could just easily fix that by wrapping the Provider. so hopefully that gives smoother DX to the library user, also they won't know how i coded it anyway hahaMakes sense for the use case
How will the user know if he went the path with worse performance?
timing inconsistencies with every consuming components. especially when using
createEffects. With that being said, using context path will be recommended on the documentation. Here's a React example: https://www.npmjs.com/package/rutter#-react-bindings-via-usestatecontext