Svelte: v2 stuff

[Rich-Harris]

I've added tasks to the v2 project, and am going to make a start on them. A couple might be slightly controversial, so I'm going to list them here:

Tidying up

• Remove cascade option — cascading is always disabled
• Remove store option — store support is always enabled
• Remove svelte.validate method (and svelte.Stylesheet) from public API — we can get validation more simply by passing generate: false
• Remove onrender and onteardown (these have been deprecated since forever)
• Remove teardown support for custom event handlers
• Remove code, map and cssMap from output of svelte.compile
• Error if element name is capitalised (capitalised tags are always components)
• Remove v1 syntax support

Don't typecast

See #623 — <Foo num=0> will create a num property with a string value of "0". To pass non-string values, use curlies: <Foo num={0}>

Error/warning codes

See #474

Replace component.observe

See #1197. Still some details to iron out, but I think it's a good move, and it would be good to get it in for v2 because otherwise we'll still need to include dispatchObservers and prototype.observe until v3

Destructuring syntax for computed properties

See #1069. I think it's a no-brainer. It would also provide an easy solution to #1303 — we can just have a computed property like props: state => state, and you could do {...props} on a component or element. Much better than {...this} in my opinion.

If we're destructuring, then we either need to rewrite that as non-destructured code, or...

...drop ES5 support

I think we're at the point where emitting ES5 code does more harm than good. If people need to support IE11 and below, it's probably reasonable to expect them to use something like Babel or Bublé. This would make the compiled code smaller, would mean we could use class if we were to do this, and would allow us to...

...change the signature of this.get()

It's been suggested that this.get() could take an option to exclude computed or store properties. If we were to do that, it would make sense to remove the existing string argument:

// instead of this...
const foo = this.get('foo');
const bar = this.get('bar');

// ...everyone does this:
const { foo, bar } = this.get();

I'm not suggesting we implement this.get({ computed: false, store: false }) just yet — we can do that post-v2. This would just pave the way for that.

---

I'm excited about this set of changes. But if you have concerns or feedback about them, please share.

[TehShrike]

[Conduitry]

[Rich-Harris]

One more: warnings and errors should have loc renamed to start, since we also have an end

[arxpoetica]

The only one I'm slightly worried about is the new observer patterns. I'm not sure I've seen this done before, and I'm slightly worried that it's going to increase code amount and amount of if / elseif / else logic, especially in the cases where one has to distinguish between init and not init, but I won't really know until it's out the gate, so all systems go!

[Rich-Harris]

Based on my experiments so far, it's unlikely that you'd end up with more app code, and certainly not significantly more. But the good news is that observe can easily be implemented on top of onstate and onupdate, and is smaller and simpler than the previous implementation. (This strongly suggests that the new lifecycle hooks are a fundamentally better design.)

So you can add observe from svelte-extras and your app will still be smaller than it would have been. But I suspect you won't want to. It's a bit like how XHR is now implemented in terms of fetch, because fetch is lower level, but everyone just uses fetch anyway because it's a nicer API.

[stalkerg]

// ...everyone does this:
const { foo, bar } = this.get();

I think it's difficult to replace this case:

this.fire('hide', { update: this.get('updateList') });

[Rich-Harris]

this.fire('hide', { update: this.get().updateList });