Ok. So {sortable} needs to not set the id values directly. Ex:

• Mainly:

  sortable/R/bucket_list.R

  Line 154 in 8e24b8f

  id = paste0("bucket-list-", css_id),

• But also:

  sortable/R/bucket_list.R

  Line 17 in 8e24b8f

  input_id <- increment_rank_list_input_id()

When these values are set, they are unaware of the NS that is being used within a module.

Reasoning:

• update_bucket_list() calls session$sendInputMessage(id, msg). Link
• Within a module, sendInputMssage will prepend the module's ID in front of the supplied id. Link
• So the message in the example app is being sent to an id of "bucket_lists-bucket-list-bucket_list_group". ({namespace}-{sortableprefix}-{cssid}).

I'm too far removed from the code to remember why I used css_id and regular input_id`. Seems odd to me. 😞

If the css_id were to be altered by adding a suffix (rather than a prefix), it could be used within modules if exposed in the function api. But this seems like a bandaid on top of a bandaid. This change would most likely be a breaking change for some users.

Originally posted by @schloerke in #95 (comment)

I had proposed another solution but it does not fully work with modules. I think we need to revisit why we have both css_id and input_id and why css_id gets a prefix.

If we can at least make it a suffix, then module name spaces (shiny::NS()) can be applied

Thank you for investigating and elaborating @schloerke 🙏

I think we need to revisit why we have both css_id and input_id and why css_id gets a prefix.

This seems like the key question, I was guessing that perhaps there was some reason related to how SortableJS works, but I'm not familiar enough with the library to know.

I assume this is something that needs input from the other devs working on sortable and I should standby before working on a PR?