peerreynders
peerreynders
SSolidJS
Created by peerreynders on 4/30/2024 in #support
“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
SSolidJS
Created by peerreynders on 4/23/2024 in #support
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:
// file: counter.jsx
import { createSignal, createContext, useContext } from "solid-js";

// **This is a module global**
const CounterContext = createContext();

export function CounterProvider(props) {
const [count, setCount] = createSignal(props.count || 0),
counter = [
count,
{
increment() {
setCount(c => c + 1);
},
decrement() {
setCount(c => c - 1);
}
}
];

return (
<CounterContext.Provider value={counter}>
{props.children}
</CounterContext.Provider>
);
}

export function useCounter() { return useContext(CounterContext); }
// file: counter.jsx
import { createSignal, createContext, useContext } from "solid-js";

// **This is a module global**
const CounterContext = createContext();

export function CounterProvider(props) {
const [count, setCount] = createSignal(props.count || 0),
counter = [
count,
{
increment() {
setCount(c => c + 1);
},
decrement() {
setCount(c => c - 1);
}
}
];

return (
<CounterContext.Provider value={counter}>
{props.children}
</CounterContext.Provider>
);
}

export function useCounter() { return useContext(CounterContext); }
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.localsbut 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 SSR
1 replies
SSolidJS
Created by peerreynders on 4/12/2024 in #support
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