Service decorator name

[MichalLytek]

From @Service JSdoc:

Marks class as a service that can be injected using container.

So it works like in Angular Injector and Inversify, so maybe it would be better to rename it to @Injectable like in this two DI?

@Service could be deprecated and exported as an alias for @Injectable for now.

[pleerock]

@Injectable is an awful name, @Service is much better, and I don't see any reason to rename it.

[MichalLytek]

Awful? It might be not a great name but it's very descriptive - it marks the class as injectable so you can inject it in your other classes (by constructor od explicit @Inject()).

Also it provide more consistency - you have @Inject() decorator already so it's related name.

And of course if someone like I is a fullstack and do both frontend in Angular 2 with @Injectable() and backend in your stack he has to switch between @Service and @Injectable(). And if someone use Inversify and would like to switch to TypeDI, he might doesn't get that @Service is equal to @injectable().

Now I'm using import { Service as Injectable } from "typedi" syntax but I have to write it by hand every time beacuse VS Code can't autoimport with rename 😜

You don't have to rename it, maybe exporting an alias and place info in doc is enough... but I know you don't like aliases 😉

[pleerock]

but it's very descriptive

I find Service quite descriptive. And elegant.

in Angular 2

I understood that you want consistency however I don't think angular named it the best possible way - @Injectable. I really think its an awful name for this. If you used some another framework which use another name for same purpose decorator I would want to have that name.

Plus I think having same decorator name just confuses users when they import - they may accidentally import injectable from typedi in frontend part (angular) and injectable from angular in backend code.

he might doesn't get that @service is equal to @Injectable().

nope, anyone would.

import { Service as Injectable } from "typedi"

I see zero point in it. Does it make sense for example if I use inversify and do: import { Injectable as Service } from "inversify" just because I like Service more then Injectable

You don't have to rename it, maybe exporting an alias and place info in doc is enough... but I know you don't like aliases 😉

better to say noone likes reduplication because its confusing

[MichalLytek]

Ok, I get you point of view but I'm also trying to show you the point of view of people like me half year ago. I saw the @Service decorator, I read the description but I still didn't know what is the purpose... I have FooService class name already, why TypeDI has to know if my class is a service or not 😆 So Injectable would be more intuitive as it marks that the class is injectable and can be injected by the TypeDI 😉

Plus I think having same decorator name just confuses users when they import - they may accidentally import injectable from typedi in frontend part (angular) and injectable from angular in backend code.

Who mix frontend code with backend? I prefer separate repos for backend and frontend or sometimes separate folders on the same repo but never one fullstack TS project with one tsconfig... services would be then mixed in services folders - one visible by Angular injector, one by TypeDI 😆 What a horrible idea!

[pleerock]

TypeDI has to know if my class is a service or not

but what else it can be if not a service

Who mix frontend code with backend?

many people and full-stack frameworks do. Meteor for example. There are lot of challenges in merged backend and frontend, but benefits as well. For example you can easily share your models which are in most of cases 100% equal on both sides representation.

[MichalLytek]

but what else it can be if not a service

A factory for creating objects (like TypeORM Repository.prototype.create) or when using GoF design patterns e.g. StrategyFactory. Or maybe a helper like DateConvertor which isn't related to domain/business logic 😉 You shouldn't put "everything that a controller uses" to one bag called "services" 😜

many people and full-stack frameworks do. Meteor for example.

Yeah, but they are a monolith framework where everything is connected together. I said about developers which create backend with routing-controllers and then want to create a frontend app with angular - it should be separated as it only communicates with HTTP, so separated folders in one repo is a good solution, you can work independently and also share request/entities models. But it's not important - going back to:

they may accidentally import injectable from typedi in frontend part (angular) and injectable from angular in backend code

Do you use single tsconfig and build chain for both part of the app? I always use different tsconfigs for backend and frontend - backend is compiled to ES6/7 (node.js) by tsc, frontend to ES5 with webpack with many polyfills. I don't have single package.json with all dependecies but one for frontend, one for backend. So in this case even VSCode quick-fix won't suggest you to import Angular's @Injectable in backend controller class file 😉

For example you can easily share your models which are in most of cases 100% equal on both sides representation.

Single project is really not needed - I've already did this with npm packages on 3 separate repos (frontend, backend, models) which are connected by dependecies in package.json (npm install from git if you don't have paid npm private packages). I have even semver done with git tags on them (no private packages), so you can easily change models and backend and then update frontend to work with new version.

Also when you have both backend and frontend really mixed together in one project folder it might be hard to create e.g. mobile version with react-native - it's better when you have separate repo for separate parts of the app. Also when you have a repo for Java Android app, you can only install backend from npm/git, not the whole bunch of related stuffs like frontend in angular 😉

[pleerock]

this discussion won't lead to anything, simply because injectable is awkward name IMHO and arguments for renaming aren't valuable. Maybe next time, with a different name 😭

[mimittqq]

@Injectable is an awful name, @Service is much better, and I don't see any reason to rename it.

sorry, i wanna inject repository to my service and '@service' is not a good decorator name for my repository. what can i do except rename ?
(my english is poor 😭 i hope i have made clear)

[github-actions]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.