feat(compile): add human readable alternative to '@=&?' #9137
Conversation
|
it looks alright to me, I think we do need another core team opinion on this though --- @tbosch wdyt? |
| expect(componentScope.optRefAlias).toBe(componentScope.optRef); | ||
| expect(componentScope.optRefAlias).toBe(undefined); | ||
| expect(componentScope.optRefVerbose).toBe(undefined); | ||
| expect(componentScope.optRefAliasVerbose).toBe(undefined); | ||
|
|
There was a problem hiding this comment.
The above 4 checks are incorrect (not just the new "verbose" ones, but the old ones as well).
We are checking against componentScope.optRef[XYZ], but they will always be undefined, because there are no such properties on componentScope.
We should be checking against componentScope.optref[XYZ] (notice the lowercase r), because these are the properties that will eventually get values, so these are the ones we want to ensure are undefined before $rootScope.name gets a value assigned.
(The rest of the it block uses optref[XYZ] correctly.
There was a problem hiding this comment.
good catch. thanks.
support using `interpolate:<name>`, `bind:<name>`, `eval:<name>` and `bind:optional:<name>` instead of `@<name>`, `=<name>`, `&<name>` and `=?<name>` Closes #9125
|
@tbosch thoughts? I like the syntax better, but idk if it's really worth changing Angular 1.x to have yet another way to do this... |
|
agree that having multiple ways to do it kind of sucks, but if we're going to do it, then this doesn't look like a bad way |
|
Just talked to @IgorMinar, for now we don't do this as it adds another way to do the same thing. Would need to keep both in sync, update the style guide, ... But we should document why we use those symbols
|
|
@shahata Could you create a docs PR instead with these explanations? |
jeffbcross
force-pushed
the
master
branch
4 times, most recently
from
e8dc429 to
e83fab9
Compare
petebacondarwin
force-pushed
the
master
branch
from
4dd5a20 to
998c61c
Compare
|
@shahata ping --- did you ever submit docs PRs about this? Someone on the IRC channel was saying we really need better docs/more examples for the isolate scope variable symbols. |
|
Sorry, somehow missed this one. I have to say that the reasoning behind the symbols doesn't make it any easier to understand imo. Even for me it sounds a bit strange:
I think we'd better close this unless someone has a good suggestion regarding how the docs can be improved. |
|
CLAs look good, thanks! |
|
Based on #9137 (comment), this is not going to land |
|
What a shame this was dismissed. When you read blogs, instructional videos,etc this is commonly discussed as a pain point. Keeping documentation up to date is a lame excuse for not implementing a small but helpful bit of code. I sense that fragile egos related to the original design are more the issue. Not one reason was presented for using symbology here and not elsewhere in angular, yet were going to hold on to it. |
|
@rcollette please keep the conversation technical and follow the code of conduct |
|
My apologies |
support using
interpolate:<name>,bind:<name>,eval:<name>andbind:optional:<name>instead of@<name>,=<name>,&<name>and=?<name>Closes #9125