fix(widgets): widget style prop keys should accept camelCase css properties and dashed css variables

[TylerMatteo]

Closes #8990

Change List

• Updated the style prop on CompassWidget, ZoomWidget, and FullscreenWidget to support camelCase CSS properties (e.g. backgroundColor) and kabab-case CSS variables (e.g. --button-size).

[coveralls]

coverage: 89.216%. remained the same
when pulling d505e3f on TylerMatteo:tm/dashcase-widget-style
into 31ff4bd on visgl:master.

[Pessimistress]

@chrisgervang if I remember right, we used to use Object.assign(element.style, style) which only worked for camel case property names. It was switched to element.style.setProperty in order to support CSS variables.

Alternatively we could just do this the dirty way by calling both of the above...

[chrisgervang]

@Pessimistress, that's correct, but I didn't account for camelCase styles. It's probably best to have a solution that supports at least variables and camelCase, or all three (even if kebab-case isn't popular).

I think there are three solutions to consider.

1. Simple to understand and supports variables and camelCase:

if (property.startsWith('--')) {
  // Assume CSS variable
  element.style.setProperty(property, value);
} else {
  // Assume camelCase
  element.style[property] = value;
}

2. The next being suggested by this PR. @TylerMatteo's solution works with all three input types. It's pretty good, but asking every widget author to understand regex isn't my preference.

3. Being explicit with handling each input.

if (property.startsWith('--')) {
  // Assume CSS variable
  element.style.setProperty(property, value);
} else if (property.includes('-')) {
  // Convert kebab-case to camelCase
  const camelCaseProperty = property.replace(/-([a-z])/g, (match, letter) => letter.toUpperCase());
  element.style[camelCaseProperty] = value;
} else {
  // Assume camelCase
  element.style[property] = value;
}

I've uploaded them into a gist for easy testing.

---

While element.style[property] = value; sometimes works with kebab-case in Chrome, it's not a standard behavior we should rely on. I think I'd prefer to go with option 1 unless there's a strong argument to support camelCase and kebab-case in JS. Core widgets are meant to be examples in themselves, so I'd like to keep them simple to read and understand.

[TylerMatteo]

@chrisgervang sounds reasonable to me - I hadn't considered css variables. Shall I go ahead and update my branch to implement solution 1?

[chrisgervang]

Yes, thank you! Could you also please take a look at the style prop docs to see if they need clarification?

[Pessimistress]

It might be easier to create a shared function applyStyles(element, styles).

[TylerMatteo]

@chrisgervang I made that change and created a shared applyStyles util added to core. Let me know if you'd prefer this change stay scoped to the widgets module.

[chrisgervang]

Great progress! Left some comments. @Pessimistress would be the one to make a call on whether she wants these utility functions in core or not. I think we could consider whether or not it'd be useful to use the Deck class too.

[chrisgervang]

Let's create a removeStyles as well. This seems useful to apply in all widgets when style has changed

[coveralls]

coverage: 91.707% (+0.005%) from 91.702%
when pulling 62a3541 on TylerMatteo:tm/dashcase-widget-style
into e9eada6 on visgl:master.