Better ES6 support

[Rich-Harris]

Would be good to support export default syntax alongside component exports =, and have better support for import statements (at present they work in an ES6-ified build chain, but only really by accident – you can't author using ES6 imports and expect the component to work in anyone else's environment).

For good measure, it'd make sense to support <script type='module'>, since linters and highlighters should probably complain if they see imports and exports inside a regular script.

[martypdx]

Would the export format be the object literal of component options?

[Rich-Harris]

Yeah, I was thinking like this:

import fade from 'ractive-transitions-fade';

export default {
  data: () => ({
    // ...
  }),

  onrender () {
    // ...
  },

  myMethod () {
    // ...
  },

  transitions: { fade }
};

It would have to get rewritten by the loader (since the default export is the return value of Ractive.extend(...), and it would need to work with e.g. ractive-load) but that's easy enough.

[fskreuz]

👍

[martypdx]

The more I think about it, the more I like sticking with options over extending a class. That way people can use whatever strategy they like to manage creating instances.

However, as a coding sugar convenience, maybe we add a check for constructor function and instantiate so we get the comma-less coding style:

import fade from 'ractive-transitions-fade';

export default class MyComponent {
  data: () => ({
    // ...
  })

  onrender () {
    // ...
  }

  myMethod () {
    // ...
  }

  transitions: { fade }
};

[Rich-Harris]

Ah, interesting. Is that even possible though? I don't think you can create a class with non-method properties – Babel's REPL discards the string, number and object from this example.

[martypdx]

Ah, interesting. Is that even possible though?

Oh right. 😭

You can add them after the the prototype (which defeats the purpose of a nicer syntax) or I suppose add them as gets:

get transitions() { return { fade }; }

[martypdx]

@Rich-Harris: https://github.com/jeffmo/es-class-fields-and-static-properties

[Rich-Harris]

@martypdx useful additions. I don't think it helps us though, because we're not in a position to transpile that syntax (even if we were comfortable bundling a parser, Acorn – which is the most likely candidate – doesn't support it). Is there much of a benefit to supporting class syntax? Commas aside, I can't think of a situation where it doesn't result in more code, and it seems a bit disingenuous and magical (since you wouldn't actually be using the class you exported)