I think state.frozen should be the default instead of state for runes

[schuwa]

(Sorry if this is a duplicate but I couldn't find a related discussion)
In my opinion switching to $state.frozen as the default makes a lot of sense for a few reasons:

Keeps Things Familiar: It’s pretty much how Svelte 3/4 handled object updates, so it wouldn’t be a big leap for anyone already used to that style.
Performance: as described in the docs, the object doesn't need to be made reactive so by default it is the more performant option (correct me if I am wrong)
Easier Comparisons: Since frozen state is immutable, we don't need to use the $state.is rune to compare

What do you think about it?

[brunnerh]

It’s pretty much how Svelte 3/4 handled object updates

Not quite. Svelte 3/4 work via invalidation on any assignment involving a state variable.
Most people work with mutable state to some degree, simple things like this would not work:

viewModel.name = 'new name';

All of that code would need a mutable state source or be rewritten to an immutable style like:

viewModel = { ...viewModel, name: 'new name' }; 

So I do not think this change would make sense, it would probably just cause more boilerplate as people would reach for the mutable version.

[schuwa]

Maybe it is only me who thinks it is more maintainable in the "verbose" version :)
I don't think it will be implemented, but I would really like a "strict" switch which only allows immutable state or maybe a lint to enforce this.

[7nik]

$state.frozen doesn't go well with fine-grain reactivity: you cannot do x.foo.bar.baz = 42, you have to do

x = {
  ...x,
  foo: {
    ...x.foo,
    bar: {
      ...x.foo.bar,
      baz: 42,
    },
  },
}

which will invalidate a lot of other props. But if you do big updates or replace the entire object/array, then $state.frozen can be better.

[everton-dgn]

$state.frozen não combina bem com reatividade de grão fino: você não pode fazer x.foo.bar.baz = 42, você tem que fazer

x = {
  ...x,
  foo: {
    ...x.foo,
    bar: {
      ...x.foo.bar,
      baz: 42,
    },
  },
}

o que invalidará muitas outras props. Mas se você fizer grandes atualizações ou substituir o objeto/matriz inteiro, então $state.frozen pode ser melhor.

Maybe you could use Immer to solve this.

[brunnerh]

Of course you could, but that defeats the purpose of having a framework that is supposed to make your life easier specifically when it comes to handling reactive data.

[flevi29]

That would also freeze the object with Object.freeze. But honestly I didn't even know about this deep reactivity until I shot myself in the foot with it. Then I read about it here first https://svelte.dev/docs/special-elements#svelte-options . The main problem is that even my custom class was deeply reactive, which is something they addressed now if I understand correctly.

It feels like something that should not be a default to me too or at least be documented better (unless I missed it).