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
I have a shiny app that would greatly benefit from meaningfully named bookmarks. This implies I am interested in "local" form of enableBookmarking = "server". Currently folders beneath shiny_bookmarks are given unique names such as "392774d3be4aa0f4". I am wanting to replace this with a name that is meaningful to a user. Obviously this will never be guaranteed unique.
Please note that I am not concerned about the location or name of the shiny_bookmarks folder itself. Please you not refer me to shinyOptions(save.interface = function(id, callback) {....}) which only relates to the parent folder.
In bookmark-state.R (line 52 as of Oct 2024) the name of the folder is created using a random id; id <- createUniqueId(8)
This id is used to create the folder, path the RDS files and in the URL creation.
It would be easy to modify line 52 to: id <- getShinyOption("bookmark.name", default = createUniqueId(8))
This would allow the use of a named bookmark (folder) beneath the usual bookmarking folder (i.e. shiny_bookmarks).
The programmer would need to set shinyOptions(bookmark.name = "something") before the call to session$doBookmark()
Since I have not tested this scenario, there may be pitfalls in this approach. In particular, it would allow (and encourage) the reuse of bookmark names. Since RDS files overwrite, the danger is whether left-over RDS files might be a problem. I suspect recursively deleting files relating to a reused bookmark name can solve this issue, provided file permissions allow this.
I do know that no better workaround exists (that I have been able to make reliable.) An obvious embellishment of this feature is to include an optional doBookmark parameter; e.g. session$doBookmark(id = "something") but this is a much bigger change.
As an aside (dare I?) ...
Since I am using shiny modules heavily, I am curious why nothing appears in the bookmark subfolders that exists for each module namespace. There is some mention of saving "additional files" but I fail to imagine what or why someone would save additional files. I half expected separate value.RDS and input.RDS files for each module. Clearly this is not the case.
The text was updated successfully, but these errors were encountered:
Thanks @ismirsehregal but I am well aware of these (and other) workarounds. I guess I am more interested in a structured improvement to shiny bookmarking along the lines I am suggesting. The use of arcane bookmark names seems so unnecessary. After all, I can use onBookmarked() to rename the directory and correct the URL to match.
I have a shiny app that would greatly benefit from meaningfully named bookmarks. This implies I am interested in "local" form of
enableBookmarking = "server"
. Currently folders beneath shiny_bookmarks are given unique names such as "392774d3be4aa0f4". I am wanting to replace this with a name that is meaningful to a user. Obviously this will never be guaranteed unique.Please note that I am not concerned about the location or name of the shiny_bookmarks folder itself. Please you not refer me to
shinyOptions(save.interface = function(id, callback) {....})
which only relates to the parent folder.In bookmark-state.R (line 52 as of Oct 2024) the name of the folder is created using a random id;
id <- createUniqueId(8)
This id is used to create the folder, path the RDS files and in the URL creation.
It would be easy to modify line 52 to:
id <- getShinyOption("bookmark.name", default = createUniqueId(8))
This would allow the use of a named bookmark (folder) beneath the usual bookmarking folder (i.e. shiny_bookmarks).
The programmer would need to set
shinyOptions(bookmark.name = "something")
before the call tosession$doBookmark()
Since I have not tested this scenario, there may be pitfalls in this approach. In particular, it would allow (and encourage) the reuse of bookmark names. Since RDS files overwrite, the danger is whether left-over RDS files might be a problem. I suspect recursively deleting files relating to a reused bookmark name can solve this issue, provided file permissions allow this.
I do know that no better workaround exists (that I have been able to make reliable.) An obvious embellishment of this feature is to include an optional doBookmark parameter; e.g.
session$doBookmark(id = "something")
but this is a much bigger change.As an aside (dare I?) ...
Since I am using shiny modules heavily, I am curious why nothing appears in the bookmark subfolders that exists for each module namespace. There is some mention of saving "additional files" but I fail to imagine what or why someone would save additional files. I half expected separate value.RDS and input.RDS files for each module. Clearly this is not the case.
The text was updated successfully, but these errors were encountered: