docs: component migration - general aspects #5262
Conversation
bajtos
force-pushed
the
spike/component-migration-2
branch
from
012f10d to
f98fc9b
Compare
bajtos
force-pushed
the
spike/component-migration-2
branch
from
f98fc9b to
d2bea58
Compare
bajtos
requested review from
agnes512,
deepakrkris,
hacksparrow and
nabdelgadir
as code owners
bajtos
changed the title
|
|
||
| - `@inject(key)` and `@inject.getter(key)` to receive values from the context | ||
| - `@inject.setter(key)` to obtain a setter function for writing values to the | ||
| context |
There was a problem hiding this comment.
We should mention that TRANSIENT scope should be used for such bindings in order to receive per-request contextual data.
| As the last resort, LoopBack 4 components can also modify the target application | ||
| directly by calling `Application` APIs (this is similar to LoopBack 3 approach). | ||
|
|
||
| To make the migration guide easier to navigate, we split component-related |
There was a problem hiding this comment.
We should mention #5304 and give an example to show how to use an application as a component to allow boot artifacts from a sub-application.
There was a problem hiding this comment.
I am afraid I don't see how the booter for loading artifacts from a sub-application is related to migrating LB3 extensions to LB4? Can you @raymondfeng please open a follow-up issue to describe in more detail what are you looking for?
| As explained in [Creating components](../../Creating-Components.md) and | ||
| [Using components](../../Using-components.md), a typical LoopBack 4 component is | ||
| an npm package exporting a Component class. | ||
|
|
There was a problem hiding this comment.
We should recommend lb4 extension command to scaffold a package to expose components.
There was a problem hiding this comment.
I am already recommending lb4 extension elsewhere, see https://github.com/strongloop/loopback-next/pull/5262/files#diff-d72cf51faca1367bfb582f0995256991R111
| <!-- | ||
| FIXME: create a follow-up task to update Extension template to follow | ||
| the latest style as used by `extensions/metrics`: | ||
| - inject the target app and component config to the component class, |
There was a problem hiding this comment.
It's also possible to build a component booter to load declarative json files similar as LB3. I plan to contribute a Configuration booter to load json/js/yaml/rc files from configs directory and use app.configure to bind such entries.
There was a problem hiding this comment.
Sure. Such booter is out of scope of my pull request though. First, it's not implemented yet. Second, this FIXME comment is just a placeholder, the changes are tracked by the following GitHub issue I created few moments ago: #5336
| FIXME: Create a new follow-up task to create a diagram per Raymond's comment: | ||
| > Maybe a diagram would help if it shows the handshake between an application | ||
| > and a component as well as typical artifacts exported from a component. | ||
| --> |
bajtos
force-pushed
the
spike/component-migration-2
branch
from
d2bea58 to
4f1effc
Compare
|
Thank you @raymondfeng @jannyHou @emonddr for the review. I addressed the remaining bits in 4f1effc and will proceed to land this PR shortly. |
Signed-off-by: Miroslav Bajtoš <[email protected]>
bajtos
force-pushed
the
spike/component-migration-2
branch
from
4f1effc to
ded442b
Compare
This is a part of documentation for the spike #4099 How to migrate LB3 components.
There is quite a lot of techniques and content to cover, I am getting overwhelmed by the amount of thinking and writing needed. To make things more manageable, I decided to split the work into smaller chunks.
In this pull request, I am starting to create basic structure for the migration guide and adding a draft content for the following migration aspects:
This is a part of a spike, so I should not be changing the real docs, but then I figured out that since I have already wrote the content, it will give more value to our users to put the content up, even if it's not finished yet. My intention is to land this pull request even if the content is not in the shape would you eventually want and create follow-up stories to make any substantial improvements as required by reviewers. (This the the part where I am getting back to our usual spike process - do the research and then open follow-up stories to implement the proposed changes.)
@raymondfeng @jannyHou @emonddr: please review
Out of scope
(will be covered by follow-up pull requests)
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 👈