[Canvas] Remove Flot from Canvas Visualizations

[clintandrewhall]

Introduction

Since its inception, Canvas has used flot for its charts. This imposes a number of restrictions:

• it relies on jQuery, of which no other components require
  • this unnecessarily increases the Canvas bundle size, which we're working to reduce
• as the sole consumer of flot, Canvas requires deep knowledge which isn't shared elsewhere in Elastic
  • this makes bugs difficult to track and fix
  • enhancements are also next to impossible to plan
• Canvas has wholesale copies of OSS code (e.g. pie

The goal is to remove both flot and jQuery in Canvas.

Considerations

We cannot replace flot in a minor release. Canvas is a "pixel-perfect" tool, and replacing flot means that workpads will change... in a significant or minor way, it doesn't really matter. Upgrading from 7.x to 7.x+1 shouldn't result in Canvas-rendered charts being different.

Therefore, we're planning to remove flot in 8.0/9.0. As a result, we need to plan for its removal now.

Options

We have a two options-- one pragmatic, one bold:

1. Replace flot with Elastic Charts.
2. Replace flot-based Canvas elements with embedded Lens/Visualize objects.

Replace flot with Elastic Charts

We could choose to remove flot and render EC visualizations instead.

Pros

• Little-to-no change to expressions within a 7.x workpad, (though some options may be disabled or deprecated, e.g. if EC doesn't support some styling toggle).
• Upward enhancements to an Elastic library.
• Support from an Elastic team.

Considerations

• @poffdeluxe spent some time playing with replacing flot with Elastic Charts. Some time has passed since, but, at the time, there were some gaps between what EC and Canvas could present. We'd have to decide whether to fill those gaps or live with the differences.
• If Lens adoption gains traction, we may end up deprecating Canvas visualization elements anyway, which would mean this was a lot of effort for little gain.

Replace flot-based Canvas elements with Lens/Visualize

We could choose to double-down on the amazing experiences Lens/Visualize provide. Canvas could choose to drive people to Lens to create new visualizations on workpads, rather than create them within Canvas.

Note: this is not an either/or proposition. We could deprecate Canvas elements in 8.0 and encourage Lens in the interface.

Pros

• Ecosystem-aligning move that would allow Canvas to focus on "what it does best".
• Likely where Kibana is going in the future.

Considerations

• Major change that would leave previous workpads broken in some way.
  • There is no way we'd be able to migrate Canvas expressions wholesale to Lens without plenty of failures. IMO, we'd have to decide to let those break, (see below for contingency).
• Power users of Canvas-- those who can write expressions in very specific ways-- would have to rely on Lens to provide the same kind of flexibility.
  • We could overcome this with the inherent extensibility of Canvas, doubling-down on external plugins for Canvas-specific expressions and visualizations.

Plan

As I see it, there are a few ways to plan to remove flot in Canvas:

1. Migrate to Elastic Charts in 8.0
2. Move to Lens Embeddables in 8.0
   a. Show elements in error with migration tips/wizard to Lens;
   b. Leave flot-based expression code in place to support older workpads; remove in 9.0;
   c. Migrate flot-based expressions to a Kibana plugin (installable by Fleet?) that people would have to install for older workpads to work?
3. Leave flot in 8.0, move to Lens Embeddables in 9.0.
   a. Provide "heads up" opportunities in 8.0 that prepares users for the change.

Personally, I am leaning toward Plan Option 2. It rips off the band-aid early and frees us up to focus. As Lens and Canvas both gain traction, it's going to be much harder to train people off the experience they're used to in Canvas without pain. I'm also wary of investing time in moving to Elastic Charts only to see Lens embeddables surpass Canvas elements.

[elasticmachine]

Pinging @elastic/kibana-presentation (Team:Presentation)

[rayafratkina]

My 2cents is: not option 3. Removing flot in 8.0 should be a high priority for the team - 9.0 is just too far away.
I would love for us to be able to get to Option 2 since it is the strategic direction we want (and for all the reasons Clint noted), but I would be ok with option 1 if the team decides that option 2 is not feasible.

[timductive]

I'm a little confused on how we propose to do Option 2. Would we still leave flot in for backwards compatibility and just remove Canvas elements from being added? @clintandrewhall

[clintandrewhall]

@timductive a, b and c are options for approach 2, which each address your question in different ways:

a. Remove flot and allow the elements to show errors, with link to help docs to migrate the expression to Lens?
b. Leave flot code in place, but not allow new workpads/elements to be created, (e.g. "read-only" expressions)
c. Move all of the flot code and expressions to a Kibana plugin, and allow people to install the plugin to make their workpads backward compatible.
d. Some other approach..?

[timductive]

Thanks @clintandrewhall as per our discussion it would be nice to have some telemetry on flot usage and some effort R&D for option b vs c.

[clintandrewhall]

Closing in favor of #101377