{"action":"created","issue":{"url":"https://api.github.com/repos/sveltejs/svelte/issues/1","repository_url":"https://api.github.com/repos/sveltejs/svelte","labels_url":"https://api.github.com/repos/sveltejs/svelte/issues/1/labels{/name}","comments_url":"https://api.github.com/repos/sveltejs/svelte/issues/1/comments","events_url":"https://api.github.com/repos/sveltejs/svelte/issues/1/events","html_url":"https://github.com/sveltejs/svelte/issues/1","id":190597066,"number":1,"title":"SSR and progressive enhancement","user":{"login":"Rich-Harris","id":1162160,"avatar_url":"https://avatars.githubusercontent.com/u/1162160?v=3","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":1,"created_at":"2016-11-21T00:51:13Z","updated_at":"2016-11-29T20:40:00Z","closed_at":null,"body":"SSR could potentially be something like this:\r\n\r\n```js\r\nrequire( 'svelte/ssr/register' );\r\n\r\nconst renderWidget = require( './components/Widget.html' );\r\nconst html = renderWidget({\r\n  foo: 1,\r\n  bar: 2\r\n});\r\n```\r\n\r\nNot exactly sure how progressive enhancement would be implemented, and whether it can be done in a zero-cost way, but it'd be pretty cool. I don't know whether it looks more like this (i.e. all components can be rendered as progressive enhancements)...\r\n\r\n```js\r\nconst widget = new Widget({\r\n  target: document.querySelector( 'main' ),\r\n  enhance: true\r\n});\r\n```\r\n\r\n...or this (i.e. only components that we know up-front we will want to use that way get the extra code):\r\n\r\n```html\r\n<!-- Widget.html -->\r\n<p>i am a widget</p>\r\n\r\n<script>\r\n  export default {\r\n    enhance: true,\r\n    // ...\r\n  };\r\n</script>\r\n```"},"comment":{"url":"https://api.github.com/repos/sveltejs/svelte/issues/comments/263691926","html_url":"https://github.com/sveltejs/svelte/issues/1#issuecomment-263691926","issue_url":"https://api.github.com/repos/sveltejs/svelte/issues/1","id":263691926,"user":{"login":"evs-chris","id":161978,"avatar_url":"https://avatars.githubusercontent.com/u/161978?v=3","gravatar_id":"","url":"https://api.github.com/users/evs-chris","html_url":"https://github.com/evs-chris","followers_url":"https://api.github.com/users/evs-chris/followers","following_url":"https://api.github.com/users/evs-chris/following{/other_user}","gists_url":"https://api.github.com/users/evs-chris/gists{/gist_id}","starred_url":"https://api.github.com/users/evs-chris/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/evs-chris/subscriptions","organizations_url":"https://api.github.com/users/evs-chris/orgs","repos_url":"https://api.github.com/users/evs-chris/repos","events_url":"https://api.github.com/users/evs-chris/events{/privacy}","received_events_url":"https://api.github.com/users/evs-chris/received_events","type":"User","site_admin":false},"created_at":"2016-11-29T20:40:00Z","updated_at":"2016-11-29T20:40:00Z","body":"In fiddling about with SSR, I've come to the conclusion that there are two ways that I would approach it:\r\n\r\n1. Add a toHTML to all of the generated components, and just use the same code for both server and client rendering.\r\n2. Add a second generator that just works with strings and have a flag to generate server/string producing code.\r\n\r\n_I_ like the second approach a lot more, as it jives with the \"don't add unnecessary stuff to the generated code\" philosophy that svelte seems to be built around. There are some challenges that would have to be overcome, like building two different flavours, client and server, of each module, publishing them, and then using the correct flavour for the correct environment. I suppose it could be as simple as exporting the client flavour as default, the server flavour as special named export, and letting the server rendering process pull the server flavour when rendering. Tree-shaking could take care of the excess flavours anywhere a bundler is being used. Does that seem reasonable, or have I wandered too far into left field?\r\n\r\nI don't think progressive enhancement is all that difficult once SSR is done, as it seems it's just a matter of adding a helper to create nodes rather than using document.createElement and friends directly. The helper would check for the enhance flag, and if present, would look for a suitable existing node to reuse before creating one. The enhance flag check could be limited to the root node, which would gather up the contents of the target element and pass them along the render chain, triggering automatic use of the existing DOM as children rendered. Of course, the presence of a helper kinda depends on the outcome of #9. Bonus: the helper refs would minify much better than document methods, which are >20b per node."}}
{"actor":{"display_login":"evs-chris"}}