Is it possible to bypass the camel-casing of properties?

[daveyarwood]

Hello! Thank you for Helix, it's fantastic. 🙌

I'm trying to add a custom, kebab-cased logical-id property on various elements in our UI for testing purposes, but I discovered that if the element is a native one, Helix automatically converts the names of all of its properties into camel-case.

Is it possible to opt out of this behavior, at least for certain properties, or on a per-element basis? Or do you have any other thoughts on how to address this? I cannot change the name of the property, as we are already using kebab-case in our tests.

[daveyarwood]

Potentially related to #9.

[lilactown]

For test IDs and other custom attributes that you don't want to be munged, you can prefix data- to the beginning and it should not be camelCased. E.g.

(d/button {:data-testid "foo-button"} "Foo")

See

helix/src/helix/impl/props.cljc

Line 11 in 6d86748

(defn camel-case

for reference, above it is a regex with other prefixes that don't get camelCased - at the moment aria- and -- attributes.

Hope that helps!

[daveyarwood]

In our case, the trouble is that the tests are expecting certain elements to be identified with the property logical-id, not e.g. data-logical-id.

[lilactown]

Maybe a silly question, but could you change the tests? AFAIK best practices for DOM testing is to use data- attributes, see https://docs.cypress.io/guides/references/best-practices#Selecting-Elements and https://testing-library.com/docs/queries/bytestid/.

The usage of data attributes for this is to ensure that future changes to the DOM spec don't end up changing the behavior of the elements you've attached the attributes to. See https://developer.mozilla.org/en-US/docs/Learn/HTML/Howto/Use_data_attributes

I can think about other fixes for this, but in general it will behoove you to store and lookup this type of information in data- attributes.

[daveyarwood]

Thanks for the information, this is helpful!

We would prefer to avoid renaming the attributes, since we are already using the non-data-prefixed version in a ton of places, but we could do it if we have to.

We might also be able to work around this by using non-native elements (e.g. MUI Box), since the properties are passed through unchanged for those.

[lilactown]

ebe00d0 allows string keys to be used to pass props to DOM elements verbatim. E.g.

(d/button {"logical-id" "foo"} "Foo")

This will go out in the next release. You're welcome to use it via git deps for now.

However, again, I would strongly encourage you to migrate your tests to use data- attributes, as it is industry best practice to do so and guarantees that your tests won't break in subtle ways later. Assuming this application (and tests) will live on for years, it's probably worth the investment now to do so.

Either way, thanks for the report! I'll close this for now. If you do try out the string keys functionality and you find any bugs, please open another issue.

[daveyarwood]

That all sounds good - thanks for the fast response!