кумарят конечно такие приколы на самом деле

<script>
 function animate() { code }

 let nodes = [];
 $: nodes && animate(); // или animate(nodes);
</script>

{#each nodes as arr, i}
  <div bind:this={nodes[i]}></div>
{/each}

Неправильно немного баг описал...

Nodes это просто массив нод, а each итерирует над другой переменной:

<script>
 export let array;

 function animate() { code }

 let nodes = [];
 $: nodes && animate(); // или animate(nodes);
</script>

{#each array as arr, i}
  <div bind:this={nodes[i]}></div>
{/each}

Ну в общем я нашел способ который также вроде работает - сравнивать длину nodes и длину array

$: if(nodes.length == array.length) animate()

Срабатывает единожды стабильно

я тебе его выше предлагал) тока я не знал что у тебя массив а не объект)

Кажется ты не уловил умора 🤔

@PaulMaly я вот баловался тут двухсторонними биндингами, когда расширял базовый компонент функционалом сверху (делал обёртку)
и в режиме мутабельности получается, что когда происходит изменение - оно триггерит $: два раза, видимо один раз изменения отправляются биндом наверх, а раз они отправились наверх, то и вниз надо - раз это и всё-таки пропс для компонента, а что изменилось - неизвестно, т.к. safe_not_equal

это адекватное поведение, или в идеале бы такое пофиксить ?

я решил использованием options:immutable в оборачиваемом компоненте

<script>
 function animate() { code }

 let nodes = [];
 $: nodes && animate(); // или animate(nodes);
</script>

{#each nodes as arr, i}
  <div bind:this={nodes[i]}></div>
{/each}

по-идее должно срабатывать на любое изменение массива nodes

то есть при добавлении каждого элемента в массив

ну да норм, кажется это довольно очевидно

хорошо бы конечно, чтобы это срабатывало умнее, но как ты верно заметил это практически неизбежное поведение при той системе реактивности, которая используется - когда связанные данные фактически присутствуют в нескольких местах и синхронизируются друг с другом

вообще у меня immutable на все приложение стоит всегда

не уверен зачем в свелт использовать мутабильность

чтобы меньше кода писать наверное ?
так то я тоже к этому прихожу, что иммутабельность прикольнее, оно просто проверит ссылки по объектам и массивам, и в поля лезть не будет, и триггерить afterUpdate тоже не будет
ну и в принципе держать методы по работе с данными лучше рядом с данными в кастомном сторе и в них направлять апдейты из вьюхи
тогда и вербозность иммутабельности не так печалит, ибо всё это в отдельном store.js, а не в теле компонента
перестал нравится подход - компонент, показывающий объект из массива меняет этот объект мутабельно в коде своего скрипта

@PaulMaly а ты используешь Immer? или спредишь объекты и массивы на несколько уровней, когда надо что-то поменять? или стараешься делать структуру максимально плоской ?

насколько я понял immutable в свелте делает equals для пропсов, но не влияет на внутренности компонентов

уловил ) это была ирония. Просто отсутствие тайпскрипта было наименьшей проблемой свелт. В отличие от остального, без чего пиарить свелт как самый-лучший-в-мире-фрэймворк если не полностью бессмысленно, то, по крайней мере, слегка рановато )

в основном юзаю встроенные методы языка + да, стараюсь делать структуру более плоской. immer тоже активно использовал и даже советовал, но чет он мне по перформансу не понравился в итоге

но immer довольно удобная штука

да, просто позволяет не тригерить лишнего