{"action":"created","issue":{"url":"https://api.github.com/repos/sveltejs/svelte/issues/1318","repository_url":"https://api.github.com/repos/sveltejs/svelte","labels_url":"https://api.github.com/repos/sveltejs/svelte/issues/1318/labels{/name}","comments_url":"https://api.github.com/repos/sveltejs/svelte/issues/1318/comments","events_url":"https://api.github.com/repos/sveltejs/svelte/issues/1318/events","html_url":"https://github.com/sveltejs/svelte/issues/1318","id":311578552,"number":1318,"title":"Syntax changes","user":{"login":"Rich-Harris","id":1162160,"avatar_url":"https://avatars3.githubusercontent.com/u/1162160?v=4","gravatar_id":"","url":"https://api.github.com/users/Rich-Harris","html_url":"https://github.com/Rich-Harris","followers_url":"https://api.github.com/users/Rich-Harris/followers","following_url":"https://api.github.com/users/Rich-Harris/following{/other_user}","gists_url":"https://api.github.com/users/Rich-Harris/gists{/gist_id}","starred_url":"https://api.github.com/users/Rich-Harris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Rich-Harris/subscriptions","organizations_url":"https://api.github.com/users/Rich-Harris/orgs","repos_url":"https://api.github.com/users/Rich-Harris/repos","events_url":"https://api.github.com/users/Rich-Harris/events{/privacy}","received_events_url":"https://api.github.com/users/Rich-Harris/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":37,"created_at":"2018-04-05T11:49:00Z","updated_at":"2018-04-07T01:54:05Z","closed_at":null,"author_association":"OWNER","body":"I've referred to this obliquely in other issues, Gitter, etc, but haven't quite got to the point of starting a proper discussion about it.\r\n\r\nEssentially, for version 2 I'd like to move away from the Mustache-esque template syntax to something a bit lighter and more modern, which boils down to using one curly brace instead of two:\r\n\r\n```html\r\n<h1 class={myClass}>Hello {name}!</h1>\r\n``` \r\n\r\nThe success of JSX has proved that the second curly is unnecessary. Moreover, a lot of people — particularly those who have been exposed to React — have a visceral negative reaction to double curlies, many of them assuming that it brings with it all the limitations of crusty old languages like Mustache and Handlebars, where you can't use arbitrary JavaScript in expressions.\r\n\r\nWe would also put an end to [this sort of thing](https://svelte.technology/repl?version=1.22.5&gist=1aad2a2fc95b7065648dbd4c19793aaa) — component properties being typecast — at the same time. (See #657).\r\n\r\n## Quoted attributes\r\n\r\nAt present, Svelte allows you to quote attributes and properties for the sake of your syntax highlighter:\r\n\r\n```html\r\n<Widget x={{y < z ? }}>this generally breaks highlighting</Widget>\r\n<Widget x=\"{{y < z ? }}\">this generally breaks highlighting</Widget>\r\n```\r\n\r\nI'd suggest that we keep that behaviour, so as not to force people to adopt additional tooling (which doesn't yet exist anyway). The same goes for directive arguments — these would be unchanged.\r\n\r\n## Control flow\r\n\r\nIt's less clear what to do about `if`/`else`/`elseif`, `each`, and `await`/`then`/`catch`. We could of course do this...\r\n\r\n```html\r\n{#if foo}\r\n  <p>foo!</p>\r\n{else}\r\n  <p>not foo!</p>\r\n{/if}\r\n```\r\n\r\n...though part of me feels like we're just continuing to accept the premise of Handlebars, and that there's a more natural approach waiting to be discovered. Just for the sake of argument:\r\n\r\n```html\r\n#if (foo) {\r\n  <p>foo!</p>\r\n} else if (bar) {\r\n  <p>bar!</p>\r\n} else {\r\n  <p>neither foo nor bar!</p>\r\n}\r\n\r\n<ul>\r\n  #each (cats as cat) {\r\n    <li><a target='_blank' href={cat.video}>{cat.name}</a></li>\r\n  }\r\n</ul>\r\n\r\n#await (promise) {\r\n  <p>wait for it...</p>\r\n} then (answer) {\r\n  <p>the answer is {answer}!</p>\r\n} catch (error) {\r\n  <p>well that's odd</p>\r\n}\r\n```\r\n\r\nMaybe that makes you want to barf, I don't know. But I'd be very interested to hear everyone's ideas.\r\n\r\n## Keyed each blocks\r\n\r\nI'm in favour of replacing `@name` with `by name`, as discussed in #703 — it has some clear advantages.\r\n\r\n## Triples\r\n\r\nTriples could arguably be unchanged — if anything, the increased distinction between `{text}` and `{{{html}}}` is a good thing. Or we could go in a totally different direction like `<{html}>`. Eager to hear thoughts.\r\n\r\n## Static tags\r\n\r\n#364 — briefly discussed, but never acted upon: the idea of adding syntax for declaring tags static, as a way of saying to the compiler 'this will never change after the initial render, don't worry about generating update code'. Would be nice if whatever choices we make preserve that possibility.\r\n\r\n## Escaping\r\n\r\nIf you needed a literal `{` character in your markup, you could always do `{'{'}`. (This is how it's done in React.) Or you could do `&#123;`, which is pleasingly easy to remember. Does there need to be some method of escaping beyond that?\r\n\r\n## Migrating\r\n\r\nAll this stuff should come with an simple, completely automated way to upgrade an existing template. There could be a CLI tool, and the REPL would detect old templates and show an 'upgrade' button.\r\n\r\n---\r\n\r\nObviously we shouldn't rush into anything. But changes like these are best made earlier on in a project's lifecycle, so I'm eager to hear what people think so that we can start making some progress. Thanks!"},"comment":{"url":"https://api.github.com/repos/sveltejs/svelte/issues/comments/379424051","html_url":"https://github.com/sveltejs/svelte/issues/1318#issuecomment-379424051","issue_url":"https://api.github.com/repos/sveltejs/svelte/issues/1318","id":379424051,"user":{"login":"Rich-Harris","id":1162160,"avatar_url":"https://avatars3.githubusercontent.com/u/1162160?v=4","gravatar_id":"","url":"https://api.github.com/users/Rich-Harris","html_url":"https://github.com/Rich-Harris","followers_url":"https://api.github.com/users/Rich-Harris/followers","following_url":"https://api.github.com/users/Rich-Harris/following{/other_user}","gists_url":"https://api.github.com/users/Rich-Harris/gists{/gist_id}","starred_url":"https://api.github.com/users/Rich-Harris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/Rich-Harris/subscriptions","organizations_url":"https://api.github.com/users/Rich-Harris/orgs","repos_url":"https://api.github.com/users/Rich-Harris/repos","events_url":"https://api.github.com/users/Rich-Harris/events{/privacy}","received_events_url":"https://api.github.com/users/Rich-Harris/received_events","type":"User","site_admin":false},"created_at":"2018-04-07T01:54:05Z","updated_at":"2018-04-07T01:54:05Z","author_association":"OWNER","body":"So, looks like `<:if ...>` is out. It was a nice idea!\r\n\r\nSeems folks are generally on board with `{expression}`, `{#if expression}`, `{:else}` and so on. Think we're probably at the point where we can exclude that from further bikeshedding.\r\n\r\nI realised that `{static expression}` and `{unescape expression}` or `{html expression}` aren't as practical as we first thought, because of ambiguities about how to parse them:\r\n\r\n```html\r\n{html (expression)} <!-- could be CallExpression or prefixed ParenthesizedExpression -->\r\n{html + whatever} <!-- could be BinaryExpression or prefixed UnaryExpression -->\r\n```\r\n\r\nSo we either need to choose sigils for those cases, or prefix the keywords, e.g.\r\n\r\n```html\r\n{=html expression}\r\n```\r\n\r\nI think prefixing is better, but have no strong opinion about which special character would make most sense (except a mild aesthetic preference for characters with vertical symmetry, and a suggestion that we avoid `<` and `&` because they have special significance in HTML and will cause highlighting weirdness).\r\n\r\nI agree with @hperrin about names for special components — I don't think it's wise to have `<Window>` and `<Component>` etc. `<slot>` is different precisely because it's an element with special meaning in HTML, and Svelte slots behave like 'real' ones do.\r\n\r\n@constgen Have wondered about that. The reason I think it's probably best not to is that we can currently use indexes (`each cats as cat, i`) and `for (cat, i of cats)` would be odd. Also, there's no good place to put `by name` or `key name`. I'm generally against having multiple ways of doing the same thing, since it creates anxiety about which is the 'right' one and what the differences are between them.\r\n\r\nWe're almost there! Think we basically just need to figure out the HTML/static tags thing."}}
{"actor":{"display_login":"Rich-Harris"}}