3 ms·
> I've been getting more and more scared of destructuring and ... copying recently Well, certainly it should be clear that `obj !== {...obj}`, and you have to
by nawgz 5y ago
> I've been getting more and more scared of destructuring and ... copying recently
Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly.
In reality though, assuming you are destructuring to pass it down a tree (and not around the app), this usually just means that you lose the optimizations of only rendering some part of the subtree and render your whole subtree more often, which is equivalent to using state management that isn't integrated into the scheduling engine very well, which is very common. So you're just going from a nicely performant app to standard fare.
I would recommend to always try to think in a singleton structure and use IDs and maps to the original objects over de- and re-constructing things you pass around as if they were the original
- eatonphil 5y ago> Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly Sure but that's not my issue. I'm saying that when you copy an object like you just did, the latter object looses its prototype. So any prototype methods I try to call on a copy/de structured object like that will crash in my app without a prior TypeScript warning. I want to be able to copy objects with a nice syntax but still have them retain their prototype. Since no one warns you (TypeScript anyway) about losing your prototype it makes me worry about this everywhere because who knows which objects weren't meant to lose their prototypes.
- mekkkkkk 5y agoDestructuring only really makes sense for simple struct-like data structures. If you are worrying about prototypes you are destructuring the wrong things. Duplicating class instances is almost always something that you'll need to do manually or through serialization in OOP afaik.
- eatonphil 5y agoAll I did was try to put some helper methods on data classes. :D But yeah clearly I'm going against the grain.
- nawgz 5y ago> > Well, certainly it should be clear that `obj !== {...obj}`, and you have to behave accordingly > Sure but that's not my issue I think you misunderstand what I'm saying. I know you know `obj !== {...obj}`, but it's important to understand exactly what that means, and one of those things to understand is > when you copy an object [via destructuring], the latter object looses its prototype For example, any class instance should most certainly not be used in that way, as it moves away from a true "object" paradigm (keys and values baby) into an inheritance paradigm, and as you observed inheritance is lost in destructuring. > TypeScript doesn't warn you I find this hard to believe. If you are passing TypeScript some interface T, and the object {...tInstance} doesn't have the keys of T, you should get an error. If you are passing TypeScript some class X, and you try to claim `typeof {...(xInstance)} === X` you would also surely see errors. Please link an example so I can understand what I mean, I would guess you didn't type the destination very stringently so the loss of the class type was unobserved