Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

docs: component migration - general aspects #5262

Merged
merged 1 commit into from
May 5, 2020

Conversation

bajtos
Copy link
Member

@bajtos bajtos commented Apr 27, 2020

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:

  • Migrate component infrastructure
  • Migrate current context
  • Migrate mixins

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)

  • Migrate Models, Entities and Repositories
  • Migrate REST API
  • Migrate API transports
  • Authentication & authorization
  • Migrate Introspection

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

  • 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

👉 Check out how to submit a PR 👈

@bajtos bajtos self-assigned this Apr 27, 2020
@bajtos bajtos added this to the April 2020 milestone Apr 27, 2020
@bajtos bajtos force-pushed the spike/component-migration-2 branch from 012f10d to f98fc9b Compare April 28, 2020 15:04
@bajtos bajtos force-pushed the spike/component-migration-2 branch from f98fc9b to d2bea58 Compare April 30, 2020 13:51
@bajtos bajtos marked this pull request as ready for review April 30, 2020 14:03
@bajtos bajtos changed the title docs: component migration - overview of instructions docs: component migration - general aspects Apr 30, 2020
@dhmlau dhmlau modified the milestones: April 2020, May 2020 May 2, 2020

- `@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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We should recommend lb4 extension command to scaffold a package to expose components.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

<!--
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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

@jannyHou jannyHou left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍 Awesome, LGTM!

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.
-->
Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Created: #5337

@bajtos bajtos force-pushed the spike/component-migration-2 branch from d2bea58 to 4f1effc Compare May 5, 2020 14:34
@bajtos
Copy link
Member Author

bajtos commented May 5, 2020

Thank you @raymondfeng @jannyHou @emonddr for the review. I addressed the remaining bits in 4f1effc and will proceed to land this PR shortly.

@bajtos bajtos force-pushed the spike/component-migration-2 branch from 4f1effc to ded442b Compare May 5, 2020 14:36
@bajtos
Copy link
Member Author

bajtos commented May 5, 2020

@bajtos bajtos merged commit 04bd52f into master May 5, 2020
@bajtos bajtos deleted the spike/component-migration-2 branch May 5, 2020 15:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants