[Feature] Deep conversion of data attributes in Rails tags

Hello!

I’m using Haml as template engine and during playing with new 3.0 version of Stimulus.js I came across an issue with data attributes in Rails tag helpers.

In Haml, hash passed to data param is recursively converted to HTML data tags.

For example: %a{data: { foo: { bar: { baz: "hello world" } } } } gets converted to <a data-foo-bar-baz="hello world" ></a>, where in Rails tag helpers such as = link_to(x, data: { foo: { bar: { baz: "Hello world!" } } }) gets converted to: <a href="x", data-foo="{bar: { baz: 'Hello world!' } }"></a> and only attributes from first level of nesting were processed and converted to HTML data attrs format.

This inconsistency really surprised me and I had to spent some time to realize this, because in some tags (Haml ones) i got output that was working in my case and in other tags (Rails tag helpers) they were not. I know that this is rather the Haml functionaliy than Rails problem, but i found that limiting.

My case was about dynamically generating params for a Stimulus controller action which are in format data-item-id-param="123", so generating { item: { id: { param: "123 } } } as a hash for data parameter seemed natural to me. Of course, i can play with hash keys and pass something like `{ “#{stimulus_controller_name}_id_param” => “123” but it does not feel flexible and is less readable in my opinion.

Using hashes gives more power and better tools to proccess this kind of data. Functionality to pass arguments to Stimulus actions (and just bare actions) are very powerful and I thought that Rails would be supporting Stimulus on the views as Stimulus is very useful on those and also a Railsy solution.

I’m aware that this kind of change could break older views, so I’m suggesting adding boolean parameter like deep_data_attributes (false by default) that would control whether to recursively convert those nested data hashes into HTML data attributes. If backward compatibility is not a concern then this parameter is unnecessary.

If idea gets accepted, I can provide a PR for this change.

Looking forward to your feedback and review.

Best regards!

2 Likes

Bumping post because it was hidden for some time and fell down in posts index.

1 Like

Bumping again because this should be the expected behavior!

This strikes me as a kind of fix that would be accepted if PR’ed well. And based on my prior experience, they’d probably prefer to skip the backwards-combat flag, especially if this is unintentional. Don’t forget to explain in the changelog!