"current data object" in templates (re: spread)

[TehShrike]

Follow-on to #195 -

In order to use the spread functionality to pass arbitrary properties that were applied to the current component on to child components, we need to be able to reference the current data/state object in the template.

I think {{...state}} and {{...data}} and {{...@}} were tossed around, but my vague impression is that {{...this}} is the current top pick.

[Rich-Harris]

One thing about template tags — {{this}} is already totally valid if you have a property called 'this': https://svelte.technology/repl?version=1.60.0&gist=3a6b97e3ec254df98cc99db546de4520

You can't, however, use it in expressions (even {{(this)}} fails).

So I wonder if the right move here is to make this be an alias for the state object regardless of spread. Would be a breaking change for anyone using {{this}} (though I suspect no-one would be affected by it, realistically). Also, would need to figure out what to do here:

<h2>{{this.thing}}</h2>

{{#each things as thing}}
  <p>What is {{this.thing}}?</p>
{{/each}}

It sort of looks like the second instance would resolve to state.thing, when {{thing}} by itself would equate to state.things[i]. Changing that would require some engineering.

[TehShrike]

I wonder if the right move here is to make this be an alias for the state object regardless of spread

👍 I think this would be the least surprising behavior. I can't think of much reason to use it outside of spread, but that would feel consistent to me.

It sort of looks like the second instance would resolve to state.thing, when {{thing}} by itself would equate to state.things[i]

One of the things that I really really like about Svelte's mustache implementation compared to Ractive is that I never have to think about scopes created by different mustache features.

The only option is to {{#each things as thing}} and then refer to thing, you can't just do .wat or this.wat, you have to be explicit.

I feel pretty strongly that I want Svelte to stay this way, and never create new scopes - devs should be forced to reference thing.wat instead of this.wat inside of that loop.

this should just refer to the component's data object.

For one thing, unless you made this inside of loops inherit objects from the scopes above it (eeeugh), you wouldn't be able to use {{...this}} to pass in arbitrary attributes to child components in a loop.

[TehShrike]

Question unrelated to the previous posts: are we cool with the idea that this would reference only the data object, and not the component - i.e., you wouldn't be able to reference this.method() from the template?

[TehShrike]

(I think having this only reference the data object would be simplest/best, but I worry that some folks might assume it's a reference to the component object, instead of just the data object)

[Rich-Harris]

are we cool with the idea that this would reference only the data object, and not the component

💯 yes, it would be deeply confusing if it had a dual meaning.

My earlier point about this.thing was purely that if this was just replaced with state, {{this.thing}} would be treated exactly the same way as {{thing}} currently is. In the context of an each block, that means it would refer to the state.things[i] even though it looks like it should refer to state.thing — unless we jump through some unfortunate hoops.

[TehShrike]

oh, I follow you now. Yeah, I would expect it/want it to reference the top-level/component state :-x

Otherwise, I can't use spread in loops, and we're in the I-have-to-think-about-what-scope-I'm-in territory where I don't want to be.

How unfortunate are the hoops? >_<

[jacwright]

So would using this allow you to label objects in your state events and not have their name collide with the event keyword in listeners? E.g.

<h2>Calendar Events</h2>

{{#each events as event}}
  <div>
    <h4>{{ event.name }}</h4>
    <button on:click="cancelEvent(this.event)">Cancel</button>
  </div>
{{/each}}

[Rich-Harris]

How unfortunate are the hoops? >_<

Well, #1173 changed the behaviour so that instead of passing down a state object followed by an arbitrary number of parameters ((state, things, thing, i)), plus additional params for every new each or awaiti block), child blocks are passed a 'context' object which has (for example) a thing property. So thing is effectively shadowed, and we can't access the top-level state within the each block. We would have to do something unpleasant like carting around a state.__topLevelState object for those cases.

So would using this allow you to label objects in your state events and not have their name collide with the event keyword in listeners?

well... no. this in an event listener refers to the node, so that you can do this sort of thing:

<input on:focus='this.select()' on:input='updateValue(this.value)' >

[PaulMaly]

Maybe we can unite this feature with one more idea - creating computed properties which depend on all data. We can use rest parameter:

computed: {
    props(...data) => data 
}

And after that spread operator:

<Child {{...props}} />

It'll also allow to pass not all data and filter it somehow:

computed: {
    props(...data) => Object.keys(data).reduce(() => {}, {})
}

Just an idea.

[TehShrike]

Related: https://gitter.im/sveltejs/svelte?at=5ac652c827c509a774df1edc

[Conduitry]

I do think that the 'computed properties with a rest param' thing is an interesting idea, but there are some things we need to be careful of. It seems like there are two main ways it could work:

• The rest param receives no computed properties in its object
• The rest param receives computed properties that are not themselves based on a rest param value, but not any that are based on a rest param value

The second option is what I was focusing on in a brief Gitter conversation, but I'm now thinking that the first one is better. It's less confusing to understand (try writing docs that don't suck for that second one!), and also it's not any less powerful. If someone wants a rest-param-using-computed-property to depend on the computed properties, they can just list it as an explicit dependency with its own argument. The list of computed properties is known at compile time to Svelte, and will also be known at coding time to the developer, so there doesn't really seem to be any reason to include computed properties in the rest param.

[PaulMaly]

@Conduitry

The list of computed properties is known at compile time to Svelte, and will also be known at coding time to the developer, so there doesn't really seem to be any reason to include computed properties in the rest param.

Completely agree. Perhaps, Store data also should be explicit:

computed: {
     foo(bar, $baz, ...data) {
     },
     bar(qux) {
     }
}

[fjorgemota]

What I understand is that anything we (as a community) define here will probably have two implications:

• Possible breaking of old code;
• Dual meaning as in the case of the each loop;

So I will suggest something that may happen to be more "friendly" and customizable to everyone, but it is just an idea, so maybe it is just bad (but to me it makes sense).

Why just do not add a new option, on the object exported by export default, to define the identifier used to identify the global state on the state? I mean, that way a few things would be possible:

• Let the feature be totally optional (probably disabled by default);
• Allow use on computed properties (as the user can define the identifier and the compiled would be able to detect the identifier usage on the computed property and work accordingly);
• Avoid possible conflicts (because the definition would be managed by the user, according to the template, so it's easy to see what is the identifier associated with the global state);
• Let each cases be more "correctly" managed (because the option would let the user to see that the identifier mentioned is referring to the global state);

As an example, I see something like that happening:

{{#each things as thing}}
  <p>What is {{root.thing}}?</p>
{{/each}}

<script>
export default {
    stateIdentifier: "root"
}
</script>

I do not have an idea actually about the name used to define the option, but I do not see a problem on the approach actually. Of course, let configuration happen that way depends totally on the architecture of the compiled (which I do not know anything about).

Another option would be to define that option as a option to compile, but, after all, it's just ideas.

What do you think? Is that a viable option? (Thanks for creating Svelte, by the way, I absolutely love this project!)