Document and improve ExDoc usage about ecto_erd HOT 4 OPEN

Hi @btkostner

Having a public Ecto.ERD.render is a good idea.

Just want to warn you that such usage adds compile-time dependencies with the schema modules. I'd suggest generating diagrams separately and do not embed them into the code directly. Code compilation is a much more frequent operation than generating docs. So, in your Account context, just insert a link to the markdown file with Mermaid diagram or directly to the generated image and that's it. If you really want to have it in moduledocs, then I'd do this only using some compile-time flag, which would require a new env for docs.

from ecto_erd.

Now, I'm not sure about exposing a public function for rendering a document in order not to encourage usage in moduledocs. I need other scenarios why public function is needed and not a mix task :)

from ecto_erd.

So, going against adding a public function in documentation because of the compile errors and all the other issues there. I think the use case still stands (just needs to be implemented differently.) I'd still like a way to render only some modules so I can do it on a per context basis. I can think of:

1. Users writing a mix task that runs the public render function and generates all of the needed files. This can already be done, but it'd be nice to clean up the functions and possibly document this approach.
2. Updating the ecto_erd configuration file to allow multiple renders and specifying which modules to render

from ecto_erd.

It is already possible to render only some modules by using map_node parameter. The callback function must return nil for modules which must be removed.
Multiple renders can be achieved by using multiple configuration files :)

from ecto_erd.