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

Prep visualizations plugin for NP migration. #44839

Merged
merged 10 commits into from
Sep 10, 2019

Conversation

lukeelmers
Copy link
Member

This is a follow-up PR which reverts some of the changes introduced in #44644 as a part of resolving #44306.

I added a comment with some feedback on the original PR, and also have been working on a draft PR that accomplishes some similar things.

Notes on my changes are below; let's discuss further in this PR if anyone has additional feedback so that we are all aligned on conventions we want to use.

This PR implements some feedback on #44644 by making the following changes:

  • Reverts changes to imports which were pulling shim contracts from the np_ready directory. I realize this is how embeddable_api currently implements that directory, but I would argue that we shouldn't expose usage of np_ready directory to consumers of the shim as it introduces confusion and is subject to change. I propose only exporting shims from a top level public/legacy, which is what we have already documented in MIGRATION.md anyway.
  • kibana.json manifest moved to the top level & added data plugin as dependency
  • public/np_ready/public felt like a redundant directory structure, so moved items to np_ready directly
  • Moved mocks up to public/mocks since they included bypasses for the eslint imports rule, which by definition means they aren't "np_ready"
  • Updated the names used in shim imports to be visualizationsSetup to be consistent with how we've named other shims. This is also consistent with the VisualizationsSetup public interface we export.
  • Removed visTypeAliasRegistry from the legacy setup dependencies, as this is already NP ready

This PR also replaces #43730 by making the following changes:

  • Updates structure of vis plugin for consistency with our shimming conventions
  • Ensures public contracts from ui/vis that need to live in the visualizations plugin are re-exported
  • Added some clarifying comments for future devs

Next steps / other considerations:

  • Should consider renaming / tweaking the interface for visTypeAliasRegistry as we do further work on this plugin. visualizations.types.visTypeAliasRegistry seems awkward. visualizations.types.registerVisualizationAlias might make more sense?
  • Consider updating embeddable_api as well to use the same np_ready structure. Not sure if this is worth the effort as we are quite close to completing migration on this.
  • Audit the legacy/NP migration table in MIGRATION.md to ensure it is consistent with the new implementation. That way people know where to find the shims they need.
  • Actually move the code and re-export legacy contracts from ui/vis and follow the rest of the steps in Visualizations 👉 New Platform #44121

@lukeelmers lukeelmers added review Feature:Visualizations Generic visualization features (in case no more specific feature label is available) v8.0.0 Team:AppArch release_note:skip Skip the PR/issue when compiling release notes v7.5.0 Feature:NP Migration labels Sep 4, 2019
@lukeelmers lukeelmers self-assigned this Sep 4, 2019
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-app-arch

@elasticmachine
Copy link
Contributor

💔 Build Failed

@mattkime
Copy link
Contributor

mattkime commented Sep 5, 2019

Reverts changes to imports which were pulling shim contracts from the np_ready directory. I realize this is how embeddable_api currently implements that directory, but I would argue that we shouldn't expose usage of np_ready directory to consumers of the shim as it introduces confusion and is subject to change. I propose only exporting shims from a top level public/legacy, which is what we have already documented in MIGRATION.md anyway.

Should we change embeddable_api? People often learn by example.

@sainthkh
Copy link
Contributor

sainthkh commented Sep 5, 2019

Thanks for the thorough review and improvements. Your code is better than mine. I agree with your changes.

When I was writing np_ready, I learned the convention from the current code base.

  • I learned importing setup from public/legacy from 2 modules: embeddable_apiand core_plugins/data.
  • I learned public/np_ready/public structure from embeddable_api and dashboard_embeddable_container.

And I agree with @mattkime. We learn by examples. Many future developers/contributors will read how current plugins are implemented and learn from them. Actually, that's what I did.

So, I think making these 3 modules follow the new rules (no import from legacy and no public/np_ready/public) will be good for new developers as a reference.

Actually, I thought about moving embeddable_api to src/plugins now. But it's impossible now because it's used in dashboard and discover, etc. We will need setup shim anyway.

And how about adding setup as a shim example to Bonus: Tips for complex migration scenarios section in MIGRATION.md?

Copy link
Member

@ppisljar ppisljar left a comment

Choose a reason for hiding this comment

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

code LGTM, however tests are currently broken

@streamich streamich mentioned this pull request Sep 5, 2019
13 tasks
@lukeelmers
Copy link
Member Author

lukeelmers commented Sep 5, 2019

Thanks for the thorough review and improvements. Your code is better than mine. I agree with your changes.

Thanks @sainthkh - but there's no "better" or "worse" here, just a question of how to make everything consistent. Your contribution got the conversation started, which is the most important thing ❤️

Actually, I thought about moving embeddable_api to src/plugins now. But it's impossible now because it's used in dashboard and discover, etc. We will need setup shim anyway.

@stacey-gammon or @ppisljar Do you think it is worth shuffling the directories around for the shims to be consistent in embeddables_api? Considering that we are hoping to move it fully to the new platform in the nearer term, I'm not sure if it is worth taking the time to make this change if the shim will soon be removed anyway?

And how about adding setup as a shim example to Bonus: Tips for complex migration scenarios section in MIGRATION.md?

This is a great idea, we could probably be more explicit here since we only briefly reference np_ready.

@sainthkh
Copy link
Contributor

sainthkh commented Sep 6, 2019

@lukeelmers If you think fixing embeddables_api is too much for now, it would be a good idea to write things like "It is recommended to follow the directory structure of visualizations in future plugins." in MIGRATION.md doc.

@stacey-gammon
Copy link
Contributor

Actually, I thought about moving embeddable_api to src/plugins now. But it's impossible now because it's used in dashboard and discover, etc. We will need setup shim anyway.

It's not impossible actually, legacy plugins can use new platform plugins, so we can move forward with this... I think now actually. I know Vadim had it on his radar, but will be out for a few weeks. I'm pretty sure this was the last blocker (#43416) and it's merged (the only blockers are actually if the embeddable api is using legacy stuff - that can't happen, so all legacy dependencies need to get moved over first.). So if you are interested you should be able to tackle that and that would be awesome! Though... you should probably wait till #44707 is merged, otherwise there will be a ton of merge conflicts. You could also try working off it cherry-picked but no telling how much will change during review process.

@lukeelmers
Copy link
Member Author

retest

@lukeelmers
Copy link
Member Author

Do you think it is worth shuffling the directories around for the shims to be consistent in embeddables_api? Considering that we are hoping to move it fully to the new platform in the nearer term, I'm not sure if it is worth taking the time to make this change if the shim will soon be removed anyway?

@stacey-gammon and I discussed and agreed that we don't need to prioritize updating the embeddables shims since we are looking to move to NP soon enough anyway. However, if whoever works on the embeddables > NP move finds it easier to update the shims as part of that process, they are of course free to do so.

@elasticmachine
Copy link
Contributor

💚 Build Succeeded

@lukeelmers lukeelmers merged commit 6039709 into elastic:master Sep 10, 2019
@lukeelmers lukeelmers deleted the fix/vis-plugin branch September 10, 2019 19:02
rylnd added a commit to rylnd/kibana that referenced this pull request Sep 10, 2019
* master:
  Prep visualizations plugin for NP migration. (elastic#44839)
jloleysens added a commit to jloleysens/kibana that referenced this pull request Sep 11, 2019
…ation_behaviour

* 'master' of github.com:elastic/kibana: (24 commits)
  [Console] SQL template with triple quote in completion (elastic#45248)
  [ML] Data Frames: Cards as links (elastic#45254)
  fix(code/frontend): should show updating instead of cloning when updating (elastic#45238)
  fix(code/frontend): fix document search result from (elastic#45236)
  disable another flaky suite (elastic#45323) (elastic#45330)
  disable flaky suite (elastic#45105)
  skip flaky suite (elastic#43069)
  skip flaky suite (elastic#45089)
  disable jest suite that has no enabled tests (elastic#44250)
  disable flaky test (elastic#45317)
  disable flaky test (elastic#45315)
  [DOCS] Creates developer folder (elastic#45280)
  [SIEM] Changes ML conditional links to use tabs, fixes a small bug with null filterQuery   (elastic#45218)
  [skip-ci][Maps] Update search docs (elastic#45307)
  Revert "[skip ci][Maps] Update search document section with ne… (elastic#45301)
  Prep visualizations plugin for NP migration. (elastic#44839)
  Replace Discover chart with elastic-charts (elastic#43788)
  [skip ci][Maps] Update search document section with new features (elastic#44819)
  Revert "Revert "[ci] compress jobs for CI stability" (elastic#44584)"
  add src/plugins to the list of plugin dirs to watch (elastic#45033)
  ...

# Conflicts:
#	src/legacy/core_plugins/console/public/src/utils.js
#	src/legacy/core_plugins/console/public/tests/src/utils_string_expanding.txt
wylieconlon pushed a commit to wylieconlon/kibana that referenced this pull request Sep 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature:NP Migration Feature:Visualizations Generic visualization features (in case no more specific feature label is available) release_note:skip Skip the PR/issue when compiling release notes review v7.5.0 v8.0.0
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants