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

[New Platform Migration Phase I]: convert timelion to vis_type_timelion #41667

Closed
8 tasks
lukeelmers opened this issue Jul 22, 2019 · 1 comment · Fixed by #43197
Closed
8 tasks

[New Platform Migration Phase I]: convert timelion to vis_type_timelion #41667

lukeelmers opened this issue Jul 22, 2019 · 1 comment · Fixed by #43197
Assignees
Labels
Feature:NP Migration Feature:Timelion Timelion app and visualization Team:Visualizations Visualization editors, elastic-charts and infrastructure

Comments

@lukeelmers
Copy link
Member

Part of #38244

Summary

The existing timelion plugin needs to be moved into its own dedicated vis_type_timelion plugin that adheres to the new platform plugin structure.

One thing to note regarding timelion is that you can currently still enable it as a standalone app via a config.yml setting (#30131). This will be removed eventually so that timelion is only available as a vis type, which is why we are renaming vis_type_timelion.

Checklist for creating a new vis type plugin

In most cases, it is recommend to break each of these steps into 3 separate PRs

  • 1. Identify all public contracts exposed by the existing service (likely not required for most vis type plugins), and create or update the new plugin to re-export the public contracts. This should be a non-breaking change. Plugin should:
    • Be a directory inside of src/legacy/core_plugins
    • Have a new platform-style plugin definition in typescript, with a setup method returning the public contract (see data plugin as an example). This needs to be exported from the top-level /server and/or /public directory, e.g. export foo = new Plugin.setup()
    • Be broken into logical "services", each with a service definition class
    • Have all static exports done from the top level plugin definition
    • Register the visualization via the "visualizations" plugin's types service.
  • 2. Update all downstream modules to import from the new location (likely not required for most vis type plugins). This should be done via relative imports: import { foo } from '../../../core_plugins/foo';
  • 3. Move the code from its original location to the new location

Background

Phase I ("Move") consists of consolidating (and in some cases separating) pieces of legacy code into the overall "shape" of the new platform architecture, while still remaining in the legacy world, as legacy plugins, consuming legacy services.

A module is done with Phase I when all of its code has been relocated to the appropriate plugin, with downstream imports for the module being updated to consume it from its new location.

@lukeelmers lukeelmers added Feature:Timelion Timelion app and visualization Feature:New Platform Team:Visualizations Visualization editors, elastic-charts and infrastructure labels Jul 22, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:NP Migration Feature:Timelion Timelion app and visualization Team:Visualizations Visualization editors, elastic-charts and infrastructure
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants