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

Change "forRoot" and "forRootAsync" signatures #10

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

Change "forRoot" and "forRootAsync" signatures #10

jmcdo29 opened this issue Mar 11, 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 11, 2020

As #9 is already a breaking change, might as well make things easier for the every day developer as well by masking the forRoot(OgmaModule, options) functionality behind a core module that sits in the background so that all is needed is OgmaModule.forRoot(options) or OgmaModule.forRoorAsync(asyncOptions). This should be easy enough to implement for anyone who wants to manage it.

@jmcdo29 jmcdo29 added enhancement help wanted 🆘 Extra attention is needed good first issue 👍 Good for newcomers core 📖 Functionality related to the service or module classes labels Mar 11, 2020
@jmcdo29 jmcdo29 added this to the 3.0.0 milestone Mar 11, 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