Wrap returned component data with Readonly

[Insadem]

Component data is immutable, but only for first scope. So I can easily edit 2-nd+ scope by accident. Is it by design, or it's impossible to wrap it to Readonly?
Ex:

SomeComponent({
someKey: []
});

const someComponent = world.get(...);
someComponent.someKey.push({});

[LastTalon]

Well matter really doesn't care if you use mutable components. It doesn't really break in any way if you give it a mutable component, you just won't get queryChanged updates for that mutable component.

However, here the issue looks like the issue is not that your component is mutable, but your someKey is a regular Array, not a ReadonlyArray. This is the same way matter sans TS handles this as well, only the first level table is frozen, if you want deep freezing you'll have to do that yourself.

[Insadem]

Well matter really doesn't care if you use mutable components. It doesn't really break in any way if you give it a mutable component, you just won't get queryChanged updates for that mutable component.

However, here the issue looks like the issue is not that your component is mutable, but your someKey is a regular Array, not a ReadonlyArray.

I understand this. Maybe it's better to close this issue, because it's optional to mutate component data. I wish matter had more explicit documentation, like what are requirements to trigger queryChanged (I figured it out through code, but still..)

[LastTalon]

I wish matter had more explicit documentation, like what are requirements to trigger queryChanged

If you find a good way to explain this and update the docs, I'm sure a matter PR would be welcome. I think the issue so far has been that there are a few nuances like this that you can technically do but aren't encouraged out of the box. Because of that they can be pretty tricky to explain accurately and concisely for general users and would likely be more confusing.

[Insadem]

Yeah, sure. I just thought what is the purpose of component mutation if it doesn't trigger queryChanged (performance wise it's bad idea). But then I realized that it's very handy to be able mutate existing data. I just wanted some safety, but probably I will just get used to it. You anyway need to call world.insert to trigger queryChanged, so it's not smart to prohibit edit component data (reference types under the keys).

[LastTalon]

I just wanted some safety, but probably I will just get used to it.

If you want that safety, you can still type them yourself to ensure you're using your components correctly in the places you want the safety.