What is the correct architectural design of a Signal Store with many state objects and complex...

Let's say I'm working with something along these lines:



I want to use Signal Stores and signal based code as much as possible.

Store Size


If I have 5 discrete memory structures which I need to store. And one of them happens to be potentially very large (5MB). Is there a good reason to separate out the different objects into individual stores. My gut reaction is yes. At the expense of replicating some boiler plate code, the way in which Signal Store requires mutation of objects and arrays mean that it would be a great idea to separate things out to avoid bottlenecks. I ask this because every example I've seen seems to indicate that the design intent behind Signal Stores is that for a single store... But, it could just be that the examples are overly simplistic by design? Is there any overriding edict that thou shalt have only one signal store?

Architecture


With reference to the rough diagram above, my question is simple, what is the design intent behind Signal Stores? Should the application interface with the store only; inject the services into the store, and then use withMethods to hide service calls away inside the store. And also hook the Local storage up directly to the store, so initial state and all updates etc are reflected. That way every access to the store will be signal based - which is clearly a good thing.

The tutorials and examples I've been working with are pushing me in this direction, but it represents a massive shift away from patterns I've worked with before (where the store is the thing that's hidden away and accessed through the service), so I wanted to check. The team that designed Angular Signals and Signal Store have obviously put an enormous amount of effort into it, so I want to be sure that I'm using it as intended.

Continue reading...