Create seperate atoms for each element in Array/Map

[TruePath]

Looking at the code for Observable Array/Map it seems like any addition/deletion/change to the whole object registers as a change to any reaction accessing any element of those objects. This seems unnecessary. Why not have one atom for the size/length property, another for non-existent keys (observed when a non-present key is looked up and changed by any new additions) and then a separate atom for each entry in the object (e.g. create a second shadow array/map whose values are the atoms for the associated elements). That way if one accesses myarray[5] during a reaction's data function and then modifies myarray[7] it doesn't trigger the reaction. Maybe something similar for set as well but I'm a bit worried that the equality used for equality in set membership isn't the same as that used for equality of object/map keys complicating atom lookup.

I'd consider adding it myself but the fact that it doesn't exist makes me worry that it's already been considered and rejected and I don't want to waste time implementing something that's already been checked to be worse.

[urugator]

I think the main reason is it's rarely needed in practice. Also IIRC there are worries about memory-leaks, because of the ability to subscribe for not yet existing keys/indices:
#2336 (comment)

EDIT: and yes there are surely performance concerns - since arrays can be quite large, managing hundreds of susbcriptions whenever you iterate the array won't be ideal I assume.

I don't want to waste time implementing something that's already been checked to be worse.

I don't think it would be accepted as a default observable array impl, but that only means you would have to instantiate such array yourself, for that specific use case, I don't see a problem in that. It doesn't even have to be part of mobx package, you don't need any internal API to implement it afaik.

[mweststrate]

It is discussed somewhere in the past, but it is indeed a perf trade off. It is important to realise that an atom per index is only valuable in some cases; e.g for an individual read in a reaction / observer, + an individual write at fixed position it will be beneficial. However looping over an array in a reaction would become a lot more expensive. And so would be operations like splice / shift / unshift etc; they would update not a single atom, but every atom in the array. If the performance is critical, and items live at stable indices, and you don't loop over the collection a lot you could consider using a Map with numeric indices instead :).