Allow `$derived` and `$derived.by` in `$bindable` props declarations

[kran6a]

Describe the problem

I stumbled upon this problem on a table component that receives an array of items and an array of available filters as props.

The component manages its own state, meaning actived filters and the list of filtered items were internal component variables.

Now I need to check if all the filtered items meet some criteria from the parent element. To do this, I would make the filtered_items variable bindable. Currently, the filtered_items variable was declaras like this:

<script lang="ts">
    const {items = $bindable(), filters = []} = $props();
    let applied_filters = $state({});//Logic to manage this variable has been omitted
    const filter = ()=>{
        const active_filters = Object.values(applied_filters).filter(Boolean);
        const filtered = items.filter(x => active_filters.every((clause) => clause.evaluate(x)));
        return filtered;
    }
    const filtered_items =  $bindable($derived.by(filter));
</script>

If I wanted to make filtered_items bindable to be able to know which items are currently displayed on the table from the parent component, I would need to use an $effect, rather than a $derived:

<script lang="ts">
    const {items = $bindable(), filters = [], filtered_items = $bindable()} = $props();
    let applied_filters = $state({});//Logic to manage this variable has been omitted
    $effect(()=>{
        const active_filters = Object.values(applied_filters).filter(Boolean);
        const filtered = items.filter(x => active_filters.every((clause) => clause.evaluate(x)));
        filtered_items = filtered;
    });
</script>

This is philosophically wrong. filtered_items is still a $derived but we are using an $effect to do that just because the compiler will complain about something like this:

<script lang="ts">
    const {items = $bindable(), filters = [], filtered_items = $bindable($derived.by(filter))} = $props();
    let applied_filters = $state({});//Logic to manage this variable has been omitted
    const filter = ()=>{
        const active_filters = Object.values(applied_filters).filter(Boolean);
        const filtered = items.filter(x => active_filters.every((clause) => clause.evaluate(x)));
        return filtered;
    }
</script>

Describe the proposed solution

I would like to be able to use $derived and $derived.by in props destructuring. Now that deriveds can be writable I don't see why this shouldn't be allowed.

Having to change from a $derived to an $effect just because you want the variable to be readable from outside seems wrong.

We may want to differentiate between writable deriveds and readonly ones. For this we can use $bindable($derived()) (writable) VS just $derived() (readonly, can still be bound, any initial value provided by the parent component will be ignored).

Importance

nice to have

[7nik]

You can use events:

    const {items = $bindable(), filters = [], onfiltered} = $props();
    let applied_filters = $state({});//Logic to manage this variable has been omitted
    const filter = ()=>{...}
    const filtered_items =  $derived.by(filter);
    $effect(() => { onfiltered?.(filterered_items) };

or export a getter:

    const {items = $bindable(), filters = [], onfiltered} = $props();
    let applied_filters = $state({});//Logic to manage this variable has been omitted
    const filter = ()=>{...}
    const filtered_items =  $bindable($derived.by(filter));
    export function getFilteredItems() { return filtered_items };

and in parent

<script>
  ...
  let child;
  $effect(() => {
    let items = child.getFilteredItems();
    ...
  });
</script>

<Child bind:this={child} ... />

[jsilveira]

I have a similar problem. I have a set of nested components that have their own logic to decide if they should be shown or not, and some parents need to know how many of their children end up being visible (to show or not some parent titles/structure).

My best idea so far was exposing a bindable property in the components to indicate if they are rendering something. The value of that prop would naturally be $derived of some state/props, that can't be assigned to a $bindable prop. The problem with $effect is that it does not run on the server, causing a state inconsistency between SSR and hydration.

I can't fully grasp which would be an elegant way of solving this. Using events does not seem natural, I want the property to be consistent with state everywhere as $bindable usually does and not have to worry about handlers and possible related bugs. At the same time I understand that for the parent component it is actually a read only property. I feel that I'm missing something basic about the svelte 5 way of doing things...