[Question] Location of shared/common services

[floriangosse]

What is a suitable location for shared services like for user login/logout/etc. which are not component related?

[toddmotto]

Hey dude. So if you think about what the main component would be for this, it could be an auth module or something, whereby inside that module you have /login/ and /logout/ components or something that have different logic bound to them. If then create auth.service.js and then simply access it inside the child modules. Hope that makes sense! So the services for shared logic are one directory level higher where they can be used for the child modules.

[floriangosse]

This is an nice approach. Currently we put all these shared services into the common module.

[toddmotto]

Yeah - I'd leave the common module for very app-specific stuff, rather than logic that's shared:

app
  /components
    /auth
      auth.service.js
      auth.component.js
      auth.controller.js
        /auth-login
          auth-login.component.js
          auth-login.controller.js

login.controller.js can just DI auth.service then, easy!

[floriangosse]

We had a similar structure in the past and found out that this don't work for us. The services went to big and were used in many other services or components. I'm currently thinking about a approach which seperates the (business) logic from the ui/view stuff. We have some servies inside of specific ui modules but these only for controlling the ui from external (e.g. modals).

[toddmotto]

Yeah - which is why I'd use Redux with it 💃

[ctaepper]

we are doing that, we separated the services containing business logic (in our case mostly services with API communication) and just put them into an /app/services directory. later on, we even moved them into a separate repository, because we needed those so called core services in 2 different frontends. however, this turned out as a huge overhead half a year later (talking about feature branches accros repos, staging versions...) and we are currently merging everything together to a mono-repo

[floriangosse]

@toddmotto I never used Redux in Angular. Maybe I should take a look on these combination. Do you have some useful resources except ngRedux itself?

@ctaepper Wow this is a big change. How does it work until now? It is not easier to describe functionality during the planning and develop the core module as a library?

[ctaepper]

our biggest problem now is when the client requests a new feature. our team follows the gitflow workflow. the project is spread across 5 repositories, so if a new feature affects the whole project, we need to create feature branches in all 5 repos. everyone in the team need to keep track of all 5 repos locally during development, and don't even get me started on deploying a review app for the client on heroku...

all of this led us to going to a monorepo and made us rethink about this flow for future projects... it is very useful for projects which have strict separation of front- and backend for example (we have those too) but as soon as multiple repos depend on each others updates, we are not going to separate them anymore...

however, this has nothing to o with the current issue, just needed to get this out of my mind ;-)

[floriangosse]

Thanks for your help.

I like the approach of Redux and saw that the package ng-component-redux was mentioned in another issue. I will check how we can try out Redux in our application.