Proposal: Alternative Store Signifier

[ChrisTalman]

Store properties have to be signified in some way. There was some discussion about this (#930) prior to the introduction of Store, and $ was settled upon.

$ is controversial
The trouble is, $ is quite controversial. It’s something JavaScript developers either love or hate. If you’re down with it, Store is great. Otherwise, it’s quite unpleasant.

Alternative signifier
It would be great for Svelte to offer an optional alternative signifier. I don’t think previous discussions exhausted all potential options for an alternative signifier, so I was hoping this discussion might be able to do so.

To start off, two options came to my mind, and I don’t think they’ve been mentioned previously.

Property: stored.property
The first could be a stored property. For example: <h1>{{stored.title}}</h1>. This is similar to previous proposals for a store property, but with the key difference that it prevents interface confusions with the actual Store object itself. Obviously, this would prevent developers from defining their own stored property, as it would essentially become a reserved word. However, this might not be a great inconvenience to developers. It has the advantage that it carries semantic meaning, and has the appearance of an ordinary object property access.

Keyword: stored property
The second could be a stored keyword. For example: <h1>{{stored title}}</h1>. In a binding, it might look like this: <input bind:value=”stored volume” type=”number” />. This has most of the benefits of a stored property, but has the additional advantage that it does not require a reserved word to be introduced. Thus, developers could still set a stored property on the component itself.

Positive improvement
At this stage, Store has been implemented, and $ is its only current signifier. Thus, this proposal might be considered minor and unnecessary. However, as strange as it might sound, quite a few developers really dislike having $ in their code. In order for them to feel comfortable using Svelte and Store, offering an alternative Store signifier like the ones I have proposed would be a welcome and positive improvement to Svelte.

[Rich-Harris]

Thanks @ChrisTalman — bear in mind that this needs to work with computed properties as well:

computed: {
  visibleTodos: ($todos, done) => $todos.filter(todo => todo.done === done)
}

I'm not sure that's possible without the prefix?

[ChrisTalman]

That's a good question, @Rich-Harris. I hadn't considered that aspect specifically. I'm not familiar with how Svelte parses its ‘behaviours’ object, but presumably that will be the crux of the matter in determining the feasibility of this proposal.

One approach could be replacement at compile time. In other words, when the compiler encounters stored property or stored.property, it replaces the expression with $property for runtime use. I don't see any reason why this wouldn't be possible. However, I can't speak on the feasibility of this, due to my lack of knowledge of how Svelte parses its behaviours object.

Another approach could be to allow a shorthand computed property, in the form of an object. It might look something like this:

export default
{
    computed:
    {
        filtered:
        {
            computer: Library.computeFiltered,
            arguments:
            [
                'stored items',
                'filter'
            ]
        }
    }
};

Something like this may be worthy of a proposal in its own right, as it is a common pattern for developers to essentially not make any use of the compute method body other than to invoke and return the value of an external method.

In the context of the current proposal at hand, a shortform like this would avoid the potential complexity of the compile time replacement approach.

[PaulBGD]

One approach could be replacement at compile time. In other words, when the compiler encounters stored property or stored.property, it replaces the expression with $property for runtime use. I don't see any reason why this wouldn't be possible. However, I can't speak on the feasibility of this, due to my lack of knowledge of how Svelte parses its behaviours object.

One issue with this is that any IDE will refuse to parse something like parse

computed: {
  filtered(stored.property) {
..

As for providing a large object to computed instead of having the compiler parse a function, it seems a bit overkill but might have a use-case somewhere?

[Rich-Harris]

I'm going to close this as there really isn't a way around the fact that we need valid JS identifiers, and I haven't heard anyone else voice the opinion that the $ is problematic.