Update vega vizs in sample web logs dashboard so applying filter won't cause them to look like they are erroring out

[bhavyarm]

Kibana version: 7.9.0

**Elasticsearch version:**7.9.0

Server OS version: darwin_x86_64

Browser version: chrome latest

Browser OS version: OS X

Original install method (e.g. download page, yum, from source, etc.): from staging

Describe the bug: In 7.9.0 - on weblogs sample data dashboard - if user adds particular source country and byte value in input controls - sample vega vizs display - Infinite extent for field "time": [Infinity, -Infinity] and other messages of that variety

@flash1293 told me (thank you) - its because vega viz got updated 5(#68639 (review)) and they are valid messages but unfortunately they are really unfriendly to the user who might be using Kibana and sample dashboards for the first time.

Can we either fix the messages or change the vizs so this doesn't happen?

[elasticmachine]

Pinging @elastic/kibana-app (Team:KibanaApp)

[flash1293]

@dziyanadzeraviankina I thought about this and let's go the disabling warnings route via config in the vega spec with an explanatory comment for this.

[DianaDerevyankina]

Disabling warnings by default with hideWarnings option also hides other vega warnings, which is probably barely better than showing this one caused by no results. So the question is what is more important: not showing all warnings at all or keep it as it is? @ghudgins what is your opinion on that?
I guess at least we might add hideWarnings to config with an explanatory comment to the default spec and other vega sample data visualizations, to highlight it as a way to get rid of this warning.

[ghudgins]

Warnings aren't errors right? I think hiding is okay if so. I really wish we could hide warnings only in the view mode (dashboard) but show in the editor* but I understand this might not be doable right now.

[flash1293]

@ghudgins Actually I just checked the code and I was wrong earlier today - sorry about that. We can control the way warnings work and we can just not show them at all in "view mode" (on the dashboard).

Technically it would work like this:
In the renderer, pass handlers.getRenderMode() to the component:

kibana/src/plugins/vis_types/vega/public/vega_vis_renderer.tsx

Line 32 in 33c124b

fireEvent={handlers.event}

Pass the flag to createVegaVisualization:

kibana/src/plugins/vis_types/vega/public/components/vega_vis_component.tsx

Line 35 in 33c124b

const VegaVis = createVegaVisualization(deps);

pass it to the VegaView class in the constructor:

kibana/src/plugins/vis_types/vega/public/vega_visualization.ts

Line 92 in 836abdf

this.vegaView = new VegaViewClass(vegaViewParams);

Store it in a member:

kibana/src/plugins/vis_types/vega/public/vega_view/vega_base_view.js

Line 92 in 836abdf

this._vegaStateRestorer = opts.vegaStateRestorer;

Read it in onWarn (and don't warn if it's set to "view"):

kibana/src/plugins/vis_types/vega/public/vega_view/vega_base_view.js

Line 242 in 836abdf

this._addMessage('warn', Utils.formatWarningToStr(...arguments));

But besides that - yes, errors are different and shown even if warnings are disabled.

[flash1293]

@dziyanadzeraviankina once you get to it, could you resolve it as described above by showing warnings only in edit mode?

[flash1293]

@dziyanadzeraviankina Here are the steps to set the render mode correctly for visualizations:

Add optional renderMode to the visualize embeddable input:

kibana/src/plugins/visualizations/public/embeddable/visualize_embeddable.tsx

Line 65 in 560cb6f

table?: unknown;

In

kibana/src/plugins/visualizations/public/embeddable/visualize_embeddable.tsx

Line 318 in 560cb6f

pass the mode to the expression loader (it will be handled from there)

      renderMode: this.input.renderMode || 'view',

In visualize, pass in edit render mode when creating the embeddable handler:

kibana/src/plugins/visualize/public/application/utils/get_visualization_instance.ts

Line 44 in d9ef453

searchSessionId: data.search.session.getSessionId(),

  renderMode: 'edit',

From there is should work as described above as the expression loader will forward it to the expression renderer.