peerreynders
“Push synchronization to the edge of the reactive graph”
TL;DR: Is this a thing?
In the Clojure community there was a saying:
“Push your impure functions to the edge of the system”
Working with
cache
and createAsync
I'm moving towards
“Push synchronization to the edge of the reactive graph”
- have a synchronization area where the up-to-date data exists.
- have external events update the synchronization data and then force revalidate the cache
points depending on that data.
- share the cache
points via context (rather than a reactive value).
- In the component mount createAsync
or createAsyncStore
(with the appropriate reconcile
options) on the cache
point to get the reactive behaviour.
Is this a thing or am I seeing things?
One benefit seems to be that stores get a lot easier to deal with as you just update the synchronization data wholesale and leave the grunt work to reconcile
.
Also you can have multiple cache
points depending on different parts of the same data.1 replies
Practice of handling application globals in Solid(Start) symmetrically across client and server?
Example: In the CSR-only days it was idiomatic to store context value as a module-global value:
In SolidStart's SSR processing modules are reused across multiple concurrent requests so that
In SolidStart's SSR processing modules are reused across multiple concurrent requests so that
CounterContext
module global gets constantly overwritten (last one wins).
Now this can be mitigated through use of isServer
and getRequestEvent.locals
but it seems an approach with client/server symmetry would be beneficial.
Seems the Svelte community had a discussion about this two years ago
Safe SvelteKit Stores for SSR1 replies
Is it possible for all requests and actions to share a server side (singleton) module in memory?
In the process of updating my Chat with SSE using SolidStart example from 0.2.26 to 1.0.0-rc.0 I've hit a snag.
All the responses (subscriptions) from the SSE endpoint (
api/messages
) share one copy of the server's pub-sub
module, while all the send-message
actions go to a separate copy of that module (which of course doesn't have any subscriptions registered).
I've tried routing the imports through src/entry-server.ts
in case that might coerce the use of one common instantiation (it didn't), and doubled down by using unjs/hookable
(perhaps improperly) there, again without success.
At this point I'll probably start looking at BroadcastChannel based workarounds or even re-imagining the server side pub-sub
solution around it.
Is there some simple solution I'm overlooking that would allow the (server) actions and streaming responses to easily gain function call access to the same in-memory pub-sub
management instance?
Thank You for your time!5 replies