Don't convert attribute values to strings for a-frame interop

[urish]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[X] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead see https://github.com/angular/angular/blob/master/CONTRIBUTING.md#question

Current behavior

When binding to an attribute, Angular automatically converts the value to a string before calling element.setAttribute(). Per MDN, setAttribute indeed expects the value to be a string, and any non-string value specified is converted automatically into a string.

A-Frame components provide an extended version of setAttribute, which can also receive object values. For example, given the following A-Frame scene:

<a-scene>
  <a-sphere position="0 1.5 -5" color="red" id="sphere1"></a-sphere>
</a-scene>

You can call setAttribute to update the position of the sphere in the frame:

  document.getElementById('sphere1').setAttribute("position", {x: 1, y: 1.5, z: -5});

It is also possible to achieve the same result by passing a string, but this can negatively affect the performance, as well as result in less readable code (when you need to parse/construct the string manually):

  document.getElementById('sphere1').setAttribute("position", '1 1.5 -5');

I created a small plnkr example where this can be seen in action: https://plnkr.co/edit/rIG4qcjpoPwZ13EiPSao?p=preview

Expected behavior

There should be a way to tell angular to pass objects directly to setAttribute(), without calling toString() first. A possible solution would be to remove the toString() call altogether, as setAttribute should convert the given argument to string anyway for native elements. I can send a PR for this, if you are interested.

Workaround

Currently, I use a pipe as a workaround in my code. The pipe basically defeats the toString() behavior of Angular, by overriding the toString() method of the given object:

import { Pipe, PipeTransform } from '@angular/core';

@Pipe({ name: 'aframe' })
export class AframePipe implements PipeTransform {
  transform(value: any, args?: any): any {
    if (value && typeof value === 'object') {
      return { toString: () => value };
    }
    return value;
  }
}

Then, I use this pipe whenever binding an object to an A-Frame attribute, e.g.:

<a-sphere [attr.position]="{x: calculateX(), y: 1.5, z: -5}|aframe"></a-sphere>

Minimal reproduction of the problem with instructions

Here is a minimal Angular app with the A-Frame scene described above:

http://plnkr.co/edit/qx0pHThNsB7KXmnHCSim?p=preview

Note that this example is working, since I have added my aframe pipe workaround. If you remove the "aframe" pipe from the attribute binding, you will see that the code stops working, as A-Frame gets '[object Object]' instead of the actual object.

What is the motivation / use case for changing the behavior?

Better interoperability with A-Frame

Environment

Angular version: 5.0.1

[gkalpak]

Wow, that's pretty weird. Any idea why A-Frame doesn't use properties for non-string values instead?

[urish]

TBH I have no idea, but perhaps @ngokevin or @Utopiah can shed some light here?

[ngokevin]

A-Frame integrates ECS (a game development pattern) into HTML. An HTML attribute is a "component" (bundle of logic/data) and components can have multiple properties. A-Frame wraps .setAttribute to take an object if you want to set multiple properties (but it can still take a string).

<a-entity material="color: red; roughness: 0.5">

That's the data defined in string form, but we can do .setAttribute('material', {color: 'blue', src: '#texture'}).

[gkalpak]

I see, thx for clarifying. Still feels a bit odd to overwrite such a fundamental method (instead of using a custom method for example), but I guess there are pros and cons in any approach (as is always the case when trying to augment a platform for something it was not designed for 😃).

So, back to the core & compiler people to give their perspective on omitting the toString() call.

[angular-robot]

Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.

Find more details about Angular's feature request process in our documentation.

[angular-robot]

Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.

We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.

You can find more details about the feature request process in our documentation.