Allow specifying non-special bindings as readonly

[benjamingwynn]

Describe the problem

Currently there appears to be no way to define a components binding as readonly, this is supported on special inbuilt elements, such as input, video and audio (for example, for "read_only_media_attributes") but Svelte currently lacks support for specifying anything outside of inbuilt elements as a readonly binding.

Looking through the source, it looks like the binding type is decided around here, and is conditioned based on the type of element:

https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Binding.ts#L88

Sorry if this has already been discussed but I couldn't find an existing issue covering this topic.

Describe the proposed solution

We should have some way of specifying a readonly binding, for example, by using the reserved export let $variable syntax:

Foo.svelte:

<script>
  import {onMount} from 'svelte';
  export let $foo = 0;
  
  onMount(() => {
   const t = setTimeout(() => {
     foo++;
   }, 100);
   return (() => {
     clearTimeout(t)
   });
  });
</script>

App.svelte

<script>
  import Foo from './Foo.svelte';
  let foo;
</script>
<Foo bind:foo />
<h1>{foo}</h1>

I'm not aware of if this syntax is intended for something else, someone might be able to chime in and suggest something that might be better suited and fit in better with the general design of Svelte.

Alternatives considered

We'd like this to warn developers not to write to certain values to components as they won't affect anything, since the component that's providing those bindings is doing some side effect that isn't controllable from the parent component.

If they do, it doesn't directly affect any result (nothing happens), so our alternative solution is just to mark these bindings as readonly in our JSDoc.

Importance

nice to have

[Tal500]

I also want this feature in Svelte.
Currently, I think that the only "Svelte way" to do this is by firing an event whenever the value changes.

Additionally, there are some generic readonly "props" in Svelte component - those are the slot props.
Maybe it should be possible to bind to slot props? E.g. if Component has an exported slot prop p, this code could be legal:

<Component bind:let:p={var} />

I know that the code isn't the cleanest, but it is just an association.

[baseballyama]

Why is just passing props not enough?
This prevents to rewrite values of a parent component from a child component.

Foo.svelte

<script>
  import { onMount } from "svelte";
  export let foo = 0;

  onMount(() => {
    const t = setTimeout(() => {
      foo++;
    }, 100);
    return () => {
      clearTimeout(t);
    };
  });
</script>

Foo at Foo.svelte: {foo}

App.svelte

<script>
  import Foo from "./Foo.svelte";
  let foo;
</script>

<Foo foo="{foo}" />
<h1>{foo}</h1>

Foo at App.svelte: {foo}

[SystemParadox]

This prevents to rewrite values of a parent component from a child component.

This issue is about the opposite, exporting a value from Foo that Foo is in control of, and App can read it but shouldn't be allowed to change it.

[baseballyama]

Ah got it. Thank you for your explanation!
Could you please explain to us for more concrete use case?

My first impression is that the complexity of the bindings will make them more difficult to understand.

• parent --> child
• parent <--> child
• parent <-- child

Also, at least in my experience, it seems that the timing of passing a child component's value to a parent component is often controlled by the code, rather than when the value is changed. (e.g. passing value to the parent when a button is clicked)
If this is true for most of the Svelte users, I thought we don't need to support it on the Svelte layer.

Thought?

[SystemParadox]

Quite simply, look at the special cases svelte has for input, video and audio. The use case is the same. Some components want to expose state back to the parent, but the parent shouldn't be allowed to modify it.

If you don't see the need for this then I would argue the special case should also be removed from the builtin elements. If it can't be removed from the builtin elements then clearly this behaviour is desirable and necessary and we should make it available everywhere.

The issue with timing is actually most of the reason for this request. If you do this with a normal two-way binding then the parent is in charge, which means the initial value comes from the parent, and the only way to get the value from the child is to have the child do something like $: { value = whatever }. Since this doesn't happen immediately you get at least one render with the parent's value, which isn't desirable.

[adiguba]

Hi,

Nice feature to have, but but I think the $ syntax is confusing with stores, and could cause problems for code analysis on IDEs.

I think it would be clearer to use a specific JS label to declare read-only variables :

export let foo = 0;
export let bar = 0;
export let baz = 0;

// With this syntax, we declare `foo` and `bar` as read-only :
$readonly: foo, bar;

[n8allan]

I'm new to Svelte, and was shocked that this isn't already present. Readable stores seems like a way to work around this limitation. For e.g.:

let internalBusyState: Writable<"idle" | "loading" | "saving"> = writable("idle");
export const busyState: Readable<"idle" | "loading" | "saving"> = { subscribe: internalBusyState.subscribe };

Seems inferior to first class read-only properties though.

UPDATE: this doesn't work, though I'm not sure why. On the consuming end of the component the store values just come out undefined. e.g. {dataset.$busyState} is always undefined

[n8allan]

I think it would be clearer to use a specific JS label to declare read-only variables :

$readonly: foo, bar;

Would it be more straight forward to have it be a modifier on the property itself? This way the reader immediately knows without looking elsewhere. Something like this:

export readonly let foo = 0;
export let bar = 0;

[benjamingwynn]

@n8allan as far as i know, svelte JS syntax has to be somewhat ESM compatible, export let bar = 0 is valid ESM, but I don't think export readonly let foo = 0 would be, the only reason the $: syntax works is because Svelte (ab)uses labels.

[Tal500]

@n8allan as far as i know, svelte JS syntax has to be somewhat ESM compatible, export let bar = 0 is valid ESM, but I don't think export readonly let foo = 0 would be, the only reason the $: syntax works is because Svelte (ab)uses labels.

We can always have a JSDoc-style comment, though I agree with your suggestion as well.

You suggestion is actually good as we can have that these props will always be reactive🙂

[arnard76]

This might be a possible workaround using a store:

1. create a writable store in the child component (e.g. Foo)
2. export a read-only version of this store (store only has subscribe, no set/update function)
3. have the parent component (e.g. App) bind a local variable to this read-only store

The writable store value could be changed at any point within the child component so better than using a readable store only.

Seems inferior to first class read-only properties though.

If the parent attempts to change the value of store, svelte generates this error message:
Error: readOnlyStore.set is not a function

Here is a code example:
https://svelte.dev/repl/2a742620fce14ce5bd9f5e27af7825a5?version=4.0.0

[hackape]

This feature can be easily implemented:

<script>
export let value = "foo"
let _value;
// if you want to set init value from outside
// uncomment this line:
// _value = value;
$: value = _value;
</script>

<input bind:value={_value} />

Outside component bind to value cannot affect the real _value, but inner _value change is always synced back to outside through value.

So I don’t think this feature needs language level support. I’d suggest a "won’t do" label for this one.