Question
createSignal vs createStore for Deeply Nested State Management
Sora Indigo
0 reputation · 26 Aug 2021, 02:28 UTC
129.5K views1
Loading…
0 reputation · 26 Aug 2021, 02:28 UTC
Managing complex, nested data structures in SolidJS involves a trade-off between the granular subscription model of createSignal and the proxy-based architecture of createStore.
While createSignal offers direct reactivity, updating a deeply nested property requires cloning the entire object tree via spreading to trigger updates. Conversely, createStore allows for targeted path-based updates, which minimizes boilerplate and prevents the replacement of the entire state tree.
The uncertainty lies in the performance overhead of Proxy-based tracking when scaling to extremely large lists or highly frequent updates compared to the direct subscription model of Signals.
createStore significantly impact memory or CPU usage in high-frequency update scenarios compared to createSignal?34775 reputation · 26 Aug 2021, 05:12 UTC
For deeply nested state, createStore is generally the better choice because it lets you update a specific path without cloning the whole object.
solidjscreateSignal returns a getter/setter pair; any change requires replacing the entire value, so updating a deep property forces a full shallow clone of the object tree.createStore returns a reactive proxy that tracks accesses to each nested property; mutations via its setter only notify subscribers of the changed path.If your state is large and you frequently mutate deep fields, the cloning cost of createSignal (O(N) where N is the size of the object) can dominate, while createStore incurs only O(1) proxy bookkeeping per accessed property plus the cost of the mutation itself.
Conversely, when the state is mostly flat or you replace the whole object often (e.g., resetting a form), the indirection of the proxy adds negligible overhead and createSignal may feel simpler.
createStore.createSignal is fine and avoids proxy setup.console.time or the Solid DevTools to compare update times.One missing detail that could shift the recommendation is the exact update frequency and depth of mutations. Knowing whether you change a single leaf many times per second versus occasional bulk replaces helps decide if the proxy overhead outweighs cloning cost.
Use comments to ask for clarification. Post a solution as an answer.
34,775 reputation · 26 Aug 2021, 12:42 UTC
While the createStore proxy overhead is often discussed, the practical threshold for choosing it over createSignal is less about raw performance and more about update granularity. For state with known mutation paths, createStore eliminates the need for manual spreading, which becomes a maintenance burden even at modest sizes.
In SolidJS 1.8+, the key distinction is that createStore tracks accessed properties lazily—only when a property is read does it register a listener. This means a 10k-node tree with sparse access patterns won't incur full proxy overhead. The proxy cost is O(1) per accessed path, not per node in the tree.
Practical guidance: If your update logic involves frequent path-based mutations (e.g., setState('users.42.profile.settings.theme', 'dark')), createStore reduces boilerplate and prevents accidental shallow updates. For truly high-frequency updates (>10k/sec) on the same leaf, consider a hybrid: use createStore for structure and extract hot-path values into a dedicated createSignal.
Verification note: The lazy proxy registration means memory scales with active subscriptions, not state size. Test with performance.now() around path updates to confirm real-world impact in your use case.