You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
RevealView has a property called canSaveAs which hides the "Save As" option, but it doesn't have a canSave to hide the normal "save" option.
The docs propose to use canEdit = false to disable saving, but that also hinders editing the dashboard, not just disables saving, so it's not the same.
Describe the solution you'd like
Having a canSave property in RevealView akin to canSaveAs. So I could have canEdit = true and canSAve=false at the same time in order to allow users using Reveal's editor but handling the save myself.
Describe alternatives you've considered
Making Reveal's button a Noop
It's possible to give make RevealView.onSave = () => {} so when the users press Reveal's Save button nothing happens. Although this would disable the functionality of that button, the button would still be in the UI, which would be confusing for our users as in the visualization editor the checkmark button does work for saving.
Hiding Reveal's button with CSS
It was proposed here in Discord that I use CSS to hide the Save button. But that would be more of a hack, which would make my code prone to break with every release: at any time the Reveal team can change the id of that button and my code would break silently (it would compile fine).
Because that button's id is not part of the public API, but an implementation detail, it's not going to be posted to the changelog when it changes. Unlike other breaking changes the Reveal Team does, which are posted to the changelog.
Besides the changelog, adding a different property is more future-proof as even if the Reveal Team changes the name of the property later, we'll notice at compilation time that the old name is not valid.
Additional context
We want to start using our own Save button which will display a dropdown with more options, as we have an in-house catalog and functionality to organize the dashboards in folders, so we want to give our users more features.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe.
RevealView has a property called
canSaveAs
which hides the "Save As" option, but it doesn't have acanSave
to hide the normal "save" option.The docs propose to use
canEdit = false
to disable saving, but that also hinders editing the dashboard, not just disables saving, so it's not the same.Describe the solution you'd like
Having a
canSave
property in RevealView akin tocanSaveAs
. So I could havecanEdit = true
andcanSAve=false
at the same time in order to allow users using Reveal's editor but handling the save myself.Describe alternatives you've considered
Making Reveal's button a Noop
It's possible to give make
RevealView.onSave = () => {}
so when the users press Reveal's Save button nothing happens. Although this would disable the functionality of that button, the button would still be in the UI, which would be confusing for our users as in the visualization editor the checkmark button does work for saving.Hiding Reveal's button with CSS
It was proposed here in Discord that I use CSS to hide the Save button. But that would be more of a hack, which would make my code prone to break with every release: at any time the Reveal team can change the id of that button and my code would break silently (it would compile fine).
Because that button's id is not part of the public API, but an implementation detail, it's not going to be posted to the changelog when it changes. Unlike other breaking changes the Reveal Team does, which are posted to the changelog.
Besides the changelog, adding a different property is more future-proof as even if the Reveal Team changes the name of the property later, we'll notice at compilation time that the old name is not valid.
Additional context
We want to start using our own Save button which will display a dropdown with more options, as we have an in-house catalog and functionality to organize the dashboards in folders, so we want to give our users more features.
The text was updated successfully, but these errors were encountered: