feat(core): introduce basic life cycle support for LoopBack applications

[raymondfeng]

Implements:

• Allow components to contribute start actions #1845
• Boot scripts #2034

The PR implements the following features:

• Allow registration and actions of life cycle observers using context bindings - See https://github.com/strongloop/loopback-next/blob/lifecycle/docs/site/Life-cycle.md
• Discover and boot life cycle scripts
• Add lb4 observer command to generate life cycle scripts - See https://github.com/strongloop/loopback-next/blob/lifecycle/docs/site/Life-cycle-observer-generator.md

Test observer cli

cd loopback-next
git checkout lifecycle
npm run build
cd sandbox
../packages/cli/bin/cli-main.js app life
cd life
../../packages/cli/bin/cli-main.js observer
cd ../..
npm i
cd sandbox/life
npm start

Checklist

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

[davidxiao]

when will this PR be merged? :)

[raymondfeng]

@bajtos Please review.

[bajtos]

Let's discuss few high-level areas first.

[bajtos]

In your proposed design, a component class has to implement LifeCycleActions interface if it wants to be notified about start/stop events.

Have you considered a different approach where the component "exports" possibly multiple LifeCycleAction classes using the same pattern we have for controllers and providers?

This is the good old Composition over inheritance advice.

// in a component
class MyComponent implements Component {
  onLifeCycle: [MyLifeCycleListener];
}

class MyLifeCycleListener {
  constructor(/* receive dependencies */) {}

  async start() {
    // ...;
  }

  async stop() {
    // ...;
  }
}

// inside `mountComponent`
component.onLifeCycle.forEach(cls => app.registerLifeCycleListener(cls));

// inside app.start()
await Promise.all(this._lifeCycleListeners.map(l => l.start()));

[raymondfeng]

Ultimately we'll switch the observer pattern so that components can subscribe to the start/stop events. See #1972.

Do we want to wait unless we settle on #1972?

[bajtos]

I think that even with the observer pattern from #1972, we should still allow components to export lifecycle observers in an indirect way, i.e. letting mountComponent to handle the actual registration.

It is not clear to me how #1972 would affect the design of lifecycle events and whether the solution based purely on low-level observer APIs would be enough easy to use.

My preferred approach is to use composition instead of inheritance, allow components to export an array of life-cycle listener/observe classes and get this pull request landed.

[bajtos]

Later on, when #1972 is implemented, we can look into ways how to leverage the observer pattern as a low-level implementation detail to power "LifeCycleObserver".

[raymondfeng]

@bajtos PTAL

[b-admike]

LGTM 💯 , left some minor comments.

[b-admike]

I wonder if this utility function can be moved to @loopback/context and be useful in other places?

[bajtos]

Great idea, +1 from me

[bajtos]

Does it mean that if the lifecycle class is decorated with @Bind and sets the type to something else than CoreTags.LIFE_CYCLE_OBSERVER, then the result of calling app.lifeCycleObserver is a binding with a type that's not LIFE_CYCLE_OBSERVER? Similarly for namespace. Are we okay with that? I find it surprising to be honest.

Please note that type and namespace options in createBindingFromClass() overrides @bind.

Well in that case, what are the arguments against setting the tag & namespace via the asLifeCycleObserver template?

What I am looking for: an easy way how to bind a life-cycle observer without using createBindingFromClass or app.lifeCycleObserver.

[hacksparrow]

There was a discussion where it was mentioned that eventually we'll be using the observer pattern for application events.

Will the API of lifeCycleObserver be affected by it? If yes, we should mention it beforehand so as to prepare our users of the future change. If only the underlying implementation is affected with no change in the API, we need not.

[raymondfeng]

The observer pattern can be used to implement life cycle observers but the proposed apis can stay. If we have to change, we can always release a new major version. Release often, release fast :-)

[bajtos]

LGTM. Please clean up the git history before landing.