Comments (9)
@Injectable
is an awful name, @Service
is much better, and I don't see any reason to rename it.
from typedi.
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 😉
from typedi.
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
from typedi.
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!
from typedi.
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.
from typedi.
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 😉
from typedi.
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 😭
from typedi.
@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)
from typedi.
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.
from typedi.
Related Issues (20)
- question: How do you test your services with dependency injection? HOT 32
- fix: Constructor Injection fail in vitest/jest HOT 3
- question: adding custom proxy traps in class constructors and instances HOT 2
- fix: non-reconstructable services are erased when imported HOT 1
- question: Stage 3 decorator support (available since TS 5.0)
- question: How to debug circular dependency injections ?
- Question: Service Injection working incorrectly HOT 1
- question: is this project/repo dead? HOT 5
- question: <Implementing repository injection using typedi-typeorm.> HOT 3
- question: <Is it possible to adapt your DI to work with modules (not classes)?> HOT 1
- question: HOT 3
- fix: Error when running in bunjs runtime HOT 2
- question: what is the point of Inject if we can use Container.get
- question: Inject Private Property HOT 2
- Using ContainerInstance in the service constructor causes TypeScript build breaks HOT 1
- question: identifier was not found in the container HOT 2
- question: Using typedi with monorepo HOT 3
- question: Using Typedi with Vite - Returning ContainerInstance2 HOT 3
- question: How to define a third-party dependency HOT 5
- question: Using Token with Generics failed in stongly typying
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from typedi.