Align property & attribute assignments

[hmans]

What's in this PR?

• Massively reduce the complexity of our attributeChangedCallback implementations
• Align attributes and properties; properties on elements can now be exposed as (kebab-cased) attributes, eg. ThreeScene.backgroundColor now can be set via <three-scene background-color="...">. Properties need to be white-listed via the new exposedProperties static property.
• For this to work well, we could no longer assign object instances or DOM CSS selectors to the same attributes/properties. In order to implement element references cleanly, this PR introduces attribute directives, eg. <three-scene ref:camera="#cam">. This is necessary because some frameworks (like Preact) will automatically assign the attribute value directly to a property of the same name if that property exists, which would require us to perform the resource fetching within each of those properties. Directive solve this in a clean fashion, even if it requires folks to write a few more characters.
• To make the attribute name syntax clearer, nested object attributes can now be set using the dotty syntax only (position.x="5"). The colon syntax is no longer supported, since we're now using colons for directives.

Open questions / to decide / todo:

• [x] Do we really want to automatically expose all props as attributes? As an alternative (requiring slightly more code, though), we could provide a mechanism to explicitly mark individual properties as also being available as attributes:
  • Pro: it gives you more control over what's exposed and what's not.
  • Pro: it gives us something to hook in to to allow the user to customize the name of the attribute representing the property.
  • Con: lots of extra code that I'm not eager to have.
  • Con: allowing the user to choose an attribute name may actually cause more confusion, namespace collisions, and other edge cases.
  • Resolution: I added the exposedProperties static property, which acts as a whitelist. applyProps will check the list contained in this property before assigning to a property.
• [x] Is the way we're introducing directives here really the best way?
• [x] Is ref:... a good name for a reference directive?
  • I think so! But it largely depends on other directives we may end up adding (if any. Hopefully there will be none none. :b)
  • Resolution: I day has passed and I still don't hate it, so yeah, it's good.
• [x] Refactor applyProp to make directive support more stable (right now, a "ref" in the middle of a property name chain would be picked up as a directive, woops)
• [x] Change applyProps test to test applyProp specifically
  • [x] Test return booleans
  • [x] Test new directives
• [x] Update Changelog
• [ ] Update Documentation

COMPLEMENTARY KITTEN:

[CodyJasonBennett]

Would it be preferable to explore a syntax like <three-scene camera-id="#camera" />?

[hmans]

Would it be preferable to explore a syntax like <three-scene camera-id="#camera" />?

I was going with that first, but it clashes with the heuristics that are already in place. In this example, right now camera-id would translate to a cameraId property on the wrapped object. If we handle -id suffixes ourselves, we would face a problem if there ever is a Three.js property named *Id that we need to set.

Prefix directives solve this cleanly because they don't clash with any existing heuristics or systems. The part where I'm not convinced that they're a good idea is that I wasn't planning on going all "frameworky" with three-elements, and this is definitely a step into that direction.