Introduce stable component api for custom components

[Swatinem]

One of reacts strength is that components can participate in the vdom lifecycle without actually rendering to the real dom.

I could imagine a component made out of 100% custom code, such as:

export default class Title {
constructor(props) {
  this.initialTitle = props.title;
}
mount() { // currently an implementation detail
  this.originalTitle = document.title;
  document.title = this.initialTitle;
}
update(props) { // is actually called `set` currently
  document.title = props.title;
}
unmount() { // is actually called `teardown` currently
  document.title = this.originalTitle;
}
}

And you can use the component something like this:

<Title title="{{foo.bar}}" />

What do you think about this @Rich-Harris ? I would really love to support components that are 100% custom code with a well-defined API for that.

[Rich-Harris]

Couldn't you do that like this?

<script>
  export default {
    onrender () {
      this.originalTitle = document.title;
      this.observe( 'title', title => document.title = title );
    },

    onteardown () {
      document.title = this.originalTitle;
    }
  };
</script>

(It's a rhetorical question – you absolutely can do it that way – I'm more asking what the difference would be, other than perhaps skipping fragment generation.)

[Swatinem]

I can think of two reasons (because sleep has wiped away the 3rd) why we should have a stable public component api:

• Like the example above, it would be nice to skip going through the compiler at all for such examples
• We need a way forward to consume components compiled with an older version of svelte. For example a component compiled with the older version does not have component._fragment.mount, whereas the newer versions generate code that depends on that implementation detail.

[Rich-Harris]

I'm worried that it leads you into a bit of an uncanny valley – all of a sudden things like this...

<Title title='{{foo.bar}}' on:teardown='doSomething()'/>

...don't work, unless we've specified that these JS components must implement the same on method that Svelte components do. (And of course you lose the convenience of Svelte's reactivity model.)

Good point re versioning. A stable public API doesn't entirely solve that problem (it just means breaking changes have to be intentional), but it does mitigate it. I'm not sure how concerned we need to be about that though – for nested components, I think it's fair to expect that someone would be compiling the entire tree at once. (Standalone widgets in a non-Svelte app is a different matter.) Running everything through the compiler is actually beneficial in that regard, because we can make breaking changes (like renaming onrender/onteardown to oncreate/ondestroy, per #40) and detect many of them – even fix some of them – at compile time.

So for me it comes down to two questions:

• Is the proposed API change beneficial?
• Do JS-only components add any expressive power?

Personally I think the answers are 'no' and 'no' – as discussed elsewhere I think adding mount and unmount creates confusion and unnecessary extra code, and I can't think of anything you could do with a JS-only component that you couldn't do with a script-only Svelte component. But I suppose those points are up for debate.

[Swatinem]

Alright then, lets skip it for now.