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
Currently it's possible to add data and aria attributes to inputs created with SimpleForm by supplying a keword argument (named either data or aria) with a hash. This is extremely useful for avoiding the ugly string-based keys we'd otherwise need to use for these types of HTML attrubutes. For example:
# Without this supportf.input(:foo,input_html: {"aria-controls": "options"})# With this supportf.input(:foo,input_html: {aria: {controls: "options"}})
becomes
<inputaria-controls="options"...>
However this only works for the aforementioned aria and data attribute types. Any other hyphenated attributes must be entered in strings, leading to a patchwork of symbols vs strings and skewer-case vs snake_case being passed in these calls.
Expected Desired behavior
It would be really nice if this behaviour was expanded to support all hyphenated attributes, or at the very least a configuration option was added to be able to add to the list keys that this behaviour applies to.
Without diving too deep into SimpleForm's code, there appears to be an array of strings at lib/simple_form/inputs/base.rb:200 which is responsible for distinguishing data and aria from everything else. Would making this configurable be viable?
As an example of a use case for this desired behaviour, my team makes heavy use of Alpine.js, which relies on many x-prefixed HTML attributes - often several per element. When mixing the string-key syntax required for these attributes with data and aria attributes, the input_html hashes we pass get quite unwieldy. Setting aside cosmetics, this inconsistent behaviour can also be confusing for developers new to SimpleForm.
I appreciate this is mostly an issue of cosmetics/usability rather than an outright bug or lack of support. I figured "don't ask, don't get" applies. Thank you for taking the time to read this and for building such a useful gem.
The text was updated successfully, but these errors were encountered:
I used to miss this too but this is not a SimpleForm feature but a Rails feature. The code that you refer to seems to deal with something else than attribute prefixing: it merges the default data / aria attributes from the configuration with the ones passed in view templates. The attribute prefixing is done by ActionView in the tag_options method. Long time ago, there actually was a Pull Request to Rails that would potentially allow to prefix more attributes like this but a simpler solution was chosen.
Current behavior
Currently it's possible to add
data
andaria
attributes to inputs created with SimpleForm by supplying a keword argument (named eitherdata
oraria
) with a hash. This is extremely useful for avoiding the ugly string-based keys we'd otherwise need to use for these types of HTML attrubutes. For example:becomes
However this only works for the aforementioned
aria
anddata
attribute types. Any other hyphenated attributes must be entered in strings, leading to a patchwork of symbols vs strings and skewer-case vs snake_case being passed in these calls.ExpectedDesired behaviorIt would be really nice if this behaviour was expanded to support all hyphenated attributes, or at the very least a configuration option was added to be able to add to the list keys that this behaviour applies to.
Without diving too deep into SimpleForm's code, there appears to be an array of strings at
lib/simple_form/inputs/base.rb:200
which is responsible for distinguishingdata
andaria
from everything else. Would making this configurable be viable?As an example of a use case for this desired behaviour, my team makes heavy use of Alpine.js, which relies on many
x
-prefixed HTML attributes - often several per element. When mixing the string-key syntax required for these attributes withdata
andaria
attributes, theinput_html
hashes we pass get quite unwieldy. Setting aside cosmetics, this inconsistent behaviour can also be confusing for developers new to SimpleForm.I appreciate this is mostly an issue of cosmetics/usability rather than an outright bug or lack of support. I figured "don't ask, don't get" applies. Thank you for taking the time to read this and for building such a useful gem.
The text was updated successfully, but these errors were encountered: