Enable & disable predefined modebar buttons via layout and template

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!

[archmoj]

This PR moves attributes and supply default files into component/modebar, register modebar in core.js and then
resolves#5623 by introducing modebar.add and modebar.remove options.

Also this PR help simplify use of config.modeBarButtonsToRemove by accepting short name variations.
For example one could use zoomin instead of zoomIn2d to disable zoom in buttun.

@plotly/plotly_js

"add": {"flags": ["v1hovermode","hoverclosest","hovercompare","togglehover","togglespikelines","drawclosedpath","drawopenpath","drawline","drawrect","drawcircle","eraseshape"]},"remove": {"flags": ["autoScale2d","autoscale","editInChartStudio","editinchartstudio","hoverCompareCartesian","hovercompare","lasso","lasso2d","orbitRotation","orbitrotation","pan","pan2d","pan3d","reset","resetCameraDefault3d","resetCameraLastSave3d","resetGeo","resetSankeyGroup","resetScale2d","resetViewMapbox","resetViews","resetcameradefault","resetcameralastsave","resetsankeygroup","resetscale","resetview","resetviews","select","select2d","sendDataToCloud","senddatatocloud","tableRotation","tablerotation","toImage","toggleHover","toggleSpikelines","togglehover","togglespikelines","toimage","zoom","zoom2d","zoom3d","zoomIn2d","zoomInGeo","zoomInMapbox","zoomOut2d","zoomOutGeo","zoomOutMapbox","zoomin","zoomout"]}

[nicolaskruchten]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

[archmoj]

I thought we'd settled on layout.modebar.(add|remove) ? No "buttonsto"

Renamed in aeb1626.

[nicolaskruchten]

Thanks! Is implementing "remove" a lot of additional work?

[archmoj]

Thanks! Is implementing "remove" a lot of additional work?

Maybe no. But the need for that is not clear? Is it to hide every possible button? Not these hidden by default ones?

[nicolaskruchten]

For symmetry and yes, to be able to remove additional buttons like the zoom buttons for example or home/reset-axes

[nicolaskruchten]

Basically a layout equivalent to config.modebarButtonsToRemove which gets used fairly often in the wild.

[alexcjohnson]

Trying to think if there are any cases we need to explicitly deal with precedence of config over layout. That's the way we decided it should work, right?

If config adds a button that layout has asked to remove, it can add it via the full object, but the string versions aren't defined in the add section below.

And if config removes a button that layout has asked to add, since removal happens first it won't be available yet when it's expected to be removed, so it will appear anyway.

So it seems like these concat need to filter out layout items that are in the opposite context entry.

[archmoj]

Good call. Addressed in 3daa2f3.

[alexcjohnson]

Using a flaglist here is convenient for validation, but it's different from the API we use for config, an array. Here we don't need to support the object form, which obviously wouldn't fit in a flaglist, I just wonder if ease of validation is sufficient reason to differ. @nicolaskruchten thoughts?

[nicolaskruchten]

I prefer an array, like in config

[archmoj]

Addressed in 5c17d6b and 3293097.

[alexcjohnson]

💃 looks good. Great tests!