Document application / component lifecycle

[str4d]

One of the things I'm having trouble figuring out is how components fit into the overall application lifecycle. After lots of digging into the code, I think the application lifecycle is roughly this:

• CLI arguments are parsed.
• Each component is created, and registered into the component graph.
• Config is loaded.
• Every component is configured independently.
  • If using the derive, components cannot be configured (Better support for overriding parts of a derived Component implementation. #332).
• The component graph is traversed, and dependencies are injected.
  • If using the derive, dependencies are injected separately (via their own methods), and in the order they are specified.
• The command is run.
• The component shutdown hook runs.
  • If using the derive, components cannot hook shutdown (Better support for overriding parts of a derived Component implementation. #332).

This means that AFAICT the methods on a component are always called in this order:

• MyComponent::new (or whatever the app chooses)
• Component::after_config
• Component::register_dependency
  • MyComponent::init_foobar etc. if using the derive.
• MyComponent::some_method by a command after fetching it via APP.state().components().get_by_id(..)
• Component::before_shutdown

If this order is reliable, it would be useful to document it in places where a new developer is going to find it (currently the docs suggest this should be the Component trait, but it could also be the component module; in either case the Component derive should have documentation that links to it).

[str4d]

The main thing the lack of documentation tripped me up on is the fact that components need basically all of their internal state to be either Optioned or Defaulted, and then filled in or altered after the config is loaded (instead of loading the config, and then constructing each component from that config).

The framework components (Terminal and Tracing) by comparison don't actually integrate in this way: they call the custom Application::term_colors and Application::tracing_config methods in between CLI argument parsing and component graph registration. These core components are constructed from a compiled-in config, but the config loaded from disk cannot influence them until after Component::register_dependency (i.e. manually during command run) instead of during Component::after_config.