Another great article @johnbiundo đź‘Ź This series is really interesting. Thanks for you work đź‘Ť
I have a few questions that might sound dumb but I'm going to ask them anyway:
I've noticed that the generated module is decorated as Global by default. Is that the way to go? Shouldn't we avoid global modules? Let's say I need a specific connection to a Postgres instance in module A and another connection to another instance in module B. If the NestKnexModule is global, won't that be an issue?
Second question is simply about the naming of the register and registerAsync methods: I thought that global modules were supposed to expose forRoot (and its async variant) and that module-scoped modules were supposed to expose register (and its async variant). Have I been wrong this whole time? Or is it just a matter of personal preference?
Again, thanks for your work! I wish those schematics were released sooner as they would have saved me some time :)
Can't wait for your next post.
Not dumb at all! I should probably discuss the use of @Global() in the article, so thanks for bringing it up. The main reason I use it is, to be honest, in a "utility" type module I find it convenient to register it once (usually in the root module), and then have it globally available. However you bring up an excellent point, and @Global() definitely has some side effects (such as breaking module encapsulation) and is usually to be avoided. I want to give this some more thought, and I have an idea or two on how to handle your Module A/Module B question, but need to test a few things out. I'll report back!
And your second question is good as well! To be honest, I hadn't quite sussed out that pattern of register vs. forRoot, but now that you mention it, I'll have to go back and look more closely.
Thanks so much for the thoughtful feedback. It really helps to have sharp eyes from people who have worked on dynamic modules. I hope to continue to improve these articles as a useful resource!
Another great article @johnbiundo đź‘Ź This series is really interesting. Thanks for you work đź‘Ť
I have a few questions that might sound dumb but I'm going to ask them anyway:
Globalby default. Is that the way to go? Shouldn't we avoid global modules? Let's say I need a specific connection to a Postgres instance in module A and another connection to another instance in module B. If theNestKnexModuleis global, won't that be an issue?registerandregisterAsyncmethods: I thought that global modules were supposed to exposeforRoot(and its async variant) and that module-scoped modules were supposed to exposeregister(and its async variant). Have I been wrong this whole time? Or is it just a matter of personal preference?Again, thanks for your work! I wish those schematics were released sooner as they would have saved me some time :)
Can't wait for your next post.
@fwoellfel, thanks! Glad it has been helpful!
Not dumb at all! I should probably discuss the use of
@Global()in the article, so thanks for bringing it up. The main reason I use it is, to be honest, in a "utility" type module I find it convenient to register it once (usually in the root module), and then have it globally available. However you bring up an excellent point, and@Global()definitely has some side effects (such as breaking module encapsulation) and is usually to be avoided. I want to give this some more thought, and I have an idea or two on how to handle your Module A/Module B question, but need to test a few things out. I'll report back!And your second question is good as well! To be honest, I hadn't quite sussed out that pattern of
registervs.forRoot, but now that you mention it, I'll have to go back and look more closely.Thanks so much for the thoughtful feedback. It really helps to have sharp eyes from people who have worked on dynamic modules. I hope to continue to improve these articles as a useful resource!
dev.to/umasankarswain/how-to-updat...