Loopback-next: Artifact Registration

[virkt25]

Overview

Today we have a wide variety of Artifact Registration options available for end users. To keep the behaviour simplified, we have to use the same methods in boot.

An example is:

app.controller(ControllerClass); // Boot calls this for controllers.
app.repository(RepositoryClass); // This requires RepositoryMixin

For .repository and .datasource, RepositoryMixin has to be used for Boot to work to ensure we bind to the correct prefix (it could change) and the right tags.

Relevant Discussion

• https://github.com/strongloop/loopback-next/pull/1076#issuecomment-370012208

Proposal

Add a new method in core to register any Artifact. The prefix and tags should be constants exported by the appropriate package. The new method can be called app.register(type, class) or app.register(class, type). The implementation of existing sugar methods would leverage this new sugar function ... and export the constants used for type so Boot can provide the same functionality without requiring the presence of a Mixin. This function would set the tag for the bound artifact to the same as the type of the artifact.

Example

@loopback/core/keys.ts

export namespace KEYS {
  export const CONTROLLER_ARTIFACT_TYPE = 'controller';
}

@loopback/core/application.ts

import {KEYS} from './keys';

class Application {
  register(type:string, class: Constructor<{}>):Binding {
    return tag ? this.bind(type + "." + class.name).toClass(class).tag(type) : this.bind(type + "." + class.name).toClass(class);
  } 

  controller(class: Constructor<{}>) {
    this.register(KEYS.CONTROLLER_ARTIFACT_TYPE, class);
}

@loopback/boot/controller.booter.ts (load)

import {KEYS} from '@loopback/core';

class ControllerBooter extends ArtifactBooter {
  // ... 
  this.classes.forEach(cls => {
    this.register(KEYS.CONTROLLER_ARTIFACT_TYPE, class);
  });
}

Similar implementation in @loopback/repository. If we wanted ... we can just remove the sugar methods entirely and just export the const's for artifact TYPE.

---

Acceptance Criteria

• [ ] Introduce app.register() method that serves as sugar for binding a Artifact
• [ ] Update existing sugar binding methods such as .controller(), .repository, .dataSource() to use the new app.register() under the hood
• [ ] Artifact type should be constants that are exported
• [ ] Boot should be updated to use the new constants and app.register to Load Artifacts
• [ ] Get rid of AppWithRepository interface
• [ ] Update Docs
• [ ] Update existing tests if needed / write new tests

[bajtos]

The proposal looks good to me.

I am proposing to unify the binding key prefix and the tag to use the same singular value, e.g. controller:

ts app.bind('controller.ProductController') .toClass(ProductController) .tag('controller') .inScope(BindingScope.SINGLETON);

Thoughts?

[b-admike]

+1 from me as well. I'm also fine with having the same singular value for prefix/tag.

[dhmlau]

@raymondfeng @virkt25 , do you think this should be tagged as DP3?

[bajtos]

@virkt25 what's your take on the priority of this issue - do you think it belongs to 4.0 GA scope? Can we move it to post-GA?

[virkt25]

It's a nice to have but don't see how it makes GA Goal simpler so I'm ok to mark this as post-GA.

[stale[bot]]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale[bot]]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.