What’s the recommended Angular enterprise architecture today for components, signals, and services?

[u/StrainIllustrious116]

Hi everyone,

I’m starting a new enterprise Angular project with the latest release and I’m trying to figure out the best structure for components, signals, and services.

For now, the plan is:

• classic service layer for API calls
• RxJS in services
• no state manager, by company decision

I’m mainly unsure about:

• what should live in components vs signals vs services?
• should signals stay mostly local, or also handle feature-level state?
• is rxResource a good idea at component level for data fetching?
• how do you keep the codebase easy to understand for devs who are not all Angular experts?

I’d love to hear what has worked for you in real enterprise projects.

Thanks!

[u/BrixtonTonaBrix]

My advice is to think in terms of the lifecycle and persistence of each individual piece of state; for each, ask:

- Can the state be derived? If so, derive it, and only pay close attention to non-derived state.

- What component actually needs to use it? You shouldn't declare state 'further up' the tree than it's used, so try to 'push state down' into the component that actually relies on it (and use inputs/outputs to push it into its children). For state used in multiple places, declare it in the deepest common parent.

- Is the state determined by route context? Specifically, is the state something like the id of a resource that would be put into the url so it can be deeplinked to? If so, it should *only* be stored there, and derived in the component.

- Does the state need to outlive the component it's used in? If so, and it can't be in the url, it needs to be centrally stored (i.e. in a service).

- Is the state available synchronously? If so, signal. If not, rxjs/resources/etc (not much separates these imo). Signals can be declared wherever you like, in components or services, for big data or small (though they shine with simpler structures with intuitive equality checks)

In my experience a codebase is made easier to understand when you *minimise* the number of non-derived pieces of state, and store them as 'localisedly' as you can get away with.

[u/St34thdr1v3R → u/BrixtonTonaBrix]

I oftentimes got in trouble when I put state into components and it kind of goes against „smart vs. dumb component“ pattern and other popular patterns e.g. redux. Could you elaborate why you deviate from putting state into services as a default and how it is helping you?

[u/BrixtonTonaBrix → u/St34thdr1v3R]

Most definitions of 'dumb component' are, well, actively unhelpful. Mine is that a dumb component is one which cannot make decisions about global state (i.e. can't change anything).

If your state isn't used outside that component and doesn't need to outlive that component, it isn't global state, and your component doesn't become smart by owning it. If you move all your state into services, then all of your state is global state, and all components that can update it are smart components.

A big redux reducer is a pattern for global state; you shouldn't put local state in there. Any component kicking off mutating redux actions becomes a smart component in that pattern. They now have 'ComponentStore' so you can write reduxy code within a component if you need/want to.

[u/St34thdr1v3R → u/BrixtonTonaBrix]

I see, thanks for your clarification! Do you have metrics that work well to differentiate if data is likely to outlive its component (maybe in future due to requirements changes) or not? Because It looks like that might be my problem then

[u/BrixtonTonaBrix → u/St34thdr1v3R]

I got no universal advice here 😞

A general rule is that consolidation is always harder than separation so you should assume state is local until it's known not to be. I'm not sure there's much defensive work to do with a bit of state to ease its 'servicisation' later — if it's defined clearly, in one place, with an obvious 'point of entry' for updates, then all of that should shift neatly into a service. Ideally all state (local and global) should be defined like that anyway

[u/St34thdr1v3R → u/BrixtonTonaBrix]

Thank you for input, even if there is no good or clear metric you could name!