Allow components to contribute models + migration guide for LB3 components #5477
Conversation
bajtos
added
Docs
Repository
bajtos
requested review from
agnes512,
deepakrkris and
hacksparrow
as code owners
Which existing approach? Link to example implementation? |
| ? this.getComponentInstance<{ | ||
| repositories?: Class<Repository<Model>>[]; | ||
| }>(component) | ||
| : component; |
There was a problem hiding this comment.
This is not needed if 1cf38b1#r426750582 is addressed.
There was a problem hiding this comment.
I am afraid the link does not point to any comment :(
I believe this is still needed to support the following use case:
app.mountComponentRepositories(SomeComponentClass);(Note that mountComponentRepositories is a public method.)
The existing approach for repositories: components provide |
bajtos
force-pushed
the
spike/component-migration--models-repositories
branch
from
c9f7f25 to
068eee7
Compare
|
Rebased on top of the latest master and addressed the review comments in f255ef8 @raymondfeng LGTY now? |
|
|
||
| // `Readonly<Application>` is a hack to remove protected members | ||
| // and thus allow `this` to be passed as a value for `ctx` | ||
| function resolveComponentInstance(ctx: Readonly<Application>) { |
There was a problem hiding this comment.
I cannot use a private method in mixins :(
packages/repository/src/mixins/repository.mixin.ts:42:17 - error TS4094:
Property '_resolveComponentInstance' of exported class expression may not be private or protected.
42 export function RepositoryMixin<T extends MixinTarget<Application>>(
~~~~~~~~~~~~~~~
068eee7 to
f255ef8
Compare
| * An optional list of Model classes to bind for dependency injection | ||
| * via `app.model()` API. | ||
| */ | ||
| models?: Class<Model>[]; |
There was a problem hiding this comment.
Do we want to add dataSources?
There was a problem hiding this comment.
I am not sure. DataSources typically require environment-specific configuration (e.g. database connection string), I am no sure if it makes sense to export them from a component. Either way, such change is out of scope of this pull request - feel free to open a follow-up GH issue to discuss this idea more.
bajtos
force-pushed
the
spike/component-migration--models-repositories
branch
from
f255ef8 to
afda58d
Compare
|
I have addressed the remaining suggestions on afda58d. @raymondfeng @jannyHou @hacksparrow LGTY now? |
Add a new optional property `models` to `Component` interface, to allow extension developers to declaratively contribute model classes to be bound in the target context. Signed-off-by: Miroslav Bajtoš <[email protected]>
- Create a first version of the migration guide describing the simplest use case where the model is not persisted. - Add a link to a follow-up issue where we will discuss advanced scenarios. Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos
force-pushed
the
spike/component-migration--models-repositories
branch
from
afda58d to
917757d
Compare
In the first commit, I am adding a new optional property
modelstoComponentinterface, to allow extension developers to declaratively contribute model classes to be bound in the target context. (I am aware that #5432 addedcreateModelClassBinding, I just realized it's different from the existing approach we are using for components contributing repositories.)In the second commit, I am starting the migration guide for LB3 components contributing models. Because we haven't figured out yet what should be our recommended solution for LB4 components wishing to contribute Entites and Repositories, I opened a follow-up issue #5476 to figure it out.
This is the last part of Spike: How to migrate LB3 components #4099.
Checklist
👉 Read and sign the CLA (Contributor License Agreement) 👈
npm testpasses on your machinepackages/cliwere updatedexamples/*were updated👉 Check out how to submit a PR 👈