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

More expressive field formatters via custom directives #4361

Closed
w33ble opened this issue Jun 30, 2015 · 20 comments
Closed

More expressive field formatters via custom directives #4361

w33ble opened this issue Jun 30, 2015 · 20 comments

Comments

@w33ble
Copy link
Contributor

w33ble commented Jun 30, 2015

As mentioned in #4357, a user may want to query another data source (elasticsearch or otherwise) to resolve that value to a label. We'd like to have a way to make field formatters more powerful and allow users to do things like this.

The current proposal is to allow users to create custom directives and use them in field formatters. This would give them access to $http, the courier, and any other resources they may need.

@cmbaxter
Copy link

cmbaxter commented Jul 1, 2015

This sounds great and I very much am looking forward to it being included in Kibana. A quick question on the approach though. Say I define a new formatter for a field that makes an http request to get the label info. If I'm on the Discover tab and I pull back a few hundred rows and all of them contain the same value for an id field (say productId) that I defined that new formatter for, will it make hundreds of queries to my rest endpoint to get the labels even though it's all the same id? I guess what I'm suggesting is that the code for this new feature be smart enough to only hit the rest endpoint once per unique field value it is applying the new formatter to.

@w33ble
Copy link
Contributor Author

w33ble commented Jul 2, 2015

Yeah, we'll need to memoize the request somehow so that the formatter knows that that product id is what's determining the label and only makes the request once per id. Ideally we'll be able to do this either automatically or via some very simple config of handler as part of the directive.

@spider-network
Copy link

+10^10

It will be grade to create a mapping index.

@roynasser
Copy link

+1 for a way to map IDs to values on another index or lookup mapping, for cases when the values be changed from the time they were logged to when they are being displayed (i.e. to obtain fresh user data from a user ID, etc).

@hadiartik
Copy link

+1 for the lookup capability in Kibana

@jpcruveilher
Copy link

+1

@guruxu
Copy link

guruxu commented Jun 17, 2016

👍👍👍
or make fields in inner_hits fully accessible

@scampi
Copy link
Contributor

scampi commented Jun 20, 2016

@w33ble it is already possible to have a custom directive when using a table https://github.com/elastic/kibana/blob/4c535f6/src/ui/public/directives/rows.js#L41
However, I am not sure that this is respected everywhere.

Field formatters return two implementations, i.e., html and text. In places where the text implementation is taken, a custom directive wouldn't be taken I think.

This issue seems related to #6416 and might provide a solution for it too, if the above problem is resolved.

@fhasanaj
Copy link

+1

4 similar comments
@hashimmm
Copy link

+1

@afrobeard
Copy link

+1

@faizana
Copy link

faizana commented Jun 21, 2016

+1

@zakirmehmood
Copy link

+1

@gokhancamas
Copy link

+1

4 similar comments
@literarymachine
Copy link

+1

@cinhtau
Copy link

cinhtau commented Aug 22, 2017

👍

@markchagers
Copy link

+1

@xav-p
Copy link

xav-p commented Sep 22, 2017

+1

@jag959
Copy link

jag959 commented Sep 27, 2017

+1

@cjcenizal
Copy link
Contributor

We're moving from Angular to React, so the details of this issue won't be applicable. #3585 proposes the addition of custom scripts for field formatters which I believe would address the original intent behind this issue. Closing in favor of #3585.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests