Waht?
Code review request: Optional context Provider pattern
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-usestatecontext8 replies
Code review request: Optional context Provider pattern
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 haha8 replies