[Tutorial] Add extra explanation for object reactivity

Is your feature request related to a problem? Please describe. There are users that are confused about how reactivity work with objects, to be more precise:

const childRef = obj.foo;
// The tutorial don't explicity says that if now 
// I modify childRef it will not create an invalidation of obj
childRef.bar = "new value"; // Users expect this to work, because
// obj.foo.bar = "new value"; // this updates as they expect, but childRef don't
// So the point its to let know new users that:
obj = obj;
// Will be needed in this case to update it, or work directly with the top level obj

Describe the solution you’d like Adding to the tutorial 02-reactivity/04-updating-arrays-and-objects a better explanation about this case would better inform new users.

The tutorial speaks about how array methods don’t create an invalidation, but this case can’t be understanded just with the explanation given.

The user @halfnelson said a rule for this case that would help new users:

[…] it can be tricky until you are used to it but the rule is broadly “the name of the reactive variable must appear on the left of the equals to react to assignments”

Describe alternatives you’ve considered An option would be to make derivated references also be reactive, but that calls for problems and I feel that just explaining to new users how it works its easier than changing the underlaying behaviour.

[Albermonte]

My bad then, it’s a little counter-intuitive seeing the code thinking it’s ok. Maybe a comment on the code saying that it’s not working would be helpful imo

[Conduitry]

Like anything where we track the identity of the objects ending up in different variables, this will open a huge can of worms. We’d never be able to catch all such situations, and it’s better to have a reasonable, well-defined goal than an impossible one that we gradually approach. We’d either have to declare that Svelte will always an unfixable bug, or we’d have to incrementally make small, subtle breaking changes.

In this case, if someone later did obj.foo = something_else; (or, even harder to detect, did obj[baz] = something_else; when baz === 'foo') would this result in updates to childRef no longer invalidating obj? What if the mutation of obj happened in code that wasn’t even part of this component? This is the sort of thing that we don’t even want to get into - and so we establish precise and very achievable rules for when reactivity happens.