Automatic HTML-safe escaping of options

Right now ember-intl has some nifty html-safe escaping.

If the argument htmlSafe is passed to the t helper it won’t escape:

https://github.com/ember-intl/ember-intl/blob/4b5e0570cce796f27f7bf9bb90947dd38d0951e1/addon/-private/formatters/format-message.js#L49-L54

I’m curious, would it be possible to iterate over the options hash and check isHtmlSafe (ref) on each option value and only escape the strings where isHtmlSafe doesn’t return true?

The benefit with that would be:

1. More convenient, since there is no need to mark stuff as HTML-safe twice.
2. Granular trust. Right now one cannot pass in two option values and only trust one of them. If you add the htmlSafe option you’ll automatically trust everything.

---

If we’d do this, that still leaves translations themselves, in the YAML source. Those are escaped automatically today. If we want to keep doing that the change gets more complicated, because we’d need to escape them before inserting the args.

Three ideas:

1. Stop escaping html in translations and treat them as trusted + escape options only when needed, by checking via isHtmlSafe.

2. Add a global toggle for escaping of translation strings, i.e. optional to trust them + escape options only when needed.

3. Do nothing and keep the current behaviour (which totally works, although it requires manual flagging whenever html is used + somewhat redundant since the user may already have marked something as htmlSafe

Let me know what you think!

[sandstrom]

I see your point about returning an object.

Maybe it’ll make more sense to postpone this until later?

If Ember drops support for IE11 it should be possible to move SafeString to be a proper subclass of String (would need an Ember RFC, but hopefully won’t be that difficult to move through). At that point we could revisit whether the helpers should take a different approach to escaping compared to what they’re doing now.

Always returning a SafeString, possibly coupled with better AST support, may allow us to do granular escaping of passed-in options + translation strings. Also, such may not even need to be breaking, so perhaps it can be introduced as a future 5.x minor.

Also, as mentioned above, this is a small problem, the current mechanisms works pretty well for us so it’s more of an ergonomics thing.

Thanks for taking time discussing this! 💯

---

One minor thing I think we could add though, is a small comment to the current code:

function escape(hash) {
  if (!hash) {
    return;
  }

  return keys(hash).reduce((accum, key) => {
    // NOTE this will skip escape if the value is an Ember `SafeString`
    if (typeof hash[key] === 'string') {
      accum[key] = escapeExpression(hash[key]);
    }

    return accum;
  }, assign({}, hash));
}

https://github.com/ember-intl/ember-intl/blob/master/addon/-private/formatters/format-message.js#L28

Just to make the current behaviour more obvious.

Feel free to merge or close: https://github.com/ember-intl/ember-intl/pull/1214

[jasonmit]

Merged and I appreciate the sanity checks ❤️

Will close for now but I’m sure will come up from time to time so will continue to reference until we have a better solution!