Support for non-boolean `classNameBinding`

[Turbo87]

Using classNameBindings: ['foo'] is ambiguous and depends on the runtime value of the foo property.

• foo: 'BarBaz' will cause class="bar-baz"
• foo: true will cause class="foo"
• foo: false will cause class=""
• foo: '' 🤷‍♂

We will need to decide what we want to do about this. Currently the codemod skips components that use this pattern.

Alternatives:

• Introduce a helper that resolves this issue at runtime.
• Use an interactive prompt each time this pattern is encountered and ask the user if this ia s boolean or string property.

[jelhan]

There might be a third option:

• Derive the type from the default value.

This would only work for components that provide a default value for the property used in classNameBinding. It's only produces correct results if two assumptions are correct:

• The type of the value must not change.
• It must not use camelCase strings as value. (Wrong assumption that classNameBindings dasherizes string values by default. See next comment.)

Both assumptions reflect best practices and should be true for most code bases. But to not do risky transforms by default, this transform could be disabled by default. A flag could be used to enable it explicitly.

[jelhan]

• foo: 'BarBaz' will cause class="bar-baz"

This scenario seems to be wrong. classNameBindings does not dasherise a string value. Such a behavior is not mentioned in docs. Also tested with this Ember Twiddle and it applies class="BarBaz".

I guess it was confused with another scenario which is missing:

• classNameBindings: ['barBaz'] with barBaz: true will cause class="bar-baz".

camelCase property names that are used with boolean values are dasherized before being applied. This is also mentioned in documentation:

Boolean value class name bindings whose property names are in a camelCase-style format will be converted to a dasherized format: