Copied SafeString is not SafeString anymore

[pswai]

Twiddle: https://ember-twiddle.com/d3dd98014787c0d6943c5b3ec88f6c57?openFiles=controllers.application.js%2C

As described in twiddle, the output of Ember.Copy(Ember.String.htmlSafe('foo')) is not SafeString. It becomes a normal object.

Suggestions:

• Make SafeString implements Copyable
• Make Ember.copy returns the original SafeString

[pixelhandler]

@pswai maybe need to copy first then call htmlSafe? or is the work around in your use case to Copy a safe string then make it htmlSafe again? (I'm not sure that copy was intended to match a type but to copy object properties instead.)

Thanks for posting the twiddle example. Can you explain your use case in more detail? Does the twiddle represent how you use Ember.copy in an application?

[pswai]

@pixelhandler The twiddle is just for demo. The actual use case is a bit complicated but I have created a simplified version here.

Basically we have some Ember models that have a computed property that represents their translated name. In Ember-i18n, the translated strings are returned as SafeString. We have a form that uses the models as user options. The form has a "Cancel" functionality that reverts its values back to previously submitted values. To achieve this, the form makes a copy of the values when it is submitted, and uses the copied values on cancel. Since the copied strings are not SafeString anymore, {{theString}} shows [object Object] instead of its string value.

Currently we workaround by const displayText = value.string || value;, which is a bit ugly as the component needs to workaround copied SafeString here and there. Copy first then htmlSafe is not desirable since the form supports user input as well.

IMHO SafeString should be able to be used like primitive String, such that the copied SafeString should at least equivalent with the original SafeString.

[rwjblue]

I don’t think it’s likely that we will add functionality to Ember.Copy here. There are a few other ways to address this issue (e.g. buffered proxy) that are likely to serve you better in the long run.

Thank you for pushing this forward, but I’m going to close (mostly as “wontfix”) for now.