New platform migration guide by epixa · Pull Request #31147 · elastic/kibana

epixa · 2019-02-14T16:30:53Z

Latest guide rendered here: https://github.com/elastic/kibana/blob/602091982d2d1c48ad464304f1e05b65d98f14a5/src/core/MIGRATION.md

elasticmachine · 2019-02-14T16:30:56Z

Pinging @elastic/kibana-platform

src/core/MIGRATION.md

This reverts commit e720b27.

src/core/MIGRATION.md

mshustov · 2019-03-18T12:11:20Z

src/core/MIGRATION.md

+
+Different service interfaces can and will be passed to `setup` and `stop` because certain functionality makes sense in the context of a running plugin while other types of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.
+
+For example, the `stop` function in the browser gets invoked as part of the `window.onbeforeunload` event, which means you can't necessarily execute asynchronous code here in a reliable way. For that reason, `core` likely wouldn't provide any asynchronous functions to plugin `stop` functions in the browser.


imho it makes sense to start Plugin introduction from lifecycles and describe their signature. Don't see any start mentions in the doc

To clarify, do you mean that you'd like to have a description in this document of the three lifecycle functions and how lifecycle functions work in general?

list of lifecycles

their meaning

their signature

their calling order

I agree that this would be valuable context. It would also be good to include the plugin factory function in the lifecycle calling order.

I pushed more information about lifecycles with a focus on relevant information for the sake of migration 5d343de

src/core/MIGRATION.md

- Add missing return statement highlighted during meeting. - `apiExport` -> `uiExport` - Small spelling check

rudolf · 2019-03-19T08:11:32Z

src/core/MIGRATION.md

+{
+  "id": "demo",
+  "server": true,
+  "ui": true


I think it's much easier to understand and build up a mental model if the configuration option key is consistent with other naming conventions. Both should be ui or both public etc.

To dig up an old discussion, although /public is a strong convention for a folder structure, it's much less intuitive as a configuration option or as code e.g. PublicStartContract or "public": true(appears to be a visibility setting?). It's also unnatural to talk about "public code", we're more likely to say "client-side code" or "ui code".

So I'd prefer if we change public -> ui.

I'm going to leave this as-is in the guide for now since ui is what exists, but feel free to open an issue to discuss this separately.

src/core/MIGRATION.md

rudolf · 2019-03-19T08:51:31Z

src/core/MIGRATION.md

+
+Different service interfaces can and will be passed to `setup` and `stop` because certain functionality makes sense in the context of a running plugin while other types of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.
+
+For example, the `stop` function in the browser gets invoked as part of the `window.onbeforeunload` event, which means you can't necessarily execute asynchronous code here in a reliable way. For that reason, `core` likely wouldn't provide any asynchronous functions to plugin `stop` functions in the browser.


I agree that this would be valuable context. It would also be good to include the plugin factory function in the lifecycle calling order.

peterschretlen · 2019-04-01T10:33:21Z

src/core/MIGRATION.md

+{
+  "id": "demo",
+  "server": true,
+  "ui": true


version appears to be a required property, we might want to include "version": "8.0.0" in the example?

Since no plugin is quite ready to completely migrate today, I'm going to proceed as-is for now, but I'll follow up with this separately. We do still want external plugins to specify a version property, but I want to remove the requirement that new platform plugins in the Kibana repo require a version property.

Issue for this: #34660

lukeelmers · 2019-04-05T16:38:34Z

I just re-read and it all makes sense to me. Only (non-urgent) suggestions I would add are:

maybe some more concrete examples around uiExports entry points could be added eventually. the server-side plan of action has a handful of code samples, and i think the client-side section could benefit from some code samples too (though admittedly the way this is handled on the client will vary more widely than the server).
in the FAQs about plugin vs package at the end, i'm wondering if it'd be worth having a brief section on "how to think about plugin boundaries," in light of some of our recent discussions around grouping plugins in terms of domains rather than treating them as highly-specialized modules

epixa · 2019-04-05T20:20:46Z

@lukeelmers Those are both great suggestions. I'm going to hold off adding them to this PR so it can go in, but they're good improvements to add to the doc in followups.

lukeelmers

Thanks for investing the time to do this; it's going to be a huge help for the rest of the team.

elasticmachine · 2019-04-05T21:05:29Z

💚 Build Succeeded

continuous-integration/kibana-ci/pull-request

epixa added Team:Core Platform Core services: plugins, logging, config, saved objects, http, ES client, i18n, etc t// non-issue Indicates to automation that a pull request should not appear in the release notes Feature:New Platform labels Feb 14, 2019

epixa self-assigned this Feb 14, 2019

epixa closed this Feb 14, 2019

epixa reopened this Feb 14, 2019

epixa added 8 commits February 19, 2019 21:08

migration guide up to services

6ce9168

expand on services

aca2423

challenges to overcome with legacy plugins

b3ec36e

clean up type definitions

9d4ce9f

being plan of action with typescript and angular stuff

20c3591

faq in table of contents

c3057bf

typo in typescript section

42e223d

wip architectural stuff

af2afbf

epixa force-pushed the np-migration branch from 4be566a to af2afbf Compare February 20, 2019 02:08

epixa added 8 commits February 22, 2019 09:35

expanded explanation in architecture overhaul

da594de

wip on client-side architecture changes

1f409ca

scratch pad for client migration

fb69d3a

more client-side brainstorming

c7a86b1

extending an app

329cdb1

creating a client-side extension point

2e6ff96

remove unnecessary ReplaySubject in registry shim

3477fa9

cleanup extension example

8e5305b

lukeelmers mentioned this pull request Feb 25, 2019

App Architecture roadmap for New Platform migration #31968

Closed

nreese reviewed Feb 26, 2019

View reviewed changes

src/core/MIGRATION.md Outdated Show resolved Hide resolved

epixa added 4 commits February 26, 2019 09:32

fix typo

9481898

react app example

cf8b02e

dom -> domElement

8b9dfd0

remove unnecessary imports from react app example

7d1283e

epixa added 8 commits March 15, 2019 14:49

remove old stuff

c02119b

faq

b97ad57

Revert "pseudo code for loading np browser shims"

fa65447

This reverts commit e720b27.

fix typo in browser details

7783af0

final migration notes

c511f75

talk to platform about apis and bundling

961b9ef

links in outline

5a64649

typo in outline

689a662

epixa changed the title ~~[skip ci] WIP New platform migration guide~~ [skip ci] New platform migration guide Mar 16, 2019

Update MIGRATION.md

4e714f9

mshustov reviewed Mar 18, 2019

View reviewed changes

src/core/MIGRATION.md Show resolved Hide resolved

src/core/MIGRATION.md Outdated Show resolved Hide resolved

Bamieh and others added 2 commits March 18, 2019 17:10

Update MIGRATION.md

a48e389

- Add missing return statement highlighted during meeting. - `apiExport` -> `uiExport` - Small spelling check

different wording on packages

6020919

rudolf reviewed Mar 19, 2019

View reviewed changes

peterschretlen reviewed Apr 1, 2019

View reviewed changes

epixa added 4 commits April 5, 2019 11:54

lifecycle function details

5d343de

PluginStop -> CoreStop

5f79b10

dependencies -> plugins

471ba43

Merge branch 'master' into np-migration

9bd2971

epixa added the review label Apr 5, 2019

lukeelmers approved these changes Apr 5, 2019

View reviewed changes

epixa merged commit a08535a into elastic:master Apr 5, 2019

epixa deleted the np-migration branch April 5, 2019 20:27

epixa changed the title ~~[skip ci] New platform migration guide~~ New platform migration guide Apr 5, 2019

thomasneirynck mentioned this pull request Oct 17, 2019

[Maps][File upload] Migrate Maps team apps to new platform #33514

Closed

26 tasks


		Different service interfaces can and will be passed to `setup` and `stop` because certain functionality makes sense in the context of a running plugin while other types of functionality may have restrictions or may only make sense in the context of a plugin that is stopping.

		For example, the `stop` function in the browser gets invoked as part of the `window.onbeforeunload` event, which means you can't necessarily execute asynchronous code here in a reliable way. For that reason, `core` likely wouldn't provide any asynchronous functions to plugin `stop` functions in the browser.

Conversation

epixa commented Feb 14, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

elasticmachine commented Feb 14, 2019

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lukeelmers commented Apr 5, 2019

Uh oh!

epixa commented Apr 5, 2019

Uh oh!

lukeelmers left a comment

Choose a reason for hiding this comment

Uh oh!

elasticmachine commented Apr 5, 2019

💚 Build Succeeded

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

epixa commented Feb 14, 2019 •

edited

Loading