Nested Destructuring of $props()

[Jazza-231]

Describe the problem

I often find myself destructuring $props. In cases such as

const { index } = $props()

This is, as shown, simple and clean. But what if the prop we are destructuring is in itself an object?

const { suggestion: { id } } = $props()

The above does not work, and gives the following error:

$props() assignment must not contain nested properties or computed keys
https://svelte.dev/e/props_invalid_pattern

Instead, we have to destructure in another line, like so:

const { suggestion } = $props()
const { id } = suggestion

Describe the proposed solution

I would love to know the reasoning behind this not being supported currently. If the issue is reactivity, I believe reactivity can be achieved using $derived or $state and $effect, like so:

const { suggestion } = $props()
const { id } = $derived(suggestion)

which is how it could work under the hood.

So, to state the obvious, my proposed solution is to...allow nested destructuring from $props().

const { suggestion: { id } } = $props()

It can be done in other parts of svelte, albeit without reactivity, and would make a few people's lives a fair bit easier.

Importance

would make my life easier

[Leonidaz]

Just sharing some thoughts.

As far as the generated code by svelte for accessing props, if it's possible that the parser can identify the path of deeper level destructuring, then it probably could convert deeper level declarations into $$props. access. Using the provided example would generate $$props.suggestion.id in the receiver component. For boundables there is a differently generated code to access the props, e.g. let suggestion = $.prop($$props, "suggestion", 15); and then reading would be suggestion().id

The generated code on the sender component wouldn't need to change as only the top level getter would be needed, same as now, e.g.

// relevant generated code of the sender calling component `Nested`
Nested(node, {
    get suggestion() {
        return suggestion;
    }
});

Renaming destructured variables could also work but it would be more work to identify and replace them with the full access path.

For boundable's it could also work as long as Svelte can replace the usage of the deeply destructure var with the full path. Currently, svelte would create a wrapper function for the declared reactive state, e.g. let suggestion = $.prop($$props, "suggestion", 15);. It makes sense just to keep it this way for the top level prop and then replace any mention of destructured var assignment id = someNewId into suggestion().id = someNewId.

it's also possible to generate an object with getters and setters for the destructured var, and then in the generated code refer to it as object.variable. this could be done for destructured vars.

// generated
let suggestion = $.prop($$props, "suggestion", 15);

const $$declared = {
  get id() {
    return suggestion().id;
  },
  set id(v) {
    suggestion().id = v;
  }
}

// access
// $$declared.id
// $$declared.id = newId

Not sure about deriveds, they wouldn't work because of bindability. Maybe just for read-only props.