-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hello There! #665
Comments
Hi there, could you provide some samples to clearly understand your idea? |
This is kinda what i'm thinking of // auth.plugin.ts
@Plugin();
@Targets("auth");
class AuthPlugin{
// Authorization logic
}
// user.plugin.ts
@Plugin()
@Targets("user")
class UserPlugin{
// Fetch user from db
}
// my.service.ts
@Service("url");
@Tag("auth");
@Tag("user");
export default class MyService{
// The Auth Plugin and User Plugin are called before executing any of the handlers in here
} What's Happening here is that you are Tagging your services or individual handlers with strings, which the plugins "target", it allows you to quickly specify exactly what plugins a service depends on. The reason it uses strings and not direct plugin class references is so that you can make multiple plugins target the same name, so that you can quickly apply multiple plugins with a single tag. you could also tag plugins as a way of defining dependencies for plugins e.g To fetch a user you need to be authorized so there would need to be a way to ensure the auth plugin is called before it. // auth.plugin.ts
@Plugin();
@Targets("auth");
class AuthPlugin{
// Authorization logic
}
// user.plugin.ts
@Plugin()
@DependsOn("auth")
@Targets("user")
class UserPlugin{
// Fetch user from db
}
// my.service.ts
@Service("url");
@Tag("user");
export default class MyService{
// The User plugin is called before the handlers, but since the user plugin depends on the auth plugin, it will be called under the hood
} |
This seems like a good idea but may be an antipattern, I'm not too experienced so i'm not sure |
Even if you're not sure let's keep this open, I need some time to think about, unfortunately I didn't have much time to work on library last year, hope this will change |
I have a suggestion for an alternate plugin system that uses decorators
Essentially the idea is that you can introduce a tagging system, where you can tag routes and controllers
You can write plugins and add a tag decorator to them aswell
The Plugins would be applied to the routes and controllers that specify the tag that it uses
You could also allow multiple plugins to use a single tag and introduce some sort of sequencing system so that one tag can apply mutiple plugins in a specific order, to reduce boilerplating
The text was updated successfully, but these errors were encountered: