Allow multiple field formatters on one field/per visualization

[timroes]

It would be great if we could specify multiple field formatters for one field. I think the easiest way to do it, would be to be able to create "meta fields", i.e. fields that just have a different name and field formatter, but use the value of a specific other field.

The current workaround to using multiple field formatters is one of the following:

• Create a scripted field with that formatter, that just copies over the value. This require scripted fields to be executed, and even if it's just using the same value, this increases request times for larges clusters immensely (like from 4s request time to 24s).
• Create a separate index pattern, that uses a slightly different wildcard (e.g. my-docs* instead of my-docs-*), and apply the field formatter there. The huge disadvantage is, that this clutters the index patterns, and without knowledge you have no chance, seeing from which index pattern (my-docs* or my-docs-*) you need to create your visualization from to achieve what.

[chrisronline]

Interesting. So, what's the use case here exactly? If you apply multiple formatters to the same field, do you have to be concerned with which formatter is applied first, since formatters can change the entire value of the field?

[timroes]

Sorry for the confusion here. I didn't mean applying multiple field formatters on top of each other on one field, but be able to apply different field formatters on a field and use in one visualization the field using this one field formatter, and in another visualization using the field, but with another field formatter.

I would have imagined, if you apply two field formatters to a field, you have 3 fields available to chose from in the end, the raw field and the field once for each formatter applied.

The use case I see users needing that the most is URL field formatter at the moment. In the long run that can hopefully be solved by properly offering interactions on data. Until then a lot of people just use the URL formatter to link from the data field to e.g. an external webpage about that data. But this often is only relevant for one chart, and in another chart this link should not be there or to some other URL. This is currently only possible by creating multiple scripted fields, that just copy over the value of that field and apply those different field formatters. Unfortunately this can totally kill large clusters sending those scripted fields, just to copy over the value of another field. I think we should solve that in Kibana in the long run, so that we can just use the same field (without a scripted field) but having different field formatters apply to it, and the user can select which field formatter should depend for which chart.

[chrisronline]

Thanks for the clarification @timroes!

What if thought about field formats as a first class citizen and let them exist without being explicitly tied to a single field? Then, when editing a field format, you'd simply assign one or many fields to use it.

In your use case, you'd create field formats that you want to use within other areas of Kibana and those areas of Kibana will not only show fields, but also all field formats associated with the relevant index pattern.

I'm not sure the effort involved but since all (or hopefully all) area of Kibana interact with index patterns through a common api, we should be able to make these changes in one place.

This may not be a good idea so feel free to point out flaws or concerns.

[Tishinator]

+1

[iget-master]

This looks like very easy to implement and not a breaking change. Why not?

[elasticmachine]

Pinging @elastic/kibana-app-services (Team:AppServices)

[ghudgins]

Lens sort of supports this via formatter overrides (formatter on the vis level)

For more advanced cases, we plan on supporting ad hoc data views which would allow each vis to have its own formatters via the embedded data view object - #126911