{"action":"created","issue":{"url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/3","repository_url":"https://api.github.com/repos/jdanyow/aurelia-async","labels_url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/3/labels{/name}","comments_url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/3/comments","events_url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/3/events","html_url":"https://github.com/jdanyow/aurelia-async/issues/3","id":101498974,"number":3,"title":"[Discussion] Syntax is terrible","user":{"login":"jods4","id":3832820,"avatar_url":"https://avatars.githubusercontent.com/u/3832820?v=3","gravatar_id":"","url":"https://api.github.com/users/jods4","html_url":"https://github.com/jods4","followers_url":"https://api.github.com/users/jods4/followers","following_url":"https://api.github.com/users/jods4/following{/other_user}","gists_url":"https://api.github.com/users/jods4/gists{/gist_id}","starred_url":"https://api.github.com/users/jods4/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jods4/subscriptions","organizations_url":"https://api.github.com/users/jods4/orgs","repos_url":"https://api.github.com/users/jods4/repos","events_url":"https://api.github.com/users/jods4/events{/privacy}","received_events_url":"https://api.github.com/users/jods4/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":13,"created_at":"2015-08-17T20:02:30Z","updated_at":"2016-02-11T14:06:24Z","closed_at":null,"body":"This is something that Aurelia absolutely needs, but I think that the double dotted syntax is aweful. It conveys no meaning. And when I just want to use a Promised value I don't see why I should `.value` it.\r\n\r\nGiven the current work on binding behaviors, I think it would be more appropriate to implement this through a behavior: `value.bind=\"promisedName & async\"`.\r\n\r\nOther options could be handled in a similar fashion if it is wanted (say using `& async-value`, `& async-status` etc.).\r\n\r\nThat said, it doesn't compose well... What about: `value.bind=\"user.address.city & async\"`. What part of the path does async apply to? :frowning: \r\n\r\nGoing a little bit further, I almost think that this should be baked in into Aurelia. I mean: what use is it to bind a Promise? Other than wanting to display its value when it resolves? So doing `value.bind=\"user.firstName\"` could \"just work\". Of course, this special-cases one object (`Promise`), but it is a core platform object with very special meaning and purpose, so I think that's OK."},"comment":{"url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/comments/182877853","html_url":"https://github.com/jdanyow/aurelia-async/issues/3#issuecomment-182877853","issue_url":"https://api.github.com/repos/jdanyow/aurelia-async/issues/3","id":182877853,"user":{"login":"jods4","id":3832820,"avatar_url":"https://avatars.githubusercontent.com/u/3832820?v=3","gravatar_id":"","url":"https://api.github.com/users/jods4","html_url":"https://github.com/jods4","followers_url":"https://api.github.com/users/jods4/followers","following_url":"https://api.github.com/users/jods4/following{/other_user}","gists_url":"https://api.github.com/users/jods4/gists{/gist_id}","starred_url":"https://api.github.com/users/jods4/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jods4/subscriptions","organizations_url":"https://api.github.com/users/jods4/orgs","repos_url":"https://api.github.com/users/jods4/repos","events_url":"https://api.github.com/users/jods4/events{/privacy}","received_events_url":"https://api.github.com/users/jods4/received_events","type":"User","site_admin":false},"created_at":"2016-02-11T14:06:24Z","updated_at":"2016-02-11T14:06:24Z","body":"> I'd also like to put to rest talk about \"just do the right thing\". We are not going to add logic to search for Promise and Observable instances throughout binding expressions. There are several reasons for this:\r\n1. Performance.\r\n2. Aesthetics: explicit is better. Think about the await keyword- it doesn't \"find the promise\" in an expression, it's passed an expression that evaluates to a promise.\r\n3. Level of effort to implement is too high. Would need to touch almost all the AST nodes.\r\n\r\nLet's talk this through. If it's not feasable or has too much drawbacks, then fine. But I don't want to dismiss it too quickly because it's currently the proposal that I like best.\r\n\r\n(1) Performance\r\nI agree it has too much impact to be always on. Now, the binding behaviour is opt-in so this becomes pay to play.\r\nThe only consideration that remains is whether a long expression such as `a.b.c[2].d + x.y()` would be prohibitively expensive to compute when in fact it only contains one or two promises...\r\nWe would need hard data to decide on this, but my feelings are that (a) quite often the expressions are going to be very short and simple. The expression above is just a bad practice anyway; (b) even so, the checks for promises aren't that expensive that a modern browser can't handle them. \r\nI am confident that as a pay to play the impact of \"per binding expression\" async support is very small.\r\n\r\n(2) Aesthetics\r\nIt's arguable. You will find that I am often a proponent of \"explicit is better\" and I don't like \"magic\" code but in this case I'm not sure that I'm with you.\r\nAll other proposals look downright ugly and clutter. Some even want to introduce new syntax elements that could clash with future JS proposals (`::` is proposed for function binding, `..` could very well one day be a range or splice operator). So for \"aesthetics\" the global binding behaviour is rather good.\r\nFor \"expliciteness\" you may have a point. I understand the behaviour as \"this expression may contain async computations (promises), please handle them\". That's an explicit opt-in but it doesn't say which parts are concerned... Is it important? Is there a case where you'd want to auto-handle a promise and bind directly to the next promise afterwards? I can't find a use case for this: `(await promise1).promise2`... Given that binding expression are (should be) short and contain few members, I'd argue the global opt-in is a fine enough granularity.\r\n\r\n(3) Effort to implement\r\nYeah this is the point that worries me most. I don't know what binding behaviour have access to, so I wondered if it would even be possible... If it's impossible / too hard it may be a deal breaker.\r\nI would love if it was attempted though. That syntax is nice and could be used for other libs (Rx comes to mind).\r\nIf you have AST access, isn't a visitor enough? In the end, the number of nodes that need to be checked are few: variables, property access, indexer access, method call (do I miss something?).\r\n\r\n\r\nI  understand the concerns but I would like to validate them before dismissing this option. From everything I've seen in this thread so far, it's the one that I like most."}}