Allow non-object literals for component registration

[alindsay55661]

Currently Svelte requires the components declaration to be an object literal. A very handy feature would be to allow non-object literals so we can bundle components into modules.

import formComponents from '@mylib/formComponents';
import MyComponent from './MyComponent';

export default {
  components: { ...formComponents, MyComponent }
  // components: Object.assign({}, formComponents, MyComponent) // more dynamic but can be interpreted by the compiler as compile time
}

http://babeljs.io/docs/plugins/transform-object-rest-spread/
http://babeljs.io/docs/plugins/transform-object-assign

Either of these babel plugins would allow for this syntax and prevent us from having to do the following in every component that needs to use a form:

import { 
  LibForm, 
  LibInput, 
  LibButton, 
  LibRadioButton, 
  LibCheckbox, 
  LibTextArea,
  LibPassword
} from '@lib/formComponents';
import MyComponent from './MyComponent';

export default {
  components: {
    LibForm, 
    LibInput, 
    LibButton, 
    LibRadioButton, 
    LibCheckbox, 
    LibTextArea,
    LibPassword,
    LibComponent
  }
}

This might not look so bad, but when you are importing from other bundled libraries the problem compounds and becomes quite significant.

Angular has solved this problem with their module system, but their module system is insane. Svelte can achieve the same benefit just by using native javascript modules and a transpiler.

[PaulBGD]

The main issue is that Svelte has to be able to statically analyze the components, which isn't possible when calling some sort of Object.assign method.

[Rich-Harris]

Yeah, am in two minds about this for that reason. I see why it's valuable when you have a great many imported components, but it does mean that Svelte has less ability to analyse your code. Some of that has concrete disadvantages e.g. in terms of code size — if Svelte can't link a component tag to an import, then it has to reference it as e.g. template.components.LibRadioButton, whereas if it can (see demo — click on the 'input' button to see the generated code, notice that the export default has been magicked away and it's referencing Nested directly), then it can produce leaner output.

Meanwhile, if LibRadioButton is missing (or if you misspelled it in the template), you'll just get a cryptic runtime error.

Then there are things that we're not currently taking advantage of but could, because static analysability is part of the design:

• More holistic app analysis that crosses component boundaries — e.g. knowing which data properties are expected and providing compile-time feedback or hints to IDE integrations
• Detecting missing components (and typos etc) at compile time

Of course, you only lose those benefits if you opt out of the object expression form (where object spread counts as opting out). My worry is that by relaxing the current constraint people might lose the benefits without realising they've done so, because the tradeoffs aren't totally straightforward to communicate. (The same applies to lots of other things — methods, transitions, etc.)

But maybe the practical considerations outweigh those benefits. Open to persuasion!

[Conduitry]

I think this can be closed. There's a boilerplate-reducing proposal in #1038, which still allows for compile-time analysis. We can re-open if someone disagrees.