9 ms·
> it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows
by agos 1y ago
> it is obviously an ES runtime thing, but it is simply weird to have to reason about objects being essentially the same but different—and if memoization allows me to not have to do it and, with some discipline, make it safe to assume that (() => true) is the same as (() => true), why pass on that opportunity?
it sucks both ways - the default is that stuff is different if it looks the same so you can't not do anything, but the only solution is both a lot of work and really easy to mess up completely. The TC39 Composites proposal[1] would be a great step in the right direction, but it will take years in the best scenario, there's really no guarantee that React will take advantage of it, and it still leaves out a lot of cases (Dates, to name one)
[1]: https://github.com/tc39/proposal-composites https://github.com/tc39/proposal-composites
- strogonoff 1y ago> the only solution is both a lot of work and really easy to mess up I think the other benefit is enough to justify the effort, though. Essentially, you don’t just make up objects, but instead you define each object’s constructor and all of its inputs. This makes it natural to keep logic contained and easy to shuffle things around when refactoring!