Proposal: change from "do" to "consider" adding 'Service' suffix to Service (02-04) classes because it doesn't improve clarity or add value

[GUSCRAWFORD]

Based on usage-pattern, what value is there in naming Data class DataService?

[bampakoa]

@GUSCRAWFORD the Angular official style guide has some good reasons 😃 . Please note that these are not strict rules, but if you ask me I try to follow them every day, since they are written from Angular experts 😏

[GUSCRAWFORD]

@bampakoa What's been the value in following 02-04 in your experience?

• What's an example of a drawback of not following it?
• Why is it helpful having a service explicitly named *er or *Service

For my part, to play devil's advocate the only example of the value that comes to mind is implementing CanActivate, and it's worthwhile to know looking at the file structure that I'm not injecting this in components or other services. I could easily manage that with directory structure too.

[mattgrande]

If I see a variable named User, I would assume that it's an instance of a user model; It would probably have properties like User.id, User.email, etc...

Conversely, if I see a variable named UserService, I would assume that it's a service; It would probably have functions like UserService.fetch(), UserService.update(), etc.

I think it improves clarity.

[bampakoa]

@GUSCRAWFORD In addition to @mattgrande's comment:

• I have seen a huge advantage when working in teams with other developers or even when I need to collaborate through plnkr or codepen, possibly for the reproduction of a bug.

• Another case is when the codebase of the project grows and you have to manage a lot of services. It is really handy if you can spot a service directly and not having to dig through files.

• Also, it helps automation tools like gulp to find those services using regex patterns and do whatever they supposed to do with them.

There is no harm in not following the rules, you will be still writing in Angular 😃 It is really helpful that we, as Angular developers, speak the same language and use the same notations in our everyday coding.

[GUSCRAWFORD]

@mattgrande I would almost agree, only that when I think of myself coding with the User example, I pretty much know it's service if I use it because it's in my constructor signature where it's being injected.

@bampakoa:

• Tell me the huge advantage you had working with team and how an explicitly named xService cleared up confusion; I can certainly see being extra illustrative in a code-pen
• Growing code-base: are you not separating services into a different directory? Should I not be also? (I'm not suggesting the file-naming convention change either)
• Give me an example (use case) of using gulp to find services? I did not think of this, I found this (AJs)package interesting but kind of moot with the CLI tools;

:) I'm not trying to be too picky, but there:

1. should be some harm or a clear drawback to not following a style-guide rule, ergo not much value without it
2. I agree we should be speaking the same language, but DI is a broader concept that implies the notation Service without ever really needing it.
3. This isn't about my own idiosyncrasies-- if I stay within 02-04 and use the CLI to create UserManager > ng g s user-manager I end up with UserManagerService despite the er (docs specify Logger as good example) being an acceptable name.

• Obviously, User is also a technically acceptable name too despite the confusion—all the more to my point why not just simplify and drop the recommendation of the Service suffix and recommend to stop adding in the cli

I feel it's just extra typing, and no benefit to readability or clarity

[bampakoa]

Tell me the huge advantage you had working with team and how an explicitly named xService cleared up confusion

I think every development team should conform to the same set of rules in the context of the same language. In our front end development team, which consists mostly of Angular developers, we need to understand each other's source code quickly in case we need to. Think what will happen, If I use Service suffix, another one uses SVC suffix and a third one none of them.
I have found it also useful when I need to have a look in an application after some time. You do not have to remember what is that User injected in your component 😃

Growing code-base: are you not separating services into a different directory? Should I not be also? (I'm not suggesting the file-naming convention change either)

I prefer folder-by-feature structure. It gives me a better understanding of the structure of my application.

Give me an example (use case) of using gulp to find services? I did not think of this, I found this (AJs)package interesting but kind of moot with the CLI tools;

There is no need to use it yet in my case but I know that it will there in case I have to.

[GUSCRAWFORD]

@bampakoa this is a reason you like the rule, it's not an example of the rule avoiding a confusion for your team. Lack thereof a clear example speak to my point.

Do you not separate feature related services into their own folder even within a feature-by-folder?

If I'd never even seen your code or was looking at it for the first time I could infer the same details of the design without injectables explicitly named xService

I want to generate services with the client and just in this instance, adding the service suffix to the name should be explicit (i.e. Ng cli g "myService")