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

Have maps use url generators and ui actions for discover -> maps drilldown. #61841

Closed
timroes opened this issue Mar 30, 2020 · 7 comments
Closed
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation technical debt Improvement of the software architecture and operational architecture

Comments

@timroes
Copy link
Contributor

timroes commented Mar 30, 2020

In #58549 code was introduced in the discover plugin, that links to the maps application. This code should not live inside the discover plugin, but should instead be an API of the maps plugin directly (or using the uiActions system, but also be implemented in Maps, see #25247), so that the maps plugin itself is responsible of taking care of updating those implementations.

The code in discover should be replaced by that API within the Maps application as soon as it's available.

@timroes timroes added [Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation technical debt Improvement of the software architecture and operational architecture labels Mar 30, 2020
@elasticmachine
Copy link
Contributor

Pinging @elastic/kibana-gis (Team:Geo)

@thomasneirynck
Copy link
Contributor

What API do you have in mind? In this case, the API is the URL-query arguments. How would this new API be meaningfully different? (e.g. wrt "[Maps] taking care of updating those implementations").

@timroes
Copy link
Contributor Author

timroes commented Mar 30, 2020

I would imagine that the API would look aroundish like:

plugins.maps.openMapsApplication({
  fields: [
    { indexPattern, field, type }
  ],
  filters,
  queries,
});

The new API would in so far be different, that the contract exposed to other plugins, is an actual TypeScript function call, that is completely typed and documented, and the implementation to build the URL from it it an implementation concern of that plugin. We've in the past just seen linking between applications fall apart more often, why we want to have a clear separation of concerns to the plugins responsible for it.

@timroes
Copy link
Contributor Author

timroes commented Mar 30, 2020

The uiActions system actually might be a nicer approach here, so that Discover can just trigger an event for VISUALIZE_GEO_POINT, and Maps can register for this, so the problem with OSS vs. x-pack code is also handled automatically by the system.

@nreese
Copy link
Contributor

nreese commented Mar 30, 2020

We've in the past just seen linking between applications fall apart more often, why we want to have a clear separation of concerns to the plugins responsible for it.

There are functional tests verifying this behavior so there is less risk of unintended breakage.

Is uiActions system implemented yet, or is that something coming in the future?

@stacey-gammon
Copy link
Contributor

stacey-gammon commented Apr 1, 2020

++ this is a great candidate for both uiActions and a new urlGenerator. The uiAction would use the maps urlGenerator to create the link.

The URL generator is beneficial because:

  • it handles backward compatibility
  • it will be used by alerting and background searches. So if you want maps to work like dashboards will for slow queries and be able to "save to background" and show up as a link in the background searches, you'll need to use a url generator. The URL generator is used in these places where links are persisted inside saved objects because it handles backward compatibility. You won't end up with a saved object with a link stored inside of it that might end up broken in future releases.

If you run with yarn start --run-examples you can see the examples for url generators.

The uiActions is beneficial here as well, because:

  • Discover app (oss code) doesn't need any direct knowledge of maps app (commerical code)
  • "Open in maps" could be an action that shows up automatically, not just in discover, but any other place in Kibana where the VISUALIZE_GEO_POINT trigger was emitted - whether you click on a geo point in SIEM, in APM, in a dashboard visualization. You get the "open in maps" app navigation everywhere. (albiet that is contingent on those solutions emitting the trigger as well).

It nicely decouples solutions from each other. Solutions only need know about the available triggers, they don't need to know about any other solutions that may attach actions to those triggers. These triggers can also be used eventually to let end users hook their own actions in.

This was a diagram I built to highlight this potential awhile ago, and it even has the "view location in maps" action (just imagine the data as a geo point instead of IP address):
Screen Shot 2020-04-01 at 9 26 26 AM

uiActions exist today! We also have an example plugin using them, which you can see via yarn start --run-examples , and opening the Ui Action Examples app.

If you need any help or more explanation of this, lmk!

@stacey-gammon stacey-gammon changed the title Create an API in the maps plugin to link to it Have maps use url generators and ui actions for discover -> maps drilldown. Apr 10, 2020
@nreese
Copy link
Contributor

nreese commented Nov 18, 2020

Closed by #74121

@nreese nreese closed this as completed Nov 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Deprecated-Use Team:Presentation]Team:Geo Former Team Label for Geo Team. Now use Team:Presentation technical debt Improvement of the software architecture and operational architecture
Projects
None yet
Development

No branches or pull requests

5 participants