Spread properties and special *state* property

[Swatinem]

It would be nice to support spreading into component props and to have a special identifier to access the whole local component state.

Spread could look something like this:

{{#each rects as rect}}
  <Rect {{...rect}} />
  <!-- or -->
  <Rect ...{{rect}} />
  <!-- same as -->
  <Rect x="{{rect.x}}" y="{{rect.y}}" />
{{/each}}

And having a special identifier for the complete state object would make decorator components really awesome, like so:

<!-- RectDecorator.html -->
<Rect {{..._}} foo="bar" />
<!-- same as -->
<Rect x="{{x}}" y="{{y}}" foo="bar" />

<!-- main.html -->
<RectDecorator x="1" y="2" />

[PaulBGD]

The ... for spreading is a JavaScript feature, maybe we should use a different indicator for spreading since Svelte templates aren't JavaScript.

[Swatinem]

Hm, I thought of ... to be more in alignment with how react does things. But you are right. Maybe we can leave it off, and just make it <Rect {{rect}} />, so if a mustache is not inside an attribute, its considered a spread…

[Rich-Harris]

Will close this now we have shorthand attributes (<Rect :x :y/> and so on).

[TehShrike]

The lack of spread continues to be a big pain for me, adding lots of difficult-to-maintain cruft in my components.

Having to maintain a list of all possible attributes that I might ever need to pass through a component is causing me a lot of friction in my most composable components.

[Rich-Harris]

@TehShrike PRs welcome 😀 (by which I mean I'm on vacation next week and slammed until then, so it's unlikely I'll be able to work on spread any time soon)

[TehShrike]

No worries, I was just thinking that this issue should probably get necro'd back to open.

[mrkishi]

Since there was reluctance on #280, here are my two (and a few more) cents:

I think this feature would be awesome. And I'm not talking about passing several properties easily, but the component decoupling aspect of it. That's an important distinction.

Most of the times I felt the need, there was actually an easy solution in encapsulating the properties, ie. changing the component API. It may be tedious (if not ugly) sometimes, but it's an easy fix.

It gets really weird when you want to use a component's default data and you can't, because you don't know if you have data to override it. This is a problem I couldn't get around unless messing with Component.data() directly or being extremely verbose with {{#if}}{else}}s (and being statically tied by doing so).

(this explanation is not gonna be succinct, but I couldn't express this clearly, sorry!)

Let's start with a simple component MainComponent with two routes: List and Item. repl.

Let's move to <:Component> by defining a unified route component API consisting of only the title and data properties. This is slightly less ergonomic inside routes, but much more ergonomic for the router. repl.

That looks perfect, until you realize you've lost the ability to use the routes' data() automatically. repl.

When you have <Route :data/>, whatever your data is (even undefined with hasOwnProperty('data') === false), it'll override Route's default data. Now, this makes sense because we would want the same behavior as set({ data: undefined }). But now we have to do something like new MainComponent({ target, data: { route: Route, data: Route.data(), ... }) to get around that. Not pretty, especially when combined with the rest of your data needs...

---

When we're dealing with a large amount of routes with SSR, data prefetching and lazy loading route chunks, the router tends to be a decoupling point. We want to minimize specific route components knowledge in the router, because it becomes too verbose and gets in the way of our chunking process (think accepting components from different teams with no static dependency).

Svelte started with no decoupling anywhere, with everything available at compile-time. Then <:Component> introduced separation at the component level -- but they're still coupled at properties. The spread feature would fill that gap. I see it as an intentional separation as opposed to an accidental shot at static analysis. I'd go as far as suggest that the spread feature should only work in <:Component> as to reduce its usage as a properties bag shortcut everywhere (which could in fact hinder future optimizations).

This is what our example could look like with spread: repl. Note how we regain the routes' data flexibility while keeping data() useable.

---

If you're still open for PRs, I'll take a look into it -- but I may need some help with Svelte's internals. 😀

[PixievoltNo1]

To paraphrase my remarks from my own issue on this, there are some good use cases for this feature, such as a tree node specifying its children like so:

{{#each children as childData}}
	<:Self {{childData}}/>
{{/each}}

And also, as mrkishi alluded to above, passing arbitrary data to an arbitrary component:

<:Component {name} {{childData}}/>

Neither of these use cases would be inhibited with any of these restrictions in place:

• not allowed for non-component elements
• no other attributes can specified on the element
• only a property name allowed (which can be a computed property), not an arbitrary expression evaluating to an object

Without being familiar with the Svelte codebase, I speculate that these restrictions could make this feature easier to implement. However, to prevent the rules for double curly braces from getting too convoluted, I think a feature with the above restrictions would need non-double curly brace syntax, such as a data directive:

<:Component {name} data:childData/>

[mrkishi]

I've been experimenting on this recently and, as much as I really want it, I don't know if the flexibility of a general solution is really worth the added complexity on the compiler.

By general solution, I mean one with no restrictions to the number of ...{{target}} attributes (and thus, proper attributes deduplication).

(note: assume there are better solutions for everything I mention here! I just couldn't see it)

I mean, it's not that bad and it's certainly not much of a runtime cost (especially since it'd only affect components which actually use it -- thanks disappearing framework!). Still, the attributes precedence algorithm is quite noisy on the output.

Since one of Svelte's main principles is reacting only to data changes (as opposed to re-render the whole app with the full state all the time), we have no option but to cache every single attribute value at different precedence layers in order to correctly deal with property drops. Take a look at this gist for what that might be.

On the other hand, we could impose restrictions to the feature in order to avoid these hard paths. For instance, if we agreed to allow at most one spread attribute per tag and to always favor statically defined attributes, we could have this much simpler variation instead.

While the general version is much more flexible, I think most use-cases would be well served by the restricted variant. It'd still be possible to merge objects with ...{{Object.assign({}, props1, props2)}}, so the only downside I'm seeing is being able to provide defaults as static attributes with spread overrides.

Since spreads will most likely be usually considered an anti-pattern, I'd argue we could start with the restricted version and then evaluate if anything else is needed.

/cc folks interested in the feature and @Rich-Harris,

Do you think that's a worthwhile path? If so, I'll work on a preliminary PR (which I expect will need some love from maintainers, sorry!).

--
I actually just thought of checking out what Vue does, and v-bind="data" has these exact same restrictions!