Usage of CustomElement bindable variables with camelCase names

[MeirionHughes]

Stumbled across this: https://github.com/aurelia/binding/issues/307

So <template bindable="testStep"> is converted to test-step. Might be worth detecting camelcase and warning about it. Should have an option to disable rule in config.

given

<template bindable="testStep">
  ${testStep}
</template>

valid usage :

<my-component test-step="test"> ${testStep} </my-component>

The warning should appear if you use camelCase names when binding values, i.e.:

<my-component testStep="test"></my-component>

[MeirionHughes]

Should be able to achieve this with a config parameter to AttributeValueRule

[MeirionHughes]

works, misses duplicate attribute check https://github.com/MeirionHughes/template-lint/issues/25

[genne]

May I ask for the reason of this rule? If you get a warning when writing camelCase names, what is the recommended way of writing it? For example

<template bindable="testStep">
  ${testStep}
</template>

And you use it like this:

<my-component test-step="test"></my-component>

Isn't this just how you're supposed to write your Aurelia components? The warning, IMO, should appear if you use camelCase names when binding values, i.e.:

<my-component testStep="test"></my-component>

[MeirionHughes]

I think the original thinking was to avoid using camel-case due to the conversion; but you are right...

<template bindable="testStep">
  ${testStep}
</template>

... is perfectly valid; the real issue trying to use <my-component testStep="something">...

You can disable this for now by clearing the attributeValueOpts entry or disabling the AttributeValue rule entirely. I will rework the rule in the rework branch.

[AdamWillden]

This ☝️ is our most common mistake and I just wanted to voice my support of this feature.

Can I also recommend that the top post be updated to explain the new purpose of this issue.

[MeirionHughes]

Problem with this one is I'm using parse5 for the html parsing, with strips out casing information of attributes; so its not readily available to detect the camel-case in the first instance.

In the next version this should hopefully be achieved for free anyway because it'll warn about missing attributes. Bar that, I could potentially check the bindables of the custom element, convert them to lowercase, then see if they match up.