$interpolate : add a way to hook string representation

[jpolo]

$interpolate has only two behavior for stringify : IF string THEN output without change OR perform json conversion.
It would be helpful to add a detection for hookable toString behavior for objects that are always represented by string or number (= where json representation has no value at all).

Use case: when using custom Int64, URI, ..., objects, everybody would expect that {{myUri}} would display a string representation instead of a json representation or a quoted string.

Idea of implementations :

• detect that valueOf or toString is overriden ?
• add a callback in $interpolate module ?
• apply toJson only for plain objects (i.e. where Object.getPrototypeOf(o) === Object.prototype) ?

[btford]

I think this is better solved by a filter.

[jpolo]

If we consider $interpolate result functionnally then foo {{myVar}} bar is equivalent to return "foo " + myVar + " bar" and foo {{myVar|filter}} bar is equivalent to return "foo " + filter(myVar) + " bar" .
Nevertheless, I understand why a toJson conversion was applied in some cases : when myVar = {} it would display always [object Object]. This has strictly no interest for developer.

Knowing that there is a filter |json when a json representation is wanted (= only for debug dump), it would be verbose to create a filter |string that would just be return String(myVar) and that we would have to have to call in every template expression.

[rodyhaddad]

@jpolo I believe @btford is proposing you create a filter for each type of object.

So using {{ myInts | ints }} or {{ myUrl | url }} is a lot better than having $interpolate do its own sniffing, adding more magic to maintain, with potential corner cases that might cause debugging problems to others.

It's better to be explicit than implicit here.

[jpolo]

Creating and using the filter is always the solution because it's explicit, I cannot deny that. This issue is more about the unexpected behavior that I felt when using $interpolate with no filter : I had to see the code to understand why it worked like that.
Why ? It might be developer's culture: in most languages (Python etc) string conversion is the default filter. (ex: https://docs.python.org/2/library/string.html#formatspec)
In the current implementation, it's a mix of "string unchanged, jsonify the rest" that can be confusing.

Maybe sniffing is not the best choice, you're right. But a simple String conversion as default behavior is preferrable. As you said, better be explicit and use |json when wanting json representation.