is the Dynamic Modules Example flawed?

[rvalle]

Is there an existing issue that is already proposing this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe it

I would like to provide feedback on this example, I am not very experienced with NestJS, so I am part of the target public.

I think the dynamic module example seems somehow flawed.

This seems more like a particular way to configure a module, but it is not dynamic.

We use dependency injection to be able to replace, modules, or to have multiple implementations, etc. Kind of a Plugin architecture.

A dynamic module should, in fact, return different set of components depending on something dynamic.

For example, will the service store in SQL database or in an Redis server, with different services / providers being instantiated as result.

Being able to configure a module and passing the configuration to the constructor is something well covered by the ConfigModule, isn't it? The provided example allows configuration at the time in which the module is included into another, which is a valuable alternative.

However, changing the structure of the application, by bringing in a dynamic set of components seems more like the responsibility of DynamicModule, that is why the register method returns a module, so that components can be altered dynamically.

I managed to implement this setup following the documentation, however, I find a problem.

DynamicModule.register method will need to take decisions before deciding the structure of the module to return.

Which tools can be used to take those decisions? Could I inject other modules to the register method in order to take those decisions? I

It would be helpful if the example covers the patterns that can take place in the DynamicModule.register method.

Describe the solution you'd like

An example that creates a module dynamically, involving different set of components brought to context.

The example should cover patters to decide at the register method.

Teachability, documentation, adoption, migration strategy

Users will be able to extract the full potential of the NestJS architecture.

What is the motivation / use case for changing the behavior?

I don't think a change of behavior is required, but rather to show what it is possible.

[kamilmysliwiec]

Which tools can be used to take those decisions? Could I inject other modules to the register method in order to take those decisions? I

Of course!

Let me move this issue to the appropriate repo since it seems that's something we should rather improve in the docs

[StdVectorBool]

What's the proper approach for submitting revisions to this doc without offending the original contributor, open an issue first or create a PR for comments?

I'm finding Dynamic Modules writing style very roundabout and that makes it difficult to read compared to the rest of the documentation.

There are wordy paragraphs of the structure "Question ... effectively ... in other words":

What about the static register() method? We can now see that its job is to return an object that has the DynamicModule interface. When we call it, we are effectively providing a module to the imports list, similar to the way we would do so in the static case by listing a module class name. In other words, the dynamic module API simply returns a module, but rather than fix the properties in the Module decorator, we specify them programmatically.

That could be much more direct:

The static register() method returns a DynamicModule interface which is a module with properties defined programmatically rather than statically with the usual Module decorator.

Other examples to make it read more concisely like Wikipedia:

Armed with this understanding, we can now look at what our dynamic ConfigModule declaration must look like. Let's take a crack at it.