In case this is helpful

Spaces in IDs aren't supported. It could help if we added a check for this and throw an error if someone tries to use it.

Yeah, it's definitely funny that including spaces works for setting ids, retrieving values, but not updating widgets, all without an error. It should definitely throw an error and be mentioned in the help pages for selectInput, numericInput, etc

This article provides a short note regarding special JavaScript characters in input id's:

You are not recommended to use special JavaScript characters such as a period . in the input id's, but if you do use them anyway, for example, inputId = "foo.bar", you will have to use input["foo.bar"] instead of input.foo.bar to read the input value.

An error message would be quite helpful 👍

Would a pull request that threw an error on bad inputIDs be welcome? I saw a note in the docs that said anything that creates backward compatibility issues would not be welcome. Since spaces in IDs work for many scenarios, there is probably a lot of functional code out there that would no longer work if this started throwing errors.

If it would be welcome, I would be open to trying if someone can point me in the direction of "these are the files that would need to change."

We'd definitely take a look at the PR, but note that there may be some tricky stuff involved to get all the details right. We definitely don't want to break existing apps, so it would be better to throw a warning than an error.

Spaces in IDs aren't supported. It could help if we added a check for this and throw an error if someone tries to use it.

Is there any mention of this being unsupported in the formal documentation? I just spent the better part of a week debugging a glitchy app and finally isolated the root cause to be the use of an inputId containing spaces (it was being dynamically generated from another variable whose value contained spaces).

We'd definitely take a look at the PR, but note that there may be some tricky stuff involved to get all the details right. We definitely don't want to break existing apps, so it would be better to throw a warning than an error.

How about something like options(shiny.inputid.strict = TRUE) to allow users to "opt-in" to strict validation of their inputIds?

Well hidden, but see the note here:

You are not recommended to use special JavaScript characters such as a period . in the input id's, but if you do use them anyway, for example, inputId = "foo.bar", you will have to use input["foo.bar"] instead of input.foo.bar to read the input value.

However, the space restriction seems to be inherited from HTML:

An id's value must not contain whitespace (spaces, tabs, etc.). Browsers treat non-conforming IDs that contain whitespace as if the whitespace is part of the ID. In contrast to the class attribute, which allows space-separated values, elements can only have one single ID value.

Browsers are funny like that: an ID must not contain whitespace, but if it does we'll consider the whitespace part of the ID.

I strongly recommend avoiding whitespace in input IDs, but given that almost anything will work in the browser – and most if not all of our inputs will work fine with spaces in them – I don't think we should be more aggressive unless we have a strong reason to do so. (In other words, if spaces in an ID break a specific input, we should proactively avoid those issues early.)

In this case, we can support input updates when spaces are involved by changing our JavaScript internals to use a CSS selector that queries by attribute value. E.g. the #spaced id selector will target an <id> element that's a child of an element with id="spaced", whereas [id="spaced id"] will find an element with id="spaced id". I've proposed an update in #3852 that fixes our input update methods, but also throws a warning message in the browser's developer console when spaced IDs are encountered.