Yep, I think WeakMap suits this more but it's just a semantical change in this case, not a critical one. Theoretically, this implementation could cause issues with some Proxy based libraries (which do intercept Symbol get/set).
Generally, I like to use symbols like well-known symbols. When I create an internal feature that I want to expose to experienced devs (by exporting the symbol) but don't want to be accidentally overwritten (like a normal prop).
I hope this helps a bit.
PS: I use both Symbols and WeakMaps in a lib which I perf profile often and I found no real difference in performance (in Chrome and Node at least.)
Cool. Maybe I'll switch then.
It was fun to type this, with the "wrapped" functions having a literal number attached to them, but it's not like either the Symbol or the WeakMap will ever be exported.
On the other hand, I won't be able to tell if a function is "wrapped" by type tooltip any more or see its bytelength :/
Yep, I think WeakMap suits this more but it's just a semantical change in this case, not a critical one. Theoretically, this implementation could cause issues with some Proxy based libraries (which do intercept Symbol get/set).
Generally, I like to use symbols like well-known symbols. When I create an internal feature that I want to expose to experienced devs (by exporting the symbol) but don't want to be accidentally overwritten (like a normal prop).
I hope this helps a bit.
PS: I use both Symbols and WeakMaps in a lib which I perf profile often and I found no real difference in performance (in Chrome and Node at least.)
Cool. Maybe I'll switch then.
It was fun to type this, with the "wrapped" functions having a literal number attached to them, but it's not like either the
Symbolor theWeakMapwill ever be exported.On the other hand, I won't be able to tell if a function is "wrapped" by type tooltip any more or see its bytelength :/
That's true. I only use TypeScript when I must so I tend to not think about typings.