-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Block params named component
are unusable in 2.9 beta
#14413
Comments
I would not consider this a bug but the previous behaviour. Helpers in 2.7 took precedence over properties with the same name (see this twiddle), so I guess that this change of behaviour just make it standard. I think I have seen a test regarding helper precedence, but cannot find it now. |
Yeah, helpers and keywords will win over properties, but they shouldn't win over block params. Block params should always win... |
@rwjblue: I updated the twiddle to show that the behaviour is consistent with block params as well: helpers win (the twiddle is using 2.7). I think this is consistent behaviour non making a difference between a block param and a property. Otherwise, refactoring a block to a component would be harder than one would expect. |
This pulls in two glimmer-engine bugfixes: - local variables (block params) should always win over helpers - stateful/class-based helpers used in `{{#if (my-helper ...)}}` and other block arguments position are destroyed when the block syntax switches from default to inverse (and vice versa) Fixes emberjs#14351, emberjs#14413
This pulls in two glimmer-engine bugfixes: - local variables (block params) should always win over helpers - stateful/class-based helpers used in `{{#if (my-helper ...)}}` and other block arguments position are destroyed when the block syntax switches from default to inverse (and vice versa) Fixes emberjs#14351, emberjs#14413
This pulls in two glimmer-engine bugfixes: - local variables (block params) should always win over helpers - stateful/class-based helpers used in `{{#if (my-helper ...)}}` and other block arguments position are destroyed when the block syntax switches from default to inverse (and vice versa) Fixes #14351, #14413 (cherry picked from commit 8c87e50)
...and `input`, `outlet`, etc. Block params (local variables) should always win over helpers and built-in syntaxes. Fixes #14413
...and `input`, `outlet`, etc. Block params (local variables) should always win over helpers and built-in syntaxes. Fixes #14413
...and `input`, `outlet`, etc. Block params (local variables) should always win over helpers and built-in syntaxes. Fixes #14413
Starting this per @rwjblue request. While I can understand why this wouldn't necessarily work.
When naming a block param
component
, it's not really usable within the block scope. This did work for me <= 2.7. I've just refactored away from the name but just reporting it here... Couple issues I noticed;<li>{{component}}</li>
<li data-value="{{component}}">Foobar</li>
Reproduced the issue in ember-twiddle: https://ember-twiddle.com/24f1983de422ed7039c5b21af68cc032?fileTreeShown=false&numColumns=2&openFiles=controllers.application.js%2Ctemplates.application.hbs
The text was updated successfully, but these errors were encountered: