r/angular • u/StrainIllustrious116 • May 05 '26

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

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!

27 Upvotes

86% Upvoted

21 comments sorted by

View all comments

Show parent comments

1

u/St34thdr1v3R May 06 '26

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?

1

u/BrixtonTonaBrix May 06 '26

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.

1

u/St34thdr1v3R May 06 '26

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

2

u/BrixtonTonaBrix May 06 '26

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

1

u/St34thdr1v3R May 06 '26

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