Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

string/length behavior change in 0.41.0 #459

Open
apellerano-pw opened this issue Apr 26, 2018 · 0 comments
Open

string/length behavior change in 0.41.0 #459

apellerano-pw opened this issue Apr 26, 2018 · 0 comments

Comments

@apellerano-pw
Copy link

apellerano-pw commented Apr 26, 2018

In 0.41.0 string/length was changed from using normalizeString to normalizeString2 and this is causing some of my previously working code (0.40.0 and earlier) to fail.

(Here's the change commit I believe is the culprit 9d37d08#diff-e79df0685b1844367badb5763902f884L3)

Repro case

If you have something in your component js like

import Component from '@ember/component';
import length from 'ember-awesome-macros/string/length';
export default Component.extend({
  myStr: null,
  crashTime: length('myStr'),
});

and a template of

{{crashTime}}

Then ember-awesome-macros will throw an error in normalizeString2 during

let prop = stringVal[func];

because stringVal is null.

The old behavior, with normalizeString, was this

if (!val) {
  return val;
}

which would early return the null value before the function trys to evaluate func.

I'm not sure what the intended behavior for your addon is so I don't know if this is a bug on my end or a regression on yours; what do you think? The question could be boiled down to, what should the string/length macro do in the case of null value strings?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant