Skip to content
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

Remove Scope.TRANSIENT from OgmaService #11

Closed
jmcdo29 opened this issue Mar 18, 2020 · 0 comments
Closed

Remove Scope.TRANSIENT from OgmaService #11

jmcdo29 opened this issue Mar 18, 2020 · 0 comments
Assignees
Labels
core 📖 Functionality related to the service or module classes Has PR This issue has a PR related to it, or is in a branch in development Ready This issue has been taken care of and is waiting to be merged

Comments

@jmcdo29
Copy link
Owner

jmcdo29 commented Mar 18, 2020

Allow for OgmaService to be transient-like scope using different injection tokens determined from forFeature and add in an @OgmaLogger() decorator that will create the correct injection token for that class. This will allow for easier use of the module and make for a better experience overall

@jmcdo29 jmcdo29 added core 📖 Functionality related to the service or module classes enhancement good first issue 👍 Good for newcomers help wanted 🆘 Extra attention is needed labels Mar 18, 2020
@jmcdo29 jmcdo29 added this to the 3.0.0 milestone Mar 18, 2020
jmcdo29 added a commit that referenced this issue Mar 27, 2020
Oh where to begin? This rewrite allows for the OgmaModule to manage so much more than just HTTP, and
in such a way that it's almost hard to describe. With the plugin system created, so long as a class
extends the `AbstractInterceptorService` **and** the class does not have any extra injections
needed, any class can be provided to the `interceptor` property of the `OgmaModuleOptions` to allow
for interceptor request parsing. By default, the class that is provided is a
`NoopInterceptorService` that really should only be there so an error gets thrown, but something had
to be there for the Nest DI ssytem to not complain. Tests are still to come to help clean out dead
code, but overall, the proof of concept is there and it works!

re #7 #8 #9 #10 #11
@jmcdo29 jmcdo29 self-assigned this Mar 28, 2020
@jmcdo29 jmcdo29 added Has PR This issue has a PR related to it, or is in a branch in development Ready This issue has been taken care of and is waiting to be merged and removed good first issue 👍 Good for newcomers help wanted 🆘 Extra attention is needed labels Mar 29, 2020
@jmcdo29 jmcdo29 closed this as completed Apr 21, 2020
jmcdo29 added a commit that referenced this issue Jun 20, 2021
Oh where to begin? This rewrite allows for the OgmaModule to manage so much more than just HTTP, and
in such a way that it's almost hard to describe. With the plugin system created, so long as a class
extends the `AbstractInterceptorService` **and** the class does not have any extra injections
needed, any class can be provided to the `interceptor` property of the `OgmaModuleOptions` to allow
for interceptor request parsing. By default, the class that is provided is a
`NoopInterceptorService` that really should only be there so an error gets thrown, but something had
to be there for the Nest DI ssytem to not complain. Tests are still to come to help clean out dead
code, but overall, the proof of concept is there and it works!

re #7 #8 #9 #10 #11
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core 📖 Functionality related to the service or module classes Has PR This issue has a PR related to it, or is in a branch in development Ready This issue has been taken care of and is waiting to be merged
Projects
None yet
Development

No branches or pull requests

1 participant