Short-circuit Problem With `SafeString` Using `or` (And Maybe Other Helper)

This issue has been tracked since 2022-04-27.

In our app we used the or-helper in a template condition with two parameters, the first a SafeString (created with htmlSafe) and the other a tracked local property.

{{#if (or @safeString this.trackedProperty)}}
... awesome application html
{{/if}}

The problem we faced is that since the @safeString is always an object (even if its an empty string) the or evaluates to true for it, but the ìf handles an empty safe string object properly and doesnt evaluate to true. This causes to never evaluate the second param, no matter if it changes to a "more truthy" value than the empty safe string. Is this something that should be changed or does it work as intended and should be addressed by the application? My problem with it is, that it handles htmlSafe in another way as the ìf-helper does.

At the moment we just simply add checks for the string before we create our SafeString, e.g.:

const safeString = isEmpty(maybeHtml) ? '' : htmlSafe(maybeHtml);

This way the or checks on a normal empty string, which evaluates to false and therefore checks also the second param. Of course there are several other approaches like changing the order of the params, putting the or logic in a local getter and so on, but thats not part of my original question

More Details About Repo
Owner Name jmurphyau
Repo Name ember-truth-helpers
Full Name jmurphyau/ember-truth-helpers
Language JavaScript
Created Date 2015-01-08
Updated Date 2022-11-28
Star Count 703
Watcher Count 13
Fork Count 94
Issue Count 28

YOU MAY BE INTERESTED

Issue Title Created Date Updated Date